A zárak elmozdulása
Egy kis elmélet
Általános szabályként a DBMS adatkezelése hierarchiája. Például: "fájl-> adatbázis-> tábla-> adatlap-> bejegyzés-> mező a rekordban". A hierarchia egyes szintjei átrendezhetők vagy tisztán virtuálisak, vagy akár teljesen hiányozhatnak is. Mindez a konkrét végrehajtás és az alkalmazott terminológia sajátosságaitól függ, és ebben az esetben nem sokat számít, csak akkor fontos, hogy egy ilyen formában, vagyis egy ilyen hierarchia szinte mindig jelen van. A hierarchikus zárolás (multigranularitási zárolás) mechanizmusát végrehajtó DBMS-ben, amely lehetővé teszi a tranzakciók párhuzamos feldolgozását, a hierarchiának bármely szintjén található objektumra zárhat. Ebben az esetben a megfelelő objektumok az alsó szinteken automatikusan blokkolódnak. Például egy exkluzív zárolás az adatlapon, blokkolja az ezen az oldalon szereplő összes bejegyzést. De ugyanakkor természetesen a szomszédos oldalak feljegyzései sem akadályozzák meg. Általában a "granularitás" kifejezést használják a blokkolandó adatok mennyiségének jelzésére. A nagyobb szemcsésség azt jelenti, hogy az objektumot a hierarchia magasabb szintjén, és ennek megfelelően minden olyan objektumban blokkolják, amely kevésbé szemcsés.
Most tulajdonképpen a vita tárgyát képeztük. A zárak elmozdulása olyan folyamat, amelyben a sok apró szemcseméretű zárak nagyobb zártságú magasabb szintű hierarchiában vannak.
Miért van ez szükség
Sőt, első pillantásra nem szükséges. Az intuitív gondolkodásmód a következő: A hierarchia magasabb szintjén történő blokkolás alacsonyabb szintű objektumok blokkolását okozza, beleértve azokat is, amelyek általában nem szükségesek blokkolni. Ez pedig a tranzakciós konkurencia mértékének csökkenéséhez és végső soron a termelékenység csökkenéséhez vezet. De valójában a hatás fordított. Ha egy kicsit mélyebbre ássz, kiderül, hogy bizonyos esetekben előnyösebb az olyan objektumok blokkolása, amelyeknek nagyobb a sűrűsége.
Hagyományosan három effektet azonosítanak a zárak beiktatásával, amelyek bizonyos esetekben előnyösebbek a fent említett hierarchia magasabb szintjén történő blokkoláshoz.
A fej fölötti lezárás. Nem számít, hogy milyen gyorsan vagy egymásra és levenni, és hány lenne kevés helyet nem foglalkoztak zár, még mindig jönni az az idő, amikor jobban megéri szabhat zár nagyobb részletességgel, mint néhány (vagy néhány ezer) kisebb. A szükségtelen objektumok blokkolásával járó költségek ellenére.
Adatotvitelt. Egy zár átfedése atomos akció, azonban több zárolás átfedése még nem létezik. Az egyik tranzakcióban lévő két zárolás átfedése között a kiszolgáló maximális hatékonysági megfontolásokkal vezérelve egy vagy akár több más tranzakciót teljes egészében végrehajthat. De ha az első tranzakció viszonylag hosszú ideig tart, és sok kis zárat késztet, akkor kellemetlen mellékhatások jelentkezhetnek. Tegyük fel, hogy van egy hosszú T1 tranzakció, amely sok rekordot blokkol. Valamikor megindult, és megkezdte a zárakat. Amikor a T1 sikerült több tárgyat elfoglalni, a Tx tranzakciók elkezdenek végrehajtani, ami viszont megakadályozza a T1 hamarosan szükséges rekordokat, de a T1 még nem érte el azokat. Ennek eredményeként a T1 kénytelen várni, amíg a tranzakció Tx fog működni, amíg ő vár egyik Tx, ezek a tranzakciók (izgalmas rekordot, amely T1 nem volt ideje, hogy elérje) lehet még. Így a T1 elvégzéséhez szükséges idő jelentősen megnövekedett. A helyzetet súlyosbítja az a tény, hogy a rajt után a T1 tűnhet Ty tranzakciók szüksége a tárgyakat, hogy T1 sikerült megragadni, és az átfutási idő T1 növekszik, növekszik és a várakozási idő Ty ügylet T1 blokkolt oldalakat.
Erőforrás állítás. A zárak - az egyszerű térfogat mellett - karbantartáshoz is szükségesek, amelyek a rendszer erőforrásainak felhasználását igénylik. Például a tranzakció várakozó gráfjának rendszeres ellenőrzése a holtpont jelenléte miatt, a foglalkozás meglehetősen drága. És minél több zár, annál több forrást fordítanak az ilyen ellenőrzésekre. Ezenkívül egyszerűen korlátozza a tranzakciók számát, amelyek a rendszeren egyidejűleg végrehajthatók, anélkül, hogy feláldoznák a teljesítményt. Egy bizonyos ponton sok egyidejű tranzakció konvergál a CPU-idő és más rendszererőforrások küzdelmében. Mindez ismét a válaszidő növeléséhez és a teljesítmény általános csökkenéséhez vezet.
Így ezek hatása három tényező vezet az a tény, hogy bizonyos esetekben, ha a szám a zár a rendszer nagy és meglehetősen hosszú tranzakciók, teljesítmény szempontjából előnyös, hogy blokkolja a webhelyeket részletesség. Csökkenti az összes zár csökkentett runtime hosszú tranzakciókat, és ennek következtében a rövid, ami nem kell sokáig várni, kevesebbet fogyaszt a rendszer erőforrásait. Az 1. ábra a teljesítményminőség-ütemterveket és a zárak szemcsézettségét mutatja rövid és hosszú tranzakciókra.
1. ábra. Teljesítmény grafikonok a zárolások rövid és hosszú tranzakciói miatt.
A legfontosabb probléma annak meghatározása, hogy az ügylet melyik pontból "elég hosszúnak" számít. Sajnos nem mindig lehet meghatározni a zárolási átfedési stratégiát fordítási idő alatt, ezért néha dinamikusan növelni kell a granuláris növekedést a lekérdezés végrehajtása során.
Gyakorlati végrehajtás
A zárak fokozódásának mechanizmusának gyakorlati megvalósítása érdekében hozhatja a Microsoft SQL Server rendszert. Ebben az esetben az érdeklődő objektumok hierarchiája a következő: "táblázat-> adatlap-> rekord".
2. ábra: Objektumok hierarchiája az MSSQL-ben
Alapértelmezés szerint ha nem zavarja a kiszolgáló logikáját, akkor megpróbál írni egy írási zárolást, vagyis egy olyan zárat, amely a legalacsonyabb granularitással rendelkezik. De ha a szerver úgy dönt, hogy az egyedi rekord szintjén található blokkolás nem a legoptimálisabb megoldás, akkor nagyobb mennyiséget blokkol. Azonban határozottan megadhatja, hogy mely granuláris elemek blokkolhatók legyenek, speciális utalásokat használva az optimalizálóhoz (tippek).
- ROWLOCK - írásszintű lezárás.
- PGLOCK - blokkolás az adatlap szintjén.
- TABLOCK - zár az asztal szintjén.
Ha az indexek beépülnek a táblába, akkor a lekérdezés részletességének kifejezett megjelölése nélkül is megteheti. Egy speciális rendszerszintű tárolt eljárás használatával, az sp_indexoption, megadhatja az indexzár nagyszerűségét. Így az indexben található táblázatban szereplő összes minta a megadott hierarchiaszinthez vezet, anélkül, hogy kifejezett utasításokat tartalmazna.
Azoknál a lekérdezéseknél, amelyek nem használnak indexeket, a sp_indxoption beállítások nem működnek. De ha van egy fürtözött index a táblázatban, és ebben az esetben az adatlapok az index részei, akkor a fürtözött indexhez megadott granularitást használjuk az indexek nélkül futó lekérdezésekhez.
De nagyjából ezek a szemcsés beállítások csak egy irányban működnek. Megkéri a kiszolgálót, hogy blokkolja csak az írási szintet, de ha úgy tűnik, hogy túl kicsi a lekérdezés végrehajtásakor, akkor is megnöveli a zárat. De ha megadja, hogy zárolást szeretne az oldal szintjén, akkor rekord szinten a zár nem lesz, de csak az oldal vagy az asztal szintjén. Ha asztalzárat szeretne megadni, ezt kifejezetten megadva vagy az indexbeállítások segítségével, akkor az egész tábla mindig le lesz tiltva, és soha nem lesz egyetlen bejegyzés vagy oldal.
Mint már említettük, a szerver növelheti zárolási során közvetlenül a megkeresés, a eszkalációja mindig történik arra a szintre, az asztalra, akkor is, ha a zár egyes rekordok előtt. SQL Server megállapítja, hogy szükség van egy eszkalációja a következő okok miatt: Ha a szám a zárak kivetett egyszeri ügylet meghaladja az 1250, illetve a több zár egyetlen index vagy asztalra több mint 765, és ha a több mint negyven százaléka a rendelkezésre álló memóriát a kiszolgáló blokkolására, akkor a szerver kiválasztja a legmegfelelőbb asztal és megpróbálja kiszabadítani a zárakat asztalszintre. Meghibásodás esetén, ha néhány, a bejegyzés a tábla miatt kiszabott összeegyeztethetetlen blokkoló egyéb ügyletek, a kiszolgáló nem vár, és továbbra is működik ugyanazon a szinten tagoltságát a következő kísérletet. Így a holtpont lehetősége közvetlenül megszűnik az eszkalációs hiba révén.
Nem nehéz észrevenni, hogy a zárak fokozódása miatt soha nem lehet biztos abban, hogy a szerver blokkolja a tárgyakat. Ezért soha nem szabad hagyatkozni rá.
Bár kétféleképpen lehet megakadályozni az eszkalációt:
Az első út, "szinte hacker". Ha azt szeretnénk, hogy a zárolások egy bizonyos asztalon ne történjenek, akkor a következő lekérdezést külön tranzakcióban kell végrehajtanunk, de a tranzakciót az alkalmazás bezárásával együtt kell végrehajtanunk.
Ilyen, első pillantásra értelmetlen lekérdezés, az IX-es zárat az asztalra kényszeríti. Ez a zár nem kompatibilis sem az S, sem az U, sem pedig különösen az X zárakkal. Így az asztalra való zárás képtelensége miatt az eszkaláció nem fog továbbhaladni. Azonban az egyéb kérések, amelyeknél kisebb a szemcsézettség, általában problémamentes lesz. Az egyetlen mellékhatás az, hogy az egész asztalra még akkor sem lehet kifejezetten zárolni.
A második út, "hivatalos". Az is lehetséges, anélkül, hogy egy trükkös megoldásokat letiltja a eszkalációs általában nem is egy külön adatbázisban, és teljes egészében egyetlen esetben (például) az SQL Server”. Erre a célra egy speciális trace flag - 1211. végrehajtása DBCC TRACEON parancs (1211), tiltja az eszkaláció egy külön példányt egy jó hosszú ideig, amíg a következő parancsot DBCC TRACEOFF (1211).
De annak ellenére, hogy a lehetőségét, féllegális és jól dokumentált módon, hogy megtiltsák a eszkalációja zárak, én tényleg nem ajánlom, hogy erre. Az eszkaláció egy jól megalapozott belső szervermechanizmus, amely nagy terhelés mellett is maximális teljesítményt nyújt. És nem kívánatos, hogy a kezed nélkül másképp emeljék fel ezt a mechanizmust.
Azt is megpróbálja megtörni a hosszú tranzakciót a sok kicsi, ami általában mindig hasznos, még akkor is, ha nem veszi figyelembe a emelkedésére, mint a legtöbb esetben ez csak a javára a szerver. És általában, az optimálisabb írásbeli tranzakciók és kérések, annál kevésbé a zárak fokozódásának kockázata. De ismét, soha nem lehetek biztosak abban, hogy az eszkaláció nem fog megtörténni. Másrészt, mint általában, zár eszkaláció egy figyelmeztető csengő, hogy az alkalmazás egy szűk, és jó lenne átírni optimális.
Ha bármilyen esetben meg kell bizonyosodni arról, hogy blokkolva lesz csak egy tárgy, vagy szükséges, hogy blokkolja az absztrakt tárgyak, mint például a „dokumentum”, hogy léteznek a felhasználóhoz zár, amely a munka egy pár rendszer tárolt eljárásokat, sp_getapplock és sp_releaseapplock. Ezekkel az eljárásokkal a kiszolgáló harmadik féltől származó alkalmazások számára lehetővé teszi a kiszolgálózárkezelő számára az igényeiknek megfelelő használatát. Végre kell hajtani a megfelelő zárszerkezet - foglalkoztatás zavaró, és ennek eredményeként a eszkalációja, ígérő.
Hasznos linkek
Használt szakirodalom
[1] Az adatbázis rendszerek közötti összeférhetetlenség ellenőrzése és helyreállítása. Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman.