Partilhar via

Notificações de eventos

Aplica-se a:SQL Server

As notificações de eventos enviam informações sobre eventos para um serviço do Service Broker. As notificações de eventos são executadas em resposta a uma variedade de instruções DDL (linguagem de definição de dados) Transact-SQL e eventos de Rastreamento SQL, enviando informações sobre esses eventos para um serviço do Service Broker.

As notificações de eventos podem ser usadas para fazer o seguinte:

  • Registre e revise alterações ou atividades que ocorrem no banco de dados.
  • Execute uma ação em resposta a um evento de forma assíncrona em vez de síncrona.

As notificações de eventos podem oferecer uma alternativa de programação aos gatilhos DDL e ao Rastreamento SQL.

Benefícios das notificações de eventos

As notificações de eventos são executadas de forma assíncrona, fora do escopo de uma transação. Portanto, ao contrário dos gatilhos DDL, as notificações de eventos podem ser usadas dentro de um aplicativo de banco de dados para responder a eventos sem usar nenhum recurso definido pela transação imediata.

Ao contrário do Rastreamento SQL, as notificações de eventos podem ser usadas para executar uma ação dentro de uma instância do SQL Server em resposta a um evento de Rastreamento SQL.

Os dados de eventos podem ser usados por aplicativos que estão sendo executados junto com o SQL Server para acompanhar o progresso e tomar decisões. Por exemplo, a notificação de evento a seguir envia um aviso para um determinado serviço toda vez que uma ALTER TABLE instrução é emitida no AdventureWorks2025 banco de dados de exemplo.

USE AdventureWorks2022;
GO

CREATE EVENT NOTIFICATION NotifyALTER_T1
    ON DATABASE
    FOR ALTER_TABLE
    TO SERVICE '//Adventure-Works.com/ArchiveService',
        '8140a771-3c4b-4479-8ac0-81008ab17984';

Conceitos de notificações de eventos

Quando uma notificação de evento é criada, uma ou mais conversas do Service Broker entre uma instância do SQL Server e o serviço de destino especificado são abertas. As conversas normalmente permanecem abertas enquanto a notificação de evento existir como um objeto na instância do servidor. Em alguns casos de erro, as conversas podem ser fechadas antes que a notificação de evento seja descartada. Essas conversas nunca são compartilhadas entre notificações de eventos. Cada notificação de evento tem suas próprias conversas exclusivas. Encerrar uma conversa impede explicitamente que o serviço de destino receba mais mensagens, e a conversa não será reaberta na próxima vez que a notificação de evento for acionada.

As informações de evento são entregues ao serviço Service Broker como uma variável do tipo xml que fornece informações sobre quando ocorre um evento, sobre o objeto de banco de dados afetado, a instrução de lote Transact-SQL envolvida e outras informações. Para obter mais informações sobre o esquema XML produzido por notificações de eventos, consulte EVENTDATA.

Notificações de eventos vs. gatilhos

A tabela a seguir compara e contrasta gatilhos e notificações de eventos.

Acionadores Notificações de eventos
Os gatilhos DML respondem a eventos de linguagem de manipulação de dados (DML). Os gatilhos DDL respondem a eventos de linguagem de definição de dados (DDL). As notificações de eventos respondem a eventos DDL e a um subconjunto de eventos de rastreamento SQL.
Os gatilhos podem executar código gerenciado Transact-SQL ou CLR (Common Language Runtime). As notificações de eventos não executam código. Em vez disso, eles enviam mensagens xml para um serviço do Service Broker.
Os gatilhos são processados de forma síncrona, dentro do escopo das transações que os fazem disparar. As notificações de eventos podem ser processadas de forma assíncrona e não são executadas no escopo das transações que as fazem disparar.
O consumidor de um gatilho está intimamente ligado ao evento que faz com que ele dispare. O consumidor de uma notificação de evento é dissociado do evento que faz com que ela seja acionada.
Os gatilhos devem ser processados no servidor local. As notificações de eventos podem ser processadas em um servidor remoto.
Os gatilhos podem ser revertidos. As notificações de eventos não podem ser revertidas.
Os nomes dos gatilhos DML têm escopo de esquema. Os nomes de gatilho DDL têm escopo de banco de dados ou de servidor. Os nomes de notificação de eventos têm o escopo definido pelo servidor ou banco de dados. As notificações de eventos em um evento QUEUE_ACTIVATION têm como escopo uma fila específica.
Os gatilhos DML pertencem ao mesmo proprietário das tabelas nas quais são aplicados. O proprietário de uma notificação de evento em uma fila pode ter um proprietário diferente do objeto no qual ela é aplicada.
Os gatilhos suportam a EXECUTE AS cláusula. As notificações de eventos não suportam a EXECUTE AS cláusula.
As informações de eventos de gatilho DDL podem ser capturadas usando a função EVENTDATA, que retorna um tipo de dados xml . As notificações de eventos enviam informações de eventos xml para um serviço do Service Broker. As informações são formatadas para o mesmo esquema da função EVENTDATA.
Os metadados sobre gatilhos são encontrados nas visualizações e sys.triggerssys.server_triggers no catálogo. Os metadados sobre notificações de eventos podem ser encontrados nas visualizações e sys.event_notificationssys.server_event_notifications no catálogo.

