Устранение проблем с производительностью с помощью Intelligent Insights — База данных SQL Azure и Управляемый экземпляр SQL Azure

Применимо к: База данных SQL Azure Управляемый экземпляр SQL Azure

Эта страница содержит сведения о проблемах производительности Базы данных SQL Azure и Управляемого экземпляра SQL Azure, которые можно обнаружить с помощью журнала ресурсов Intelligent Insights. Метрики и журналы ресурсов можно потоково передать в журналы Azure Monitor, Центры событий Azure, службу хранилища Azure или стороннее решение для разработки настраиваемых функций оповещения и создания отчетов в соответствии с процедурами DevOps.

Примечание.

Краткие инструкции по устранению неполадок производительности с помощью Intelligent Insights приведены на блок-схеме рекомендуемой последовательности устранения неполадок в этом документе.

Intelligent Insights — это предварительная версия функции, недоступная в следующих регионах: Западная Европа, Северная Европа, западная часть США 1 и восточная часть США 1.

Выявляемые шаблоны снижения производительности базы данных

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

Выявляемые шаблоны снижения производительности	База данных SQL Azure	Управляемый экземпляр SQL Azure
Достижение лимитов ресурсов	Потребление доступных ресурсов, рабочих потоков базы данных или сеансов входа в базу данных, доступных в отслеживаемой подписке, достигло своих ограничений на ресурсы. Это влияет на производительность.	Достигнуты лимиты по потреблению ресурсов ЦП. Это негативно влияет на производительность базы данных.
Увеличение рабочей нагрузки	Обнаружено увеличение рабочей нагрузки или непрерывное накопление рабочей нагрузки для базы данных. Это влияет на производительность.	Обнаружено увеличение рабочей нагрузки. Это негативно влияет на производительность базы данных.
Нехватка памяти	Рабочим ролям, запрашивающим временно предоставляемый буфер памяти, потребовалось ожидать выделения памяти статистически значимое количество времени, или накоплено повышенное количество рабочих ролей, запрашивающих временно предоставляемый буфер памяти. Это влияет на производительность.	Рабочие роли, запрашивающие временно предоставляемый буфер памяти, ожидают выделения памяти статистически значимое количество времени. Это негативно влияет на производительность базы данных.
Блокировка	Обнаружена чрезмерная блокировка, негативно влияющая на производительность базы данных.	Обнаружена чрезмерная блокировка базы данных, негативно влияющая на производительность базы данных.
Повышенное значение MAXDOP	Значение параметра максимальной степени параллелизма (MAXDOP) было изменено, что негативно влияет на эффективность выполнения запроса. Это влияет на производительность.	Значение параметра максимальной степени параллелизма (MAXDOP) было изменено, что негативно влияет на эффективность выполнения запроса. Это влияет на производительность.
Состязание за кратковременную блокировку страниц	Несколько потоков одновременно пытаются обратиться к одним и тем же страницам в буфере данных в памяти, что приводит к увеличению времени ожидания и вызывает состязание за кратковременную блокировку страниц. Это влияет на производительность.	Несколько потоков одновременно пытаются обратиться к одним и тем же страницам в буфере данных в памяти, что приводит к увеличению времени ожидания и вызывает состязание за кратковременную блокировку страниц. Это негативно влияет на производительность базы данных.
Отсутствующий индекс	Обнаружен отсутствующий индекс, негативно влияющий на производительность базы данных.	Обнаружен отсутствующий индекс базы данных, негативно влияющий на производительность базы данных.
Новый запрос	Обнаружен новый запрос, который негативно влияет на общую производительность.	Обнаружен новый запрос, который негативно влияет на общую производительность базы данных.
Повышенное значение статистики ожидания	Обнаружены повышенные значения времени ожидания, негативно влияющие на производительность базы данных.	Обнаружены повышенные значения времени ожидания базы данных, негативно влияющие на производительность базы данных.
Состязание за tempdb	Несколько потоков пытаются получить доступ к одному tempdb ресурсу, что приводит к узким местам. Это влияет на производительность.	Несколько потоков пытаются получить доступ к одному tempdb ресурсу, что приводит к узким местам. Это негативно влияет на производительность базы данных.
Нехватка DTU эластичного пула	Нехватка доступных eDTU в эластичном пуле негативно влияет на производительность.	Недоступно для Управляемого экземпляра SQL Azure, так как в нем используется модель с виртуальными ядрами.
Снижение эффективности плана	Обнаружен новый план или изменение рабочей нагрузки существующего плана. Это влияет на производительность.	Обнаружен новый план или изменение рабочей нагрузки существующего плана. Это негативно влияет на производительность базы данных.
Изменение значения конфигурации уровня базы данных	Обнаружено изменение конфигурации базы данных, негативно влияющее на производительность базы данных.	Обнаружено изменение конфигурации базы данных, негативно влияющее на производительность базы данных.
Медленная работа клиента	Медленный клиент приложения не может достаточно быстро использовать выходные данные из базы данных. Это влияет на производительность.	Медленный клиент приложения не может достаточно быстро использовать выходные данные из базы данных. Это негативно влияет на производительность базы данных.
Переход на более низкую ценовую категорию	Действие перехода на более низкую ценовую категорию уменьшило объем доступных ресурсов. Это влияет на производительность.	Действие перехода на более низкую ценовую категорию уменьшило объем доступных ресурсов. Это негативно влияет на производительность базы данных.

