Суперечка DDL на TempDB

У мене є стандарт S64 Server 2005 x64, який протягом останніх кількох місяців відчуває проблеми із суперечкою DDL в TempDB. Сервер буде відчувати суперечки на ресурсі очікування 2: 1: 103 (тип очікування - PAGELATCH_EX).

Здається, проблема виникає епізодично, коли сервер знаходиться під гідним навантаженням. Я спостерігав за темпом "Темп-таблиць для знищення", і він може підскочити до 5000+ під час, коли у нас є проблеми PAGELATCH_EX на 2: 1: 103. З того, що я читав, цей лічильник повинен становити 0 більшість часу, але наш, здається, залишається десь від 300-1100 більшість часу. Лічильник лише 0, коли користувачів в системі дуже мало.

Як я можу звузити те, що викликає суперечки DDL на tempdb, не потребуючи шукати голку в стосі сіна?

Я бачив саме цю проблему, і виправлення, яке в кінцевому підсумку було випущено, щоб виправити це, насправді був прямим результатом мого випадку з Microsoft CSS. Немає публічної статті KB для виправлення. Переконайтеся, що ви застосували Service Pack 4 та останнє накопичувальне оновлення до SQL Server (на момент написання, це сукупне оновлення №3 (9.00.5259) ).

Поки виправлення не було випущено, пропозиція Microsoft полягала в тому, щоб просто припинити створювати таблиці #temp (приблизно як KB # 916086 ). Оскільки це означало б істотне переписування десятків і десятків процедур звітності, рішення в моєму випадку (незалежно від прапорців трасування або макета файлу тимчасового режиму) було перезапустити наш кластер через кожні інші вихідні. Гидота.

Для того, щоб відстежити використання tempdb, існує кілька сценаріїв, які можуть допомогти, наприклад, див. Sp_whoIsActive Адама Маханіка , зокрема:

• sp_whoisactive: Аналіз суперечок Tempdb
• Як визначити, який запит заповнює журнал транзакцій tempdb?

А також цей сценарій (і ті, що в коментарях) від @SQLSoldier:

• Порушення суперечки TempDB

Я б переконався, що всі ваші курсори використовують LOCAL STATIC READ_ONLY FORWARD_ONLY(див. Це і це ), і переконаюся, чи існують відомі дорогі запити, які широко використовують таблиці #temp / змінні @table, CTE, чи можуть містити непотрібні сорти або призводити до хеш-з'єднань. ... все це може сприяти проблемі (я сумніваюся, ви знайдете одну золоту справу). Найпростішим виправленим виправленням як початковою точкою "вибух для вашого долара" буде використання правильних і недорогих параметрів курсору замість значень за замовчуванням.

Тим часом я б (а) встановив CU №3 та (b) зателефонував до PSS. Скажіть їм, що ви маєте дуже специфічне виправлення, яке вже було підтверджено як помилка та було видано іншим користувачам як приватне виправлення: "VSTS # 109112 - відкладене падіння таблиці темпів не масштабує для певних навантажень". Можливо, вам доведеться сплатити судовий збір спочатку, але, оскільки це помилка, стягнення потрібно повернути.

Вам, напевно, потрібен прапор сліду 1118

Дивіться спочатку міфи Пола Рандала про tempdb , а також його статтю TF 1118

Коефіцієнт TF описаний тут у KB 328551

Я не маю прямого досвіду цього, але це звучить як я прочитав

Я припускаю, що ви вже розділили свої файли даних TempDB, щоб спробувати полегшити суперечки (очевидно, попередньо перед виробництвом). Якщо ви хоробріші, розгляньте прапор сліду, на який автором посилається Пол Рандал: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-повинен завжди мати-один-файл-дані-на-процесор-core.aspx

Що стосується того, що спричиняє біль, вам потрібно виконати деякі слідчі роботи:

• це тільки почало відбуватися? що змінилося?
• чи знаходиться сервер під тиском пам'яті, тому сортування потрібно робити в TempDB?
• Чи є якісь процеси DBA, такі як CheckDB, або запущена онлайн реіндексація?
• чи використовуються більш екзотичні рівні ізоляції чи сервіс-брокер? подивитися на sys.databases

Внизу цього документа Microsoft TempDB є приємний запит, щоб спробувати розробити те, що використовується tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Якщо ви все ще хочете відстежити це, у мене нещодавно виникла така ж дивна проблема продуктивності із синхронними краплями таблиці. Якщо у вас є велика кількість баз даних (> 100 або більше) на екземплярі sql, на якому працює SQL 2005, і у вас є багато заяв про створення та падіння таблиці темп, ви можете отримати повільні краплі таблиці темп. Перевірка підрахунку рядків, повернута з sys.dm_db_index_usage_stats, може виключати це вже зараз як винуватця.

Стаття KB описує проблему. http://support.microsoft.com/kb/2003031

Продуктивність запитів знижується, коли sys.dm_db_index_usage_stats має велику кількість рядків

Розглянемо наступний сценарій:

У Microsoft SQL Server 2005 ви часто виконуєте операції DDL, які передбачають скидання та відтворення багатьох таблиць (особливо тимчасових таблиць у базі даних tempdb). У динамічному управлінні sys.dm_db_index_usage_stats (DMV) ви маєте велику кількість записів (100 000 або більше).

Взяте з моєї прийнятої відповіді на це питання. Там є ще кілька деталей. Повільний стіл темп падає в sql 2005 року