Падение производительности после перехода на sql 2017 с 2012 года для табличных функций

Question

Мигрировано с 2012 по 2017 год один месяц назад (тестирование проходит нормально, но тестирование не является строгим). Через месяц я заметил, что функции табличных значений, начинающиеся с последовательности табличных выражений Commmon, выполняются очень долго или не выполняются вообще. Я в порядке с переписыванием кода (стороннее приложение вместе с нашим собственным кодом рядом ... ой). Сегодня я заметил, что запрос отлично работает на сервере SQL2012 (я до сих пор имею к нему доступ) и полностью переходит на ланч на SQL2017. Я думал, что это может произойти, и сохранил настройки совместимости для всех БД. Кто-нибудь сталкивался с этим?

Я играл с 9481, но, как я понимаю, с Comp Level 110, это даже не должно быть проблемой. Есть ли какие-либо другие настройки сервера, которые я могу установить, чтобы заставить его вести себя так, как он решает проблемы (их много), один за другим.

Кроме того, поскольку эти таблицы tvf используются повторно и используются везде, важно, чтобы они оставались как таковые. Я не могу переставить мебель слишком много. Разработчики использовали как TVF, так и CTE.

Мигрировано с 2012 по 2017 год месяц назад, совместимость не изменилась. Разработан шаблон, в результате которого запросы:

Select t1.Col1
t1.Col2,t2.Col8,
tvfTable1.Col10, etc...
FROM table1 t1 join table2 t2 on t1.key=t2.foreignkey
CROSS APPLY (t1.Col1,t2,col4,0,1,2,3) tvfTable1

Кажется, что все TVF начинаются с:

...
AS RETURN (
WITH CTE1 AS (query),
CTE2 AS (query referencing CTE1)
...
SELECT MANYColumns
FROM MANYTABLES JOIN CTE4 on mt.key=cte4.key

Answer 1

Спасибо всем.Кажется, я ошибся в том, что у меня уже был уровень совместимости 140, когда я думал, что это 110. Итак, мое первоначальное недоразумение заключалось в том, как поведение могло быть таким плохим на старом уровне.Я вернул его к 110, и теперь все предсказуемо.Это никогда не было здорово с TVF, но на 140, это ужасно.У нас много работы.

Answer 2

Подобно тому, как Jaroen уже прокомментировал, любую проблему с производительностью лучше всего рекомендовать, как минимум:

1. Информация об объеме данных базовой таблицы

2. Базовая таблица и структура индекса

3. Предоставляются скриншот или подробности плана выполнения.

С предоставлением ограниченных деталей ,Вот несколько вещей, которые вы можете попробовать:

1. Во время выполнения запроса проверьте статистику ожиданий на сервере, выполнив запросы к dmvs: sys.dm_os_wait_stats и sys.dm_tran_locks.Проверьте, не вызвано ли ожидание CXPACKET (ожидание из-за других параллельных процессов) или PAGEIOLATCH (чтение с диска, а не из ОЗУ) или блокировками.Это отправная точка расследования, которая даст вам основную причину, и вы сможете принять соответствующие меры.
2. Пожалуйста, проверьте, обновляется ли статистика на вашем новом сервере.Если нет, обновите статистику базовых таблиц (попробуйте с помощью FULLSCAN, если это возможно, если вы не обновляли статистику с момента перехода на новый сервер)

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

4. Не могли бы вы убедиться, что ваша конфигурация MAXDOP оптимизирована с учетом количества логических процессоров, которые вы используете?есть в вашем новом сервере?

5. Я также хотел бы спросить вас разницу в оперативной памяти между двумя серверами.Не могли бы вы проверить «Доступную оперативную память» на каждом сервере, когда выполняете один и тот же запрос?

6. В идеале, если это возможно, я бы посоветовал вам перейти на уровень совместимости 2017 как можно скорее, потому что дляДолгое время уровень совместимости влиял только на интерпретацию T-SQL и не влиял на производительность.Но начиная с SQL Server 2014, мы получаем новые оценки мощности и другие улучшения в том, как строятся планы выполнения.И, изменив это, мы неожиданно получаем другой план запросов для многих запросов, который может выполняться намного быстрее, чем старые планы выполнения, которые генерировал уровень совместимости 2012 или более старая версия.Обычно во время обновления SQL Server рекомендуется изначально поддерживать уровень совместимости.Как только он будет работать нормально в течение 1-2 недель после обновления сервера, мы можем установить уровень совместимости SQL Server на последнюю версию на сервере dev и проверить, все ли работает нормально.После этого уровень совместимости можно обновить до последней версии в производственной среде.
7. Вот статья о производительности TVF для разных версий SQL Server: https://www.mssqltips.com/sqlservertip/5728/sql-server-multi-statement-table-value-function-mtvfs-performance-difference-between-versions/