Оценка количества элементов в устаревших версиях SQL Azure не работает, как SQL Server 2016

У нас есть две идентичные базы данных (точно такие же данные, структура и т. Д.), Одна в Azure Sql (Premium 500 DTU), а другая на виртуальной машине в Azure под управлением SQL Server 2016 SP1 (8 виртуальных ядер, 64 ГБ ОЗУ). У нас есть запрос, который при запуске с «Legacy Cardinality Estimation» на уровне базы данных, установленным на OFF, приводит к тому, что время выполнения запроса в обеих базах данных составляет около 4 минут.

Если мы изменим «Оценка мощности предыдущих версий» на ВКЛ в обеих базах данных, виртуальная машина с SQL Server 2016 SP1 выполнит тот же запрос за 30 секунд, в то время как база данных Azure SQL будет работать с еще худшей производительностью и потребует почти 7 минут для выполнения.

Повторное написание запроса на данном этапе не вариант. Я надеюсь, что кто-нибудь скажет мне, как я могу заставить Azure SQL соблюдать параметр «Legacy Cardinality Estimation» и обеспечивать производительность, аналогичную моей виртуальной машине SQL Server 2016 SP1.

Я заметил, что в блоке SQL Server 2016 SP1 загрузка ЦП будет резко возрастать (90% +), когда «Legacy Cardinality Estimation» включена, в то время как в Azure SQL процент DTU никогда не поднимается выше 25%.


azure sql-server azure-sql-database azure-sql-server sql-server-2016
person Ken Brannigan    schedule 05.07.2018    source источник
comment
Вы проверяли / сравнивали планы?   -  person Aaron Bertrand    schedule 05.07.2018
comment
25% кажется подозрительно магическим числом - возможно ли, что другие настройки отличаются (например, эквиваленты maxdop в Azure SQL DB, пороговое значение затрат для параллелизма или любые ограничения ресурсов)? Тем не менее, способ увидеть различия - это сравнить планы выполнения.   -  person Aaron Bertrand    schedule 05.07.2018
comment
Кроме изменения устаревшей оценки мощности во вновь созданной базе данных SQL Azure, другие параметры не меняются. Я попытаюсь сравнить планы, но это большой запрос, поэтому план выполнения - не самая простая вещь для сортировки. Ограничение на процент DTU тоже было для меня странным, и я подумал, что, возможно, в Azure SQL есть что-то встроенное, что не позволяет одному запросу пережевывать все ресурсы.   -  person Ken Brannigan    schedule 05.07.2018
comment
Всевозможные вещи могут привести к разным планам в двух разных базах данных. Вы не можете игнорировать планы только потому, что запрос большой. Обычно вы можете довольно легко сосредоточиться на основных болевых точках в каждом плане, а когда они различаются, вы можете углубиться в причину (или задать нам более конкретный вопрос). Если вам сложно сделать это в SSMS, попробуйте SentryOne Plan Explorer. Заявление об ограничении ответственности: я работаю в SentryOne.   -  person Aaron Bertrand    schedule 05.07.2018
comment
Спасибо, Аарон. Планы точно разные. Я могу попробовать загрузить упомянутый вами инструмент SentryOne, чтобы посмотреть, поможет ли он выявить проблему. Я постараюсь опубликовать больше информации, когда копну глубже. Спасибо за помощь.   -  person Ken Brannigan    schedule 05.07.2018
comment
Я вижу, что виртуальная машина SQL Server 2016 с пакетом обновления 1 (SP1) демонстрирует 8 степеней параллелизма с 267 параллельными операциями, в то время как план Azure SQL вообще не указывает параллелизм. Я использовал инструмент SentryOne, как рекомендовал Аарон. Счетчик чтения в Azure SQL составляет почти 56 миллионов чтений, тогда как виртуальная машина SQL Server 2016 SP1 показывает чуть менее 8 миллионов чтений. Есть ли рекомендации по поводу других вещей, на которые следует обратить внимание в плане выполнения?   -  person Ken Brannigan    schedule 06.07.2018
comment
Когда я перешел на Premium 1000 DTU, запрос пошел параллельно и завершился за 22 секунды.   -  person Ken Brannigan    schedule 06.07.2018

Ответы (1)


arrow_upward
0
arrow_downward

В базе данных SQL Azure установите уровень совместимости 110, чтобы включить старую оценку мощности.

ALTER DATABASE [YourDatabase] SET COMPATIBILITY_LEVEL = 110

На уровне запроса используйте подсказку ниже.

USE HINT ( 'FORCE_LEGACY_CARDINALITY_ESTIMATION')

Дополнительную информацию см. здесь.

person Alberto Morillo    schedule 05.07.2018
comment
Мы опробовали уровень совместимости, и он дает такие же медленные результаты, как и при включении Legacy Cardinality Estimation. Также Azure SQL не нравится USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'), поскольку он не поддерживает ключевое слово USE. - person Ken Brannigan; 06.07.2018
comment
Вернитесь к исходному уровню совместимости и используйте только подсказку на уровне инструкции. Пожалуйста, дайте мне знать результаты. - person Alberto Morillo; 06.07.2018
comment
ВЫБЕРИТЕ CustomerId, OrderAddedDate из таблицы заказов, ГДЕ OrderAddedDate ›= '2016-05-01'; ВАРИАНТ (ИСПОЛЬЗУЙТЕ СОВЕТ ('FORCE_LEGACY_CARDINALITY_ESTIMATION')); - person Alberto Morillo; 06.07.2018
comment
Никакой разницы в скорости. Те же результаты, что и при установке для Legacy Cardinality Estimation значения ON, как указано в исходном сообщении. - person Ken Brannigan; 06.07.2018