V SQL Server 2016 tedy aktualizace statistik pomocí ukázkového režimu nyní běží paralelně pod úrovní kompatibility 130 a takto to funguje ve výchozím nastavení pro všechny automatické a ruční aktualizace statistik. Toto je stručně vysvětleno zde:
- Přidání Optimalizátoru dotazů v SQL Server 2016
(Dokumentace byla také aktualizována, jak téma Úroveň kompatibility, tak téma AKTUALIZACE STATISTIKY.)
Nebylo by však hezké mít možnost specifikovat, kolik CPU lze pro tyto operace skutečně použít (kromě povolení limitu 16)? Myslím, že možnost omezit toto na 4 nebo 8 by byla samozřejmá a logická věc. Zejména pro zákazníky provozující systémy s 16 nebo méně jádry nebo více instancemi v krabici, kteří se nemohou spolehnout na podnikové funkce, jako je Resource Governor (který si většina podnikových zákazníků IMHO ani nemůže obtěžovat).
Obchodní zdůvodnění pro toto by bylo stejné jako zdůvodnění použité pro přidání podpory MAXDOP REBUILD, DBCC CHECKDB a jeho rodiny operací údržby atd. Chcete zabránit tomu, aby tento typ činnosti převzal všechna jádra, aniž byste udělali něco tak drastického jako vypnutí automatických aktualizací nebo použití MAXDOP pro celou instanci – protože ne každý má ten luxus oken údržby.
A v tomto případě MAXDOP pro celou instanci stejně nepomůže , protože SQL Server 2016 RTM má chybu, kdy MAXDOP je ignorován pro aktualizace vzorků statistik. Oprava se blíží, ale myslel jsem, že byste to měli vědět; pokud vám to způsobuje problém, jednou z možností je použít nižší úroveň kompatibility.
Ale zopakuji něco, co říkám často:Úroveň kompatibility je příliš přeplněná. Pokud chci paralelní vzorkované statistiky ve své databázi, ale mám dostatek regresí odhadu mohutnosti na to, abych vyžadoval starý CE, musím si vybrat jedno nebo druhé.
A další věc:Resource Governor je pro tento případ použití přehnaný a omezení využití jádra z aktualizací statistik by ve skutečnosti nemělo být funkcí Enterprise (stejně jako výše uvedené REBUILD a CHECKDB). Neříkejte mi prosím, že RG je přijatelná alternativa, protože je možná pouze pro uživatele s klasifikací zátěže Enterprise Edition *a*, která by měla být omezena MAXDOP stále . Měl bych být schopen to omezit konkrétní operací (nebo řekněme pouze pro mé největší/problémové tabulky), nikoli omezením celé relace přihlášení.
Jak bych si přál, aby to udělali
V ideálním případě bychom to byli schopni nastavit na úrovni databáze pomocí nové možnosti DATABASE SCOPED CONFIGURATION a na úrovni příkazů pomocí známé syntaxe OPTION (MAXDOP n). Úroveň příkazu by zvítězila a jakékoli aktualizace statistiky vzorového režimu (včetně automatických) bez explicitní nápovědy MAXDOP by se vrátily zpět na nastavení úrovně databáze. To by mi umožnilo nastavit MAXDOP na 4, například pro všechny automatické aktualizace statistik, ke kterým dochází v nepředvídatelných časech, ale 8 nebo 16 pro manuální operace ve známých oknech údržby. Jako jeden příklad.
Pokud pro to chcete hlasovat, podívejte se prosím na následující položku Connect a přidejte pro to obchodní odůvodnění (a la Michael Campbell):
- Connect #628971 :Přidejte parametr MAXDOP k aktualizaci statistik
Samozřejmě, že tato položka existuje od roku 2010, takže není vůbec žádná zmínka o třídě DATABASE SCOPED CONFIGURATION, a proto jsem také zanechal komentář.
Mezitím, pokud chcete zakázat paralelismus pro ukázkový režim, existuje příznak trasování pro efektivní návrat ke staršímu chování (můžete to také provést návratem na úroveň kompatibility nižší než 130, ale nedoporučuji to, protože to ovlivňuje spoustu dalších věcí). Tento prostor aktualizuji, až budu mít právo zveřejnit příznak sledování, ale právě teď ho Microsoft drží pevně na jejich hrudi.