Compartilhar via

Eventos Estendidos no SQL do Azure

Aplica-se a:Banco de dados SQL do AzureInstância Gerenciada de SQL do AzureBanco de Dados SQL no Microsoft Fabric

Para ver uma introdução aos Eventos Estendidos, consulte:

Os cenários de conjunto de recursos, funcionalidade e uso para Eventos Estendidos no Banco de Dados SQL do Azure, banco de dados SQL no Fabric e Instância Gerenciada de SQL do Azure são semelhantes ao que está disponível no SQL Server. As diferenças principais são:

  • No Banco de Dados SQL do Azure, no Banco de Dados SQL no Fabric e na Instância Gerenciada de SQL do Azure, o event_file destino sempre usa blobs no Armazenamento do Azure, em vez de arquivos em disco.
    • No SQL Server, o destino event_file pode usar tanto arquivos em disco quanto blobs no Armazenamento do Azure.
  • No Banco de Dados SQL do Azure e no Banco de Dados SQL no Fabric, as sessões de eventos sempre têm escopo de banco de dados. Isso significa que:
    • Uma sessão de evento em um banco de dados não pode coletar os eventos de outro banco de dados.
    • Um evento deve ocorrer no contexto de um banco de dados de usuário para ser incluído em uma sessão.
  • Na Instância Gerenciada de SQL do Azure, você pode criar sessões de evento com escopo de servidor e de banco de dados. Recomendamos o uso de sessões de evento com escopo de servidor para a maioria dos cenários.

Introdução

Há dois exemplos passo a passo para ajudá-lo a começar a usar eventos estendidos rapidamente:

Os Eventos Estendidos podem ser usados para monitorar réplicas somente leitura. Para obter mais informações, confira Consultas de leitura em réplicas.

Práticas recomendadas

Adote as práticas recomendadas a seguir para usar Eventos Estendidos de forma segura, confiável e sem afetar a integridade do mecanismo de banco de dados e o desempenho da carga de trabalho.

  • Se você usar o destino event_file:
    • Dependendo dos eventos adicionados a uma sessão, os arquivos produzidos pelo event_file destino podem conter dados confidenciais. Examine cuidadosamente as atribuições de função RBAC e as ACL (listas de controle de acesso) na conta de armazenamento e no contêiner, incluindo o acesso herdado, para evitar a concessão de acesso de leitura desnecessário. Siga o princípio do privilégio mínimo.
    • Use uma conta de armazenamento na mesma região do Azure que o banco de dados ou a instância gerenciada onde as sessões de eventos forem criadas.
    • Alinhe a redundância da conta de armazenamento com a redundância do banco de dados, pool elástico ou instância gerenciada. Para recursos com redundância local, use LRS, GRS ou RA-GRS. Para recursos com redundância de zona, use ZRS, GZRS ou RA-GZRS. Confira Redundância do Armazenamento do Azure para obter mais detalhes.
    • Não use nenhuma camada de acesso de BLOb diferente de Hot.
    • Não habilite o namespace hierárquico para a conta de armazenamento.
  • Se você quiser criar uma sessão de eventos com execução contínua que seja iniciada automaticamente após cada reinicialização do Mecanismo de Banco de Dados (por exemplo, após um failover ou um evento de manutenção), inclua a opção de sessão de evento STARTUP_STATE = ON em suas instruções CREATE EVENT SESSION ou ALTER EVENT SESSION.
  • Por outro lado, use STARTUP_STATE = OFF para sessões de eventos de curto prazo, como as utilizadas na solução de problemas ad hoc.
  • No banco de dados SQL do Azure, não leia eventos de deadlock na sessão de eventos interna dl. Se houver um grande número de eventos de deadlock coletados, lê-los com a função sys.fn_xe_file_target_read_file() pode causar um erro de memória insuficiente no banco de dados master. Isso pode afetar o processamento de logon e resultar em uma interrupção do aplicativo. Para ver as maneiras recomendadas de monitorar deadlocks, consulte Coletar gráficos de deadlock no banco de dados SQL do Azure com eventos estendidos.

Destinos da sessão de evento

Para obter mais informações sobre os destinos de Eventos Estendidos com suporte no Banco de Dados SQL do Azure, no Banco de Dados SQL no Fabric, na Instância Gerenciada de SQL do Azure e no SQL Server, consulte Destinos para Eventos Estendidos.

Transact-SQL diferenças

