Перестройка индекса Задачи Прерывания Завершение хранимой процедуры

Question

Перестройка индекса Задачи Прерывания Завершение хранимой процедуры

1

У меня есть план обслуживания, который выполняется на моем сервере SQL Server 2008 каждое утро до рабочего времени. Он был введен в действие несколько лет назад, чтобы помочь с некоторыми проблемами производительности. Проблема, которую я вижу, заключается в том, что после завершения индекса перестроения в одной из баз данных будет храниться процедура, которая пройдет от девяти секунд до запуска до семи минут.

Решение, которое я решил исправить, заключается в том, чтобы открыть SQL Management Studio и запустить:

EXEC sp_recompile N'stored_proc_name';
EXEC stored_prod_name @userId=579

После того, как я запустил это, SP исправляет себя и возвращается к работе менее девяти секунд.

Я попробовал пару различных путей для автоматизации этого, но он будет работать, только если я запустил его с моего компьютера через студию управления. Я попытался завершить его в небольшом исполняемом файле С#, который запускался через несколько минут после завершения задания индекса пересоединения, но это не сработало. Я также попытался создать задание SQL для запуска его на сервере после завершения задания индекса пересоединения, но это тоже не сработало. Его нужно запустить из студии управления.

Итак, два вопроса:

Как я могу остановить восстановление индекса от взлома моих SP, или,
Любые идеи о том, как и почему мое быстрое решение будет работать только в очень конкретной ситуации?

Спасибо, Майк

Mike 09 июнь 2014, в 20:42

Источник

0

Вы после быстрого исправления или после более тщательного решения? Вы, вероятно, должны настроить proc, чтобы не было проблем с планом. Существует несколько распространенных решений, таких как OPTION (RECOMPILE) и OPTIMIZE FOR UNKNOWN .
usr 09 июнь 2014, в 17:57
0

На самом деле, дело не в том, что задача «перестроить индекс» нарушает хранимую процедуру; Дело в том, что это приводит к тому, что кэш плана запросов становится недействительным, и сразу после этого новый план запроса становится кэшированным с предвзятыми данными, в результате чего для большей части работы используется неоптимальный план запроса.
Marc Gravell♦ 09 июнь 2014, в 18:06

Теги:

sql-server

c#

stored-procedures

sql

sql-server-2008

1 ответ

Ещё вопросы

Вы после быстрого исправления или после более тщательного решения? Вы, вероятно, должны настроить proc, чтобы не было проблем с планом. Существует несколько распространенных решений, таких как OPTION (RECOMPILE) и OPTIMIZE FOR UNKNOWN .
На самом деле, дело не в том, что задача «перестроить индекс» нарушает хранимую процедуру; Дело в том, что это приводит к тому, что кэш плана запросов становится недействительным, и сразу после этого новый план запроса становится кэшированным с предвзятыми данными, в результате чего для большей части работы используется неоптимальный план запроса.

Marc Gravell · Accepted Answer · 2014-06-09T15-35-00.000Z

Это похоже на стандартное кэширование запросов-параметров на основе параметров. Трюк здесь обычно заключается в использовании подсказки OPTIMIZE FOR/UNKNOWN - либо для конкретного параметра, вызывающего проблему, либо просто для всех параметров. Это значительно снижает вероятность того, что значение параметра с смещенным распределением отрицательно повлияет на систему для других значений. Более экстремальный вариант (более полезный при использовании командного текста, не столь полезный при использовании хранимых процедур) заключается в том, чтобы вставлять значение непосредственно в TSQL, а не использовать параметр. Это... оказывает влияние, однако, и должно использоваться с осторожностью.

В вашем случае я подозреваю, что добавление:

OPTION (OPTIMIZE FOR (@userId UNKNOWN))

в конце вашего запроса это исправит.