Что делает установка уровня совместимости в SQL Server?
Пересказ статьи Brent Ozar. What Does Setting the SQL Server Compatibility Level Do?
Если щелкнуть правой кнопкой по базе данных в SQL Server Management Studio, вы получаете возможность установить уровень совместимости (Compatibility Level) на уровне базы данных:
При апгрейде SQL Server или в случае, когда вы хотите улучшить производительность, какой вариант вы должны выбрать? Всегда ли нужно переходить на самый новый уровень совместимости? Если у вас есть старое приложение, можете ли вы сделать апгрейд SQL Server, но оставить при этом старый уровень совместимости без ведома продавца? Давайте ответим на общие вопросы.
Когда выходит новая версия SQL Server, разработчики пытаются содержать новые функции доступными только в новейших уровнях совместимости. Например, SQL Server 2022’s Parameter Sensitive Plan Optimization (PSPO) доступен только базах данных, выполняющихся при уровне совместимости SQL Server 2022.
Это означает, что если взять базу данных, которая жила на более старой версии SQL Server, и вы хотите перенести ее на SQL Server 2022 и чтобы при этом она имела то же поведение, что и обычно, вам следует сохранить для нее текущий уровень совместимости. Например, если вы используете SQL Server 2016, и база данных имеет в данный момент уровень совместимости SQL Server 2016, то вы можете перенести эту базу данных на сервер 2022, но оставить для нее уровень совместимости 2016. Тогда пользователи не должны заметить разницы.
Хотя на самом деле есть кое-что внутри самого SQL Server, на уровне сервера, что изменится вне зависимости от вашего уровня совместимости. Например, если Microsoft отказывается от некоторой функции и совсем удаляет ее, эта функция не будет доступна, даже если вы используете более старый уровень совместимости. (Привет, Big Data Clusters.)
Если есть необходимая вам специфическая функция, которая доступна только при этом уровне совместимости, то да.
Однако если вас устраивает производительность, то нет. Выслушайте меня: изменение уровня совместимости может сделать производительность не лучше, а хуже. Конечно, в некоторых случаях это может улучшить производительность - но, поскольку любое изменение - это риск, то изменение уровня совместимости, когда вас все устраивает, опасно.
Если вы переходите с SQL Server 2019 на 2022, вот как изменение уровня совместимости базы данных может улучшить или ухудшить ситуацию:
В каждой версии SQL Server различные функции доступны при новейших уровнях совместимости. Прежде чем изменить уровень совместимости, вам следует сделать обзор добавленных функций, которые вступят в силу, когда вы измените текущий уровень совместимости на новый. Вот хорошая точка для старта.
Теоретически при настройке производительности вы должны руководствоваться следующими указаниями:
Затем, когда люди внезапно пожалуются на производительность, вы можете проверить ваше руководство, чтобы посмотреть, действительно ли стало хуже, или вашим пользователям это померещилось. Вы должны также отслеживать, какие запросы находятся ТЕПЕРЬ наверху списка потребляющих ресурсы запросов, посмотреть, как РАНЬШЕ выглядели их планы запросов, а затем решить, как вернуться к старым добрым временам.
Обычно для этого используются сторонние продукты мониторинга, хранилище запросов (Query Store) или First Responder Kit.
На самом деле вы ничего из этого не собираетесь делать заранее. Поэтому когда вы меняете уровни совместимости на лету, и производительность становится хуже, у вас не будет никаких ответов.
Нет, конечно, нет! Вы можете менять уровни совместимости, когда захотите, по одной базе данных. Вы также можете сразу вернуть его обратно. Вам просто нужно знать, что вы поменяли, когда внесли изменения, и сообщить это остальной команде, чтобы они при необходимости могли откатить свои изменения.
Скриншот в начале статьи был сделан на SQL Server 2022, и даже в этом последнем релизе Microsoft поддерживает все уровни совместимости вплоть до SQL SErver 2008. Это круто, поскольку означает, что Microsoft пытается обеспечить хорошую работу старых баз данных в более новых версиях SQL Server.
Теоретически это означает, что вы можете взять старое приложение поставщика, которое было сертифицировано на SQL Server 2008, и переносить его на все новые и новые версии SQL Server. Теоретически оно будет продолжать работать точно так же, пока вы сохраняете тот же самый уровень совместимости - и да, оно даже может работать быстрее, если вы измените уровень совместимости на более новый.
Ну, нет. Я имею в виду, что вы можете, но можно попасться.
Вот в чем дело: поставщик мог полагаться на некую функцию, которая уже недоступна в более новой версии SQL Server. Если честно, это весьма маловероятно, но возможно. А если таковы есть, и их приложение вдруг сломается, вы не сможете восстановить базу данных из более новой версии SQL Server на более старую версию SQL Server.
Итак, если вы возьмете свой сервер SQL Server 2008, сделаете резервные копии баз данных, восстановите их затем на SQL Server 2022, и начнете использовать приложение - и люди начнут жаловаться - вы не сможете восстановить их бэкапы 2022 обратно на сервере SQL Server 2008, даже если они все еще имеют уровень совместимости 2008. Вы можете выполнять восстановление только на более новых версиях SQL Server, но не на старых.
Следовательно вы рискуете, когда переносите базы данных на более новые версии SQL Server. Убедитесь, что поставщик действительно поддерживает более новые версии SQL Server, поскольку вы не хотите стать тем, кого поставщик обвинит в том, что их приложение не работает.
Ссылки по теме
Что делает уровень совместимости
Когда выходит новая версия SQL Server, разработчики пытаются содержать новые функции доступными только в новейших уровнях совместимости. Например, SQL Server 2022’s Parameter Sensitive Plan Optimization (PSPO) доступен только базах данных, выполняющихся при уровне совместимости SQL Server 2022.
Это означает, что если взять базу данных, которая жила на более старой версии SQL Server, и вы хотите перенести ее на SQL Server 2022 и чтобы при этом она имела то же поведение, что и обычно, вам следует сохранить для нее текущий уровень совместимости. Например, если вы используете SQL Server 2016, и база данных имеет в данный момент уровень совместимости SQL Server 2016, то вы можете перенести эту базу данных на сервер 2022, но оставить для нее уровень совместимости 2016. Тогда пользователи не должны заметить разницы.
Хотя на самом деле есть кое-что внутри самого SQL Server, на уровне сервера, что изменится вне зависимости от вашего уровня совместимости. Например, если Microsoft отказывается от некоторой функции и совсем удаляет ее, эта функция не будет доступна, даже если вы используете более старый уровень совместимости. (Привет, Big Data Clusters.)
Должен ли я изменить уровень совместимости?
Если есть необходимая вам специфическая функция, которая доступна только при этом уровне совместимости, то да.
Однако если вас устраивает производительность, то нет. Выслушайте меня: изменение уровня совместимости может сделать производительность не лучше, а хуже. Конечно, в некоторых случаях это может улучшить производительность - но, поскольку любое изменение - это риск, то изменение уровня совместимости, когда вас все устраивает, опасно.
Как уровень совместимости влияет на производительность?
Если вы переходите с SQL Server 2019 на 2022, вот как изменение уровня совместимости базы данных может улучшить или ухудшить ситуацию:
- Cardinality Estimation Feedback (обратная связь по оценке кардинального числа) может изменить оценку числа строк запроса.
- Degrees of Parallelism Feedback (обратная связь по степени параллелизма) может уменьшить накладные расходы плохого параллелизма (хотя, по большей части, параллелизм - это хорошо).
- Parameter Sensitive Plan Optimization (оптимизация плана с учетом параметров) может кэшировать множество планов для одного и того же запроса.
В каждой версии SQL Server различные функции доступны при новейших уровнях совместимости. Прежде чем изменить уровень совместимости, вам следует сделать обзор добавленных функций, которые вступят в силу, когда вы измените текущий уровень совместимости на новый. Вот хорошая точка для старта.
Что я должен измерить перед изменением уровня совместимости?
Теоретически при настройке производительности вы должны руководствоваться следующими указаниями:
- Метрики ЦП, памяти и хранилища
- Знание узких мест SQL Server, вызывающих основные типы ожиданий
- Какие запросы потребляют больше всего ресурсов
- Планы запросов с хорошей производительностью (поскольку возможно ухудшение, и вы захотите знать, как они выглядели в старые добрые времена)
Затем, когда люди внезапно пожалуются на производительность, вы можете проверить ваше руководство, чтобы посмотреть, действительно ли стало хуже, или вашим пользователям это померещилось. Вы должны также отслеживать, какие запросы находятся ТЕПЕРЬ наверху списка потребляющих ресурсы запросов, посмотреть, как РАНЬШЕ выглядели их планы запросов, а затем решить, как вернуться к старым добрым временам.
Обычно для этого используются сторонние продукты мониторинга, хранилище запросов (Query Store) или First Responder Kit.
На самом деле вы ничего из этого не собираетесь делать заранее. Поэтому когда вы меняете уровни совместимости на лету, и производительность становится хуже, у вас не будет никаких ответов.
Означает ли это, что я не должен трогать уровень совместимости?
Нет, конечно, нет! Вы можете менять уровни совместимости, когда захотите, по одной базе данных. Вы также можете сразу вернуть его обратно. Вам просто нужно знать, что вы поменяли, когда внесли изменения, и сообщить это остальной команде, чтобы они при необходимости могли откатить свои изменения.
Какие уровни совместимости доступны?
Скриншот в начале статьи был сделан на SQL Server 2022, и даже в этом последнем релизе Microsoft поддерживает все уровни совместимости вплоть до SQL SErver 2008. Это круто, поскольку означает, что Microsoft пытается обеспечить хорошую работу старых баз данных в более новых версиях SQL Server.
Теоретически это означает, что вы можете взять старое приложение поставщика, которое было сертифицировано на SQL Server 2008, и переносить его на все новые и новые версии SQL Server. Теоретически оно будет продолжать работать точно так же, пока вы сохраняете тот же самый уровень совместимости - и да, оно даже может работать быстрее, если вы измените уровень совместимости на более новый.
Так я действительно могу это сделать?
Ну, нет. Я имею в виду, что вы можете, но можно попасться.
Вот в чем дело: поставщик мог полагаться на некую функцию, которая уже недоступна в более новой версии SQL Server. Если честно, это весьма маловероятно, но возможно. А если таковы есть, и их приложение вдруг сломается, вы не сможете восстановить базу данных из более новой версии SQL Server на более старую версию SQL Server.
Итак, если вы возьмете свой сервер SQL Server 2008, сделаете резервные копии баз данных, восстановите их затем на SQL Server 2022, и начнете использовать приложение - и люди начнут жаловаться - вы не сможете восстановить их бэкапы 2022 обратно на сервере SQL Server 2008, даже если они все еще имеют уровень совместимости 2008. Вы можете выполнять восстановление только на более новых версиях SQL Server, но не на старых.
Следовательно вы рискуете, когда переносите базы данных на более новые версии SQL Server. Убедитесь, что поставщик действительно поддерживает более новые версии SQL Server, поскольку вы не хотите стать тем, кого поставщик обвинит в том, что их приложение не работает.
Ссылки по теме
- Значение уровня совместимости базы данных в SQL Server
- Адаптивные соединения в SQL Server
- Кардинальное число (мощность множества)
- Введение в план выполнения SQL Server
- Сравнение планов запроса в Management Studio
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой