Posledních několik verzí SQL Serveru zavedlo spoustu nových funkcí a také vylepšení stávajících funkcí. Jednou z oblastí enginu, kterou lze snadno přehlédnout, jsou statistiky. Koneckonců, statistiky se stále vytvářejí stejným způsobem, stále vám říkají o distribuci dat, stále je používá Optimalizátor dotazů… v čem se liší? Základní funkce statistik zůstává stejná – ale způsob, jakým je používá Optimalizátor dotazů, se mění v závislosti na odhadu mohutnosti, který používáte. Existuje také několik pozoruhodných změn souvisejících s aktualizací statistik a byly přidány nové funkce týkající se prohlížení statistických informací. Celkově mohou tyto změny v nejnovějších verzích způsobit odchylky v chování serveru SQL, které jste neočekávali.
Poznámka:Tento příspěvek je nejvíce použitelný pro SQL Server 2012 a vyšší, ale pro referenci (a zábavu) jsou uvedeny některé podrobnosti pro předchozí verze.
SQL Server 7.0
- Počet kroků v histogramu je omezen na 300. V SQL Server 6.5 a starších by měl histogram obsahovat počet kroků, které by se vešly na stránku o velikosti 2 kB, na základě velikosti prvního sloupce v klíči.
- Zavádí se možnost databáze „automaticky aktualizovat statistiky“; dříve byly statistiky aktualizovány pouze ručně.
SQL Server 2000
- Počet kroků v histogramu se sníží z 300 na 200 (technicky 201, pokud zahrnete krok pro hodnotu NULL, za předpokladu, že první sloupec v klíči umožňuje hodnoty NULL).
SQL Server 2005
- Aktualizace statistik, které používají FULLSCAN, mohou běžet paralelně.
- Trace Flags 2389 a 2390 jsou zavedeny v SP1, aby pomohly s problémem vzestupného klíče, který je popsán v příspěvku, Vzestupné klíče a statistiky automatických rychlých oprav. Podrobný příklad tohoto scénáře je uveden v mém příspěvku Trace Flag 2389 a novém nástroji Cardinality Estimator.
- Je zavedena možnost instance „Automaticky aktualizovat statistiky asynchronně“. Pamatujte, že aby to bylo účinné, musí být také povolena možnost „Automaticky aktualizovat statistiky“. Pokud vám není jasné, co tato možnost dělá, projděte si dokumentaci v části Možnosti ALTER DATABASE SET. Toto je nastavení, které doporučuje Glenn (jak je uvedeno ve svém příspěvku, na který odkazuje níže), ale myslím si, že je důležité si uvědomit potenciální problémy, jak je uvedeno v části Jak mohou automatické aktualizace statistiky ovlivnit výkon dotazů.
Poznámka: Došlo k nevracení paměti související s tímto nastavením v SQL Server 2008 až SQL Server 2012; Další podrobnosti naleznete v Glennově příspěvku Důležitá oprava hotfix pro SQL Server 2008.
SQL Server 2008
- Byly zavedeny filtrované statistiky, které lze vytvářet odděleně od filtrovaného indexu. Kolem filtrovaných indexů existují určitá omezení s ohledem na příspěvek Optimalizátor dotazů (viz příspěvek Tima Chapmana The Pains of Filtered Indexes a příspěvek Paula Whitea Omezení optimalizace s filtrovanými indexy) a je důležité porozumět chování počítadla, které sleduje úpravy (a tak může spustit automatické aktualizace). Další podrobnosti najdete v příspěvku Kimberly Filtrované indexy a filtrované statistiky mohou být vážně zastaralé a také doporučuji, abyste si prohlédli její uloženou proceduru, která analyzuje zkreslení dat a doporučí, kde můžete vytvořit filtrované statistiky, abyste Optimalizátoru dotazů poskytli více informací. Implementoval jsem to pro několik velkých zákazníků, kteří mají VLT a zkreslenou distribuci ve sloupcích často používaných v predikátech.
- Byla přidána dvě nová zobrazení katalogu, sys.stats a sys.stats_columns, aby poskytovaly snazší přehled o statistikách a zahrnutých sloupcích. Použijte tato dvě zobrazení namísto sp_helpstats, který je zastaralý a poskytuje méně informací.
SQL Server 2008R2 SP1
- Je zpřístupněn příznak trasování 2371, který lze použít ke snížení počtu úprav požadovaných pro automatické aktualizace statistik. Připomínám, že jsem příznivcem pravidelné aktualizace statistik prostřednictvím naplánované úlohy a ponechání automatické aktualizace z důvodu bezpečnosti povoleno.
SQL Server 2008R2 SP2
- Je zahrnuta funkce sys.dm_db_stats_properties, která poskytuje stejné informace jako v záhlaví DBCC SHOW_STATISTICS a také sloupec úprav, který lze použít ke sledování změn a programovému určení, zda je potřeba aktualizace. Pamatujete si, jak preferuji používání úlohy k aktualizaci statistik? Tato práce je s tímto DMF mnohem chytřejší...teď se mohu podívat, kolik dat bylo změněno, a POUZE aktualizovat statistiky, pokud se změnilo určité procento dat. Slick.
SQL Server 2012
- Pokud se nezmění žádné řádky, aktualizace statistik nezpůsobí zrušení platnosti plánů. Tohle je ten, který spoustu lidí překvapuje, a Kimberly má zábavný příspěvek, Co způsobilo, že se ten plán strašně pokazil – měli byste aktualizovat statistiky?, který prochází jejím dobrodružstvím při zjišťování toho.
SQL Server 2012 SP1
- DBCC SHOW_STATISTICS vyžaduje pouze oprávnění SELECT – dříve vyžadovalo, aby uživatel byl členem sysadmin nebo členem databázové role db_owner nebo db_ddladmin. To lze globálně zakázat příznakem trasování 9485.
- Zahrnuje sys.dm_db_stats_properties (viz poznámka 2008R2 SP2 výše)
SQL Server 2012 SP2
- Kumulativní aktualizace 1 zavádí opravu související s tím, že vzestupné klíče nejsou správně identifikovány ani při použití příznaků trasování 2389 a 2390. To vyžaduje příznak trasování 4139 kromě CU1, jak je uvedeno v KB 2952101.
SQL Server 2014
- Je představen nový nástroj Cardinality Estimator implementovaný nastavením režimu kompatibility databáze na 120 nebo použitím příznaku trasování 2312. Pokud jste o novém CE nic nečetli, doporučuji začít s dokumentací Cardinality Estimation a poté si přečíst Joe Podrobné informace obsahuje Sackův dokument Optimalizace plánů dotazů pomocí nástroje SQL Server 2014 Cardinality Estimator.
- Chování z příznaků trasování 2389 a 2390 pro vzestupné klíče je nyní implementováno prostřednictvím režimu kompatibility databáze. Pokud je režim kompatibility databází nastaven na 120 (nebo vyšší v pozdějších verzích), nemusíte k identifikaci statistik, které mají vzestupné klíče, používat příznaky trasování 2389 a 2390 pro SQL Server.
- Pro oddíly jsou zavedeny přírůstkové statistiky a lze je zobrazit prostřednictvím nového DMF sys.dm_db_incremental_stats_properties. Přírůstkové statistiky poskytují způsob, jak aktualizovat statistiky pro oddíl, aniž byste je aktualizovali pro celou tabulku. Dodatečné statistické informace z přírůstkové statistiky však Optimalizátor dotazů nepoužívá, ale jsou složeny do hlavního histogramu pro tabulku.
- CU2 obsahuje stejnou opravu uvedenou výše pro SQL Server 2012 SP2, která také vyžaduje příznak trasování 4139.
SQL Server 2014 SP1
- Příznak trasování 7471 je zpětně portován na CU6, původně dostupný v SQL Server 2016, jak je uvedeno níže.
SQL Server 2016
- Příznak trasování 2371 již není potřeba ke snížení prahu pro automatické aktualizace statistik, pokud je režim kompatibility databáze nastaven na 130. Viz Řízení chování Autostat (AUTO_UPDATE_STATISTICS) na serveru SQL Server.
- Aktualizace statistik mohou běžet paralelně při použití SAMPLE, nikoli pouze FULLSCAN. To je vázáno na režim kompatibility (musí být 130), ale může potenciálně poskytovat rychlejší aktualizace a tím zkrátit dobu údržby. Aaron Bertrand o tomto vylepšení hovoří ve svém příspěvku Potenciální vylepšení pro aktualizace statistik:MAXDOP.
- V CU1 je zaveden příznak trasování 7471, který umožňuje souběžné spuštění několika příkazů UPDATE STATISTICS pro jednu tabulku a Jonathan poskytuje několik skvělých příkladů toho, jak to lze použít ve svém příspěvku Vylepšená podpora pro přestavby paralelních statistik.
SQL Server 2016 SP1
- Je zavedena možnost nápovědy pro dotaz ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS spolu s argumentem FOR HINT, což je ekvivalent příznaku trasování 4139.
- DMF sys.dm_db_stats_histogram je vystaven v CU2, což je alternativa k výstupu histogramu z DBCC SHOW_STATISTICS. Informace v obou jsou stejné, použijte to, co je pro vás jednodušší nebo lépe odpovídá problému, který potřebujete vyřešit.
- V CU4 je zavedena možnost PERSIST_SAMPLE_PERCENT, kterou lze použít k vynucení použití stejné vzorkovací frekvence při každé aktualizaci statistiky do budoucna, a příklady tohoto chování lze nalézt v příspěvku Vzorkovací frekvence perzistentních statistik.
SQL Server 2017
- Volba PERSIST_SAMPLE_PERCENT je k dispozici v CU1 (další informace viz položka 2016 SP1).
- Atributy StatsInfoType a OptimizerStatsUsageType jsou přidány do plánu dotazů, který uvádí statistiky používané během optimalizace dotazů. To je k dispozici v CU3 a je vázáno na verzi CE (120 a vyšší). To je docela fajn! Ještě jsem neměl možnost si s tím pohrát, ale abyste tyto informace získali dříve, museli jste použít nezdokumentované příznaky trasování.
- CU3 také zavedl volbu MAXDOP pro CREATE STATISTICS a UPDATE STATISTICS, kterou lze použít k přepsání hodnoty MAXDOP pro instanci nebo databázi.
- Ještě jeden přírůstek v CU3:atributy UdfCpuTime a UdfElapsedTime lze nalézt v plánu dotazů, což představuje statistiku provádění pro skalárně hodnocené UDF.
Shrnutí
Pokud se chystáte upgradovat na novější verzi nebo pokud jste upgradovali nedávno, poznamenejte si, jak tyto změny ovlivní vaše řešení. Po upgradu z 2005/2008/2008R2 na 2014 nebo 2016 nás kontaktovalo mnoho klientů, kteří si stěžovali na problémy s výkonem. V mnoha případech nebylo před upgradem dokončeno dostatečné testování.
To je něco, na co se opravdu zaměřujeme, když pomáháme upgradovat klienta. Kromě kroků k přesunu produkční instance z jedné verze do druhé s malými prostoji se chceme ujistit, že den po upgradu bude pro správce databází a vývojáře nudný.
Netestujeme pouze proces upgradu, ale testujeme, jak systém po upgradu vypadá. Jsou v novém prostředí potřeba stejné příznaky trasování ze starého prostředí? Jaká nastavení databáze je třeba upravit? Mění se výkon dotazů – k lepšímu nebo horšímu? Pokud neznáte odpovědi na tyto otázky, než upgradujete výrobu, pak se chystáte na jeden až mnoho dní hašení požáru, volání Sev 1, jídla u vašeho stolu, nedostatek spánku a kdo ví co ještě .
Udělejte si čas na to, abyste pochopili dopad nových funkcí a změn ve funkčnosti uvedených výše, naplánujte upgrade a otestujte co nejvíce.