Хранимая процедура Sql Server 2000 Предотвратить параллелизм или что-то?

Question

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

Я точно знаю, что если я возьму тело хранимой процедуры, а затем объявлю / установлю значения параметров и запустю его в анализаторе запросов, он будет работать более чем в 20 раз быстрее.

Из Интернета я читал, что это, вероятно, связано с плохим планом кэшированных запросов. Итак, я попытался запустить sp с «WITH RECOMPILE» после EXEC, и я также попытался поместить «WITH RECOMPLE» в sp, но ни один из них не помог даже немного.

Когда я смотрю на план выполнения sp и запроса, самое большое различие заключается в том, что sp имеет повсеместно выполняемые операции "Parallelism", а в запросе их нет. Может ли это быть причиной разницы в скоростях?

Спасибо, любые идеи были бы великолепны ... Я застрял.

Answer 1

Если единственное различие между двумя планами запросов - это параллелизм, попробуйте поставить OPTION (MAXDOP 1) в конце запроса, чтобы ограничить его последовательным планом.

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

Последовательность v и параллель определенно могут объяснить разницу в скоростях. В SQL Server 2000 для параллельных планов используются все процессоров на компьютере , а не только те, которые ему необходимы:

Если SQL Server решает использовать параллелизм, он должен использовать все настроенные процессоры (как определено конфигурацией подсказки запроса MAXDOP) для выполнения параллельного плана. Например, если вы используете MAXDOP = 0 на 32-стороннем сервере, SQL Server пытается использовать все 32 процессора, даже если семь процессоров могут выполнять работу более эффективно по сравнению с последовательным планом, в котором используется только один процессор. Из-за этого поведения «все или ничего», если SQL Server выбирает параллельный план и вы не ограничиваете подсказку запроса MAXDOP [...], время, которое требуется SQL Server для координации всех процессоров на высокопроизводительном сервере перевешивает преимущества использования параллельного плана.

По умолчанию, я считаю, что для всего сервера значение MAXDOP равно 0, что означает использование максимально возможного количества. Если вы недавно обновили свой сервер базы данных, добавив больше процессоров для повышения производительности, это может иронично объяснить, почему ваша производительность страдает. Если это так, вы можете попытаться установить подсказку MAXDOP для числа процессоров, которые у вас были раньше, и посмотреть, поможет ли это.

Answer 2

попробуйте добавить SET ARITHABORT ON вверху процедуры.

как видно здесь: https://stackoverflow.com/questions/2465887/why-would-set-arithabort-on-dramatically-speed-up-a-query

Answer 3

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

Answer 4

Может ли быть проблема с раздором? Выполняется ли эта процедура хранения в определенное время, когда также происходит другой тяжелый подъем?

Answer 5

Я знаю, что если я возьму тело хранимая процедура, а затем объявить / установить значения параметры и запустить его в запросе анализатор, который работает более 20 раз быстрее.

Вы уверены, что не получение этих параметров перед выполнением SP не вызывает вашу медлительность? В обход популяции параметров вы могли бы упростить вашу проблему.

Откуда эти параметры? Как они заселены? Судя по вашему вопросу, вы изолировали хранимый процесс и выяснили, что это не проблема.