Поделиться через

Расширенные события в SQL Azure

Область применения:База данных SQL AzureУправляемый экземпляр SQL Azureбаза данных SQL в Fabric

Общие сведения о расширенных событиях см. в статье:

Набор функций, функциональные возможности и сценарии использования расширенных событий в Базе данных SQL Azure, базе данных SQL в Fabric и Управляемом экземпляре SQL Azure похожи на то, что доступно в SQL Server. Основные различия:

  • В Azure SQL Database, SQL базе данных в Fabric и управляемом экземпляре Azure SQL всегда используются блобы в Azure Storage, а не файлы на диске.
    • В SQL Server целевой event_file объект может использовать файлы на диске или блобы в службе хранилища Azure.
  • В Базе данных SQL Azure и базе данных SQL в Fabric сеансы событий всегда находятся в пределах базы данных. Это означает, что:
    • Сеанс событий в одной базе данных не может собирать события из другой базы данных.
    • Событие должно происходить в контексте пользовательской базы данных, включаемой в сеанс.
  • В Управляемый экземпляр SQL Azure можно создавать сеансы событий с областью действия сервера и базой данных. Рекомендуется использовать сеансы событий с областью действия сервера для большинства сценариев.

Get started

Существует два пошаговых примера, которые помогут вам быстро приступить к работе с расширенными событиями:

Расширенные события можно использовать для мониторинга реплик только для чтения. Дополнительные сведения см. в статье "Чтение запросов на реплики".

Лучшие практики

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

  • Если вы используете целевой event_file объект:
    • В зависимости от событий, добавленных в сеанс, файлы, созданные event_file целевым объектом, могут содержать конфиденциальные данные. Тщательно просмотрите назначения ролей RBAC и списки управления доступом (ACL) в учетной записи хранения и контейнере, включая унаследованный доступ, чтобы избежать предоставления ненужного доступа на чтение. Следуйте принципу наименьших привилегий.
    • Используйте учетную запись хранения в том же регионе Azure, что и база данных или управляемый экземпляр, где создается сеансы событий.
    • Выравнивание избыточности учетной записи хранения с избыточностью базы данных, эластичного пула или управляемого экземпляра. Для локальных избыточных ресурсов используйте LRS, GRS или RA-GRS. Для ресурсов, избыточных между зонами, используйте ZRS, GZRS или RA-GZRS. Дополнительные сведения см. в служба хранилища Azure избыточности.
    • Не используйте уровень доступа к BLOB-объектам, кроме Hot.
    • Не включите иерархическое пространство имен для учетной записи хранения.
  • Если вы хотите создать непрерывно выполняющийся сеанс событий, который запускается автоматически после каждой ядро СУБД перезапуска (например, после отработки отказа или события обслуживания), включите параметр STARTUP_STATE = ON сеанса событий в инструкции или CREATE EVENT SESSION инструкцииALTER EVENT SESSION.
  • И наоборот, используется STARTUP_STATE = OFF для краткосрочных сеансов событий, таких как те, которые используются в нерегламентированном устранении неполадок.
  • В База данных SQL Azure не считывайте события взаимоблокировки из встроенного сеанса dl событий. Если собрано большое количество событий взаимоблокировки, считывание их с помощью функции sys.fn_xe_file_target_read_file() может вызвать ошибку вне памяти в master базе данных. Это может повлиять на обработку входа и привести к сбою приложения. Рекомендуемые способы отслеживания взаимоблокировок см. в разделе "Сбор графов взаимоблокировок" в База данных SQL Azure с расширенными событиями.

Целевые объекты сеанса событий

Дополнительные сведения о целевых объектах расширенных событий, поддерживаемых в базе данных SQL Azure, базе данных SQL в Fabric, Управляемом экземпляре SQL Azure и SQL Server, см. в разделе "Целевые объекты для расширенных событий".

различия Transact-SQL

