Eventos estendidos no SQL do Azure

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

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

O conjunto de recursos, a funcionalidade e os cenários de uso para Eventos Estendidos no Banco de Dados SQL do Azure, no Banco de Dados SQL no Fabric e na Instância Gerenciada SQL do Azure são semelhantes aos disponíveis no SQL Server. As principais diferenças são:

  • No Base de Dados SQL do Azure, no SQL database em Fabric e na Azure SQL Managed Instance, o event_file alvo utiliza sempre blobs no Armazenamento do Azure, em vez de ficheiros no disco.
    • No SQL Server, o event_file destino pode usar ficheiros no disco ou blobs no Armazenamento Azure.
  • Na Base de Dados SQL do Azure e na Base de Dados SQL no Fabric, as sessões de eventos são sempre limitadas ao âmbito da base de dados. Isto significa que:
    • Uma sessão de eventos em um banco de dados não pode coletar 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 SQL do Azure, você pode criar sessões de eventos com escopo de servidor e de banco de dados. Recomendamos o uso de sessões de eventos 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 os Eventos Estendidos rapidamente:

Os Eventos Estendidos podem ser usados para monitorizar réplicas só de leitura. Para obter mais informações, consulte Ler consultas em réplicas.

Melhores práticas

Adote as seguintes práticas recomendadas para usar os 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 event_file destino:
    • Dependendo dos eventos adicionados a uma sessão, os ficheiros produzidos pelo destino event_file podem conter dados confidenciais. Analise cuidadosamente as atribuições de função RBAC e as listas de controle de acesso (ACL) 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 menor privilégio.
    • Use uma conta de armazenamento na mesma região do Azure que o banco de dados ou a instância gerenciada onde você cria sessões de eventos.
    • 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 localmente redundantes , use LRS, GRS ou RA-GRS. Para recursos com redundância de zona, utilize ZRS, GZRS ou RA-GZRS. Consulte Redundância do Armazenamento do Azure para obter detalhes.
    • Não utilize qualquer escalão de acesso do blob que não seja Hot.
    • Não habilite o namespace hierárquico para a conta de armazenamento.
  • Se quiser criar uma sessão de eventos de execução contínua que seja iniciada automaticamente após cada reinicialização do Motor de Base de Dados (por exemplo, após um failover ou um evento de manutenção), inclua a opção da sessão de eventos em STARTUP_STATE = ON nas 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 usadas na solução de problemas ad hoc.
  • Na Base de Dados SQL do Azure, não leia eventos de deadlock da sessão de eventos incorporada dl. Se for recolhido um grande número de eventos de interbloqueio, a sua leitura com a função sys.fn_xe_file_target_read_file() pode causar um erro de memória insuficiente na base de dados master. Isso pode afetar o processamento de login e resultar em uma interrupção do aplicativo. Para obter 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 destinos de Eventos Estendidos com suporte no Banco de Dados SQL do Azure, Banco de Dados SQL no Fabric, Instância Gerenciada SQL do Azure e SQL Server, consulte Destinos para Eventos Estendidos.

Diferenças de Transact-SQL

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

Vistas do catálogo de Eventos Expandidos

Eventos Estendidos fornecem várias vistas de catálogo. As visualizações de catálogo indicam os metadados ou a definição da sessão de evento. Essas exibições não retornam informações sobre instâncias de sessões de eventos ativas.

Para obter uma lista de exibições de catálogo para cada plataforma, consulte Exibições de catálogo de eventos estendidos.

Vistas de gestão dinâmica dos Eventos Estendidos

Os Eventos Estendidos disponibilizam várias vistas de gestão dinâmica (DMVs). Os DMVs retornam informações sobre sessões de eventos iniciadas .

Para obter uma lista de DMVs para cada plataforma, consulte Vistas de Gestão Dinâmica de Eventos Estendidos.

DMVs comuns

