Tam je přetrvávající mýtus v SQL Server svět, že obě DROP TABLE TRUNCATE TABLE příkazy jsou non-přihlášen.
nejsou. Oba jsou plně přihlášeni, ale efektivně přihlášeni.
můžete to snadno dokázat sami., Spusťte následující kód k nastavení testovací databáze a tabulky, a ukázat, máme 10 000 řádky v naší tabulce:
Výsledky:
—-
10000
A potom následující kód, který zkrátí tabulka v rámci transakce a kontroluje počet řádků:
BEGIN TRAN;GOTRUNCATE TABLE ;GO SELECT COUNT (*) AS N'RowCount'FROM ;GO
Výsledky:
—-
0
stolek je prázdný., Ale mohu vrátit transakce a dát všechny údaje znovu:
ROLLBACK TRAN;GO SELECT COUNT (*) AS N'RowCount'FROM ;GO
Výsledky:
—-
10000
Jasně TRUNCATE operace musí být zaznamenána jinak vrátit zpět operace nebude fungovat.
odkud pochází mylná představa?
pochází z chováníDROP aTRUNCATE operace na velkých tabulkách., Budou kompletní téměř okamžitě, a když se podíváte do protokolu transakcí pomocí fn_dblog hned potom, uvidíte pouze malý počet záznamů protokolu generované z provozu. To malé číslo nemusí korelovat s velikostí stolu jsou zkráceny nebo vynechány, takže se zdá, jako kdyby DROP TRUNCATE operace nejsou protokolovány.
ale jsou plně zaznamenány, jak jsem ukázal výše. Takže kde jsou záznamy záznamů pro operace?,
odpověď je, že záznamy protokolu budou vytvořeny, jen ne okamžitě, mechanismem nazvaným „odložený pokles“, který byl přidán do SQL Server 2000 SP3.
když je tabulka vynechána nebo zkrácena, musí být všechny stránky datových souborů přidělené pro tabulku přiděleny.,nevyžaduje výhradní přidělování zámek na rozsah
Sonda stránky zámek pro každou stránku v rozsahu (získat zámek v exkluzivním režimu, a okamžitě to zahoď, ujistěte se, nikdo jiný se na stránce zamčené)
neuvolňují míry zámek, což zaručuje, že nikdo jiný nemůže použít v tomto rozsahu.
Přesunout na další míry,
End
stejně Jako všechny míry zámky konaly až do konce provozu, a každý zámek má malé množství paměti, je možné, že se zámek správce spustit z paměti, když DROP nebo TRUNCATE velmi velké tabulky došlo., Někteří zákazníci serveru SQL Server začali zjišťovat, že na serveru SQL Server 2000 narazili na podmínky mimo paměť, protože tabulky rostly velmi velké a výrazně překonaly růst systémové paměti.
odložené-drop mechanismus simuluje DROP nebo TRUNCATE operace dokončení okamžitě, rozepínat příděly pro tabulky a jejich uvádění na odložené přesuňte fronty‘, pro pozdější zpracování pomocí úlohy na pozadí. Tato operace unhook-and-transfer generuje pouze hrst záznamů protokolu., Toto je operace, která se provádí a vrácena zpět v mém příkladu kódu výše.
‚odložené přesuňte úkol na pozadí se otáčí každých několik sekund a zruší přidělení všech stránek a rozsahy na odložené přesuňte fronty v malých dávkách, což zaručuje, že operace není dostatek paměti. Tyto deallocations jsou plně zaznamenány, ale nezapomeňte, že zpět navrácení stránku plnou dat nebo index záznamy protokolu individuální odstraní ty záznamy; místo toho celá stránka je označen jako platný v příslušné PFS (Strana Volného Místa) přidělení byte-mapa.,
Z SQL Server 2000 SP3 a dále, při provádění DROP nebo TRUNCATE tabulky, uvidíte pouze několik záznamů protokolu jsou generovány. Pokud budete čekat na minutu nebo tak, a pak se podívej do protokolu transakce znovu, uvidíte tisíce záznamů protokolu generované odložené-drop operace, každý zpět navrácení stránky nebo rozsahu. Operace je plně a efektivně zaznamenána.,
Zde je příklad, s využitím scénáře, který jsme vytvořili výše:
CHECKPOINT;GOTRUNCATE TABLE ;GOSELECT COUNT (*) AS N'LogRecCount'FROM fn_dblog (NULL, NULL);GO
Výsledky:
—-
25
Jak můžete vidět, tam určitě nejsou záznamy protokolu zpět navrácení 10 000 stránek, plus 1,250 rozsahy v TestTable stolu.
Pokud jsem počkat několik sekund, a pak spustit fn_dblog kód znovu jsem si:
—-
3811
možná se divíte, proč tam nejsou alespoň 10 000 log záznamů – jeden pro každou stránku je platný., To je, protože stránka deallocations jsou dokonce zaznamenány efektivně – s jeden záznam protokolu odráží PFS stránka přidělování změny pro 8 po sobě jdoucích datových souborů stránky, místo toho, aby jeden záznam pro každý soubor dat stránka odráží jeho přidělení statusu mění v PFS stránky.
SQL Server se vždy snaží vytvořit co nejmenší protokol transakcí a přitom dodržovat pravidla o úplném nebo minimálním protokolování na základě aktuálního modelu obnovy., Pokud se chcete podívat na aktuální záznamy protokolu generované odpojit-a-transfer a odložené přesuňte mechanismy, jednoduše nahradit * pro COUNT (*) v fn_dblog kódu výše a podívejte se na transakce s Transakcí Název nastaven na DeferredAllocUnitDrop::Process.
v budoucích příspěvcích budu diskutovat o vnitřnostech, které jsou základem dalších přetrvávajících mýtů o výkonnostních aspektech SQL Server Storage Engine.
Napsat komentář