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 são restritas ao escopo do 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 usar sessões de eventos no escopo do 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 para leitura. Para obter mais informações, consulte Ler consultas 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 qualquer 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 da sessão de eventos interna integrada dl. Se houver um grande número de eventos de deadlock coletados, a leitura deles com a função sys.fn_xe_file_target_read_file() poderá causar um erro de falta de memória no banco de dados master. Isso pode afetar o processamento de logon e resultar em uma interrupção do aplicativo. Para conhecer 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.

Diferenças do Transact-SQL

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. No Banco de Dados SQL do Azure, você usa a cláusula ON DATABASE em vez disso, porque, no Banco de Dados SQL do Azure, as sessões de evento têm escopo no nível do banco de dados.

Exibições do catálogo de Eventos Estendidos

Os Eventos Estendidos fornecem vários modos de exibição de 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 dos Eventos Estendidos

Os Eventos Estendidos fornecem vários modos de exibição de gerenciamento dinâmico (DMVs). As DMVs retornam informações sobre as sessões de evento iniciadas.

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

DMVs mais 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 Colaborador de Dados de Blob de Armazenamento do RBAC à identidade gerenciada do servidor lógico do SQL do Azure ou da instância gerenciada do 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 a atribuir a função RBAC Storage Blob Data Contributor, você pode atribuir as seguintes ações 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).
    • Tenha o horário de início e o horário de expiração que abranjam toda a duração da sessão do evento.
    • Não ter restrições de endereço IP.

Perímetro de segurança de rede (versão prévia)

O perímetro de segurança de rede (prévia) estabelece um limite de acesso à rede ao redor do Banco de Dados SQL do Azure e de outros recursos da plataforma Azure como serviço (PaaS). Quando você associa um servidor lógico a um perímetro de segurança de rede (NSP), as conexões de saída que o Extended Events faz para o Armazenamento do Azure estão sujeitas às regras de acesso do perímetro.

Note

O perímetro de segurança de rede está disponível apenas para Banco de Dados SQL do Azure. Esta seção não se aplica ao Instância Gerenciada de SQL do Azure ou ao banco de dados SQL no Fabric. Como recurso de pré-visualização, o perímetro de segurança de rede está sujeito aos Termos Suplementares de Uso para as Prévias do Microsoft Azure.

Como o Extended Events utiliza o acesso à rede

O Extended Events faz conexões de saída do Mecanismo de Banco de Dados para o Armazenamento do Azure em dois casos:

  • Gravando dados de evento. Quando você inicia uma sessão de eventos com um destino event_file que aponta para um blob, o Mecanismo de Banco de Dados verifica o acesso de saída antes de iniciar a sessão e novamente sempre que descarrega os buffers de eventos no blob.
  • Lendo dados de eventos. Quando você chama sys.fn_xe_file_target_read_file ou sys.fn_MSxe_read_event_stream com uma URL de blob, o Mecanismo de Banco de Dados verifica o acesso de saída quando a função é inicializada. O SSMS chama sys.fn_MSxe_read_event_stream quando você abre dados de eventos capturados no Visualizador de Eventos.

Conexões TDS de entrada usadas para gerenciar sessões de eventos via T-SQL não precisam de nenhuma configuração NSP específica para Eventos Estendidos. As instruções CREATE EVENT SESSION, ALTER EVENT SESSION e DROP EVENT SESSION, e as funções de leitura, são executadas por meio de uma conexão de cliente normal, portanto seguem as mesmas regras de acesso de entrada que qualquer outra conexão de cliente com o banco de dados.

Configurações suportadas

O comportamento depende do modo de acesso do perímetro, de se a conta de armazenamento está no mesmo perímetro do servidor lógico e de se dois perímetros diferentes estão conectados entre si.

Servidor lógico SQL NSP Conta de armazenamento NSP Behavior
Sem NSP Sem NSP O perímetro não avalia a conexão. Extended Events se conecta à conta de armazenamento usando a credencial que você configurou e as regras do firewall da conta de armazenamento. Para mais informações, veja Autorização e controle de contêineres de armazenamento.
Sem NSP Em um NSP O perímetro não avalia o acesso de saída a partir do servidor lógico. O fato de a conexão ser bem-sucedida depende das regras de entrada do próprio perímetro da conta de armazenamento.
Em um NSP (Forçado) Mesma NSP O acesso é sempre permitido. Você não precisa de uma regra de saída.
Em um NSP (Aplicado) NSP diferente, mas interligado O acesso é permitido por meio de regras de perímetro cruzado. Você não precisa de uma regra de FQDN de saída.
Em um NSP (Aplicado) NSP diferente e não vinculado, ou sem NSP O acesso é permitido quando você usa uma identidade gerenciada, ou quando uma regra FQDN de saída no perfil perimetral corresponde ao nome do host da conta de armazenamento. Se você usar um token SAS e nenhuma regra corresponder, a sessão de eventos não será iniciada com o erro 25602, e as funções de leitura poderão falhar com o erro 25759.
Em um NSP (Transição) Qualquer O perímetro avalia e registra regras, mas não bloqueia o tráfego.