Há DMVs de Eventos Estendidos adicionais que são comuns ao Banco de Dados SQL do Azure, à Instância Gerenciada do 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 as permissões para obter permissões detalhadas por plataforma.

Autorização e controlo de contentores de armazenagem

Quando se usa o alvo event_file com blobs de Armazenamento do Azure, o Mecanismo de Banco de Dados que executa a sessão de eventos deve ter acesso específico ao recipiente de blobs. 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 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 à atribuição da função RBAC Storage Blob Data Contributor, 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 SQL do Azure e no SQL Server, use uma credencial com escopo de servidor.

    O token SAS que você cria para seu contêiner de Armazenamento do Azure deve atender aos seguintes requisitos:

    • Ter as permissões rwdl(Read, Write, Delete, List).
    • Tenha a hora de início e a hora de expiração que abrangem o tempo de vida da sessão do evento.
    • Não tem restrições de endereço IP.

Perímetro de segurança de rede (pré-visualização)

O perímetro de segurança de rede (pré-visualização) estabelece um limite de acesso à rede em torno do Base de Dados SQL do Azure e de outros recursos da plataforma Azure as a Service (PaaS). Quando associa um servidor lógico a um perímetro de segurança de rede (NSP), as ligaçõ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 o Base de Dados SQL do Azure. Esta secção não se aplica ao Azure SQL Managed Instance nem à base de dados SQL no Fabric. Como funcionalidade de pré-visualização, o perímetro de segurança de rede está sujeito a Termos Suplementares de Utilização para Pré-visualizações do Microsoft Azure.

Como o Extended Events utiliza o acesso à rede

O Extended Events faz ligações de saída do Database Engine para o Armazenamento do Azure em dois casos:

  • A escrever dados de eventos. Quando inicia uma sessão de eventos com um alvo event_file que aponta para um blob, o Motor da Base de Dados verifica o acesso de saída antes de a sessão ser iniciada e, novamente, sempre que descarrega os buffers de eventos para o blob.
  • Leitura de dados de eventos. Quando chamas sys.fn_xe_file_target_read_file ou sys.fn_MSxe_read_event_stream com um URL de blob, o Database Engine verifica o acesso de saída quando a função se inicializa. O SSMS chama sys.fn_MSxe_read_event_stream quando abre os dados de eventos capturados no visualizador de eventos.

As ligações TDS de entrada usadas para gerir sessões de eventos via T-SQL não necessitam 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 todas executadas através de uma ligação normal de cliente, pelo que seguem as mesmas regras de acesso de entrada do que qualquer outra ligação de cliente à base 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 ligados entre si.

Servidor lógico SQL NSP Conta de armazenamento NSP Comportamento
Sem NSP Sem NSP O perímetro não verifica a ligação. O Extended Events liga-se à conta de armazenamento usando a credencial que configurou e as regras do firewall da conta de armazenamento. Para mais informações, consulte Autorização e controlo de contentores de armazenamento.
Sem NSP Num NSP O perímetro não avalia o acesso de saída a partir do servidor lógico. O sucesso da ligação depende das regras de entrada do próprio perímetro da conta de armazenamento.
Num NSP (Aplicado) Mesma NSP O acesso é sempre permitido. Não precisas de uma regra de saída.
Num NSP (Aplicado) NSP diferente mas ligado O acesso é permitido através de regras de perímetro cruzado. Não precisas de uma regra de FQDN outbound.
Num NSP (Aplicado) NSP diferente, não associado, ou sem NSP O acesso é permitido quando usa uma identidade gerida, ou quando uma regra FQDN de saída no perfil perimetral corresponde ao nome do host da conta de armazenamento. Se utilizar um token SAS e nenhuma regra corresponder, a sessão de eventos não consegue iniciar, apresentando o erro 25602, e as funções de leitura podem falhar com o erro 25759.
Numa NSP (Transição) Any O perímetro avalia e regista as regras, mas não bloqueia o tráfego.

Configurar o acesso de saída à conta de armazenamento