При выполнении инструкций CREATE EVENT SESSION, ALTER EVENT SESSION и DROP EVENT SESSION в SQL Server и в Управляемый экземпляр SQL Azure используется ON SERVER предложение. В База данных SQL Azure вместо этого используется ON DATABASE предложение, так как в сеансах событий База данных SQL Azure областью действия базы данных.

Представления каталога расширенных событий

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

Список представлений каталога для каждой платформы см. в разделе "Представления каталога расширенных событий".

Динамические административные представления расширенных событий

Расширенные события предоставляют несколько динамических административных представлений (DMV). Динамические административные представления возвращают сведения о запущенных сеансах событий.

Список представлений динамического управления для каждой платформы см. в разделе "Представления динамического управления расширенных событий".

Общие динамические административные представления

Существуют дополнительные динамические административные представления расширенных событий, которые являются общими для База данных SQL Azure, Управляемый экземпляр SQL Azure и SQL Server:

Доступные события, действия и целевые объекты

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

SELECT o.object_type,
       p.name AS package_name,
       o.name AS db_object_name,
       o.description AS db_obj_description
FROM sys.dm_xe_objects AS o
INNER JOIN sys.dm_xe_packages AS p
ON p.guid = o.package_guid
WHERE o.object_type IN ('action','event','target')
ORDER BY o.object_type,
         p.name,
         o.name;

Permissions

Смотрите разрешения для получения подробной информации по каждой платформе.

Авторизация и управление контейнером хранилища

При использовании целевой event_file настройки для двоичных объектов хранилища Azure, ядро СУБД, выполняющее сеанс событий, должно иметь определенный доступ к контейнеру BLOB-объектов. Этот доступ можно предоставить одним из следующих способов:

  • Назначьте роль RBAC участника больших двоичных объектов хранилища управляемому удостоверению логического сервера SQL Azure или управляемого экземпляра SQL Azure в контейнере и создайте учетные данные для указания ядро СУБД использовать управляемое удостоверение для проверки подлинности.

    В качестве альтернативы назначению роли RBAC участника больших двоичных объектов хранилища можно назначить следующие действия RBAC:

    Namespace Action
    Microsoft.Storage/storageAccounts/blobServices/containers/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ write

  • Создайте маркер SAS для контейнера и сохраните маркер в учетных данных.

    В База данных SQL Azure необходимо использовать учетные данные с областью базы данных. В Управляемом экземпляре SQL Azure и SQL Server используйте учетные данные на уровне сервера.

    Маркер SAS, создаваемый для контейнера служба хранилища Azure, должен соответствовать следующим требованиям:

    • rwdl У вас есть разрешения (Read, Write, Delete) List.
    • Время начала и срок действия, охватывающие время существования сеанса событий.
    • Нет ограничений IP-адресов.

Управление ресурсами

В База данных SQL Azure потребление памяти расширенными сеансами событий динамически контролируется ядро СУБД для минимизации проблем ресурсов.

Существует ограничение на память, доступную для сеансов событий:

  • В одной базе данных общий объем памяти сеанса ограничен 128 МБ.
  • В эластичном пуле отдельные базы данных ограничены ограничениями одной базы данных, и в общей сложности они не могут превышать 512 МБ.

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

  • уменьшить количество одновременно запущенных сеансов событий;
  • Использование CREATE и ALTER инструкции для сеансов событий сокращают объем памяти, указанной MAX_MEMORY в предложении для сеанса.

Note

В расширенных событиях MAX_MEMORY предложение отображается в двух контекстах: при создании или изменении сеанса (на уровне сеанса) и при использовании ring_buffer целевого объекта (на целевом уровне). Указанные выше ограничения применяются к памяти уровня сеанса.

В База данных SQL Azure существует ограничение на количество запущенных сеансов событий:

  • В одной базе данных ограничение равно 100.
  • В эластичном пуле ограничение составляет 100 сеансов в пределах базы данных на пул.

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

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

SELECT name AS session_name,
       total_buffer_size + total_target_memory AS total_session_memory
FROM sys.dm_xe_database_sessions;

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

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

  • Last updated on