Configurar o acesso de saída à conta de armazenamento

Quando você configura um banco de dados para usar Eventos Estendidos, pode escolher entre identidade gerenciada e autenticação por token SAS. O mecanismo de autenticação que você escolher determina se você precisa de uma regra de acesso de saída.

  1. Verifique a associação ao perímetro. No portal Azure, pesquise por Perímetro de Segurança de Rede, selecione seu perímetro e então selecione Recursos Associados no menu de Configurações para confirmar que seu servidor está listado. Para mais informações, veja Perímetro de Segurança de Rede.
  2. Escolha seu mecanismo de autenticação. Use autenticação de identidade gerenciada. Um token de identidade gerenciada inclui as reivindicações que o perímetro precisa, então você não precisa adicionar uma regra de saída e pode pular a próxima etapa.
  3. Adicione uma regra de acesso de saída (apenas o token SAS). Se você usar um token SAS e o perímetro estiver em modo imposto, adicione uma regra de acesso de saída ao perfil do perímetro. Use um tipo de regra de domínios totalmente qualificados (FQDN) e o nome host da sua conta de armazenamento como valor myxedata.blob.core.windows.net, por exemplo.

Neste exemplo, você pode usar *.blob.core.windows.net para permitir todas as contas do Armazenamento do Azure, mas essa configuração permite conexões de saída para contas de armazenamento que você não possui. Use o nome específico do host sempre que puder.

Mantenha o perímetro em modo transição até confirmar quais regras de saída você precisa. No modo transição, o perímetro registra as avaliações das regras sem bloquear o acesso, então você pode encontrar regras faltantes antes que causem falhas. Mude para o modo forçado depois que as regras estiverem em vigor.

Limitações e diferenças de comportamento

  • O Mecanismo de Banco de Dados verifica o acesso de saída quando uma sessão é iniciada e a cada descarregamento do buffer. Se você remover uma regra de saída enquanto uma sessão estiver em execução, a sessão não será interrompida. As escritas individuais no buffer começam a falhar.
  • Identidades gerenciadas e tokens SAS não são equivalentes dentro de um perímetro. Um token de identidade gerenciada carrega declarações de perímetro, portanto não precisa de uma regra de saída. Um token SAS não carrega essas reivindicações, então ele precisa de uma regra de saída correspondente no modo aplicado.
  • Uma função de leitura bloqueada pode não gerar erro. Quando um perímetro bloqueia sys.fn_xe_file_target_read_file ou sys.fn_MSxe_read_event_stream, a função pode gerar o erro 25759 ou 25717, ou devolver um conjunto de resultados vazio sem erro. Se você espera dados, mas não obtém nenhuma linha nem erro, verifique suas regras de saída.

Erros quando um perímetro bloqueia o acesso

Erro 25602 significa que o event_file alvo não pôde inicializar porque o perímetro bloqueou a conexão de saída para a conta de armazenamento:

The target, "<target_name>", encountered a configuration error during initialization. Object cannot be added to the event session.
For more information, see https://go.microsoft.com/fwlink/?linkid=2336061.

Erro 25759 significa que um perímetro bloqueou uma função de leitura:

Network Security Perimeter (NSP) blocked outbound access to the storage URL '<url>'.
The NSP configuration does not allow reading from the specified location.

O erro 25717 significa que o acesso foi revogado enquanto uma função de leitura estava lendo. Como o Mecanismo de Banco de Dados lê dados de blobs em blocos em vez de baixar arquivos inteiros, esse erro pode ocorrer no meio de um conjunto de resultados:

The operating system returned error <error details> while reading from the file '<url>'.

Para resolver qualquer um desses erros, mude para autenticação gerenciada de identidade, adicione uma regra FQDN de saída que corresponda ao nome do host da conta de armazenamento, ou mova a conta de armazenamento para o mesmo perímetro do servidor lógico.

Para obter mais detalhes de diagnóstico sobre falhas de inicialização de destinos e de gravação em buffer, consulte o log do mecanismo de Eventos Estendidos:

SELECT CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_XE_LOG';

Alterações na associação de perímetros e mudanças no modo de acesso aparecem no Registro de Atividades do Azure para o servidor lógico. Avaliações de regras de entrada e saída aparecem nos registros de diagnóstico do perímetro de segurança da rede.

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:

  • Realize menos sessões de evento simultâneas.
  • Use as instruções CREATE e ALTER para sessões de evento a fim de reduzir a quantidade de memória que você especifica 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 com escopo de 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