SQL Server 2008 до 2012 - вопрос времени компиляции плана запроса - PullRequest
0 голосов
/ 23 января 2019

Хорошо, очень странно, это, к сожалению, за пределами моего уровня квалификации. У нас довольно большая база данных (35 ГБ) со средним уровнем использования. Это было на старом оборудовании и SQL Server 2008. Мы получили новый сервер, гораздо больше процессоров ОЗУ / быстрее - отлично! Настройка жесткого диска такая же (т.е. raid / configuration / location). Резервное копирование базы данных и восстановление на новом сервере (работает в режиме 2012). Все казалось хорошо - но все было не хорошо. У меня очень странные проблемы с производительностью. Большинство запросов выполняется немного быстрее, и это здорово, но некоторые запросы в первый раз выполняются намного медленнее.

Пример - у нас есть запрос, который при первом запуске занимает 7 секунд. Если я запускаю его снова, это займет 250 мс. Если я изменяю значение параметра, потребуется 7 секунд для повторного запуска. Если очистить кэш плана запросов, потребуется 7 секунд для повторного запуска. Если я выполняю тот же запрос в старой базе данных, он занимает 500 мс при первом запуске, 400 мс при втором запуске.

Итак, что-то не так с тем, сколько времени потребуется для компиляции запроса. Когда я возвращаю фактический план выполнения, он такой же, но оценочные затраты на строки / поддеревья намного выше на новом сервере. Когда я делаю свойства и получаю время компиляции его 7000 против 350 на старом сервере (при условии, что это мс).

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

В рамках миграции перестраиваются все индексы и обновляется статистика.

Короче говоря, новый сервер работает быстрее, но только после создания плана запроса. Идеи?

Не включая какой-либо код, поскольку запрос не является проблемой - работает нормально на SQL Server 2008 и работает нормально в 2012 году после первоначального запуска. [Правка - пример того, что я имею в виду под переменной. Между изменениями я просто меняю «что-то» на «что-то1»]

DECLARE @myReference VARCHAR(50) = 'something'
SELECT Column1, Column2
FROM dbo.Table
WHERE Column3 = @myReference 

[/ Edit]

Я бы ожидал, что общая производительность по сравнению с 2008 годом будет незначительно улучшена благодаря более качественному оборудованию.

Изображение выходов профилировщика: [profiler]: https://imgur.com/hq5t73t "изображение профилировщика"

Confirmation of version: Microsoft SQL Server 2012 (SP4) (KB4018073) - 
11.0.7001.0 (X64)   Aug 15 2017 10:23:29   Copyright (c) Microsoft Corporation  Standard 
Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) 

1 Ответ

0 голосов
/ 23 января 2019

Очевидно, что проблема в большом времени компиляции.

Возможно, эта проблема уже решена и исправлена ​​MS.

Обновлен ли сервер до последней версии пакета обновления и накопительного обновления? Трассировка 4199 включена? SQL для включения:

DBCC TRACEON (4199, -1)

Длительное время компиляции может быть вызвано большим количеством статистики, особенно автоматически созданной статистики. Будет ли удаление некоторых из них корректировать время компиляции?

Перекомпиляция также может быть предотвращена путем параметризации силы:

ALTER DATABASE [your db] SET PARAMETERIZATION FORCED

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

...