Оновлення статистики з повним скануванням на SQL Server 2014 використовує 100% процесор, на R2 2008 року 15%

Чому статистика оновлень повного сканування використовує 100% процесора на SQL Server 2014, коли він використовує, можливо, 20% процесора на SQL Server 2008 R2, для тих же таблиць з аналогічною апаратною здатністю?

Я дивився на MAXDOPінші варіанти, і справді не бачу нічого, що виділяється. Я розумію, що можуть бути налаштування, які можуть викликати це, але налаштування дуже схожі для обох баз даних (наприклад, MAXDOP4 для обох, причому обидва мають декілька ядер). Обидва є Enterprise Edition.

Чи є щось "інше" у SQL Server 2014 порівняно з SQL Server 2008 R2, що могло б пояснити це? У мене є можливість пам'яті на 90% для обох серверів. Будь-які думки, на що звернути увагу?

Я запускаю статистику оновлень при повному (100%) скануванні один раз на тиждень на двох серверах за допомогою SQL Server 2008 R2 / SP3 та SQL Server 2014 / SP2, а бази даних мають однакову структуру. На сервері R2 2008 р. Статистика оновлення двох дуже великих таблиць займає кілька годин, і це те, що я очікую, але процесор залишається меншим за 20% або більше використання всього цього часу. Однак на сервері 2014 року процесор працює на 100% приблизно 40 хвилин. Таблиць трохи менше на сервері 2014 року. Я бачу це за допомогою меню аналізу SQL Monitor.

Ось вихід файлу журналу Ola на SQL Server 2014, процесор переходить на 100% приблизно від 2:10 до 2:45:

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  

Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

Ось вихід файлу журналу Ola на SQL Server 2008 R2 для двох статистичних даних вище, але процесор може становити, можливо, 15%:

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  

Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

Я не можу запустити їх із сервером maxdop = 1, оскільки це виключає все паралельне генерування плану, і це може зашкодити додатку. Я планую піти в зворотному напрямку і збільшити його до 8 (на коробці є 16 ядер) і подивитися, що станеться. Може йти швидше, щоб зменшити тривалість прив’язки процесора. Ця робота працює, поки користувачі в основному не входять.

Оновлення статистики можуть йти паралельно на основі безлічі різних варіантів у SQL Server:

• Поріг вартості для паралельності - запит повинен бути таким високим, щоб їхати на поїзді паралелізму. Ваші два сервери можуть мати різні налаштування CTFP, які призводять до того, що оновлення 2008R2 може переходити однопотоково, тоді як 2014 року може бути багатопоточним.
• Максимальна ступінь паралельності - диктує, скільки ядер може використовувати запит, щонайбільше, якщо SQL Server вирішить паралелізувати його так далеко. У вікні 2008R2 може бути MAXDOP встановлено на 1, тоді як у вікні 2014 року він може бути встановлений за замовчуванням 0 (необмежено.)
• Управління ресурсами - ця функція Enterprise Edition дозволяє пересувати різні групи користувачів або додатки на різні MAXDOP.

У пізніших версіях SQL Server (2016 та новіших) це стає ще складнішим:

• Параметри масштабу на рівні бази даних - ви можете клацнути правою кнопкою миші на базі даних, перейти у властивості та встановити рівень MAXDOP для цієї бази даних.
• Підказки щодо паралелізму статистики - починаючи з SP2 2016 року, заяви про створення та оновлення статистики приймають підказки MAXDOP

Як ви зазначали, ваш 2008R2 - це однопотоковий, тоді як 2014-й - багатопотоковий (таким чином, закінчується швидше, але максимізує процесор під час роботи.)

Щоб знайти правильний баланс для вашої роботи з статистикою, подумайте про:

• Які ще робочі навантаження відбуваються в базі даних одночасно? Чи можете ви дозволити собі домінувати над коробочкою протягом коротких періодів? Наприклад, в сховищах даних, які сидіють у режимі очікування протягом більшості вихідних годин, я бачив, як люди сильно хрустять на оновленнях статистики за допомогою повних камер, коли їм відомо, що сервер ніхто не використовує. У важких транзакційних умовах вам доведеться починати використовувати менший вплив на завдання технічного обслуговування, якщо користувачі скаржаться навіть у опівночі.
• Чи справді потрібен повний скан? Ви бачите запити, які отримують хороші плани лише тоді, коли ви користуєтесь повнофункціональним варіантом, або ви просто робите це як найкраща практика? Коли ваша база даних зростає, якщо ваші інвестиції в обладнання не йдуть в ногу, можливо, вам доведеться почати компроміси в статистичній вибірці, а не робити великі камери.
• Чи можете ви оновлювати статистику рідше? Наприклад, оновлюйте 1/4 вашої статистики кожен вихідний, а потім щомісяця все оновлюватиме статистику?
• Чи можете ви оновити менше об’єктів? Часто я бачу, як люди оновлюють статистику навіть на величезних таблицях аудиту чи архіву просто тому, що було зроблено кілька десятків нових вставок, але ці вставки насправді не впливають на статистику на столі (і ніхто не запитує її в будь-якому разі).

_{Відповідь вікі спільноти :}

Найкраща здогадка: план, вибраний для оновлення статистики, є або паралельним, або більш паралельним, у вікні 2014 року, ніж у вікні R2 2008 року.

Статистика паралельних оновлень fullscanіснує вже з 2005 року, а про вибіркові статистичні дані, починаючи з 2016 року, див. Додавання оптимізатора запитів у SQL Server 2016 від Gjorgji Gjeorgjievski в блозі двигуна бази даних SQL Server.

Якщо у вас є Enterprise Edition, ви можете використовувати Resource Governor для обмеження процесора, який використовується вашим завданням з обслуговування.

Розглянемо також голосування за пропозицію Connect Додати MAXDOPпараметр до оновлення статистики Хав'єра Віллегаса.

Пов'язані запитання та запитання: Паралельне оновлення статистики