|
Ha az adatokat nem védenénk zárolással, a konkurens hozzáférések miatt többféle problémánk is adódna.
Elveszett frissítés (lost update)
Ez a probléma akkor jelentkezik, amikor két vagy több tranzakció ugyanazt a sort olvassa el, majd egyszerre módosítják azt. Mivel az egyes tranzakciók egymásra nincsenek tekintettel, a legkésőbb megszólaló tranzakció felülírja a többiek módosítását, így adatot vesztünk. Például két szerkesztő egyszerre dolgozik ugyanazon a cikken. Mindkettő módosításokat hajt végre, majd elmentik. Aki később ment, az felülírja az előző mentést, vagyis az egyik szerkesztő munkája elvész.
Dirty read
A dirty read annyit jelent, hogy miközben az egyik tranzakció módosít egy rekordot, a másik tranzakció közben ezt elolvashatja. Például egy szerkesztő megkapja a cikket, és belejavít. Javában dolgozik még, amikor egy másik szerkesztő lemásolja a dokumentumot, és szétküldi az érdekelteknek, vagy esetleg leküldi a nyomdába. Az első szerkesztő tovább folytatja a munkát, és további javításokat eszközöl, esetleg saját korábbi kiegészítéseiből töröl, stb. A munka végeztével elmenti a dokumentumot. A közzétett cikk így hamis információkat tartalmazhat. Jobb lett volna, ha a második folyamat (közzététel) megvárja az első (szerkesztés) végét.
Nonrepeatable read
Egy szerkesztő kétszer is elolvassa a cikket, a két olvasás közben azonban a cikk írója módosít rajta. A második olvasáskor a szerkesztő már egy teljesen átszabott cikket lát, ami félreértésekhez vezet.
Phantom
A szerkesztő lemásolja a cikket, és elviszi, hogy belejavítson. Eközben valaki módosítja a cikket, mondjuk a szerzője hozzáír még pár sort. A szerkesztő később visszatér, hogy átvezesse a módosításait, és a cikkben talál néhány új sort, ami összezavarhatja. Ha most elmegy, hogy majd később foglalkozik a problémával, az írónak van lehetősége 'visszagörgetni' az előző műveletét, és a szerkesztő számára tényleg fantom lesz a feltűnő majd ismét eltűnő néhány sor.
Az SQL Server különböző egységeket képes zárolni. Hogy a zárolás minél kisebb költségű legyen, az SQL Server automatikusan eldönti, hogy melyik művelethez milyen egységet kell zárolni. Minél kisebb egységeket zárolunk (például sorokat), annál nagyobb lehetőség van konkurens feldolgozásra, viszont a sok zár kezelése erőforrásokat foglal le. Ha egy egész táblát zárolunk, az adminisztráció gyors és egyszerű, hiszen egyetlen zárat kell kezelni, de a táblát egy másik tranzakció már nem tudja elérni.
Az SQL Server a következő egységeket tudja zárolni.
RID Sor azonosító, vagyis az SQL Server sor szintű zárolást képes megvalósítani. A tranzakció alatt kizárólag az érintett sor kerül zár alá. A tábla összes többi sora elérhető a többi tranzakció számára.
Kulcs (Key) Sor szintű zárolás az index állományokban.
Lap (Page) Egy 8 KB-os egység zárolódik.
Extent 8 lap egyszerre zárolódik.
Tábla Zárolhatunk egyszerre egy egész táblát is. Ekkor a táblához tartozó indexek is zárolódnak.
Adatbázis Az egész adatbázis zár alá helyezhető.
A zárolás módja az egyes esetekben más és más lehet. A következő módok vannak:
Shared(S) Azon műveletek esetében kerül shared lock az adatokra, amelyek csak olvassák azokat. (SELECT). Amíg az egyik tranzakció olvas egy ilyen sort, más tranzakciók nem módosíthatják, nem törölhetik, de ők is elolvashatják. A zár az olvasás befejeztével azonnal lekerül az adatról, hacsak a tranzakció izolációs szintje nem repeatable read vagy magasabb szintű. Ekkor a zár a tranzakció végéig megmarad.
Update (U) Azokra az egységekre kerül update lock, amiket valószínűleg módosítani fogunk. Ezzel elkerülhető, hogy egyidejű módosításkor holtpont (deadlock) alakuljon ki. Egy tipikus módosítás a következő minta szerint zajlik. A tranzakció elolvassa a rekordot, az olvasáskor shared (S) lock kerül az egységre (sorra vagy lapra), ezután módosítja a rekordot, ehhez viszont a shared lockot exclusive (X) lockra kell konvertálni. Ha két tranzakció tesz shared lockot az egységre, majd mindkét tranzakció módosítani szeretne, az először módosítani szándékozó tranzakció megpróbál majd exclusive lockot feltenni. De a lock konverzióval várnia kell, mert az exclusive lock nem kompatibilis egy másik tranzakció shared lockjával. A első tranzakció várakozni kényszerül, amíg a második tranzakció le nem veszi a shared lockját (lock wait). Most a második tranzakció is módosítani szeretne, és exclusive lockkal próbálkozik. A konverzióval neki is várakoznia kell, és máris kialakul a holtpont, kölcsönös egymásra várakozás van. Az ilyen típusú holtpont elkerülésére szolgál az update lock. Update lockot egyszerre csak egy tranzakció tehet az egységre. Ha aztán sor kerül a tényleges módosításra, az update lock exclusive lockká konvertálódik. Ha mégsem módosítunk, shared lock lesz belőle.
Exclusive (X) Az UPDATE, DELETE és INSERT utasítások használják. Használatával biztosítható, hogy több tranzakció nem tud egy erőforrást egyszerre módosítani. Amíg egy egységen exclusive lock van, más tranzakciók sem módosítani, sem olvasni nem tudják.
Intent Az intent lock jelzi, hogy az SQL Server a későbbiek folyamán shared vagy exclusive lockot szeretne elhelyezni valahol a hierarchia alsóbb szintjén. Például egy shared intent lock a táblán azt jelenti, hogy a tranzakció szeretne shared lockot használni a tábla sorain és lapjain. A tábla szintű intent lock más tranzakciókat megakadályozhat abban, hogy exclusive lockot tegyenek a tábla valamelyik lapjára. Így nő az SQL Server teljesítménye, hiszen csak meg kell nézni a táblán az intent lockot, és máris el lehet dönteni, hogy zárolható-e az a tábla. Ha ez a jelzés nem lenne rajta, a táblát zárolni kívánó tranzakciónak végig kellene nézni a tábla minden egyes sorát, hogy meggyőződhessen róla, vajon zárolható-e az egész tábla. Háromféle intent lock van, intent shared (IS), intent exclusive (IX) és shared with intent exclusive (SIX).
Schema M típusú schema lock (Sch-M) akkor kerül egy táblára, ha azon DDL (data definition language) műveletet hajtunk végre, például új oszlopokat adunk hozzá. S típusú schema lockot (Sch-S) akkor használ az SQL Server, ha éppen lekérdezést fordít. Ez a többi lockot nem befolyásolja, éppen ezért amikor az SQL Server lekérdezést fordít, minden tranzakció tetszés szerint futhat, ugyanakkor az érintett táblákon DDL műveletek nem végezhetők.
Ha egy egységen már van valamilyen zár, akkor csak egy azzal kompatibilis másik zár kerülhet rá. Például ha egy soron exclusive lock van, semmilyen más zárolás nem alkalmazható erre sorra, mert az exclusive lock nem kompatibilis a többi lock típussal. Vagy egy másik példa: ha egy soron shared lock van, egy másik tranzakció kérhet rá shared vagy akár update lockot is attól függetlenül, hogy az első tranzakció még nem zajlott le. Exclusive lock azonban csak akkor kérhető, ha az adott egységen már nincs több shared lock. Az egyes zárolási típusok kompatibilitását a következő táblázat foglalja össze.
Existing granted mode
Requested mode IS S U IX SIX X
Intent shared (IS) Yes Yes Yes Yes Yes No
Shared (S) Yes Yes Yes No No No
Update (U) Yes Yes No No No No
Intent exclusive (IX) Yes No No Yes No No
Shared with intent
exclusive (SIX) Yes No No No No No
Exclusive (X) No No No No No No
Az Sch-S mindenkivel kompatibilis, kivétel az Sch-M, az Sch-M pedig senkivel nem kompatibilis.
Ha kíváncsiak vagyunk a rendszerben levő aktív zárolásokra, az sp_lock nevű rendszer szintű tárolt eljárást kell használnunk. Persze ha a szerverünk éppen terhelés alatt van, nem célravezető éppen így monitorozni, mert a zárak gyorsabban fel- és lekerülnek, mint az sp_lock megjeleníti azt a képernyőn. Ekkor célszerű az SQL Server Profilert, vagy az NT Performance Monitorát használni.
A példaprogramban megnyitjuk a pubs adatbázis authors tábláját két példányban. Kezdjük el szerkeszteni az egyik tábla egyik rekordját, és próbáljuk meg szerkeszteni ugyanazt a rekordot a másik táblában.
|