Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
Точнее, после перевода базы на новый Compatability level (130), производительность у нескольких запросов просто рухнула.
Я был поражен, как новый СЕ не может сообразить, что дешевле прочитать 300тыс страниц, а не 60млн.
Ну это все эмоции.
С налету, пофиксить на получилось. Запрос сложный со многими вложенными вьюхами (до 5ти уровней). Мозги уже в ступоре, так что нужен волшебный пинок в правильном направлении.

На что стоит обращать внимание при подобной проблеме в первую очередь? Поделитесь опытом реальным.

Заранее спасибо.
15 апр 19, 05:49    [21861876]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
aleks222
Member

Откуда:
Сообщений: 693
Статистику, страдалец, обновил?
15 апр 19, 06:12    [21861878]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
aleks222,

ну а как же, с этого начал.

Новый СЕ считает, что его план лучше в 10 раз и точка.
Я один и тот же запрос запускаю с разным СЕ. Получается 10% к 90% при Estimation plan, а вот по результатам с точностью до наоборот (старый план быстрее).

Не могу заставить новый СЕ думать по старому :).
15 апр 19, 06:36    [21861883]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6376
Idol_111,

или отключить новый CE или переписывать
15 апр 19, 08:27    [21861916]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
dklim.kzn
Member

Откуда: Казань
Сообщений: 123
посмотреть старый план
и как там используется - индексы приткнуть да forceseek/forcescan
хотя вангую обойдется и option (recompile) если не было указано еще
15 апр 19, 08:29    [21861918]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 3926
Idol_111
Точнее, после перевода базы на новый Compatability level (130), производительность у нескольких запросов просто рухнула.
Я был поражен, как новый СЕ не может сообразить, что дешевле прочитать 300тыс страниц, а не 60млн.
Ну это все эмоции.
С налету, пофиксить на получилось. Запрос сложный со многими вложенными вьюхами (до 5ти уровней). Мозги уже в ступоре, так что нужен волшебный пинок в правильном направлении.

На что стоит обращать внимание при подобной проблеме в первую очередь? Поделитесь опытом реальным.

Заранее спасибо.


Ну тык закинте сюда запрос, здесь любителей покопаться в километровых партянках много.
15 апр 19, 18:56    [21862929]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1018
Idol_111,

если перешли на 16, используйте Query Store. сможете зафорсировать для вашего запроса необходимый план.
15 апр 19, 20:27    [21862982]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2263
Idol_111
На что стоит обращать внимание при подобной проблеме в первую очередь?.
на estimated vs actual.
15 апр 19, 22:37    [21863063]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
Mind
Idol_111
На что стоит обращать внимание при подобной проблеме в первую очередь?.
на estimated vs actual.

вот тут пожалуйста по-подробнее.
понятное дело, что СЕ даже при актуальной статистике считает неправильно estimated, но как определить какая статистика и для какого объекта является ключевой, чтобы СЕ перестал считать плохой план хорошим?
Начать сверху по дереву плана перебирать или по затратным операциям? Какова логика СЕ?
16 апр 19, 04:39    [21863160]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
TaPaK
Idol_111,

или отключить новый CE или переписывать

Спасибо, запрос на переписывание уже направил, что зная реалии это вечность.

Подумываю применить Legacy Cardinality Estimation.
16 апр 19, 04:41    [21863162]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
dklim.kzn
посмотреть старый план
и как там используется - индексы приткнуть да forceseek/forcescan
хотя вангую обойдется и option (recompile) если не было указано еще

recompile не вариант совсем, это не parameter sniffing problem.

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

При этом еще какой-то "умник" умудрился половину параметров закодить прямо в скрипт, так что Plan guide (вместе с Query Store) тоже не вариант.
16 апр 19, 04:52    [21863166]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
a_voronin
Ну тык закинте сюда запрос, здесь любителей покопаться в километровых партянках много.

Это будет рельно портянка :).
Если совсем будет кирдык, может и закину.
Хотя, как по мне, по одному плану такие вещи не пофиксить.
16 апр 19, 04:57    [21863167]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6532
Idol_111,

в описании cardinality estimator указано, что его новая версия может давать нежелательный эффект, поэтому, если не планируете регулярных обновлений сервера, вполне можно использовать lagecy. Иначе они внесут изменения в работу, но у вас будет всё ещё legacy.
16 апр 19, 11:27    [21863441]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6376
Владислав Колосов
Idol_111,

в описании cardinality estimator указано, что его новая версия может давать нежелательный эффект, поэтому, если не планируете регулярных обновлений сервера, вполне можно использовать lagecy. Иначе они внесут изменения в работу, но у вас будет всё ещё legacy.

Та то вы перегибаете... Новый CE с 2014 а на дворе то огого.

Перед переходом на любую версию надо тестировать, что бы удивлений не возникало. В 2017 помоемому query store уже позволяет прикрутить смену CL и увидеть деградацию.
И да, перезд на 2016 повлёк переписывание массы вроде как обычных конструкций, но при этом он значительно веселее в ресурсах(хотя иногда и приходится уговоравать на "возьми побольше" :))
16 апр 19, 11:38    [21863460]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6532
Мое мнение совершенно такое же - переписать запросы. Но есть и варианты, не лучшие, но позволяющие быстро ликвидировать проблему. Понятно, что лучше заменить трубу вместо установки хомута на свищ.
16 апр 19, 12:13    [21863504]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
Idol_111
Member

Откуда:
Сообщений: 538
Полезно пообщаться на форуме, хотя бы понимаешь "что правильной дорогой идете товарищи" :).

Довольно кратко и по сути написано в этой статье.

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

Всем спасибо за участие.
16 апр 19, 23:48    [21864328]     Ответить | Цитировать Сообщить модератору
 Re: деградация производительности при апгрейде на 2016  [new]
dklim.kzn
Member

Откуда: Казань
Сообщений: 123
Idol_111,

мдя, надо мс подсказать идею для таких переездов

типа по шаблону запроса выполнять совсем другой, новый и хороший запрос
а тому, кто старый написал, чтобы икалось каждый раз при вызове, пусть такую функцию добавят тоже
17 апр 19, 10:29    [21864542]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить