Извините, что долго, но я хочу дать вам как можно больше информации, которая может быть полезна для анализа.
Я знаю, что есть несколько постов с похожими проблемами, однако я уже следил за этими постами и другой информацией, доступной в Интернете, но проблема остается.
У меня серьезная проблема с производительностью в 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 советы, но я не смог их включить из-за ограничения символов. Если есть другой способ поделиться, пожалуйста, укажите.)