У нас возникли проблемы, вызванные, по нашему мнению, разногласиями в tempDB.
Всякий раз, когда у нас возникают проблемы, наша система всегда ожидает одного конкретного ресурса: 2: 1: 103, который, когда мы ищем его (используя DBCC PAGE (2,1,103)), отслеживает возврат к object_id 75, который является системной таблицей sysmultiobjrefs .
Чтобы решить эту проблему, нам иногда удается убрать висящие spid-пакеты, ожидающие на этом ресурсе ... в худших случаях мы должны фактически остановить SQL и запустить его обратно.
Есть идеи, как это облегчить?
Мы запускаем SQL 2005 SP3 x64 на сервере quad / quad с 128 ГБ ОЗУ. Диски также находятся в сети SAN с log / tempdb / data, каждый на своем собственном диске RAID 1/0.
TempDB имеет 16 файлов данных (по одному для каждого ядра) и один файл журнала.
Заранее спасибо.
Я понимаю, что опаздываю на вечеринку, но на этой неделе моя команда проиграла со счетом 2: 1: 103. По сути, конфликт за этот ресурс указывает на конкуренцию с операциями DDL в базе данных tempdb и вызван созданием / удалением слишком большого количества временных таблиц или переменных временных таблиц. Я писал об этом в блоге http://www.mattwrock.com/post/2011/09/10/Latch-waits-on-21103-You-are-probably-creating-too-many-temp-tables-in-Sql-Server.aspx Разногласия здесь не будут устранены с помощью флага трассировки T1118 или добавления файлов в tempDb. Ключ состоит в том, чтобы либо уменьшить использование временных таблиц и переменных временных таблиц, либо оценить контекст их использования, чтобы увидеть, кэшируются ли они. Видеть http://technet.microsoft.com/en-us/library/cc966545.aspx подробности здесь.
Роб,
В нашем окружении мы занимаемся его проблемой 2: 1: 103 около месяца. Один из способов предотвратить эту проблему - периодически перезапускать службу SQL, если это возможно. На многих форумах не было четкого ответа на этот конкретный вопрос. Флаг T1118 не был назван эффективным в аргументах, выдвинутых Линчи Шеа (MVP) и несколькими другими в их блогах.
Один производственный сценарий, в котором я лично видел, как проблема возникла и исчезла, был, когда SQL-сервер получил возможность увеличить объем памяти с 24 ГБ до 27 ГБ. На 24 ГБ было около 40 процессов, зависших на 2: 1: 103, в то время как несвязанное задание задачи выполнялось на сервере db. Я убил эту задачу, и SQL начал забирать больше памяти из доступных 30 ГБ, конфликт Tempdb постепенно исчез на 27 ГБ примерно через минуту после того, как он получил 27 ГБ. Это одна из областей, которую вы можете попробовать проверить самостоятельно. Уменьшите следы других сервисов на сервере БД и увеличьте максимально доступную память для SQL.
Дайте мне знать, если вы найдете другое решение для того же.
Сингх.
У вас много операторов SELECT INTO в вашем коде SQL? Это вызовет блокировку нескольких системных объектов tempdb, пока оператор SELECT INTO не будет завершен.
Вы проверяли, не возникают ли тупиковые ситуации из-за того, что транзакции наступают на работу друг друга? Проверяли ли вы запущенные / заблокированные SQL-запросы при возникновении блокировки?
Вы пробовали включить флаг трассировки T1118?
Цитата из статьи:
Примечание. Флаг трассировки -T1118 также доступен и поддерживается в Microsoft SQL Server 2005 и SQL Server 2008. Однако, если вы используете SQL Server 2005 или SQL Server 2008, вам не нужно устанавливать какие-либо исправления.
Увеличьте количество файлов данных tempdb, по крайней мере, равное количеству процессоров. Кроме того, создавайте файлы одинакового размера. Для получения дополнительной информации см. Раздел «Дополнительная информация».
Раньше была проблема производительности с флагом трассировки T1118 в SP2, но Ms выпустила исправление, и оно должно быть исправлено в SP3, как и в вашем случае.
Я согласен с mrdenny относительно того, как создаются временные таблицы, вы никогда не должны создавать соблазн с помощью SELECT * INTO #x FROM TableA, если у вас нет такого предложения WHERE:
ГДЕ 1 = 2
Но я рекомендую использовать синтаксис CREATE TABLE #x. Зачем? SQL будет устанавливать множество блокировок в системных таблицах, пока ваш запрос пытается получить данные для вставки в вашу временную таблицу. Если вы используете предложение where, которое, очевидно, не возвращает никаких строк или синтаксис создания таблицы, блокировки будут удерживаться в течение короткого периода времени.
/ Хокан Винтер