TempDB утверждения

У нас есть активная база данных OLTP 40GB на SQL Server 2014 SP1. Обнаружено, что запросы выполняются медленно: ожидания IO_Completion, длина очереди диска увеличиваются до 900, а SQL Server перестает отвечать на запросы. Что мы пробовали:

1. Перезапустите экземпляр, и через минуту он начнет работать так же.

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

Примечание. Мы используем табличные переменные для промежуточных наборов результатов. Эти наборы результатов очень малы.

Это случилось два раза в месяц. Каждый раз, когда я вручную добавляю немного места к файлам данных, он начинает работать нормально. Более интересно то, что те же настройки (то же самое оборудование, те же настройки папок и файлов, та же рабочая нагрузка), что и у нас в SQL Server 2008 R2 и SQL Server 2012, работают нормально.

Пожалуйста, помогите нам найти постоянное решение.

Начальный размер всех файлов данных - 1000 МБ, текущий - 1500 МБ каждый. Все идентичны. Автовыбор составляет 100 МБ для каждого. До этого мы сталкивались с конфликтом страниц PFS и GAM, и мы увеличились до 16, и проблема была решена. Оба флага трассировки 1117 и 1118 включены. 24 ядра на 2 узлах NUMA. Все файлы данных находятся на одном и том же томе. Простой диск, без SAN.

Экземпляр находится на физической машине. Запросы с табличными переменными и запросы с хеш-соединениями чаще всего генерируют ожидания IO_Completion.

Подробный ответ от wBob подтолкнул нас к поиску более подробно. Как мы пропустили это раньше:

Автоматический рост файла 'templog' в базе данных 'tempdb' был отменен пользователем или истек по истечении 7704 миллисекунд. Используйте ALTER DATABASE, чтобы установить меньшее значение FILEGROWTH для этого файла или явно установить новый размер файла.

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

Я думаю, что вы перефрагментировали свою базу данных tempdb, и существует несоответствие между процессором сервера и настройкой диска, но давайте соберем немного больше информации:

Вопросы / Требуется дополнительная информация

• Пожалуйста, подтвердите имя и тип процессора (я в основном пытаюсь установить, если это 2 х шестнадцатеричный с HT). Используйте Системную информацию (например, Панель управления> Система и безопасность> Система в Windows Server 2012 R2) и / или инструмент sysinternals CoreInfo для подтверждения.
• Пожалуйста, подтвердите сервер maxdop (например EXEC sp_configure 'max degree of parallelism'). Если процессоры являются шестнадцатеричными, maxdop сервера должен быть не более 6 (как здесь ) или, возможно, ниже в системе OLTP. Обычно я держу свои файлы tempdb в соответствии с моим DOP на сервере максимум до 8, но мы придем к этому.
• Пожалуйста, подтвердите общий объем памяти сервера на коробке и ограничение памяти SQL Server (например EXEC sp_configure 'max server memory (MB)').
• Пожалуйста, подтвердите, если какие-либо другие службы работают на коробке (например, SSIS, SSAS, SSRS, приложение, iTunes и т. Д.)
• Убедитесь, что для учетной записи службы SQL Server включена функция мгновенной инициализации файла. (Способы проверить это здесь ).
• Почему существует такое большое расхождение между ЦП (настройка NUMA с двумя узлами) и одним диском (домашний ПК)? Попробуйте добавить диски, чередование, SSD для базы данных tempdb (хотя избегайте чрезмерной реакции :) .
• Пожалуйста, добавьте фактический план выполнения для одного из проблемных запросов. Если хотите, анонимизируйте в SQL Sentry Plan Explorer .

• Хэш соединяется с табличными переменными в системе OLTP? Это говорит об отсутствии индексации для переменной таблицы, основной таблицы или обоих. Вы объявляете свои переменные таблицы как это (без индексов)?

  DECLARE @t TABLE ( x INT )

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

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• Размещение плана выполнения поможет диагностировать это.

• Проверьте код, предотвращающий кэширование табличных переменных, как здесь , здесь . Я думаю, что динамический SQL и proc, выполняемые с помощью RECOMPILE, являются единственными, которые влияют на переменные таблицы.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Проверьте журнал SQL Server (Обозреватель объектов> Управление> Журналы SQL Server) на наличие сообщений, например предупреждений ввода-вывода.

• Проверьте Windows Event Viewer
• Начиная с SP1 выпущено несколько сборок. Просмотрите исправления CU, введенные начиная с SP1 . Вполне возможно, что ошибки в SP1 исправлены в последующих CU, например, FIX: оператор сортировки выливается в базу данных tempdb в SQL Server 2012 или SQL Server 2014, когда предполагаемое количество строк и размер строки указаны правильно https://support.microsoft.com/en- нас / кб / 3088480
• Убедитесь, что это ваша причина, прежде чем устанавливать какие-либо исправления, хотя более важно поддерживать актуальность CU с SQL Server 2014 из-за ряда новых функций (OLTP в памяти, кластерное хранилище столбцов).
• Наконец, потребность в одном файле tempdb для каждого ядра - это миф, и, глядя на настройки вашего диска, я думаю, что tempdb слишком фрагментирован. У меня есть ноющее чувство, что у вас одна головка диска, у tempdb одна файловая группа, много файлов.

Однако забудьте, что мы думаем, что знаем; создайте испытательный стенд, который воспроизводит вашу проблему, и поэкспериментируйте с уменьшением количества временных файлов ... начните с 1, 2, 4, 6 и т. д., соберите информацию, чтобы принять обоснованное решение. Теперь это сложнее, так как ваша проблема кажется неустойчивой, и вы, возможно, не сможете возиться с настройкой tempdb, но я бы так и решил.

Удачи. Дайте нам знать, как вы поживаете.