SQL Server глобальное замедление 2005 года

Два дня назад наш рабочий сервер перенес крупное замедление, где основной признак был то, что чрезвычайно высокое количество запросов переносило SQLTimeouts. Я быстро опишу нашу установку, что я исследовал, наше обходное решение, и буду затем следовать со своим вопросом.

Наша установка

Пара серверов размещает это ответвление нашего приложения SAS. Один являющийся сервером приложений, запускающим несколько приложений на IIS и другом, тот, который перенес замедление, является полем Windows Server 2008, выполняющим SQL-сервер 2005. SQL размещает где-нибудь между 100 и 200 базами данных.

Проблема / расследование

Сервис в значительной степени останавливается. Некоторые запросы проходят, но большинство переносит тайм-ауты SQL. Машина SQL ЦП и RAM выглядит хорошо, составляющая в среднем приблизительно 25%-я рабочая нагрузка ЦП и 85% RAM. Я не думал для проверки активности диска в то время, когда я перешел прямо к 'ДОЛЖНОСТНОМУ ЛИЦУ sp_who2'

Результат показал сотни задач, заблокированных идентификатором 123, который был самостоятельно и со ста другими, заблокированными идентификатором 456. Нормальное выполнение обычно не имеет никаких задач блокирования вообще. Когда я повторно выполнил sp_who2 после того, как 15-20 secs, различные идентификаторы блокирования открылись, но сумма блокировала/блокировала, задачи, казалось, оставались такими же. (не считал группы из-за чрезвычайного режима),

Большинство задач блокировалось с операторами, такими как "ВЫБОР В" или "CREATE INDEX на поддающемся соблазну".

Обходное решение

Уничтожьте процесс SQL и перезапустите его для восстановления сервиса. Замедление не вновь появлялось, но мы знаем, что находимся в опасности.

Мой вопрос

Что я могу сделать для решения этой проблемы, предпочтительно прежде чем она будет повторяться?

Дополнительные вопросы:

• Есть ли другой путь, который я могу исследовать во время нормального действия?
• Если/когда проблема повторяется, какую информацию я должен собрать? (Потребности быть быстрым для получения, поскольку это означает, что мы будем испытывать приостановку обслуживания снова),

Что я сделал до сих пор

От признаков мы подозревали, что проблемой была конкуренция некоторого вида на tempdb. (Другой признак был то, что щелчок правой кнопкой по tempdb для наблюдения свойств во время проблемы генерировал ошибку после короткого времени),

Никакие журналы не указали, что автовыращивать событие имело место на tempdb, хотя насколько я знаю, автовырастите, успехи не зарегистрированы, только отказы.

Я считал много других источников информации с тех пор о tempdb конкуренции, не ограниченной, но включая:

http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/ http://www.sqlservercentral.com/blogs/robert_davis/2010/03/05/Breaking-Down-TempDB-Contention/

Из того, что я собираюсь, это - лучшая практика, чтобы иметь начальный размер набора tempdb файлы и иметь один на ядро, до 8 файлов. Это - наш план поместить это на месте (8 ядер, таким образом, 8 файлов) как можно скорее, так как это - лучшая практика. Они все были бы на том же жестком диске (на данный момент), но мы полагаем, что худший случай не является никаким улучшением, и лучший случай, мы получаем различие между логическим состязательным узким местом и диском узкое место ввода-вывода.

Однако мы не можем быть уверены в корреляции с проблемой, которую мы имели. Из того, что я понимаю, разделение в несколько временных файлов помогло бы типу "PAGELATCH_XX", ожидает, но запрос рабочего Paul S. Randal (см. 1-ю отправленную ссылку) во время нормального действия тот тип ожидания отсутствует. Лучшие 3, которые я вижу во время нормального действия:

CXPACKET 68,63%
LATCH_EX 18,46%
PAGEIOLATCH_SH 4,35%

У меня нет способа знать, какое блокирование происходило во время замедления, хотя, так как у нас не было всей этой информации затем.