Database
 sql >> база данни >  >> RDS >> Database

Потенциално подобрение за актуализации на статистиката:MAXDOP

Така че в SQL Server 2016 актуализациите на статистиката, използващи примерен режим, вече се изпълняват паралелно при ниво на съвместимост 130 и това е как работи по подразбиране за всички автоматични и ръчни актуализации на статистически данни. Това е обяснено накратко тук:

  • Допълнения на оптимизатора на заявки в SQL Server 2016

(Документацията също е актуализирана, както темата Ниво на съвместимост, така и темата АКТУАЛИЗИРАНЕ НА СТАТИСТИКА.)

Не би ли било хубаво обаче да можете да посочите колко процесора всъщност могат да се използват за тези операции (освен просто да се разреши ограничението от 16)? Мисля, че възможността да ограничим това до 4 или 8 би било очевидно и логично нещо, което трябва да се подкрепи. Особено за клиенти, работещи със системи с 16 или по-малко ядра или множество екземпляри в кутия, които не могат да разчитат на корпоративни функции като Resource Governor (който повечето корпоративни клиенти също не биха могли да се притесняват да използват, IMHO).

Бизнес обосновката за това би била същата като обосновките, използвани за добавяне на поддръжка на MAXDOP REBUILD, DBCC CHECKDB и неговото семейство от операции по поддръжка и т.н. Искате да предотвратите този тип дейност да поеме всички ядра, без да правите нещо толкова драстично като изключване на автоматичните актуализации или използване на MAXDOP за целия екземпляр – защото не всеки разполага с лукса на прозорците за поддръжка.

И в този случай MAXDOP за целия екземпляр така или иначе няма да помогне , тъй като SQL Server 2016 RTM има грешка, при която MAXDOP се игнорира за актуализации на извадка на статистиката. Предстои поправка, но мислех, че трябва да знаете; ако това ви създава проблем, една от опциите е да използвате по-ниско ниво на съвместимост.

Но ще повторя нещо, което казвам често:нивото на съвместимост става твърде пренаселено. Ако искам паралелни извадкови статистики в моята база данни, но имам достатъчно регресии за оценка на кардиналността, за да изисквам старата CE, трябва да избера едното или другото.

И още нещо:Resource Governor е излишен за този случай на употреба и ограничаването на използването на ядрото от актуализации на статистическите данни всъщност не трябва да е функция на предприятието (точно като REBUILD и CHECKDB, споменати по-горе). Моля, не ми казвайте, че RG е приемлива алтернатива, защото е възможна само за потребители с Enterprise Edition *и* класификации на натоварването, които трябва да бъдат ограничени от MAXDOP през цялото време . Би трябвало да мога да огранича това чрез конкретна операция (или, да речем, само за моите най-големи/проблемни таблици), а не чрез ограничаване на цялата сесия за влизане.

Как ми се иска да го направят

В идеалния случай бихме могли да зададем това на ниво база данни, използвайки новата опция DATABASE SCOPED CONFIGURATION и на ниво израз, използвайки познатия синтаксис OPTION (MAXDOP n). Нивото на изявление ще спечели и всички актуализации на статистиката на примерния режим (включително автоматични) без изричен намек за MAXDOP ще се върнат към настройката на нивото на базата данни. Това би ми позволило да задам MAXDOP от 4, например, за всички автоматични актуализации на статистиката, които се случват в непредвидими моменти, но 8 или 16 за ръчни операции в известни прозорци за поддръжка. Като един пример.

Ако искате да гласувате за това, моля, вижте следния елемент Connect и добавете бизнес обосновка за това (a la Michael Campbell):

  • Свързване #628971 :Добавете параметър MAXDOP към актуализиране на статистиката

Разбира се, този елемент е там от 2010 г., така че изобщо не се споменава за ОБХВАТ НА КОНФИГУРАЦИЯТА НА БАЗА ДАННИ, поради което и аз оставих коментар.

Междувременно, ако искате да деактивирате паралелизма за примерен режим, има флаг за проследяване за ефективно връщане към по-старо поведение (можете също да направите това, като се върнете към ниво на съвместимост по-малко от 130, но аз не препоръчвам това, защото засяга много други неща). Ще актуализирам това пространство, когато ми бъде дадено разрешението да разкрия публично флага за проследяване, но в момента Microsoft го държи здраво до гърдите си.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Автоматично управление на индекси в Azure SQL база данни

  2. Опции за база данни/Отчитане за използване на пакети

  3. SQL SELECT за начинаещи

  4. SQL Pivot – Знайте как да конвертирате редове в колони

  5. Как да активирате общи регистрационни файлове и регистрационни файлове за грешки в AWS RDS