Совет

Чтобы непрерывно оптимизировать производительность базы данных, рекомендуется включить автоматическую настройку. Это функция встроенного аналитического механизма, которая постоянно отслеживает базу данных, автоматически настраивает индексы и применяет исправления к плану выполнения запросов.

В следующем разделе более подробно описаны обнаруженные шаблоны снижения производительности.

достижение лимитов ресурсов;

Что происходит

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

Ресурсы в Базе данных SQL Azure обычно называются ресурсами DTU или ресурсами виртуального ядра, а ресурсы в Управляемом экземпляре SQL Azure — ресурсами виртуального ядра. Шаблон достижения лимитов ресурсов обнаруживается, когда причиной выявленного снижения производительности обработки запросов является достижение лимитов измеряемого ресурса.

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

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

Устранение неполадок с ограничениями ресурсов

Журнал диагностики генерирует хэши запросов, которые повлияли на производительность и процент потребления ресурсов. Эти сведения можно использовать в качестве отправной точки для оптимизации рабочей нагрузки базы данных. В частности, можно оптимизировать запросы, приводящие к снижению производительности, путем добавления индексов. Или оптимизировать приложения за счет более равномерного распределения рабочей нагрузки. Если не удалось уменьшить рабочую нагрузку или применить оптимизацию, следует рассмотреть возможность повышения ценовой категории подписки базы данных, чтобы увеличить объем доступных ресурсов.

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

Дополнительные предложения по устранению проблем с ограничениями максимального числа операций входа см. в этой статье. Сведения об ограничениях на уровне сервера и подписки см. в База данных SQL Azure в База данных SQL Azure.

Увеличение рабочей нагрузки

Что происходит

Этот шаблон снижения производительности позволяет выявить проблемы из-за увеличения рабочей нагрузки или, если ситуация серьезнее, из-за накопления рабочей нагрузки.

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

В более серьезной ситуации рабочая нагрузка постоянно накапливается из-за того, что база данных не справляется с ее обработкой. В результате размер рабочей нагрузки постоянно растет, то есть возникает ее накопление. В этой ситуации время, на протяжении которого рабочая нагрузка ожидает выполнения, увеличивается. Это состояние — одна из наиболее серьезных проблем с производительностью базы данных. Данная проблема выявляется за счет мониторинга увеличения числа прерванных рабочих потоков.

Устранение неполадок с ростом рабочей нагрузки

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

Можно также рассмотреть возможность более равномерного распределения рабочих нагрузок в базе данных. Вы можете оптимизировать запрос, который влияет на производительность, добавив индексы. Можно также распределить рабочую нагрузку между несколькими базами данных. Если такие решения невозможны, рассмотрите возможность повышения ценовой категории подписки базы данных, чтобы увеличить объем доступных ресурсов.

