Úvod
Optimalizátor dotazů SQL Server využívá statistiky během kompilace dotazů, aby pomohl určit optimální plán dotazů. Ve výchozím nastavení, pokud optimalizátor zjistí, že statistika je zastaralá kvůli příliš mnoha změnám v tabulce, aktualizuje statistiku bezprostředně předtím, než bude pokračovat kompilace dotazu (pouze statistiky, které potřebuje, ne všechny statistiky pro tabulku) .
Všimněte si, že „příliš mnoho“ není konkrétní, protože se liší podle verze a toho, zda je povolen příznak trasování 2371 – podrobnosti naleznete v části AUTO_UPDATE_STATISTICS na této stránce.
Problém se synchronními aktualizacemi statistik
Synchronní aktualizace statistik před kompilací zjevně přináší zpoždění a prodlužuje kompilaci a provádění dotazu. Jak velké zpoždění závisí na několika faktorech, včetně:
- Kolik tabulek zahrnutých do dotazu dosáhlo prahové hodnoty „příliš mnoho změn“
- Kolik statistik pro každou z těchto tabulek je třeba aktualizovat, protože jsou potřebné pro kompilaci
- Kolik řádků je v příslušných tabulkách
- Možnosti zadané při vytváření každé statistiky (např. FULLSCAN a PERSIST_SAMPLE_PERCENT=ON)
Může tedy docházet ke zdánlivě náhodnému zpoždění, které může v některých scénářích způsobit problémy, zvláště pokud má aplikace nastaven velmi nízký časový limit dotazu.
Vyhnutí se synchronním aktualizacím statistik
Existují různé způsoby, jak se vyhnout synchronním aktualizacím statistik, například:
- Nastavení AUTO_UPDATE_STATISTICS na OFF, což vypne všechny automatické aktualizace a znamená, že budete muset provádět vlastní údržbu statistik, abyste se vyhnuli možnosti neoptimálních plánů dotazů z neaktuálních statistik.
- Nastavení AUTO_UPDATE_STATISTICS_ASYNC na ON, takže když optimalizátor zjistí, že je třeba aktualizovat statistiku, pokračuje v kompilaci a úloha na pozadí aktualizuje statistiku o něco později. Toto funguje pouze v případě, že máte také AUTO_UPDATE_STATISTICS nastaveno na ON.
- Provádějte pravidelnou údržbu statistik, aby automatické synchronní nebo asynchronní aktualizace statistik vůbec neprobíhaly.
V komunitě SQL Server se hodně diskutuje o tom, zda povolit asynchronní aktualizace statistik. Zeptal jsem se své milé manželky Kimberly L. Tripp, jaký je její názor, a ona mi to vždy doporučuje povolit a na statistiky zapomněla víc, než kdy budu vědět, takže jí věřím. ☺
Sledování aktualizací synchronních statistik
Nikdy neexistoval zřejmý způsob, jak zjistit, zda dotaz trval dlouho, protože čekal na synchronní aktualizaci statistik. *po* dokončení aktualizace statistik jste poznali, zda již běžela relace rozšířené události a sledovali jste auto_stats událost a filtrování na async sloupec je nastaven na 0. Tento sloupec ve výstupu události byl však přidán pouze v SQL Server 2017 a také byste museli nakonfigurovat akci, která něco zachytila, abyste identifikovali příslušný dotaz.
Nyní v SQL Server 2019 existuje typ čekání WAIT_ON_SYNCHRONOUS_STATISTICS_UPDATE a na první pohled se zdá, že by vám snadno umožnil zjistit, zda dotaz čeká na aktualizaci synchronní statistiky, stačí se podívat do sys.dm_os_waiting_tasks a zjistit, jaký je aktuálně dotaz. čekání na.
Bohužel tomu tak není.
Termín „čekání“ je zde trochu zavádějící, protože v tomto případě vlákno ve skutečnosti nečeká. Tento nový typ čekání je příkladem toho, čemu se říká „preemptivní“ čekání, kdy se vlákno přepne do režimu, kdy zůstane na procesoru, dokud nedokončí svou práci. Většina preemptivních čekání je, když vlákno zavolá mimo SQL Server (např. za účelem získání informací o zabezpečení z řadiče domény), ale někdy vlákno dělá něco uvnitř SQL Serveru a potřebuje to dokončit, než bude potenciálně nuceno vydat procesor. protože jeho 4ms vláknové kvantum vypršelo. Ani jedna z těchto věcí se zde neděje. V tomto případě vlákno zaregistruje začátek preemptivního čekání s novým typem čekání a poté provede aktualizaci statistik, přičemž pravděpodobně způsobí další *skutečné* čekání jako PAGEIOLATCH_SH. Preventivní čekání skončí až po dokončení aktualizace statistik a bude zohledněno v metrikách statistiky čekání.
Proč je to velký problém? No, DMV sys.dm_os_waiting_tasks ukazuje typy čekání pro všechna vlákna, která *skutečně* čekají, tj. na seznamu čekajících úloh plánovače, takže pokud vlákno aktualizace synchronní statistiky nečeká na WAIT_ON_SYNCHRONOUS_STATISTICS_UPDATE, typ čekání se nezobrazí ve výstupu DMV. Nový typ čekání nelze použít ke zjištění, zda dotaz aktuálně čeká na aktualizaci statistik.
Můžete si to snadno dokázat následujícím způsobem:
- Vytvořte tabulku s několika stovkami tisíc řádků
- Vytvořte statistiku pro sloupec tabulky a jako možnosti zadejte FULLSCAN a PERSIST_SAMPLE_PERCENT =ON, čímž při každé aktualizaci statistiky vynutíte načtení celé tabulky.
- Aktualizujte dvacet tisíc řádků
- Zkontrolujte databázi a spusťte DBCC DROPCLEANBUFFERS
- Proveďte příkaz SELECT s klauzulí WHERE ve sloupci se statistikou, kterou jste vytvořili
- Podívejte se v sys.dm_os_waiting_tasks DMV na ID relace SELECT a uvidíte, že pravděpodobně čeká na PAGEIOLATCH_SH, jak bude aktualizace statistik číst v tabulce
Pomineme-li toto zklamání, existuje trik, jak zjistit, zda dotaz čeká na synchronní aktualizaci statistik. Když dojde k aktualizaci statistik, spustí se příkaz nazvaný STATMAN a můžete to vidět ve výstupu z sys.dm_exec_requests :stav bude „pozastaveno“ (i když vlákno běží, jak jsem popsal výše) a příkaz bude “SELECT (STATMAN).”
K čemu slouží nový typ čekání?
Ačkoli nový typ čekání nelze použít jako okamžitý způsob, jak zjistit, že dotaz čeká na aktualizaci synchronních statistik, pokud se objeví ve vaší pravidelné analýze statistik čekání, víte, že některé dotazy v pracovní zátěži mohou trpět těmito zpožděními . Ale to je podle mě na hranici jeho užitečnosti. Pokud se průměrná doba čekání neukáže jako příslušné procento průměrné doby provádění dotazu nebo pokud neustále nezaznamenáváte čekání po krátké časové úseky, abyste umožnili řádnou analýzu, nevíte jistě, zda se jedná o problém.
Toto je typ čekání, kde se doba čekání může výrazně lišit v závislosti na faktorech, které jsem zmínil dříve. Proto bych použil pouze přítomnost tohoto typu čekání, abych byl upozorněn na potenciální problémy, a chtěl bych implementovat relaci Extended Event, jak je popsáno výše, abych zachytil instance synchronních aktualizací statistik, abych zjistil, zda je jejich trvání dostatečně dlouhé, aby si to zasloužilo. podniknout nějaké nápravné opatření.
Shrnutí
Nejsem si jistý, zda přidání typu čekání WAIT_ON_SYNCHRONOUS_STATISTICS_UPDATE změní, zda lidé konfigurují aktualizace asynchronních statistik nebo jednoduše provádějí veškerou údržbu statistik sami, ale alespoň nyní budete moci zjistit, zda dotazy čekají na synchronní statistiky aktualizace a podnikněte další kroky.
Do příště přejeme hodně úspěchů při odstraňování problémů!