SQL Server 2016 Enterprise низкая производительность

Извините, что долго, но я хочу дать вам как можно больше информации, которая может быть полезна для анализа.

Я знаю, что есть несколько постов с похожими проблемами, однако я уже следил за этими постами и другой информацией, доступной в Интернете, но проблема остается.

У меня серьезная проблема с производительностью в SQL Server, которая сводит пользователей с ума. Эта проблема тянется в течение нескольких лет, и до конца 2016 года управлялась другая организация, а с 2017 года я управляла ею.

В середине 2017 года мне удалось решить эту проблему, следуя указаниям по индексированию, указанным в отчетах панели мониторинга производительности Microsoft SQL Server 2012. Эффект был мгновенным, он звучал как волшебство. Процессор, который был в последние дни почти всегда на 100%, стал супер безмятежным, и отзывы пользователей были ошеломляющими. Даже наш специалист по ERP был в восторге, так как обычно требовалось 20 минут, чтобы получить определенные списки, и, наконец, он мог сделать это за считанные секунды.

Однако со временем оно постепенно начало ухудшаться. Я избегал создавать больше индексов, опасаясь, что слишком большое количество индексов ухудшит производительность. Но в какой-то момент мне пришлось стереть ненужные и создать новые, которые мне предлагает Performance Dashboard. Но не влияет.

Медлительность ощущается, по сути, при сбережении и консультировании, в ERP.

У меня есть Windows Server 2012 R2, выделенный для SQL Server 2016 Enterprise (64-разрядная версия) со следующей конфигурацией:

• Процессор: Intel Xeon CPU E5-2650 v3 @ 2,30 ГГц
• Память: 84 ГБ
• С точки зрения хранения, на сервере есть том, выделенный для операционной системы, другой - для данных, а другой - для журналов.
• 17 баз данных
• Пользователи:
  • В самой большой БД подключено более или менее 113 пользователей одновременно
  • В другом есть около 9 пользователей
  • В двух из них 3 + 3
  • Остальные имеют только 1 пользователя каждый
  • У нас есть сеть, которая также пишет для более крупной базы данных, но там, где ее использование гораздо менее регулярное, и в ней должно быть около 20 пользователей.
• Размер БД:
  • Самая большая из баз данных имеет 290 ГБ
  • Второй по величине имеет 100 ГБ
  • Третий по величине имеет 20 ГБ
  • Четвертый 14 гб
  • Остальные чуть более 3 ГБ каждый

Это производственный экземпляр, но у нас также есть пример разработки, который, я считаю, может быть проигнорирован для этой цели, потому что большую часть времени я там только соединяюсь, но эта проблема возникает постоянно, даже когда я не подключен ,

Процессор почти всегда такой:

У нас есть рутины, которые запускаются ночью (не проблематично), а некоторые - днем.

Пользователи подключаются через удаленный рабочий стол к другим компьютерам, настроенным ODBC 32 для доступа к SQL Server.

Центр обработки данных, в котором расположены серверы, имеет скорость 100/100 Мбит / с, также как и я. Большинство сайтов связаны MPLS, а другие - IPSec (от FO до 4G). Провайдер сделал много анализа, и схема в порядке.

Коэффициент попадания в кэш-память составляет 99% (как пользовательские запросы, так и пользовательские сеансы)

Ожидания выглядят так:

Я уже собрал данные с Perfmon, и у меня есть результаты, если они помогут с вашим анализом - лично я не получил никаких выводов из анализа.

Я рассчитываю на вашу поддержку в решении этой проблемы, предоставляя информацию, которую вы считаете необходимой для решения этой проблемы.

Большое спасибо.

Вот уценка sp_blitz (я заменил названия компаний псевдонимами):

Приоритет 1: Надежность :

• Последний хороший DBCC CHECKDB старше 2 недель

  • мастер

  • модель - последняя успешная CHECKDB: 2018-02-07 15: 04: 26.560

  • msdb - последний успешный CHECKDB: 2018-02-07 15: 04: 27.740

Приоритет 10: Производительность :

• ЦП с нечетным числом ядер

  • Узлу 0 назначено 5 ядер. Это действительно плохая конфигурация NUMA.

  • Узлу 1 назначено 5 ядер. Это действительно плохая конфигурация NUMA.

Приоритет 20: Конфигурация файла :

• TempDB на диске C tempdb - база данных tempdb содержит файлы на диске C. TempDB часто непредсказуемо растет, подвергая ваш сервер риску нехватки места на диске C и серьезного сбоя. C также часто намного медленнее, чем другие диски, поэтому производительность может снижаться.

Приоритет 50: Надежность :

• Ошибки, зарегистрированные недавно в трассировке по умолчанию
  • master - 2018-03-07 08: 43: 11.72 Ошибка входа: 17892, уровень серьезности: 20, состояние: 1. 2018-03-07 08: 43: 11.72 Ошибка входа в систему для входа в систему «example_user» из-за выполнения триггера. [КЛИЕНТ: IPADDR]

(примечание: многие ошибки, подобные этой, из-за включенного триггера, ограничивающего пользовательские сеансы - для контроля использования лицензирования ERP)

• Проверка страницы не оптимальна

  • DATABASE_A - База данных [DATABASE_A] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_B - База данных [DATABASE_B] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_C - База данных [DATABASE_C] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_D - База данных [DATABASE_D] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_E - База данных [DATABASE_E] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_F - База данных [DATABASE_F] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_G - База данных [DATABASE_G] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_H - База данных [DATABASE_H] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_I - База данных [DATABASE_I] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_Z - База данных [DATABASE_Z] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_K - База данных [DATABASE_K] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_J - База данных [DATABASE_J] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_L - База данных [DATABASE_L] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_M - База данных [DATABASE_M] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_O - База данных [DATABASE_O] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_P - База данных [DATABASE_P] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_Q - База данных [DATABASE_Q] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_R - База данных [DATABASE_R] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_S - База данных [DATABASE_S] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_T - База данных [DATABASE_T] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_U - База данных [DATABASE_U] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_V - База данных [DATABASE_V] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

  • DATABASE_X - База данных [DATABASE_X] имеет NONE для проверки страницы. SQL Server может быть труднее распознавать и восстанавливать данные после повреждения хранилища. Попробуйте вместо этого использовать CHECKSUM.

• Удаленный ЦАП отключен - Удаленный доступ к выделенному соединению администратора (DAC) не включен. ЦАП может значительно облегчить удаленное устранение неполадок, когда SQL Server не отвечает.

Приоритет 50: Информация о сервере :

• Мгновенная инициализация файла не включена - рассмотрите возможность включения IFI для более быстрого восстановления и увеличения размера файла данных.

Приоритет 100: Производительность :

• Коэффициент заполнения изменен

  • DATABASE_A - База данных [DATABASE_A] содержит 417 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_B - База данных [DATABASE_B] содержит 318 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_C - База данных [DATABASE_C] содержит 346 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_D - База данных [DATABASE_D] содержит 663 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_E - База данных [DATABASE_E] содержит 335 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_F - База данных [DATABASE_F] содержит 1705 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_G - База данных [DATABASE_G] содержит 671 объект с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_H - База данных [DATABASE_H] содержит 2364 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_I - База данных [DATABASE_I] содержит 1658 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_Z - База данных [DATABASE_Z] содержит 673 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_K - База данных [DATABASE_K] содержит 312 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_J - База данных [DATABASE_J] содержит 864 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_L - База данных [DATABASE_L] содержит 1170 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_M - База данных [DATABASE_M] содержит 382 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_O - База данных [DATABASE_O] содержит 356 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • msdb - База данных [msdb] содержит 8 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_P - База данных [DATABASE_P] содержит 291 объект с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_Q - База данных [DATABASE_Q] содержит 343 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_R - База данных [DATABASE_R] содержит 2048 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_S - База данных [DATABASE_S] содержит 325 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_T - База данных [DATABASE_T] содержит 322 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_U - База данных [DATABASE_U] содержит 351 объект с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_V - База данных [DATABASE_V] содержит 312 объектов с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • DATABASE_X - База данных [DATABASE_X] содержит 352 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

  • tempdb - База данных [tempdb] содержит 2 объекта с коэффициентом заполнения = 70%. Это может вызвать проблемы с памятью и производительностью хранилища, но также может предотвратить разбиение страниц.

• Множество планов для одного запроса - в кэше планов имеется 20763 планов для одного запроса - это означает, что у нас, вероятно, есть проблемы с параметризацией.

• Триггеры сервера включены - триггер сервера [connection_limit_trigger] включен. Убедитесь, что вы понимаете, что делает этот триггер - чем меньше работы, тем лучше.

• Хранимая процедура с RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] содержит WITH RECOMPILE в коде хранимой процедуры, что может привести к увеличению использования ЦП из-за постоянной перекомпиляции кода.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] содержит WITH RECOMPILE в коде хранимой процедуры, что может привести к увеличению использования ЦП из-за постоянной перекомпиляции кода.

Приоритет 110: Производительность :

• Активные таблицы без кластерных индексов

  • DATABASE_A - База данных [DATABASE_A] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_B - База данных [DATABASE_B] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_C - База данных [DATABASE_C] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_E - База данных [DATABASE_E] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_F - База данных [DATABASE_F] имеет кучи - таблицы без кластеризованного индекса, которые активно запрашиваются.

  • DATABASE_H - База данных [DATABASE_H] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_I - База данных [DATABASE_I] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_K - База данных [DATABASE_K] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_O - База данных [DATABASE_O] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_Q - База данных [DATABASE_Q] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_S - База данных [DATABASE_S] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_T - База данных [DATABASE_T] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_U - База данных [DATABASE_U] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_V - База данных [DATABASE_V] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

  • DATABASE_X - База данных [DATABASE_X] имеет кучи - таблицы без кластеризованного индекса - которые активно запрашиваются.

