Хронирование хранимых процедур

Question

У меня есть веб-сервис, который вызывает хранимую процедуру из БД MS-SQL2005. У моего веб-сервиса было время ожидания вызова одной из хранимых процедур, которые у меня были (она работала в течение нескольких месяцев без перерывов), поэтому я попытался запустить запрос в Query Analyzer, который также истек. Я решил удалить и воссоздать хранимую процедуру без изменений в коде, и она снова начала выполняться ..

Вопросы:

Это обычно ошибка в TSQL моей хранимой процедуры?

-Или-

Кто-нибудь видел это и обнаружил, что это вызвано какой-то проблемой с компиляцией хранимой процедуры?

Также, конечно, приветствуются любые другие идеи по этому вопросу.

Аналогично:

• Плохая производительность плана выполнения хранимых процедур в SQL - сниффинг параметров
• Обнаружение параметров (или спуфинг) в SQL Server

Answer 1

Обновляете ли вы свою статистику в базе данных? Это похоже на то, что оригинальный SP использовал устаревший план запросов. sp_ перекомпиляция могла бы помочь, а не сбросить / воссоздать его.

Answer 2

Есть несколько вещей, которые вы можете сделать, чтобы исправить / диагностировать это.

1) Обновляйте свою статистику на регулярной / ежедневной основе. SQL генерирует планы запросов (думаю, оптимизирует) на основе вашей статистики. Если они «устареют», ваша хранимая процедура может работать не так, как раньше. (особенно когда ваша база данных меняется / растет)

2) Посмотрите вашу хранимую процедуру. Вы используете временные таблицы? Есть ли в этих временных таблицах индексы? Большую часть времени вы можете найти виновника, посмотрев хранимую процедуру (или таблицы, которые она использует)

3) Проанализируйте вашу процедуру, пока она "зависает", взгляните на план запроса. Есть ли какие-либо недостающие индексы, которые помогли бы не дать плану вашей процедуры сойти с ума. (Ищите такие вещи, как сканирование таблицы и другие ваши самые дорогие запросы)

Это похоже на поиск имени в телефонной книге, обязательно читайте каждое имя быстро, если ваша телефонная книга состоит только из 20 или 30 имен. Попробуйте сделать это с миллионами имен, это не так быстро.

Answer 3

Это случилось со мной после перевода нескольких сохраненных процедур из разработки в производство. Это произошло не сразу, а после того, как производственные данные выросли за пару месяцев. Мы использовали функции для создания столбцов. В некоторых случаях было несколько вызовов функций для каждой строки. Когда данные росли, время вызова функции также увеличивалось.

Первоначальный подход был хорошим в тестовой среде, но потерпел неудачу при большой нагрузке. Проверьте, есть ли какие-либо вызовы функций в процедуре.

Answer 4

Параметр сниффинг.

Ответил день или 3 назад: " странная проблема производительности отчета сервера SQL, связанная со статистикой обновления "

Answer 5

Если он работал быстро, он (по прошествии нескольких месяцев) больше не работает быстро, и код не был изменен, то, вероятно, изменились базовые данные.

• Моим первым предположением будет увеличение объема данных - за последние несколько месяцев (или за последние несколько часов, вы никогда не знаете) было добавлено так много данных, что запрос сейчас не работает.
• В качестве альтернативы, как предполагает CodeByMoonlight, данные могут со временем измениться настолько, что исходный план запроса, созданный для процедуры, больше не годится (хотя это предполагает, что план запроса вообще не очищался и не перекомпилировался в течение длительного периода времени). времени).
• Аналогично статистика индекса / базы данных также может быть устаревшей. Включена или отключена функция AutoUpdateSatistics для базы данных?

Опять же, это может помочь только в том случае, если с течением времени ничего не изменилось.

Answer 6

Я думаю, что таблица, которую пытается использовать SP, заблокирована каким-то процессом. Используйте "exec sp_who" и "exec sp_lock", чтобы узнать, что происходит с вашими таблицами.