|
Изменение уровня совместимости, что-то пошло не так...
|
|||
---|---|---|---|
#18+
День добрый коллеги! Так исторически сложилось, что у нас уже несколько лет установлен SQL 2016: Microsoft SQL Server 2016 (SP2-GDR) (KB4583460) - 13.0.5103.6 (X64) А вот у наших баз данных compatibility level=100, хотя особой необходимости уже нет. Вот мы и изменили compatibility level на 130. В принципе все работает хорошо, но одна процедура бежит несколько часов вместо порядка одной-двух минут. Статистики обновляли, индексы перестраивали, никто ему не мешает- опять зависает. Вернули на 100- нормально бежит, 1-2 минуты в зависимости от параметров, меняем на 130- опять висит. Процедура достаточно сложная, решил я проверить что там не так, запускаю код процедуры с параметрами не как процедура, а только код- бежит около минуты с новым уровнем совместимости, т.е. как и положено. А внитри процедуры нет. Ну видимо кэш. Почистил как надо было и как не надо было- не помогло DBCC FREESYSTEMCACHE('All') DBCC FREESESSIONCACHE DBCC FREEPROCCACHE DBCC FLUSHPROCINDB(5) DBCC DROPCLEANBUFFERS Создал новую процедуру с новым именем, но с тем же кодом- все отлично. А оригинальная процедура висит. Дропнул процедуру и создал заново- заработало как нужно. Т.е. на сколько я понимаю, все-таки либо я не дочистил какой-то кэш либо изменение уровня совместимости требует еще каких-то действий? Хотя в документации ничего об этом не сказано... Может быть кто-то сталкивался с похожей проблемой? Ну и еще один вопрос, у нас включен Query Store. На сколько я понимаю- он отображает только предполагаемый план запроса, так? У меня тут одна коллега настаивает на том, что план актуальный. А как он может быть актуальный если запрос не выполнен еще? я его останавливаю во время выполнения. Так кто из нас прав? Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2021, 17:33 |
|
Изменение уровня совместимости, что-то пошло не так...
|
|||
---|---|---|---|
#18+
abrashka, dbcc FREEPROCCACHE не забыли после смены уровня совместимости? а, не забыли... Много букв :) Значит у процедуры были настройки SET ARITHABORT OFF. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2021, 17:55 |
|
Изменение уровня совместимости, что-то пошло не так...
|
|||
---|---|---|---|
#18+
abrashka, Про QS - там же по самому плану видно, что он предварительный. В нём просто нет никакой runtime-статиситки. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2021, 18:00 |
|
Изменение уровня совместимости, что-то пошло не так...
|
|||
---|---|---|---|
#18+
Всем спасибо! И еще вопрос: В коде процедуры написано "WITH RECOMPILE" Значит ли это что на самом деле каждый запуск процедуры будет создавать новый план, а не использовать один из сохраненых? Т.е. если в Query Store я вижу "плохой" план под номером 12345, то это значит что именно этот план был использован всего один раз? Т.е. если я его удалю или оставлю, то ничего не изменится, каждый следующий запуск процедуры будет создавать новый план из-за "WITH RECOMPILE"? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2021, 19:25 |
|
Изменение уровня совместимости, что-то пошло не так...
|
|||
---|---|---|---|
#18+
abrashka, при with recompile план в кэше не сохраняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2021, 20:12 |
|
Изменение уровня совместимости, что-то пошло не так...
|
|||
---|---|---|---|
#18+
abrashka, https://www.brentozar.com/archive/2013/12/recompile-hints-and-execution-plan-caching/ ... мне особо понравилось, не знал: (гугл транслейт) Использование RECOMPILE в заголовке хранимой процедуры довольно радикально - процедура не кэширует план выполнения при запуске. Это означает: В кеше нет планов выполнения для проверки Статистика выполнения не записывается в sys.dm_exec_query_stats Статистика выполнения не записывается в sys.dm_exec_procedure_stats Вау, это облом. Если вам нужно определить влияние этой процедуры на ваш сервер, вы должны запустить своего рода сеанс трассировки или расширенных событий и собрать и интерпретировать результаты. Это не быстро, и отслеживание может повлиять на производительность. Вид большой минус. По этой причине мне совсем не нравится этот выбор. P.S. Чтобы два раза не вставать: https://sqlperformance.com/2013/08/t-sql-queries/parameter-sniffing-embedding-and-the-recompile-options ... WITH RECOMPILE and OPTION (RECOMPILE) When a parameter-sensitivity problem is encountered, a common piece of advice on forums and Q&A sites is to “use recompile” (assuming the other tuning options presented earlier are unsuitable). Unfortunately, that advice is often misinterpreted to mean adding WITH RECOMPILE option to the stored procedure. Using WITH RECOMPILE effectively returns us to SQL Server 2000 behaviour, where the entire stored procedure is recompiled on every execution. A better alternative, on SQL Server 2005 and later, is to use the OPTION (RECOMPILE) query hint on just the statement that suffers from the parameter-sniffing problem. This query hint results in a recompilation of the problematic statement only. Execution plans for other statements within the stored procedure are cached and reused as normal. Using WITH RECOMPILE also means the compiled plan for the stored procedure is not cached. As a result, no performance information is maintained in DMVs such as sys.dm_exec_query_stats. Using the query hint instead means that a compiled plan can be cached, and performance information is available in the DMVs (though it is limited to the most recent execution, for the affected statement only). For instances running at least SQL Server 2008 build 2746 (Service Pack 1 with Cumulative Update 5), using OPTION (RECOMPILE) has another significant advantage over WITH RECOMPILE: Only OPTION (RECOMPILE) enables the Parameter Embedding Optimization. The Parameter Embedding Optimization ... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2021, 20:20 |
|
|
start [/forum/topic.php?fid=46&msg=40094877&tid=1684342]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
119ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 214ms |
0 / 0 |