Зміст TempDB

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

1. Перезапустіть екземпляр і вже через хвилину він почне поводитись так само.

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

Примітка: Ми використовуємо змінні таблиці для проміжних наборів результатів. Ці набори результатів дуже малі.

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

Ласкаво допоможіть нам знайти постійне рішення.

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

Екземпляр знаходиться на фізичній машині. Запити із табличними змінними та запити з Hash Joins найчастіше генерують очікування IO_Completion.

Детальна відповідь від wBob підштовхнула нас до пошуку детальніше. Як ми пропустили його раніше:

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

Це ми виявили в журналі, коли виникає такий тип проблем. Ми переміщуємо TempDB, щоб розділити швидкий диск.

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

Питання / Потрібна додаткова інформація

• Підтвердьте ім'я та тип процесора (я в основному намагаюся встановити, чи це 2-х шістнадцятковий ядро ​​з HT). Для підтвердження скористайтеся інформацією про систему (наприклад, Панель управління> Система та безпека> Система на Windows Server 2012 R2) та / або інструмент системних підключень 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 2 вузла) між одним диском (домашнім ПК)? Подумайте про додавання дисків, смугастих, SSD для tempdb (хоча уникайте зайвої реакції:) .
• Будь ласка, додайте фактичний план виконання для одного з проблемних запитів. Анонімізуйте програму SQL 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) на повідомлення, наприклад, попередження IO.

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

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

Удачі. Дайте нам знати, як ви дістаєтесь.