Trabalhar com o provedor WMI para eventos de servidor
Aplica-se a: 
SQL Server
Este artigo fornece diretrizes que você deve considerar antes de programar usando o Provedor WMI para Eventos de Servidor.
Habilitar o Service Broker
O Provedor WMI para Eventos de Servidor funciona traduzindo consultas WQL de eventos para notificações de eventos no banco de dados de destino. Um entendimento de como funcionam as notificações de eventos pode ser útil ao programar com base no provedor. Para obter mais informações, consulte Conceitos do Provedor WMI para Eventos de Servidor.
Em particular, como as notificações de eventos criadas pelo Provedor WMI usam o SQL Server para enviar mensagens sobre eventos do servidor, esse serviço deve ser habilitado onde quer que os eventos sejam gerados. Se o programa consultar eventos em uma instância do servidor, o Service Broker nessa msdb instância deverá ser habilitado, pois esse é o local do serviço do Service Broker de destino (chamado SQL/Notifications/ProcessWMIEventProviderNotification/v1.0) criado pelo provedor. Se o programa consultar eventos em um banco de dados ou em um objeto de banco de dados específico, o Service Broker nesse banco de dados de destino deverá ser habilitado. Se o Service Broker correspondente não estiver habilitado depois que seu aplicativo for implantado, todos os eventos gerados pela notificação de evento subjacente serão enviados para a fila do serviço usado pela notificação de evento, mas não serão retornados ao seu aplicativo de gerenciamento WMI até que o Service Broker seja habilitado.
A consulta a seguir determina quais Service Brokers são habilitados em uma instância de servidor, e o GUID de instância do Service Broker:
SELECT name, is_broker_enabled, service_broker_guid FROM sys.databases;
O GUID do agente de msdb serviços é de interesse particular porque esse é o local do serviço de destino do provedor.
Para habilitar o Service Broker em um banco de dados, use a opção ENABLE_BROKER SET da instrução ALTER DATABASE .
Especificar uma cadeia de conexão
Os aplicativos direcionam o Provedor WMI para Eventos de Servidor para uma instância do SQL Server conectando-se a um namespace WMI definido pelo provedor. O serviço Windows WMI mapeia esse namespace para o DLL do provedor, Sqlwep.dll, e carrega-o na memória. Cada instância do SQL Server tem seu próprio namespace WMI, cujo padrão é: \\.\root\Microsoft\SqlServer\ServerEvents\instance_name. instance_name padrão para MSSQLSERVER em uma instalação padrão do SQL Server.
Permissões e autenticação do servidor
Para acessar o Provedor WMI para Eventos de Servidor, o cliente no qual um aplicativo de gerenciamento WMI se origina deve corresponder ao logon ou grupo autenticado do Windows na instância do SQL Server especificada na cadeia de conexão do aplicativo do aplicativo.
Permissões e escopo de notificação de eventos
O Provedor WMI para Eventos de Servidor traduz as consultas WQL para notificações de eventos no banco de dados de destino. Por isso, o aplicativo de chamada deve ter não apenas as permissões mínimas necessárias para acessar o provedor, mas também deve ter as permissões corretas no banco de dados para criar as notificações de eventos necessárias. A seguir estão as permissões:
Para criar uma notificação de evento com escopo no banco de dados, no mínimo, é necessária a permissão CREATE DATABASE DDL EVENT NOTIFICATION no banco de dados atual.
Para criar uma notificação de evento em uma instrução DDL com escopo no servidor, no mínimo, é necessária a permissão CREATE DDL EVENT NOTIFICATION no servidor.
Para criar uma notificação de evento em um evento de rastreamento, no mínimo, é necessária a permissão CREATE TRACE EVENT NOTIFICATION no servidor.
Para criar uma notificação de evento com escopo em uma fila, no mínimo, é necessária a permissão ALTER na fila.
Para obter informações sobre o escopo das consultas WQL, consulte Usando o WQL com o Provedor WMI para eventos de servidor.
Para ilustrar escopo, considere um aplicativo de Provedor WMI que inclui a consulta WQL a seguir:
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = "AdventureWorks2022"
AND SchemaName = "Person"
AND ObjectName = "Person"
AND ObjectType = "TABLE";
O provedor WMI traduz essa consulta para uma notificação de evento que é criada no banco de dados do AdventureWorks2022 . Isso significa que o chamador precisa ter as permissões necessárias para criar essa notificação de evento, especificamente a permissão CREATE DATABASE DDL EVENT NOTIFICATION no banco de dados do AdventureWorks2022 .
Se uma consulta WQL especifica uma notificação de evento com escopo no nível de servidor, por exemplo, emitindo a consulta SELECT * FROM ALTER_TABLE, o aplicativo de chamada precisará ter a permissão CREATE DDL EVENT NOTIFICATION no nível de servidor. As notificações de eventos no escopo do servidor são armazenadas no master banco de dados. Você pode usar a exibição do catálogo sys.server_event_notifications para ver seus metadados.
Observação
O escopo da notificação de evento criada pelo Provedor WMI (servidor, banco de dados ou objeto) por fim depende do resultado do processo de verificação de permissões usado pelo provedor WMI. Isso é afetado pelo conjunto de permissões do usuário que está chamando o provedor e pela verificação do banco de dados que está sendo consultado.
No exemplo anterior, o provedor tenta primeiro criar uma notificação de evento com escopo no banco de dados (ON DATABASE). Se o provedor verifica que o banco de dados existe e que o chamador tem as permissões necessárias para criar uma notificação de evento nele, o registro é bem-sucedido. Se não for bem-sucedido, o provedor tentará criar uma notificação de evento no servidor (ON SERVER). Supondo que essa tentativa seja bem-sucedida, todos os ALTER_TABLE eventos que ocorrem no servidor são enviados do processo do SQL Server para o processo do Serviço WMI. No entanto, o provedor filtra todos os eventos que não se aplicam ao AdventureWorks2022 banco de dados. Apesar de, por um lado, esse processo possivelmente aumentar a quantidade de tráfego de rede necessária para o escopo do evento, por outro, ele também oferece a flexibilidade de registrar consultas WQL no banco de dados antes de serem criadas e de receber os dados de evento depois de o banco de dados ser criado e a atividade de DDL ser iniciada nele.
Permissões e verificação de mensagens
O Provedor WMI não enviará mensagens para notificações de eventos se ambas as condições a seguir forem verdadeiras:
O usuário que criou a notificação de evento através do Provedor WMI não existe mais no banco de dados ou não tem mais a permissão necessária para criar uma notificação de evento semelhante.
As notificações de evento são criadas nos eventos a seguir:
DROP_LOGINALTER_LOGINDROP_USERALTER_USERADD_ROLE_MEMBERDROP_ROLE_MEMBERADD_SERVER_ROLE_MEMBERDROP_SERVER_ROLE_MEMBERDENYouREVOKE(Aplica-se somente aALTER DATABASE,ALTER ANY DATABASE EVENT NOTIFICATION,CREATE DATABASE DDL EVENT NOTIFICATION,CONTROL SERVER,ALTER ANY EVENT NOTIFICATION, ,CREATE DDL EVENT NOTIFICATIONouCREATE TRACE EVENT NOTIFICATIONpermissões.)
Trabalhar com dados de eventos no lado do cliente
Depois que o Provedor WMI para Eventos de Servidor cria a notificação de evento necessária no banco de dados de destino, a notificação de evento envia dados de evento para o serviço msdb de destino chamado SQL/Notifications/ProcessWMIEventProviderNotification/v1.0. O serviço de destino coloca o evento em uma fila msdb chamada WMIEventProviderNotificationQueue. (O serviço e a fila são criados dinamicamente pelo provedor quando ele se conecta pela primeira vez ao SQL Server.) Em seguida, o provedor lê os dados de evento XML dessa fila e os transforma em MOF (formato de objeto gerenciado) antes de retorná-los ao aplicativo cliente. Os dados MOF consistem nas propriedades do evento que é solicitado pela consulta WQL como uma definição de classe de modelo CIM. Cada propriedade tem um tipo CIM correspondente. Por exemplo, a propriedade SPID é retornada como tipo CIM Sint32. Os tipos de CIM para cada propriedade são listados em cada classe de evento em classes e propriedades do Provedor WMI para Eventos de Servidor.