Обновление статистики с полной проверкой на SQL Server 2014 использует 100% ЦП, на 2008 R2 - 15%

10

Почему полная статистика обновлений сканирования использует 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, и базы данных имеют одинаковую структуру. На сервере 2008 R2 статистика обновления двух очень больших таблиц занимает несколько часов, чего я и ожидаю, но загрузка ЦП не превышает 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 sql-server-2008-r2 sql-server-2014 TRH_SETRANS
источник
Вы проверили, связан ли процесс с IO на сервере 2008 R2? Является ли tempdbконфигурация же? Его можно использовать во время UPDATE STATISTICSработы, так что это также может быть проблемой.
MicSim
1
Я тоже подозреваю, что параллелизм, вероятно, является виновником. Вы случайно проверили порог стоимости для параллелизма? Кроме того, может быть хорошей идеей получить полный список sp_configure из обоих блоков и сравнить их, чтобы увидеть, что еще отличается.
DBADon

Ответы:

1

Обновления статистики могут идти параллельно, в зависимости от множества параметров в SQL Server:

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

В более поздних версиях SQL Server (2016 и новее) это становится еще сложнее:

  • База данных на уровне области видимости варианты - вы можете щелкнуть правой кнопкой мыши на базе данных, перейдите в свойства, и установить уровень MAXDOP для этой базы данных.
  • Советы по параллелизму статистики - начиная с SP2 2016, операторы создания и обновления статистики принимают подсказки MAXDOP

Как вы заметили, ваш 2008R2 будет однопоточным, а 2014 - многопоточным (таким образом, процесс завершается быстрее, но при этом увеличивается загрузка ЦП во время работы).

Чтобы найти правильный баланс для вашей статистики работы, подумайте о:

  • Какие другие рабочие нагрузки происходят в базе данных одновременно? Можете ли вы позволить себе доминировать на поле в течение коротких периодов? Например, в хранилищах данных, которые бездействуют в течение большинства выходных, я видел, как люди усердно занимаются обновлением статистики с полным просмотром, когда они знают, что сервер в любом случае никто не использует. В транзакционных средах с высокой нагрузкой вы должны начать меньше влиять на задачи обслуживания, если пользователи жалуются даже в полночь.
  • Полное сканирование действительно необходимо? Видите ли вы запросы, которые получают хорошие планы, только когда вы используете опцию fullscan, или вы просто делаете это как лучший метод? По мере роста вашей базы данных, если ваши инвестиции в аппаратное обеспечение не будут идти в ногу, вам, возможно, придется пойти на компромисс в выборке статистики, а не в полномасштабном сканировании.
  • Можете ли вы обновлять статистику реже? Например, обновлять 1/4 вашей статистики каждые выходные, а затем каждый месяц, все будет получать обновления статистики?
  • Можете ли вы обновить меньше объектов? Часто я вижу, как люди обновляют статистику даже в огромных аудиторских или архивных таблицах просто потому, что было сделано несколько десятков новых вставок, но эти вставки на самом деле не влияют на статистику в таблице (и никто не запрашивает ее в любом случае).
Брент Озар
источник
0

Ответ сообщества вики :

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

Параллельная статистика обновлений fullscanсуществует с 2005 года, а выборочные статистические данные, начиная с 2016 года, см. В статье « Дополнения оптимизатора запросов в SQL Server 2016 », автор Gjorgji Gjeorgjievski, блог SQL Server Database Engine.

Если у вас есть Enterprise Edition, вы можете использовать Resource Governor, чтобы ограничить использование процессора вашей работой по обслуживанию.

Также рассмотрите возможность голосования за предложение «Подключить». Добавьте MAXDOPпараметр «Обновить статистику» от Хавьера Виллегаса.

Связанные вопросы и ответы: параллельное обновление статистики

оборота user126897
источник