Notificações de eventos vs. SQL Rastreamento

A tabela a seguir compara e contrasta usando notificações de eventos e Rastreamento SQL para monitorar eventos do servidor.

Registo SQL Notificações de eventos
O Rastreamento SQL não gera nenhuma sobrecarga de desempenho associada às transações. O empacotamento de dados é eficiente. Há uma sobrecarga de desempenho associada à criação dos dados de evento formatados em XML e ao envio da notificação de evento.
O Rastreamento SQL pode monitorar qualquer classe de evento de rastreamento. As notificações de eventos podem monitorar um subconjunto de classes de eventos de rastreamento e também todos os eventos DDL (linguagem de definição de dados).
Você pode personalizar quais colunas de dados gerar em um evento de rastreamento. O esquema dos dados de eventos formatados em XML retornados por notificações de eventos é corrigido.
Os eventos de rastreamento gerados pela DDL são sempre gerados, independentemente de a instrução DDL ser revertida. As notificações de eventos não são acionadas se o evento na instrução DDL correspondente for revertido.
O gerenciamento do fluxo intermediário de dados de eventos de rastreamento envolve o preenchimento e o gerenciamento de arquivos de rastreamento ou tabelas de rastreamento. O gerenciamento intermediário de dados de notificação de eventos é realizado automaticamente por meio de filas do Service Broker.
Os rastreamentos devem ser reiniciados sempre que o servidor for reiniciado. Depois de registradas, as notificações de eventos persistem nos ciclos do servidor e são transacionadas.
Depois de iniciado, o disparo de vestígios não pode ser controlado. Os tempos de paragem e os tempos de filtro podem ser utilizados para especificar quando são iniciados. Os rastreamentos são acessados sondando o arquivo de rastreamento correspondente. As notificações de eventos podem ser controladas usando a WAITFOR instrução na fila que recebe a mensagem gerada pela notificação de evento. Eles podem ser acessados pesquisando a fila.
ALTER TRACE é a permissão mínima necessária para criar um rastreamento. A permissão também é necessária para criar um arquivo de rastreamento no computador correspondente. A permissão mínima depende do tipo de notificação de evento que está sendo criada. RECEIVE A permissão também é necessária na fila correspondente.
Os vestígios podem ser recebidos remotamente. As notificações de eventos podem ser recebidas remotamente.
Os eventos de rastreamento são implementados usando procedimentos armazenados do sistema. As notificações de eventos são implementadas usando uma combinação de instruções Transact-SQL do Mecanismo de Banco de Dados e do Service Broker.
Os dados de eventos de rastreamento podem ser acessados programaticamente consultando a tabela de rastreamento correspondente, analisando o arquivo de rastreamento ou usando a classe TraceReader do SQL Server Management Objects (SMO). Os dados de evento são acessados programaticamente emitindo XQuery em relação aos dados de evento formatados em XML ou usando as classes de evento SMO.

Tarefas de notificação de eventos

Tarefa Artigo
Descreve como criar e implementar notificações de eventos. Implementar notificações de eventos
Descreve como configurar a segurança da caixa de diálogo do Service Broker para notificações de eventos que enviam mensagens para um agente de serviços em um servidor remoto. Configurar a segurança da caixa de diálogo para notificações de eventos
Descreve como retornar informações sobre notificações de eventos. Obter informações sobre notificações de eventos

Conteúdo relacionado

  • Last updated on