Мониторинг производительности базы данных
Основная часть методов устранения неполадок, используемых для устранения неполадок с производительностью базы данных, остается той же в SQL Azure.
Все средства, которые обычно используются для мониторинга и устранения неполадок SQL Server, также применимы к SQL Server, работающему на виртуальной машине Azure, включая такие инструменты, как Монитор производительности. Однако из-за характера платформы как службы (PaaS) База данных SQL Azure и Управляемый экземпляр SQL Azure предоставляют другой набор инструментов. Далее мы рассмотрим конкретные инструменты для предложений PaaS Azure и их функциональных возможностей.
Сравнение результатов производительности с базовым показателем
Процесс создания базового плана обычно начинается хорошо до фактической миграции базы данных. Это включает сбор комплексного набора измерений данных, которые отражают стандартную производительность базы данных в исходной среде. Эти измерения могут включать в себя, но не ограничиваются, использование ЦП, время отклика, скорость транзакций и частоты ошибок.
Этот базовый план служит эталонной точкой, с которой можно сравнить производительность перенесенной базы данных. Однако оценка или сравнение этих базовых данных с метриками производительности перенесенной базы данных происходит только после завершения миграции.
После миграции производительность новой среды базы данных отслеживается и измеряется. Затем эти метрики после миграции сравниваются с базовыми показателями предварительной миграции для выявления любых несоответствий или проблем с производительностью. Это сравнение помогает понять, имеет ли миграция какие-либо негативные последствия для производительности базы данных или если существуют области, требующие оптимизации для повышения производительности.
Автоматическая настройка
Автоматическая настройка — это функция, которая постоянно изучает рабочую нагрузку, определяет потенциальные проблемы и улучшения и предлагает рекомендации на основе хранилище запросов данных. Он адаптируется к изменениям в планах выполнения, вызванных изменениями схемы или индекса или обновлениями данных.
Вы можете вручную применить рекомендации по настройке с помощью портал Azure или разрешить автоматическую настройку автономно применять рекомендации по настройке. В База данных SQL Azure он также может повысить производительность запросов, настроив индексы.
Автоматическое исправление плана
С помощью хранилище запросов ядро СУБД может определить, когда планы выполнения запросов регрессировали в производительности. Такие планы можно определить вручную с помощью пользовательского интерфейса, однако хранилище запросов также предоставляет возможность автоматического уведомления о снижении производительности.
В данном примере рядом с идентификатором плана 1 отображается знак проверка, указывающий на принудительное выполнение плана.
После включения автоматической настройки ядро СУБД автоматически будет применять любой предлагаемый план выполнения запросов в следующих условиях:
- Частота ошибок предыдущего плана превышает частоту рекомендуемого плана.
- Предполагаемое увеличение ЦП превышает 10 секунд
- Принудительный план опережает предыдущий
При автоматическом принудительном выполнении плана ядро СУБД применяет последний хороший план и отслеживает его производительность. Если принудительный план не выполняется лучше предыдущего плана, он не выполняется и скомпилируется новый план. Если он опережает предыдущий план, он остается вынужденным до тех пор, пока не произойдет повторная компиляция.
Используйте следующий запрос T-SQL, чтобы включить автоматическое исправление плана.
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);
Вы можете просматривать рекомендации по автоматической настройке с помощью динамического административного представления. sys.dm_db_tuning_recommendations
В этом динамическом административном представлении содержатся сведения о рекомендациях, типах и состояниях. Чтобы проверить, включена ли автоматическая настройка для базы данных, обратитесь к представлению sys.database_automatic_tuning_options
.
Автоматическая настройка только для Управляемый экземпляр SQL Azure поддерживаетсяFORCE LAST GOOD PLAN
.
Сведения о включении уведомлений для автоматической настройки см. в статье "Уведомления электронной почты" для автоматической настройки
Автоматическое управление индексами
База данных SQL Azure поддерживает автоматическую настройку индекса. Это означает, что с течением времени база данных имеет возможность узнать о существующих рабочих нагрузках и предоставить рекомендации по добавлению или удалению индексов для повышения производительности. Как и принудительное повышение планов запросов, база данных может быть настроена для автоматического создания или удаления индекса в зависимости от существующей производительности индекса.
Кроме того, используйте следующий запрос, чтобы просмотреть функции автоматической настройки, включенные в базе данных.
SELECT name,
desired_state_desc,
actual_state_desc,
reason_desc
FROM sys.database_automatic_tuning_options
Создание индекса является ресурсоемким, и его успешное создание критически важно, чтобы не влиять на рабочие нагрузки.
База данных SQL Azure отслеживает ресурсы, необходимые для автоматического внедрения новых индексов, чтобы предотвратить снижение производительности. Действие настройки откладывается до тех пор, пока ресурсы не становятся доступными, например, когда ресурсы, необходимые для существующих рабочих нагрузок, препятствуют созданию индекса.
Изучение анализа производительности запросов
Начальный этап любой задачи оптимизации производительности базы данных включает определение запросов, которые являются наиболее ресурсоемкими. В предыдущих версиях SQL Server это требуется обширная трассировка и набор сложных скриптов SQL, что делает процесс сбора данных трудоемким.
Выявление проблемных запросов
База данных SQL Azure предлагает средство с именем Анализ производительности запросов, позволяющий администратору быстро удостоверять дорогостоящие запросы. Его можно найти в главной колонке База данных SQL Azure в разделе "Интеллектуальная производительность".
Аналитика производительности запросов в База данных SQL Azure предоставляет три варианта фильтрации: для длительных запросов, наиболее потребляющих ресурсы запросов (который по умолчанию) или настраиваемого фильтра. В нем отображаются пять первых запросов, отсортированных по выбранному ресурсу, например ЦП, операций ввода-вывода данных или операций ввода-вывода журнала. Вы можете выполнить детализацию отдельных запросов, выбрав строку в нижней сетке. Каждая строка помечается отдельным цветом, соответствующим цвету в графе линейчатой диаграммы.
Пользовательская вкладка обеспечивает большую гибкость, чем другие параметры. Это позволяет более специально проверять данные о производительности с несколькими раскрывающимися меню, влияющими на визуализацию данных. Ключевые метрики включают ЦП, операции ввода-вывода в журнал, операции ввода-вывода данных и память, которые являются аспектами производительности, которые охватывают уровень служб База данных SQL Azure и вычислительные ресурсы.
Если мы детализируем отдельный запрос, мы можем увидеть идентификатор запроса и сам запрос, а также тип агрегирования запроса и связанный период времени.
Хотя анализ производительности запросов не показывает план выполнения запроса, можно быстро выявить этот запрос и использовать полученные сведения для извлечения плана из хранилища запросов в базе данных.
видны узлы
Вы можете настроить оповещения о производительности баз данных в База данных SQL Azure с помощью портал Azure. Эти оповещения могут уведомлять вас по электронной почте или вызывать веб-перехватчик, когда определенная метрика (например, размер базы данных или использование ЦП) достигает порогового значения.
Процесс настройки оповещений аналогичен База данных SQL и Управляемый экземпляр SQL. Чтобы настроить оповещения о производительности для База данных SQL Azure, перейдите в раздел "Мониторинг" и выберите "Оповещения". После этого необходимо установить новое правило генерации оповещений, определить условие и создать группу действий.
Дополнительные сведения о оповещениях для Управляемый экземпляр SQL Azure см. в статье "Создание оповещений для Управляемый экземпляр SQL Azure с помощью портал Azure". Если вы хотите База данных SQL Azure, см. статью "Создание оповещений для База данных SQL Azure и Azure Synapse Analytics с помощью портал Azure".
Аналитика SQL Azure
Аналитика SQL Azure улучшает возможности мониторинга, предоставляя интерактивные и готовые визуализации. Вы можете настроить сбор и частоту данных телеметрии и объединить данные из нескольких источников в единый интерфейс мониторинга. SQL Insights также сохраняет этот набор метрик на протяжении времени работы, что позволяет исследовать проблемы производительности, которые могли возникать в прошлом.
Внимание
Мы рекомендуем настроить Аналитика SQL Azure только после полной интеграции перенесенной базы данных в рабочую среду. Это позволяет инструменту записывать шумные данные на этапе миграции и тестирования.
Чтобы приступить к работе с SQL Аналитика, требуется выделенная виртуальная машина, которая отслеживает и удаленно собирает данные с серверов SQL. На этой выделенной виртуальной машине должны быть установлены следующие компоненты:
- Агент Azure Monitor
- Расширение Аналитики рабочей нагрузки
Кроме того, для настройки SQL Аналитика требуются следующие компоненты.
Профиль мониторинга — группирование серверов, экземпляров или баз данных для мониторинга.
Рабочая область Log Analytics — куда отправлять данные мониторинга SQL.
Параметры коллекции — можно настроить сбор данных для профиля. Параметры по умолчанию охватывают большинство сценариев мониторинга и обычно не нужно изменять.
Расширенные события
Средство расширенных событий — это надежная система мониторинга, которая фиксирует подробные действия сервера и базы данных. Фильтры можно применять для уменьшения затрат на сбор данных и сосредоточиться на конкретных проблемах производительности. Все предложения SQL Azure поддерживают расширенные события.
Хотя настройка расширенных событий аналогична sql Server, База данных SQL Azure и Управляемый экземпляр SQL Azure, в этом модуле основное внимание уделяется их различиям, а не обучению процесса установки.
Ниже приведены некоторые основные различия при настройке расширенных событий на База данных SQL Azure:
Transact-SQL: при выполнении
CREATE EVENT SESSION
команды в SQL Server используетсяON SERVER
предложение. Но на База данных SQL Azure вместо этого вы используетеON DATABASE
предложение. ПредложениеON DATABASE
также применяется к командамALTER EVENT SESSION
DROP EVENT SESSION
Transact-SQL. База данных SQL Azure поддерживает только сеансы на уровне базы данных.Сеансы область базы данных: расширенные события создаются в модели изоляции одного клиента в База данных SQL Azure. Сеанс событий в одной базе данных не может получить доступ к данным или событиям из другой базы данных. Инструкцию
CREATE EVENT SESSION
в контексте базы данных master нельзя выдавать.служба хранилища. Так как у вас нет доступа к файловой системе сервера, в котором находится база данных в База данных SQL Azure, можно настроить целевую учетную запись хранения для хранения расширенных сеансов событий.