Нехватка памяти

Что происходит

Этот шаблон снижения производительности указывает на снижение текущей производительности базы данных из-за нехватки памяти или, если ситуация более серьезная, из-за накопления запросов на выделение памяти по сравнению с базовыми показателями производительности за последние семь дней.

Нехватка памяти означает состояние производительности, в котором большое количество рабочих потоков запрашивает временно предоставляемый буфер памяти. Это приводит к использованию большого объема памяти. В данной ситуации база данных не может эффективно выделить память для всех запрашивающих ее рабочих процессов. С одной стороны, одна из наиболее распространенных причин этой проблемы связана с объемом памяти для базы данных, а с другой стороны — с увеличением рабочей нагрузки, приводящей к увеличению числа рабочих потоков и нехватке памяти.

В более серьезной ситуации нехватки памяти запросы на выделение памяти накапливаются. Это признак того, что число рабочих потоков, запрашивающих временно предоставляемый буфер памяти, превышает число запросов, освобождающих память. Это число рабочих потоков, запрашивающих временно предоставляемый буфер памяти, также может постоянно увеличиваться (накапливаться), так как ядру СУБД не удается эффективно выделять память для удовлетворения этих потребностей. Накопление запросов на выделение памяти представляет собой одну из наиболее серьезных проблем с производительностью базы данных.

Устранение неполадок с давлением на память

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

Можно оптимизировать или удалить запросы, связанные с клерками с наибольшим использованием памяти. Можно также проследить за тем, чтобы данные, которые не планируется использовать, не запрашивались. Рекомендуется всегда использовать в запросах предложение WHERE. Кроме того, рекомендуется создать некластеризованные индексы для поиска данных, а не сканирования.

Вы можете снизить рабочую нагрузку, оптимизировав или распределив ее по нескольким базам данных. Рабочую нагрузку также можно распределить между несколькими базами данных. Если такие решения невозможны, рассмотрите возможность повышения ценовой категории базы данных, чтобы увеличить объем ресурсов памяти, доступных базе данных.

Дополнительные рекомендации по устранению неполадок см. в разделе Memory Grants Meditation: The mysterious SQL Server memory consumer with Many Names (Устранение проблем с памятью: загадочный потребитель памяти SQL Server со множеством имен). Дополнительные сведения об ошибках, связанных с нехваткой памяти в Базе данных SQL Azure, см. в статье Устранение ошибок нехватки памяти в базе данных Azure SQL.

Блокировка

Что происходит

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

В современных реляционных СУБД блокировка необходима для реализации многопоточных систем, в которых максимальная производительность достигается благодаря выполнению нескольких одновременных рабочих процессов и параллельных транзакций базы данных, где это возможно. Блокировка в этом контексте означает встроенный механизм доступа, при котором только одна транзакция может иметь монопольный доступ к необходимым строкам, страницам, таблицам и файлам, не состязаясь за ресурсы с другой транзакцией. После того как транзакция, заблокировавшая ресурсы, завершает их использование, их блокировка снимается и они становятся доступны другим транзакциям. Дополнительные сведения о блокировке см. в статье Блокировка в ядре СУБД.

Транзакции, выполняемые ядром SQL, в течение длительного времени ожидают доступа к заблокированным ресурсам, это вызывает снижение производительности выполнения рабочей нагрузки.

Устранение неполадок с блокировкой и блокировкой

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

Наиболее простой и безопасный способ устранения проблемы — ограничение объема транзакций и сокращение объема блокируемых ресурсов для наиболее ресурсоемких запросов. Большой пакет операций можно разбить на операции меньшего размера. Рекомендуется сократить объем блокируемых запросом ресурсов, максимально повысив его эффективность. Сократите крупные операции сканирования, так как они повышают вероятность возникновения взаимоблокировок и отрицательно влияют на общую производительность базы данных. Для выявленных запросов, которые вызывают блокировку, можно создать новые индексы или добавить столбцы в существующий индекс, чтобы избежать сканирования таблиц.

Дополнительные рекомендации см. в следующих статьях:

• Изучение и устранение проблем с блокировкой Базы данных SQL Azure
• Как решить проблемы с блокировками, вызванные эскалацией блокировок в SQL Server

Повышенное значение MAXDOP

Что происходит

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

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

Параметр конфигурации сервера MAXDOP позволяет указать, сколько ядер ЦП можно использовать для выполнения запроса в параллельном режиме.

Устранение неполадок параллелизма

Журнал диагностики содержит хэши запросов, время выполнения которых увеличилось из-за чрезмерного распараллеливания. Журнал также содержит значения времени ожидания CXP. Это время, которое отдельный поток организатора или координатора (поток 0) ожидает завершения выполнения всех остальных потоков перед объединением результатов и переходом к следующей операции. Кроме того, журнал диагностики содержит общее время ожидания выполнения для запросов с низкой производительностью. Эти сведения можно использовать как основу при устранении неполадок.

Сначала следует оптимизировать или упростить сложные запросы. Рекомендуется разбить длительные пакетных задания на более мелкие. Кроме того, убедитесь, что созданы индексы для обработки запросов. Можно также вручную задать максимальную степень параллелизма (MAXDOP) для запроса, производительность которого оказалась низкой. Для настройки этой операции с помощью T-SQL см. сведения в разделе Настройка параметра конфигурации сервера max degree of parallelism.

Если для параметра конфигурации сервера MAXDOP в качестве значения по умолчанию задать ноль (0), то база данных сможет использовать все доступные ядра ЦП для параллельного выполнения потоков, выполняющих отдельный запрос. Если для параметра конфигурации сервера MAXDOP задать единицу (1), то для выполнения отдельного запроса сможет использоваться только одно ядро. То есть фактически распараллеливание будет отключено. В зависимости от ситуации, доступных ядер базы данных и сведений в журнале диагностики, можно задать для параметра MAXDOP соответствующее число ядер для параллельного выполнения запросов, чтобы устранить возникшую проблему.

Состязание за кратковременную блокировку страниц

Что происходит

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

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

Есть много типов кратковременных блокировок. В целях упрощения кратковременные блокировки буфера используются для защиты страниц в памяти в буферном пуле, а кратковременные блокировки ввода-вывода используются для защиты страниц, которые еще не загружены в буферный пул. При каждой операции записи или чтения данных страницы в буферном пуле рабочий поток должен сначала наложить кратковременную блокировку на буфер для этой страницы. Каждый раз, когда рабочий поток пытается получить доступ к странице, которая еще не доступна в буферном пуле в памяти, выполняется запрос на ввод-вывод для загрузки необходимых сведений из хранилища. Эта последовательность событий указывает на более серьезное снижение производительности.

Состязание за кратковременную блокировку страниц происходит, когда несколько потоков одновременно пытаются наложить кратковременную блокировку на одну и ту же структуру в памяти, что приводит к увеличению времени ожидания выполнения запроса. В случае состязания за блокировку страниц для вода-вывода, когда требуется доступ к данным из хранилища, время ожидания будет еще больше. Это может значительно повлиять на производительность рабочей нагрузки. Состязание за кратковременную блокировку страниц — наиболее распространенная ситуация, в которой потоки ожидают друг друга и состязаются за ресурсы в многопроцессорных системах.

Устранение неполадок, связанных с блокировкой страниц

Журнал диагностики выводит сведения о состязании за кратковременную блокировку страниц. Эти сведения можно использовать как основу при устранении неполадок.

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

Один из методов обработки состязаний за кратковременную блокировку — замена последовательного ключа индекса непоследовательным ключом, что позволяет равномерно распределить вставку данных в пределах индекса. Как правило, начальный столбец в индексе распределяет рабочую нагрузку пропорционально. Кроме того, можно рассмотреть возможность секционирования таблиц. Создание схемы хэш-секционирования с вычисляемым столбцом для секционированной таблицы — распространенный способ устранения чрезмерного состязания за кратковременную блокировку. В случае состязания за блокировку страниц для вода-вывода рекомендуется добавить индексы, что позволит устранить данную проблему с производительностью.