Приоритет 150: Производительность :

(Примечание: здесь Nany советы, но я не смог их включить из-за ограничения символов. Если есть другой способ поделиться, пожалуйста, укажите.)

Вы задали нам длинный (и очень подробный) вопрос. Теперь вам приходится иметь дело с длинным ответом. ;)

Есть несколько вещей, которые я бы предложил изменить на вашем сервере. Но давайте начнем с самого насущного вопроса.

Единовременные экстренные меры:

Тот факт, что производительность была удовлетворительной после развертывания индексов в вашей системе и медленно ухудшающаяся производительность, является очень сильным указанием на то, что вам нужно начать поддерживать свою статистику и (в меньшей степени) позаботиться о фрагментации индекса.

В качестве экстренной меры я бы рекомендовал один раз вручную обновить статистику по всем вашим базам данных. Вы можете получить необходимый TSQL, выполнив этот скрипт:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

Это предоставлено Тимом Фордом в его посте на mssqltips.com, и он также объясняет, почему обновление статистики имеет значение.

Обратите внимание, что это задача, интенсивно использующая процессор и ввод-вывод, которая не должна выполняться в рабочие часы.

Если это решит вашу проблему, пожалуйста, не останавливайтесь на достигнутом!

Регулярное обслуживание:

Взгляните на решение для технического обслуживания Ola Hallengren, а затем настройте по крайней мере следующие два задания:

• Задание по обновлению статистики (если возможно каждую ночь). Вы можете использовать этот код CMD в своей работе агента. Эта работа должна быть создана с нуля.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Индекс обслуживания задания. Я бы посоветовал начинать с плановой казни раз в месяц. Вы можете начать со значениями по умолчанию, которые Ola предоставляет для задания IndexOptimize.

Есть несколько причин, по которым я предлагаю первую работу для обновления статистики отдельно:

• Перестройка индекса будет обновлять только статистику столбцов, охватываемых этим индексом, в то время как реорганизация индекса вообще не обновляет статистику. Ола разделяет фрагментацию на три категории. По умолчанию будут перестроены только индексы с высокими категориями.
• Статистика для столбцов, не охватываемых индексом, будет обновляться только заданием IndexOptimize.
• Для смягчения восходящей ключевой проблемы .

SQL Server автоматически обновит статистику, если оставить значение по умолчанию включенным. Проблема с этим - пороги (меньше проблемы с вашим SQL Server 2016). Статистика обновляется при изменении определенного количества строк (20% в более старых версиях SQL Server). Если у вас большие таблицы, перед обновлением статистики может произойти много изменений. Смотрите больше информации о порогах здесь .

Поскольку, насколько я могу судить, вы делаете CHECKDB, вы можете продолжать делать их как раньше или использовать для этого также решение по обслуживанию.

Для получения дополнительной информации о фрагментации и обслуживании индекса смотрите:

Обзор фрагментации индекса SQL Server

Хватит беспокоиться о фрагментации SQL Server

Рассматривая вашу подсистему хранения, я бы посоветовал не зацикливаться на «внешней фрагментации», потому что в любом случае данные хранятся не по порядку в вашей SAN.

Оптимизируйте свои настройки

Скрипт sp_Blitz дает вам отличный список для начала.

Приоритет 20: Конфигурация файла - TempDB на диске C: поговорите с администратором хранилища. Спросите их, является ли ваш диск C самым быстрым диском, доступным для вашего SQL Server. Если нет, поместите свою базу данных там ... точка. Затем проверьте, сколько у вас есть файлов temdb. Если ответ один исправить это . Если они не одинакового размера, исправьте это два.

Приоритет 50: Информация о сервере - мгновенная инициализация файла не включена: перейдите по ссылке, которую дает вам скрипт sp_Blitz, и включите IFI.

Приоритет 50: Надежность - проверка страницы не оптимальна: вам следует установить значение по умолчанию (CHECKSUM). Перейдите по ссылке, которую дает скрипт sp_Blitz, и следуйте инструкциям.

Приоритет 100: Производительность - изменен коэффициент заполнения. Спросите себя, почему существует так много объектов с коэффициентом заполнения, равным 70. Если у вас нет ответа, и ни один из поставщиков приложений не требует его строго. Установите его обратно на 100%.

Это в основном означает, что SQL Server оставит 30% свободного места на этих страницах. Таким образом, чтобы получить тот же объем данных (по сравнению со 100% полных страниц), ваш сервер должен прочитать на 30% больше страниц, и они будут занимать на 30% больше места в памяти. Это часто делается для предотвращения фрагментации индекса.

Но опять же, ваше хранилище в любом случае сохраняет эти страницы в разных блоках. Поэтому я бы установил его обратно на 100% и взял бы оттуда.

Что делать, если все счастливы:

• Посмотрите остальные выходные данные sp_Blitz и решите, если вы измените их, как предложено.
• Выполните sp_BlitzIndex и посмотрите на созданные вами индексы, если они используются или где есть возможность добавить / изменить один из них.
• Взгляните на данные своего магазина запросов (как предложено Питером). Вы можете найти введение здесь .
• Наслаждайтесь жизнью рок-звезды, которой заслуживает администратор БД. ;)

Не принимая во внимание все ваши ответы, которые были очень полезны и которые я применял или буду применять, найти самую большую проблему было нелегко.

Проблема усугубилась через несколько дней после наших последних сообщений.

Поскольку мы основаны на облаке, ни я, ни компания, которая управляет инфраструктурой и оказывает нам поддержку, не имеют доступа к физическим хостам.

Что-то заставило меня задуматься, когда я заметил, что в некоторые дни процессор в среднем составлял 20%, а в другие дни он был намного выше, более 60%, когда рабочая нагрузка, хотя и не всегда была одинаковой, схожа. Есть такое же количество людей, которые выполняют более или менее одинаковые операции.

Ранее на этой неделе пользователи начали зависать на несколько минут, и был задушен только процессор. Я попросил нескольких пользователей выйти из системы (тех, кто тратил больше ресурсов, но все еще ничего необычного), я отключил различные службы, связанные с базой данных, и в итоге ничего не изменилось. Я попросил сисадмина, который поддерживает нас и который может общаться с ребятами из нашего облака, чтобы я мог удаленно посмотреть на мою машину, чтобы увидеть то, что я вижу, и помочь мне найти что-то, потому что я не мог лучше найти проблему.

Техник тоже ничего не нашел. Наконец он начал объяснять мне причину, по которой что-то еще должно было вызывать эту проблему, и это произошло, когда он связался с облаком. В облаке они ничего не поняли, просто потому, что настроена балансировка нагрузки между физическими хостами, виртуальная машина, которая поддерживает наш SQL Server, в этот день несколько раз перемещалась между физическими хостами. К счастью, я сообщил нашему технику точно, в какое время проблемы начали возникать в тот день, что совпало с моментом, когда виртуальная машина была перемещена в последний раз на один из физических хостов, с которого она не покидала оставшуюся часть дня.

Если технический специалист не внимательно следил за этой проблемой, это был бы еще один из тех случаев, когда он мог даже поговорить с облачными парнями, но когда они увидели образцы производительности, они ничего не получили бы, потому что облако снова увидело только выборки с процессором порядка 40/50%, когда на самом деле оно было в среднем выше 80% и часто зависало на 100%.

Теперь машина стоит на физическом хосте (не перемещается между хостами), и хотя мы еще не достигли идеальной производительности, все работают и дают гораздо больше положительных отзывов, потому что средний ЦП составляет около 20% со всеми нашими пользователями и Сервисы.

Тем временем мы также поместили базу данных tempdb на другой диск (он был на диске с операционной системой) и увеличили файлы, чтобы они больше соответствовали количеству ядер процессоров.

Количество ядер также было скорректировано на основе рекомендаций sp_Blitz.

Была также автоматическая процедура, которая выполнялась весь день на основе старой даты ... и, поскольку она не заканчивалась утром, когда мы приехали, и у нас нет возможности проверить, работает ли она или нет, я все еще начал запустить вручную. Но, вероятно, другой все еще работал и работал в течение этого времени дважды. Мы изменили дату, чтобы сократить время, необходимое, и теперь уже поздно ночью. Но это не было решением, так как оно было решено до того, как у нас возникло много проблем, описанных здесь.

Нам также удалось заставить ассистента ERP запланировать встречу с производителем, поэтому мы собираемся показать нашу систему и найти предложения, а также прояснить некоторые сомнения, поскольку в обучающих видеороликах есть рекомендации, которые противоречат большинству рекомендации, в том числе сама Microsoft, такие как Приоритетное повышение и Fill Factor 70%.

Поскольку приложение также имеет экран обслуживания, я буду искать необходимую периодичность обслуживания и то, что остается делать вне приложения. Моя идея - использовать планы Олы Хелленгрен.

Я считаю, что ответ Томаса Кронавиттера абсолютно правильный, и я применяю его, однако, я думаю, что это описание может быть важно для других людей, которые после применения всех передовых методов все еще не могут решить проблему, потому что это может быть в физических хостах , Спасибо Томас.