Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As notificações de evento enviam informações sobre eventos para um serviço do Service Broker. As notificações de evento são executadas em resposta a uma variedade de instruções DDL (linguagem de definição de dados) Transact-SQL e eventos de rastreamento de SQL enviando informações sobre esses eventos para um serviço do Service Broker.
As notificações de evento podem ser usadas para fazer o seguinte:
Registrar e examinar alterações ou atividades que ocorrem no banco de dados.
Execute uma ação em resposta a um evento de maneira assíncrona em vez de síncrona.
As notificações de evento podem oferecer uma alternativa de programação aos gatilhos DDL e ao Rastreamento de SQL.
Benefícios das notificações de evento
As notificações de evento 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 evento podem ser usadas dentro de um aplicativo de banco de dados para responder a eventos sem usar os recursos definidos pela transação imediata.
Ao contrário do Rastreamento do SQL, as notificações de evento podem ser usadas para executar uma ação dentro de uma instância do SQL Server em resposta a um evento de Rastreamento do SQL.
Os dados do evento podem ser usados por aplicativos que estão em execução junto com o SQL Server para acompanhar o progresso e tomar decisões. Por exemplo, a notificação de evento a seguir envia uma notificação a um determinado serviço sempre que uma instrução ALTER TABLE é emitida no banco de dados de amostra AdventureWorks2012.
USE AdventureWorks2012;
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 evento
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 desde que a notificação de evento exista como um objeto na instância do servidor. Em alguns casos de erro, as conversas podem ser fechadas antes que a notificação do evento seja removida. Essas conversas nunca são compartilhadas entre notificações de evento. Cada notificação de evento tem suas próprias conversas exclusivas. O término de 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 de tipo xml que fornece informações sobre quando ocorre um evento, sobre o objeto de banco de dados afetado, a instrução Transact-SQL lote envolvida e outras informações. Para obter mais informações sobre o esquema XML produzido por notificações de evento, consulte EVENTDATA (Transact-SQL).
Notificações de evento versus gatilhos
A tabela a seguir compara e contrasta gatilhos e notificações de evento.
| Gatilhos | Notificações de eventos |
|---|---|
| Os gatilhos de DML respondem a eventos da linguagem de manipulação de dados (DML). Os gatilhos DDL respondem a eventos de DDL (linguagem de definição de dados). | As notificações de evento respondem a eventos DDL e a um subconjunto de eventos de rastreamento do SQL. |
| Os gatilhos podem executar Transact-SQL ou código gerenciado CLR (Common Language Runtime). | As notificações de evento não executam código. Em vez disso, eles enviam mensagens xml para um serviço Service Broker. |
| Os gatilhos são processados de forma síncrona, dentro do escopo das transações que fazem com que eles sejam acionados. | As notificações de evento podem ser processadas de forma assíncrona e não são executadas no escopo das transações que as acionam. |
| O consumidor de um gatilho está firmemente acoplado ao evento que o aciona. | O consumidor de uma notificação de evento é dissociado do evento que faz com que ele seja acionado. |
| Os gatilhos devem ser processados no servidor local. | As notificações de evento podem ser processadas em um servidor remoto. |
| Os gatilhos podem ser desfeitos. | As notificações de evento não podem ser revertidas. |
| Os nomes de gatilho DML têm escopo de esquema. Os nomes de gatilho DDL têm escopo de banco de dados ou com escopo de servidor. | Os nomes de notificação de eventos têm como escopo o servidor ou o banco de dados. As notificações de um evento QUEUE_ACTIVATION estão limitadas a uma fila específica. |
| Os gatilhos DML têm o mesmo proprietário que as tabelas nas quais são aplicados. | O proprietário de uma notificação de evento em uma fila pode ser diferente do proprietário do objeto ao qual está aplicado. |
| Os gatilhos dão suporte à cláusula EXECUTE AS. | As notificações de evento não dão suporte à cláusula EXECUTE AS. |
As informações de evento de gatilho DDL podem ser capturadas usando a função EVENTDATA, que retorna um xml tipo de dados. |
As notificações de evento enviam xml informações do evento para um serviço do Service Broker. As informações são formatadas para o mesmo esquema da função EVENTDATA. |
| Metadados sobre gatilhos são encontrados nas vistas de catálogo sys.triggers e sys.server_triggers. | Metadados sobre notificações de eventos são encontrados nas visões de catálogo sys.event_notifications e sys.server_event_notifications. |
Notificações de Evento vs. Rastreamento SQL
A tabela a seguir compara e contrasta o uso de notificações de eventos e rastreamento de SQL para monitoramento de eventos do servidor.
| Rastreamento do SQL | Notificações de eventos |
|---|---|
| O Rastreamento de SQL não gera sobrecarga de desempenho associada a transações. O empacotamento de dados é eficiente. | Há uma sobrecarga de desempenho associada à criação dos dados de evento formatados por XML e ao envio da notificação de evento. |
| O SQL Trace pode monitorar qualquer classe de evento de rastreamento. | As notificações de evento podem monitorar um subconjunto de classes de evento de rastreamento e também todos os eventos de 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 evento formatados por XML retornados por notificações de evento é corrigido. |
| Eventos de rastreamento gerados por DDL são sempre gerados, independentemente de a instrução DDL ser revertida. | As notificações de evento não serão disparadas se o evento na instrução DDL correspondente for revertido. |
| O gerenciamento do fluxo intermediário de dados de evento de rastreamento envolve o preenchimento e o gerenciamento de arquivos de rastreamento ou tabelas de rastreamento. | O gerenciamento intermediário dos 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. | Após serem registradas, as notificações de evento persistem entre os ciclos do servidor e são transacionadas. |
| Depois de iniciado, o disparo de traços não pode ser controlado. Tempos de parada e tempos de filtro podem ser usados para especificar quando eles iniciam. Os rastreamentos são acessados consultando o arquivo de rastreamento correspondente. | Notificações de eventos podem ser controladas usando a instrução WAITFOR na fila que recebe a mensagem gerada pela notificação de evento. Eles podem ser acessados sondando 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. A permissão RECEIVE também é necessária na fila correspondente. |
| Rastros podem ser recebidos à distância. | As notificações de evento podem ser recebidas remotamente. |
| Os eventos de rastreamento são implementados usando procedimentos armazenados do sistema. | As notificações de evento são implementadas usando uma combinação de instruções do mecanismo de banco de dados e instruções de serviço BrokerTransact-SQL. |
| Os dados de evento 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 do evento são acessados programaticamente emitindo XQuery em relação aos dados de evento formatados por XML ou usando as classes de evento SMO. |
Tarefas de notificação de eventos
| Tarefa | Tópico |
|---|---|
| Descreve como criar e implementar notificações de evento. | Implementar notificações de evento |
| 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ço 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 evento. | Obter informações sobre notificações de evento |