Дополнительные сведения см. в документе Diagnosing and Resolving Latch Contention on SQL Server (Диагностика и устранение состязания за кратковременную блокировку в SQL Server), который можно скачать в формате PDF.

Отсутствующий индекс

Что происходит

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

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

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

Устранение неполадок с дорогостоящими запросами с помощью индексов

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

Совет

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

Чтобы непрерывно оптимизировать производительность, рекомендуется включить автоматическую настройку. Эта уникальная функция встроенного аналитического механизма постоянно отслеживает базу данных и автоматически создает и настраивает индексы для баз данных.

Создать запрос

Что происходит

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

Иногда создание высокопроизводительного запроса может быть сложной задачей. Дополнительные сведения о создании запросов см. в статье о написании SQL-запросов. Дополнительные сведения об оптимизации производительности имеющихся запросов см. в статье Настройка запроса.

Устранение проблем с производительностью запросов

Журнал диагностики содержит до двух новых запросов, потребляющих больше всего ресурсов ЦП, включая их описание и хэши. Так как обнаруженный запрос влияет на производительность рабочей нагрузки, его можно оптимизировать. Целесообразно извлекать только те данные, которые необходимо использовать. Мы также рекомендуем использовать запросы с предложением WHERE . а также упростить сложные запросы и разделить их на запросы меньшего размера. Рекомендуется также разбивать большие пакетные запросы на пакетные запросы меньшего размера. Как правило, устранить данную проблему с производительностью помогает создание индексов для новых запросов.

В База данных SQL Azure рекомендуется использовать аналитику производительности запросов для База данных SQL Azure.

Повышенное значение статистики ожидания

Что происходит

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

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

Устранение неполадок статистики ожидания

Журнал диагностики содержит сведения о повышенных значениях времени ожидания и хэши соответствующих запросов.

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

Дополнительные сведения об оптимизации производительности запросов см. в статье Настройка запроса.

Состязание за tempdb

Что происходит

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

Устранение неполадок с состязанием tempdb

Диагностика журнал выводит tempdb сведения о состязании. Данные можно использовать в качестве отправной точки при устранении неполадок. Есть две вещи, которые можно предпринять, чтобы обойти эту проблему и увеличить пропускную способность всей рабочей нагрузки: прекратить использование временных таблиц и использовать таблицы, оптимизированные для памяти.

Дополнительные сведения см. в статье Введение в таблицы, оптимизированные для памяти.

Нехватка DTU эластичного пула

Что происходит

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

Ресурсы эластичного пула Azure используются в качестве пула доступных ресурсов, совместно используемого несколькими базами данных в целях масштабирования. Когда ресурсов eDTU, доступных в эластичном пуле, недостаточно, чтобы обеспечить все базы данных в пуле, система выявляет проблему с производительностью из-за нехватки DTU эластичного пула.

Устранение неполадок с нехваткой DTU эластичного пула

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

Так как данная проблема производительности связана с несколькими базами данных, использующими один пул eDTU в эластичном пуле, действия по устранению этой проблемы сосредотачиваются на базах данных, которые используют больше всего ресурсов DTU. Вы можете уменьшить нагрузку на самые ресурсоемкие базы данных, оптимизировав самые ресурсоемкие запросы в этих базах данных. Можно также проследить за тем, чтобы данные, которые не используются, не запрашивались. Другой подход заключается в оптимизации приложений, использующих базы данных, которые потребляют больше всего ресурсов DTU, и перераспределении рабочей нагрузки между несколькими базами данных.

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

Снижение эффективности плана

Что происходит

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

Ядро СУБД определяет план выполнения запросов с наименьшими затратами на выполнение запроса. Иногда из-за изменения типа запросов и рабочих нагрузок имеющиеся планы утрачивают эффективность. Проблема может заключаться также в недостаточной качественной оценке ядра СУБД. Исправить планы выполнения запросов можно вручную.

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