Ao executar as instruções CREATE EVENT SESSION, ALTER EVENT SESSION e DROP EVENT SESSION no SQL Server na Instância Gerenciada de SQL do Azure, você usa a cláusula ON SERVER. Porém, no Banco de Dados SQL do Azure, você usa a cláusula ON DATABASE, porque as sessões de evento do Banco de dados SQL do Azure têm escopo de banco de dados.

Exibições do catálogo de Eventos Estendidos

Os Eventos Estendidos têm várias exibições do catálogo. As exibições do catálogo informam sobre metadados ou definição da sessão de eventos. Essas exibições não retornam informações sobre as instâncias de sessões de eventos ativas.

Para obter uma lista de exibições de catálogo para cada plataforma, consulte Exibições do Catálogo de Eventos Estendidos.

Exibições de gerenciamento dinâmico de Eventos Estendidos

Os Eventos Estendidos têm várias exibições de gerenciamento dinâmico (DMVs). As DMVs retornam informações sobre as sessões de eventos iniciadas.

Para obter uma lista de DMVs para cada plataforma, consulte Exibições de Gerenciamento Dinâmico de Eventos Estendidos.

DMVs comuns

Existem outras DMVs de Eventos Estendidos que são comuns ao Banco de Dados SQL do Azure, à Instância Gerenciada de SQL do Azure e ao SQL Server:

Eventos, ações e destinos disponíveis

Você pode obter eventos, ações e destinos disponíveis usando esta consulta:

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

Consulte permissões para permissões detalhadas por plataforma.

Controle e autorização de contêiner de armazenamento

Quando você usa o event_file alvo com blobs do Armazenamento do Azure, o motor de banco de dados que executa a sessão de eventos deve ter acesso específico ao contêiner de blob. Você pode conceder esse acesso de uma das seguintes maneiras:

  • Atribua a função RBAC do Colaborador de Dados de Blob de Armazenamento à identidade gerenciada do servidor lógico do SQL do Azure ou da instância gerenciada de SQL do Azure no contêiner e crie uma credencial para instruir o Mecanismo de Banco de Dados a usar a identidade gerenciada para autenticação.

    Como alternativa à atribuição da função RBAC do Colaborador de Dados de Blob de Armazenamento, você pode atribuir as seguintes ações de 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

  • Crie um token SAS para o contêiner e armazene o token em uma credencial.

    No Banco de Dados SQL do Azure, você deve usar uma credencial com escopo de banco de dados. Na Instância Gerenciada do SQL do Azure e no SQL Server, use uma credencial com escopo de servidor.

    O token SAS criado para o contêiner de Armazenamento do Azure deve atender aos seguintes requisitos:

    • Tenha as permissões rwdl (Read, Write, Delete, List).
    • Ter um período com hora de início e hora de expiração que abranja a vida útil da sessão de evento.
    • Não ter restrições de endereço IP.

Governança de recursos

No Banco de Dados SQL do Azure, o consumo de memória por sessões de eventos estendidos é controlado dinamicamente pelo Mecanismo de Banco de Dados para minimizar a contenção de recursos.

Existe um limite de memória disponível para sessões de eventos:

  • Em um único banco de dados, a memória total para sessões é limitada a 128 MB.
  • Em um pool elástico, os bancos de dados individuais são restringidos pelos limites do banco de dados individual, e não podem exceder 512 MB no total.

Se receber uma mensagem de erro fazendo referência a um limite de memória, as medidas corretivas que você pode tomar são:

  • Executar menos sessões simultâneas do evento.
  • Usar as instruções CREATE e ALTER para sessões de eventos, além de reduzir a quantidade de memória especificada na cláusula MAX_MEMORY da sessão.

Note

Em Eventos Estendidos, a cláusula MAX_MEMORY aparece em dois contextos: ao criar ou alterar uma sessão (no nível da sessão) e ao usar o destino ring_buffer (no nível de destino). Os limites acima se aplicam à memória de nível de sessão.

Existe um limite para o número de sessões de evento iniciadas no Banco de Dados SQL do Azure:

  • Em um banco de dados individual, o limite é 100.
  • Em um pool elástico, o limite é de 100 sessões no escopo do banco de dados por pool.

Em pools elásticos densos, iniciar uma nova sessão de evento estendido poderá falhar devido a restrições de memória, mesmo quando o número total de sessões iniciadas estiver abaixo de 100.

Para localizar a memória total consumida por uma sessão de evento, execute a seguinte consulta enquanto estiver conectado ao banco de dados onde a sessão de evento foi iniciada:

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

Para localizar a memória total da sessão de eventos de um pool elástico, essa consulta precisa ser executada em todos os bancos de dados do pool.

Conteúdo relacionado

  • Last updated on