Tömeges zár az IS munkájában (1. rész)
A zárolások konfliktusa - talán a legelterjedtebb és egyúttal nehéz probléma az adatbázisban. Ha például a nem optimális kód felgyorsításához egyszerűen fel kell építeni a hardver "izmokat"
Konfliktusok zárak - talán a leggyakoribb, és ugyanabban az időben, slozhnoreshaemaya problémát, ha dolgozik az adatbázisban. Ha például, hogy gyorsítsa fel az optimálisnál kódot, akkor csak építeni a hardver „izom”, és felejtsd el a probléma, és zárja le ez a trükk nem fog működni: ott szinte meggondolatlan döntéseket nem engedik visszatér, hogy orvosolja a helyzetet meg kell fordítania a fejét, és keresse meg a probléma gyökerét. Ebben a cikkben fogjuk elemezni, csak a legnépszerűbb „gyökerekhez”, ahol gyakran kell szembenézniük, lebegő kibontakozása esetekben a felhasználók.
Ne feledje, hogy a saját maguk által történő blokkolás semmiképpen nem összeegyeztethetetlen gonosz, amelyet minden lehetséges módon meg kell küzdeni. Ellenkezőleg, az erőforrások blokkolása rendkívül fontos mechanizmus a többfelhasználós rendszer számára, amely biztosítja a feldolgozandó adatok következetességét és integritását. A felhasználó által megszabott zár azt biztosítja, hogy a szükséges adatokat ne változtassa meg egy másik tranzakció, ami azt jelenti, hogy a felhasználó megkapja a művelet várt eredményét. De amikor az ügyletek elkezdik megakadályozni a felesleges erőforrásokat, amelyek nem szükségesek az aktuális feladathoz, a problémák elkezdődnek, a felhasználók letilják, a munka hatékonysága élesen csökken. Ilyen problémákkal küzdenek.
Mielőtt elkezdenénk a problémák elemzését, pár fontos pontot tárgyalunk:
Először. Nem lesz leírása az olvasás klasszikus tárgyirodalmáról, a velük való foglalkozás módjáról; a tranzakció elkülönítési szintjei enyhén tekintendők. A fentiek mindegyike - meglehetősen általános elmélet, amelyet az olvasó már biztosan tud. Szükség esetén frissítheti a tudást ugyanabban az MSDN-ben (Tranzakcióelkülönítési szint), és ebben a cikkben, a gyakorlatra orientálva hosszas elméleti kitérés nyilvánvalóan felesleges.
Régen, a távoli, távoli ...
Nyilvánvaló, hogy több mint 20 felhasználó letiltja a blokkolást, és várakozik a felhasználó 449-es tranzakciójának vége felé. Az MSDN-ben a "várakozási típus" felkutatása arra kéri, hogy mindezen felhasználók valamit felírjanak az asztalra; Az erőforrás leírása ("TAB") azt jelzi, hogy nem egy kis terület blokkolt, hanem egy teljes tábla.
Egy kis vizsgálat azt mutatja, hogy leggyakrabban a zárolások jelennek meg a táblán _1SJOURN - egyetlen dokumentumnap 1C 7.7-ben. Ez a táblázat tárolja a programban írt összes dokumentum dátumát, számát és azonosítóját. A probléma az, hogy minden dokumentum exkluzív zárja az egész asztalon. Ez így van: még akkor is, ha a felhasználók különböző típusú dokumentumokat vezetnek, egyszerre csak egy dokumentum rögzíthető. Nagy bejövő dokumentumáramlás esetén (például nagyszámú alkalmazás kisboltban) ez a viselkedés komoly problémává válik.
. Néha visszajönnek
Fa blokkolja a gyanús mutatja ismerős képet: vár kizárólagos zár (LCK_M_IX), ahol az egész táblát (TAB) le van zárva. Nos, legalább egy különálló dokumentum táblája, nem egyetlen magazin - és ez jó! Mi még 1C "lusta"? Valójában a fejlesztõ hibája nincs itt. 1C 8.x a kérésüket nem ró tábla zárolások (kivéve, ha dolgozik az ideiglenes táblák -, de vannak táblák „élő” kizárólag az adott ülés, és így nem kellene megosztani senkivel, így nyugodtan blokkolni az egészet - senki nem fog sérülni. Ebben a helyzetben mélyebb mechanizmusok jönnek létre - nevezetesen a zárolások MS-SQL szintre való emelkedése.
Minden zár maga egy olyan objektum, amelynek szervizelése CPU-időt és RAM-ot igényel. Igen, persze, hogy egy modern szerver léptéke egy legfeljebb egy hatalmas hangár méhekénél észrevehető. De amikor az ilyen méhek egy egészet kapnak ... Körülbelül úgy, hogy a DBMS indokolja, becsülve az asztalra kirótt zárak számát. Kezdetben, ha az alkalmazás nem ad ki kifejezett utasításokat (és 1C nem ad ilyen utasításokat!), Akkor a rögzítési szint vagy az adatlap "Pont" zárolása felkerül az asztalra. De amikor a DBMS nagyszámú zárat lát ugyanazon az asztalon, ugyanabból a tranzakcióból, vagy ha hiányzik a szabad RAM a rendszerben, akkor döntést hoznak: a kis számú kis zár helyett csak egy, de egy nagyat kell elhelyezni. Ennek eredményeképpen csökken a hardver erőforrások terhelése, de a táblázatban lévő olyan sorok is, amelyek a tranzakcióban egyáltalán nem szükségesek. A felhasználók gyakrabban ütköznek egymásnak az azonos táblázatokért folytatott verseny miatt, de az erőforrások gazdaságosabbak.
Mielőtt megbirkózol a zárak eszkalációival, akkor teljesen érthető lesz, mert mindegyikük felmerül. Talán a program túl hosszú tranzakciókat használ, az adatokat nagy csomagokban változtatja. Vagy, valójában, a rendszer egyszerűen nincs elég szabad RAM-ja. Ilyen esetekben az okot, nem pedig a következményt kell kezelni - mindegyik helyzetet tele van más problémákkal, a zárak fokozódása nem a legszörnyűbb.
Visszatérve az 1C-re, nem szabad megfeledkezni arról, hogy a táblázatok közvetlenül az adatbázisban történő manipulálása (változó opciók, indexek hozzáadása stb.) A konfigurátor nem emlékszik, és felülírható a következő szerkezetátalakítással. Tehát érdemes olyan szkriptet készíteni, amely nem teszi lehetővé az escalációt a szükséges táblázatokon, és végrehajtja a konfiguráció frissítése után. Szerencsére az eszkaláció letiltásának nagyon mûködése egy másodperc törtrészét veszi igénybe.
Másrészről nincsenek "helyes" megoldások az adatbázis-adminisztrációban, amelyek mindenütt és bármikor alkalmazhatók. Ha a felhasználók ritkán találkoznak tábla zárolások, uralja rövid tranzakciók vagy adatbázis még nem nőtt a hangerő, ha a eszkalációja lesz a probléma, húzza ki a eszkaláció nem segít felgyorsítani a felhasználói élményt, hanem éppen ellenkezőleg, vezet túlzott fogyasztása források. Mint mindig a DB adminisztrációban - bármely eszközt csak akkor szabad használni, ha vannak kifejezett utalások és a következmények világos megértése.
A megadott illusztrációkat a PerfExpert monitoring rendszer segítségével kapjuk meg