Снижение эффективности нового плана означает, что ядро СУБД начало выполнять новый план выполнения запросов, эффективность которого ниже, чем эффективность старого плана. Снижение эффективности старого плана означает, что ядро СУБД переключилось с нового, более эффективного плана, на старый план, эффективность которого ниже. Снижение эффективности существующих планов из-за изменения рабочей нагрузки означает ситуацию, в которой новый и старый план непрерывно использовались по очереди, причем предпочтение отдавалось плану с более низкой эффективностью.

Дополнительные сведения о регрессии плана см. в статье "Что такое регрессия плана в SQL Server?"

Устранение неполадок регрессии плана

Журнал диагностики содержит хэши запросов, идентификатор высокоэффективного плана, идентификатор низкоэффективного плана и идентификаторы запросов. Эти сведения можно использовать как основу при устранении неполадок.

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

Дополнительные сведения см. в разделе How SQL Server 2017 prevents plan regressions (Как SQL Server 2017 предотвращает снижение эффективности).

Совет

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

Чтобы непрерывно оптимизировать производительность, рекомендуется включить автоматическую настройку. Эта функция встроенного аналитического механизма постоянно отслеживает базу данных и автоматически создает оптимальные планы выполнения запросов для баз данных.

Изменение значения конфигурации уровня базы данных

Что происходит

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

Изменение конфигурации уровня базы данных можно задать отдельно для каждой базы данных. Данная конфигурация используется на индивидуальной основе для оптимизации производительности отдельных баз данных. Для каждой отдельной базы данных можно настроить следующие параметры: MAXDOP, LEGACY_CARDINALITY_ESTIMATION, PARAMETER_SNIFFING, QUERY_OPTIMIZER_HOTFIXES и CLEAR PROCEDURE_CACHE.

Устранение неполадок с изменениями конфигурации с областью действия базы данных

Журнал диагностики содержит последние изменения конфигурации уровня базы данных, которые привели к снижению производительности по сравнению с показателями рабочей нагрузки за последние семь дней. Вы можете отменить изменения конфигурации и восстановить предыдущие значения. Можно также поочередно настроить все ее значения, пока не будет достигнут нужный уровень производительности. Можно также скопировать значения конфигурации уровня базы данных из аналогичной базы данных с удовлетворительной производительностью. Если вам не удалось устранить проблемы с производительностью, восстановите значения по умолчанию и попытайтесь оптимизировать ее, начав с этих базовых показателей.

Дополнительные сведения об оптимизации конфигурации уровня базы данных и синтаксисе T-SQL для изменения конфигурации приведены в статье ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL).

Медленная работа клиента

Что происходит

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

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

Устранение неполадок клиентских приложений

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

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

Понижение ценовой категории

Что происходит

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

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

Устранение неполадок с понижением ценовой категории

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

Рекомендуемая процедура устранения неполадок

На блок-схеме показан рекомендуемый подход к устранению проблем с производительностью с помощью Intelligent Insights.

Функции Intelligent Insights доступны на портале Azure. Чтобы воспользоваться ими, следует перейти к SQL Azure Analytics. Попытайтесь найти входящее оповещение о производительности и выберите его. На странице "Обнаружения" выясните, что происходит. Изучите предоставленный анализ первопричин проблемы, текст запросов, тенденции длительности запросов и развитие инцидента. Попытайтесь устранить проблему с производительностью с помощью соответствующей рекомендации Intelligent Insights.

Совет

Выберите блок-схему, чтобы загрузить версию PDF.

Обычно Intelligent Insights требуется один час для выполнения анализа первопричин проблемы с производительностью. Если проблему не удается найти в Intelligent Insights, но это крайне важно для вас, используйте хранилище запросов, чтобы вручную определить первопричину проблемы производительности. (Как правило, такие проблемы возникли менее одного часа назад.) Дополнительные сведения см. в статье Мониторинг производительности с использованием хранилища запросов.

Связанный контент

• Intelligent Insights для мониторинга и устранения неполадок производительности базы данных (предварительная версия)
• Использование журнала диагностика производительности Intelligent Insights База данных SQL Azure и проблем с производительностью Управляемый экземпляр SQL Azure
• Azure SQL Analytics
• Сбор и использование данных журнала из ресурсов Azure