Trabalhando com o Provedor WMI para Eventos de Servidor
Este tópico fornece diretrizes que você deve considerar antes de programar o uso do Provedor WMI para Eventos de Servidor.
Habilitando 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, veja Provedor WMI para conceitos de eventos de servidor.
Em particular, como as notificações de evento criadas pelo Provedor WMI usam SQL Server para enviar mensagens sobre eventos de servidor, esse serviço deve ser habilitado onde quer que os eventos sejam gerados. Se o programa consultar eventos em uma instância de servidor, o Service Broker no msdb dessa instância deverá ser habilitado, pois esse é o local do serviço 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 o 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 aplicativo de gerenciamento WMI até que o Service Broker esteja 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;
A GUID do service broker do msdb é de interesse especial porque é 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 .
Especificando uma cadeia de caracteres de conexão
Os aplicativos direcionam o Provedor WMI para Eventos de Servidor para uma instância de 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, que usa como padrão: \\.\root\Microsoft\SqlServer\ServerEvents\instance_name. instance_name o padrão é 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 é originado deve corresponder ao logon ou grupo autenticado do Windows na instância de SQL Server especificada na cadeia de conexão do aplicativo do aplicativo.
Permissões e escopo da 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 precisa ter não só as permissões mínimas necessárias para acessar o provedor, como também 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 = "AdventureWorks2012"
AND SchemaName = "Person"
AND ObjectName = "Person"
AND ObjectType = "TABLE";
O provedor WMI converte essa consulta em uma notificação de evento criada no banco de dados AdventureWorks2012 . Isso significa que o chamador deve 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 AdventureWorks2012 .
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. Observe que notificações de evento com escopo no servidor são armazenadas no banco de dados mestre. 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 de SQL Server para o processo do Serviço WMI. Entretanto, o provedor filtra quaisquer eventos que não se aplicam ao banco de dados do AdventureWorks . 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 mensagem
O Provedor WMI não enviará mensagens para notificações de evento 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_LOGIN
ALTER_LOGIN
DROP_USER
ALTER_USER
ADD_ROLE_MEMBER
DROP_ROLE_MEMBER
ADD_SERVER_ROLE_MEMBER
DROP_SERVER_ROLE_MEMBER
DENY ou REVOKE (Aplica-se somente às permissões ALTER DATABASE, ALTER ANY DATABASE EVENT NOTIFICATION, CREATE DATABASE DDL EVENT NOTIFICATION, CONTROL SERVER, ALTER ANY EVENT NOTIFICATION, CREATE DDL EVENT NOTIFICATION ou CREATE TRACE EVENT NOTIFICATION.)
Trabalhando com dados de evento 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 de destino no msdb chamado SQL/Notifications/ProcessWMIEventProviderNotification/v1.0. O serviço de destino coloca o evento em uma fila no 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. São listados os tipos CIM para cada propriedade listada sob cada classe de evento em Classes e propriedades do Provedor WMI para Eventos de Servidor.