Když vytvoříte novou databázi na serveru SQL Server, je ve výchozím nastavení povolena možnost Auto Update Statistics. Obecně se doporučuje ponechat tuto volbu povolenou. V ideálním případě jsou statistiky spravovány naplánovanou úlohou a automatická možnost se používá jako záchranná síť – dostupná pro aktualizaci statistik v případě, že k plánované aktualizaci nedojde nebo náhodně nezahrnuje všechny existující statistiky.
Někteří správci databází se při správě statistik spoléhají pouze na automatické aktualizace, a pokud neexistují žádné problémy s výkonem související s neaktuálními nebo špatně vzorkovanými statistikami, je to přijatelné. Pokud se při správě statistik spoléháte na tuto možnost a máte nějaké velmi velké tabulky, možná by stálo za to implementovat příznak trasování 2371. Stejně jako u jakéhokoli jiného příznaku trasování se ujistěte, že před implementací do produkce testujete s reprezentativní zátěží. Možná už víte, že existují chvíle, kdy automatická aktualizace může ovlivnit výkon systému. Aktualizace statistiky může například způsobit nárůst CPU nebo I/O při čtení dat tabulky nebo indexu a také zpozdit provedení dotazu, když dojde k aktualizaci. Existuje další možnost databáze, kterou můžete povolit, abyste se vypořádali s tímto zpožděním dotazu, a tomu se budu věnovat později v tomto příspěvku.
Často dostávám otázku:„Jak poznáte, že automatické aktualizace statistik způsobují problémy s výkonem?" Jednou z možností je sledovat je a spojit aktualizace se změnou výkonu. Existuje mnoho možností pro sledování aktualizací a v tomto příspěvku zkontrolujeme několik dostupných metod, abyste si mohli vybrat a poté implementovat možnost, která nejlépe vyhovuje vaší stávající metodě monitorování problémů s výkonem.
Trasování SQL
Pokud ve svém prostředí používáte SQL Server 2008 R2 nebo nižší, je SQL Trace jednou z metod, kterou můžete použít k zachycení automatických aktualizací. Skript pro definici trasování použitý níže zachycuje pouze událost Auto Stats, která se zachytí, když se statistika automaticky aktualizuje a když se statistika automaticky vytváří. Poté, co toto trasování nějakou dobu běží ve vašem prostředí, můžete jej načíst do tabulky a poté zadat dotaz na výstup, abyste zjistili, k jakým aktualizacím došlo. Přiložený skript níže projde příkladem pomocí vzorové databáze baseballových statistik.
Rozšířené události
Pokud používáte SQL Server 2012 nebo vyšší, doporučuji použít Extended Events k zachycení automatických aktualizací. Stejně jako skript SQL Trace i zahrnutý skript definice relace zachycuje pouze události Auto Stats – opět automatické aktualizace i automatické vytváření. Jakmile relace XE nějakou dobu poběží, můžete načíst výstup do tabulky prostřednictvím uživatelského rozhraní a poté se v ní dotazovat, abyste zjistili, k jakým aktualizacím došlo. Zahrnutý skript prochází stejným příkladem jako předtím, ale tentokrát ke sběru dat používá Extended Events.
sys.dm_db_stats_properties
Třetí možností, kterou byste mohli zvážit ke sledování aktualizací statistik, je sys.dm_db_stats_properties DMF, který je k dispozici pouze v SQL Server 2008 R2 SP2 a vyšší a SQL Server 2012 SP1 a vyšší. I když mám tento DMF rád, toto řešení je složitější, pokud jde o zajištění zachycení všech dat, a kontrola výstupu vyžaduje více práce. S DMF není každá automatická aktualizace sledována, pouze aktualizujeme statistiky trendů, abychom viděli, kdy k aktualizacím dojde.
Je to jednoduchý úkol:vytvoříte tabulku, která bude obsahovat informace o statistikách, a poté pravidelně zaznamenáváte informace z DMF do tabulky. Klíčem je zde zjistit, jak často data zaznamenávat. Každá hodina je pravděpodobně přehnaná, jednou denně nemusí být dost často. Doporučuji začít s úlohou SQL Agent, která každé čtyři hodiny pořídí snímky DMF dat. Nechte to několik dní běžet a poté zkontrolujte svá data. Pokud se statistiky aktualizují maximálně jednou denně, můžete interval prodloužit na každých osm nebo dvanáct hodin. Pokud se statistiky snadno aktualizují každé čtyři hodiny, snižte interval na každé dvě hodiny – chcete mít jistotu, že zaznamenáváte každou aktualizaci. Z tohoto důvodu u některých systémů sys.dm_db_stats_properties nemusí to stát za námahu; relace XE nebo trasování mohou být jednodušší.
Poslední ukázkový skript vás provede příkladem toho, jak byste použili sys.dm_db_stats_properties k aktualizaci trendů statistik. Uvědomte si, že tento skript zachycuje statistické informace pouze pro jednu tabulku. Pokud změníte skript tak, aby zachytil každou tabulku v databázi, bude k analýze mnohem více dat.
Další kroky
Stáhněte si ukázkové skripty a rozhodněte se, kterou metodu byste měli použít ke sledování aktualizací statistik.
Jakmile budete mít data, která ukazují, kdy dojde k automatickým aktualizacím, musíte je spojit se známými problémy s výkonem. Pokud tedy nesledujete žádné metriky výkonu, pak údaje o automatické aktualizaci statistik nepomohou s žádným druhem korelace. Za předpokladu, že máte časová razítka pro jakýkoli problém s výkonem, můžete jej porovnat s StartTime a EndTime z Trace, timestamp z XE nebo last_updated z sys.dm_db_stats_properties DMF, abyste zjistili, zda automatická aktualizace ovlivnila výkon systému.
Pokud nemůžete vytvořit žádnou korelaci mezi aktualizacemi a problémy s výkonem, můžete vyloučit aktualizace jako příčinu problému a zaměřit se na jinou oblast. Pokud jsou hlavní příčinou aktualizace, máte dvě možnosti:deaktivovat možnost Auto Update Statistics nebo povolit možnost Auto Update Statistics asynchronně. Obojí má své klady a zápory, které musíte jako DBA zvážit.
Deaktivace statistik automatických aktualizací
Pokud se rozhodnete zakázat možnost automatických aktualizací statistik, dvě nejdůležitější věci, které byste měli vědět, jsou:
- Své statistiky musíte bezpodmínečně spravovat prostřednictvím úlohy údržby nebo vlastní úlohy.
- Při aktualizaci statistik v SQL Server 2008 R2 a nižších nebudou dotazy znovu zkompilovány.
Druhou položku vnímám jako větší výzvu – jsem velkým zastáncem správy statistik a očekávám, že je to něco, co DBA tak jako tak dělají. Větší problém je, že i když aktualizace statistik normálně způsobí rekompilaci dotazů (k využití aktualizovaných statistik), to není dojde, když máte vypnutou možnost automatické aktualizace statistik. Psal jsem o tom již dříve a pokud s tímto chováním nejste obeznámeni, doporučuji si tyto informace přečíst. Podívejte se také na následný příspěvek s možnostmi, jak to řešit.
Obecně to není cesta, kterou doporučuji. Existují velmi specifické okrajové případy, kdy by to mohlo být vhodné, ale raději bych viděl, aby DBA prováděl manuální aktualizace (prostřednictvím naplánovaných úloh), aby se vyhnul automatickým aktualizacím, a jako bezpečnostní opatření ponechal možnost povolenou.
Asynchronní povolení automatických aktualizací statistik
Když povolíte možnost Automaticky aktualizovat statistiku asynchronně, pokud byla statistika zrušena a byl spuštěn dotaz, který tuto statistiku používá, statistika se aktualizuje až po dokončení dotazu – aktualizace je asynchronní. Výhodou je, že aktualizace neovlivní dotaz, který byl spuštěn; nevýhodou je, že dotaz bude používat stávající plán, který již nemusí být optimálním plánem. Zda je plán stále optimální, bude záviset na vašem pracovním vytížení (např. vytížení sestav s dlouhotrvajícími dotazy). Jako správce databází musíte zvážit pro a proti povolení této možnosti a určit, co je pro vaši databázi nejlepší. Všimněte si, že pokud používáte SQL Server 2008 až 2012, je s tímto nastavením spojeno nevracení paměti. Společnost Microsoft má k dispozici kumulativní aktualizace, které poskytují opravu, ale pokud je ještě nemáte aplikované, stojíte před dalším rozhodnutím:použijte CU, abyste mohli povolit možnost, nebo neaplikujte CU a nepovolujte možnost.
Shrnutí
Jediným způsobem, jak zjistit, zda automatické aktualizace statistik ovlivňují výkon dotazu, je buď vidět, že aktualizace nastala ve stejnou dobu jako problém, nebo zachytit, kdy dojde k aktualizacím, a uvést data do vztahu k dalším informacím, které zachycujete o problémech s výkonem. Druhá možnost vám umožňuje být proaktivní – i když nemáte problémy s výkonem, může být dobré vědět, jak často dochází k automatickým aktualizacím. Časté aktualizace mohou znamenat, že budete muset znovu navštívit úlohu agenta, která ručně spravuje statistiky. Obecně ponechte možnost automatické aktualizace statistik povolenou, ale mějte metodu správy statistik a použijte tuto možnost jako záchrannou síť.