Сервер баз данных 100%, без причины

Question

У нас Windows Server 2003 (x64) работает как сервер базы данных. База данных оснащена 32 ГБ оперативной памяти

Обычно использование памяти базы данных (диспетчер задач) составляет 5-10%. Однако иногда база данных внезапно запускается до 100% и остается там, случайным образом и без каких-либо изменений в коде или выполнении.

Все виды исследований, платные или мной, указывают на одну хранимую процедуру. Когда база данных на 100%, отключение этой процедуры вернет базу данных в нормальное состояние.

Теперь это звучит довольно очевидно, но вот странная часть.

Хранимая процедура оптимизирована, и использование памяти (из плана выполнения) составляет 0,01, что исключительно хорошо. Обычно выполнение хранимой процедуры мгновенно возвращает набор результатов. Я также заплатил администратору службы поддержки RackSpace Fanatic за это, и он сказал, что не видит проблем с хранимой процедурой.

Теперь дополнительный странный бит.

• Запуск SP происходит мгновенно.
• Когда DB равен 100%, запуск SP продолжает выполнение в течение минут за минутами.
• Отключая SP, отправляет БД на 5-10%.
• Хотя SP включен, DB равен 100%, если я открываю новое окно запроса и запускаю EXACT код из SP, но как запрос, а не как SP, результаты снова возвращаются МОМЕНТАЛЬНО

Итак, хотя на первый взгляд кажется, что SP нуждается в оптимизации, реальный код в SP не является проблемой.

Я в отчаянии!

Answer 1

План выполнения может меняться в зависимости от входных параметров SP и размера результирующего набора.

Вы можете попытаться добавить WITH RECOMPILE к хранимой процедуре, чтобы получить новый план выполнения для каждого вызова. Это сделает его немного медленнее, но иногда SQL Server застревает с необычно плохим планом выполнения для большинства запросов, и в этих сценариях помогает перекомпиляция.

Answer 2

Profiler:

SQL Server поставляется с отличным инструментом под названием Profiler, который позволяет в реальном времени просматривать запросы, выполняемые на сервере. Вы должны запустить профилировщик и выяснить, что на самом деле происходит, и использовать это, чтобы найти виновника.

Существует 4 измерения для запросов: память, процессор, чтение, запись. Операторы SQL, которые занимают много из них (по отдельности или в сочетании) и вызываются с высокой частотой, являются наилучшими кандидатами для оптимизации.

Как только вы запустите профиль и получите выходные данные, вы сможете определить элементы для оптимизации. Затем вы можете запустить операторы SQL, просмотреть планы выполнения и выполнить необходимую оптимизацию.

(редактирование: добавлено содержание)

Возможно, это не сам оператор, который не является оптимальным, а некоторые блокировки / блокировки / взаимоблокировки, которые могут вызвать это. На сервере может одновременно работать что-то еще, что потребляет ресурсы, необходимые для этого SP, и вызывает скачок в CPU.

Читать на Profiler:

http://msdn.microsoft.com/en-us/library/ms187929.aspx