van egy állandó mítosz az SQL Server világában, hogy mind a DROP TABLE and TRUNCATE TABLE a parancsok nem naplózottak.
ők nem. Mindkettő teljesen naplózott, de hatékonyan naplózott.
ezt könnyen bizonyíthatja magának., Futtassa a következő kódot kell beállítani a teszt adatbázis tábla, valamint azt mutatják, hogy a 10,000 sor a táblázatot:
Eredmények:
—-
10000
aztán a következő kódot, mely csonkolni fogja a táblázat egy ügylet, valamint ellenőrzi a sor szám:
BEGIN TRAN;GOTRUNCATE TABLE ;GO SELECT COUNT (*) AS N'RowCount'FROM ;GO
Eredmények:
—-
0
a táblázat üres., De én roll vissza a művelet minden adatot újra:
ROLLBACK TRAN;GO SELECT COUNT (*) AS N'RowCount'FROM ;GO
Eredmények:
—-
10000
Egyértelmű, hogy a TRUNCATE művelet, be kell jelentkezned, különben a visszagörgetés működés nem fog működni.
tehát honnan származik a tévhit?
aDROP ésTRUNCATE nagy táblákon végzett műveletek viselkedéséből származik., Szinte azonnal befejeződnek, és ha a fn_dblog használatával nézed meg a tranzakciós naplót, akkor csak egy kis számú naplórekord jelenik meg a műveletből. Ez a kis szám nem korrelál a csonkolt vagy ledobott táblázat méretével, így úgy tűnik, mintha DROPés TRUNCATE a műveletek nem naplózottak.
de teljesen naplózva vannak, amint azt fentebb bemutattam. Szóval hol vannak a naplórekordok a műveletekhez?,
a válasz az, hogy a naplórekordokat csak nem azonnal hozza létre egy “halasztott csepp” nevű mechanizmus, amelyet az SQL Server 2000 SP3-ban adtak hozzá.
amikor egy táblát leejtenek vagy csonkolnak, a táblázathoz rendelt összes adatfájl oldalt el kell különíteni.,uire kizárólagos elosztási zár mértékig
Szonda az oldal zár minden oldal a mértékben (megszerezzék a zár kizárólagos módban, azonnal dobd el, ügyelve arra, hogy senki másnak az oldal zárva)
NE engedje el a mértékben zár, garantálja, hogy senki más nem használhatja, hogy milyen mértékben
ugrás a következő mértékben
Vége
Mint minden olyan mértékben, zárak tartottak, amíg a végén a művelet, minden zárat kell egy kis mennyiségű memória, volt lehetséges, hogy a lock manager, hogy elfogy a memória, amikor egy DROP vagy TRUNCATE egy nagyon nagy asztal történt., Néhány SQL Server ügyfelek kezdett, hogy megtalálja futottak ki-a-memória feltételek az SQL Server 2000, táblázatokat nőtt nagyon nagy jelentősen meghaladta a növekedés a rendszer memória.
a halasztott ejtési mechanizmus szimulálja a DROPvagy TRUNCATE műveletet, azonnal befejezve, a táblázat allokációinak kikapcsolásával és a “halasztott ejtési sorba” helyezésével, későbbi feldolgozásra háttérfeladattal. Ez az unhook-and-transfer művelet csak néhány naplórekordot generál., Ez az a művelet, amelyet a fenti kódpéldában hajtanak végre.
a ‘halasztott-drop háttérfeladat’ néhány másodpercenként felpörög, és kis tételekben deallocálja a halasztott-drop sorban lévő összes oldalt és kiterjesztést, garantálva, hogy a művelet nem fogy ki a memóriából. Ezek a kijelölések mind teljesen naplózva vannak, de ne feledje, hogy az adatokkal vagy indexrekordokkal teli oldal áthelyezése nem naplózza az egyes rekordok törlését; ehelyett az egész oldalt csak a megfelelő PFS (Page Free Space) hozzárendelési bájttérképen jelöli.,
Az SQL Server 2000 SP3-tól kezdve, amikor egy DROP vagy TRUNCATE táblázatot hajt végre, csak néhány naplórekordot fog generálni. Ha vár egy percet, majd újra megnézi a tranzakciós naplót, látni fogja, hogy több ezer naplórekordot generált a halasztott csepp művelet, mindegyik oldal vagy méret deallocating. A művelet teljes mértékben és hatékonyan naplózva.,
Itt egy példa segítségével a forgatókönyv hoztuk létre felett:
CHECKPOINT;GOTRUNCATE TABLE ;GOSELECT COUNT (*) AS N'LogRecCount'FROM fn_dblog (NULL, NULL);GO
Eredmények:
—-
25
Mint látható, ott egyértelmű, hogy nem naplóban deallocating a 10.000 oldal, plusz 1,250 mértékben a TestTable táblázat.
ha várok néhány másodpercet, majd futtassam újra a fn_dblog kódot, megkapom:
—-
3811
lehet, hogy csodálkozol, hogy miért nincs legalább 10 000 naplórekord – egy minden egyes oldal kiosztásához., Ez azért van, mert az oldal deallocations még naplózott hatékonyan – egy log record tükröző PFS oldalallokáció változások 8 egymást követő adatfájl oldalak, ahelyett, hogy egy log rekord minden adatfájl oldal tükrözi a kiosztási állapota változik a PFS oldal.
az SQL Server mindig a lehető legkevesebb tranzakciónaplót próbálja előállítani, miközben továbbra is betartja a teljes vagy minimális naplózásra vonatkozó szabályokat az aktuális helyreállítási modell alapján., Ha meg szeretné nézni az unhook-and-transfer and halasztott-drop mechanizmusok által generált tényleges naplórekordokat, egyszerűen cserélje ki a * számot ( * ) a fenti fn_dblog kódban, és keressen egy tranzakciót a DeferredAllocUnitDrop::Processtranzakciós névvel.
a jövőbeli hozzászólásokban megvitatom azokat a belső tényezőket, amelyek alátámasztják az SQL Server Storage Engine teljesítmény-aspektusait.
Vélemény, hozzászólás?