Конфликт DDL на TempDB

У меня есть SQL Server 2005 Standard x64, в течение последних нескольких месяцев испытывающий проблемы с конфликтом DDL в TempDB. Сервер столкнется с ресурсом ожидания 2: 1: 103 (тип ожидания PAGELATCH_EX).

Эта проблема возникает спорадически, когда сервер находится под достойной нагрузкой. Я следил за частотой «временных таблиц для уничтожения», и она может подскочить до 5000+ во времена, когда у нас возникают проблемы с PAGELATCH_EX 2: 1: 103. Из того, что я прочитал, этот счетчик должен быть равен 0 большую часть времени, но, похоже, у нас он остается где-то в 300-1100 большую часть времени. Счетчик обнуляется только тогда, когда в системе очень мало пользователей.

Как я могу сузить, что вызывает конфликт DDL на базе данных tempdb без необходимости искать иголку в стоге сена?

Я видел именно эту проблему, и исправление, которое в конечном итоге было выпущено, чтобы исправить это, было прямым результатом моего случая с Microsoft CSS. Для исправления нет общедоступной статьи базы знаний. Убедитесь, что вы применили Пакет обновления 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 и (б) вызвал 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.database

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

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

Статья в КБ описывает проблему. 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