Ao configurar uma base de dados para usar Eventos Estendidos, pode escolher entre identidade gerida e autenticação com token SAS. O mecanismo de autenticação que escolher determina se precisa de uma regra de acesso de saída.

  1. Verifique a associação ao perímetro. No portal Azure, procure por Perímetro de Segurança de Rede, selecione o seu perímetro e depois selecione Recursos Associados no menu Definições para confirmar que o seu servidor está listado. Para mais informações, consulte Perímetro de Segurança de Rede.
  2. Escolhe o teu mecanismo de autenticação. Use autenticação de identidade gerida. Um token de identidade gerida inclui as declarações de que o perímetro necessita, pelo que não precisa de adicionar uma regra de saída e pode ignorar o passo seguinte.
  3. Adicionar uma regra de acesso de saída (apenas token SAS). Se utilizar um token SAS e o perímetro estiver em modo imposto, adicione uma regra de acesso de saída no perfil de perímetro. Use um tipo de regra de nomes de domínio totalmente qualificados (FQDN) e o nome de host da sua conta de armazenamento como valor myxedata.blob.core.windows.net, por exemplo.

Neste exemplo, podes usar *.blob.core.windows.net para permitir todas as contas do Armazenamento do Azure, mas essa definição permite ligações de saída a contas de armazenamento que não possuis. Usa o nome de anfitrião específico sempre que puderes.

Mantenha o perímetro em modo de transição até confirmar quais as regras de saída de que necessita. No modo de transição, o perímetro regista as avaliações das regras sem bloquear o acesso, por isso pode encontrar regras em falta antes que causem falhas. Muda para o modo forçado depois de as regras estarem em vigor.

Limitações e diferenças de comportamento

  • O motor de base de dados verifica o acesso de saída quando uma sessão é iniciada e sempre que o buffer é descarregado. Se remover uma regra de saída enquanto uma sessão está a decorrer, a sessão não é interrompida. Em vez disso, as escritas individuais no buffer começam a falhar.
  • Identidades geridas e tokens SAS não são equivalentes sob um perímetro. Um token de identidade gerida inclui afirmações de perímetro, pelo que não precisa de uma regra de saída. Um token SAS não transporta essas reivindicações, por isso precisa de uma regra de saída correspondente em modo aplicado.
  • Uma função de leitura bloqueada pode não gerar um 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 esperares dados, mas não obtiveres nenhuma linha nem nenhum erro, verifica as tuas regras de saída.

Erros quando um perímetro bloqueia o acesso

O erro 25602 significa que o event_file alvo não conseguiu inicializar porque o perímetro bloqueou a ligação de saída à 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.

O 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 a ler. Como o Database Engine lê dados de blobs em blocos em vez de descarregar ficheiros inteiros, este erro pode ocorrer a meio de um conjunto de resultados:

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

Para resolver qualquer um destes erros, mude para autenticação de identidade gerida, 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 a inicialização do destino e as falhas de escrita em buffer, consulte o registo do motor 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 alterações no modo de acesso aparecem no Registo de Atividades do Azure para o servidor lógico. As avaliações das regras de entrada e saída aparecem nos registos de diagnóstico do perímetro de segurança da rede.

Governação dos recursos

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

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

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

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

  • Execute menos sessões de eventos simultâneos.
  • Ao utilizar as instruções CREATE e ALTER para sessões de eventos, reduza a quantidade de memória que especifica na cláusula MAX_MEMORY da sessão.

Note

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

Há um limite no número de sessões de eventos iniciadas no Banco de Dados SQL do Azure:

  • Em um único banco de dados, o limite é 100.
  • Num pool elástico, o limite é de 100 sessões ao nível da base de dados por pool.

Em pools elásticos densos, iniciar uma nova sessão de evento estendida pode 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 para um pool elástico, essa consulta precisa ser executada em todos os bancos de dados do pool.

Conteúdo relacionado

  • Última atualização a