Usando o WQL com o Provedor WMI para eventos de servidor

Sintaxe

SELECT { event_property [ ,...n ] | * }
FROM event_type 
WHERE where_condition 

Argumentos

• event_property
  É uma propriedade de um evento. Exemplos incluem PostTime, SPID e LoginName. Procure cada evento listado em Classes e propriedades do Provedor WMI para eventos de servidor a fim de determinar as propriedades que ele contém. Por exemplo, o evento DDL_DATABASE_LEVEL_EVENTS contém as propriedades DatabaseName e UserName. Ele também herda as propriedades SQLInstance, LoginName, PostTime, SPID e ComputerName de seus eventos pai.

• ,...n
  Indica que event_property pode ser consultado várias vezes, separadas por vírgulas.

• *
  Especifica que todas as propriedades associadas com um evento são consultadas.

• event_type
  É qualquer evento no qual uma notificação de eventos pode ser criada. Para obter uma lista de eventos disponíveis, consulte Provedor WMI para classes e propriedades de eventos de servidor. Observe que os nomes de event type correspondem ao mesmo event_type | event_group que pode ser especificado quando você cria uma notificação de eventos manualmente usando CREATE EVENT NOTIFICATION. Exemplos de event type incluem CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS e TRC_DATABASE.

  Observação

  Determinados procedimentos armazenados do sistema que executam operações semelhantes a DDLs também podem acionar notificações de eventos. Teste as notificações de eventos para determinar suas respostas aos procedimentos armazenados que são executados. Por exemplo, a instrução CREATE TYPE e o procedimento armazenado sp_addtype irão, ambos, acionar uma notificação de eventos que tenha sido criada em um evento CREATE_TYPE. No entanto, o procedimento armazenado sp_rename não aciona nenhuma notificação de eventos. Para obter mais informações, consulte Eventos DDL.

• where_condition
  É um predicado de consulta da cláusula WHERE formado por operadores de comparação e lógicos e nomes de event_property. O where_condition determina o escopo no qual a notificação de eventos correspondente é registrada no banco de dados de destino. Ele também pode atuar como um filtro para atingir um determinado esquema ou objeto no qual event_type. deve ser consultado. Para obter mais informações, consulte a seção Comentários posteriormente neste tópico.

  Somente o operando = pode ser usado juntamente com DatabaseName, SchemaName e ObjectName. Não é possível usar outras expressões com essas propriedades de eventos.

Comentários

O where_condition da sintaxe do Provedor de WMI para eventos de servidor determina o seguinte:

• O escopo no qual o provedor tenta recuperar o event_type especificado: no nível de servidor, no nível de banco de dados ou no nível de objeto (o único objeto para o qual há suporte no momento é o de fila). Por fim, esse escopo determina o tipo de notificação de eventos criado no banco de dados de destino. Esse processo chamou o registro de notificação de eventos.

• O banco de dados, o esquema e o objeto, quando apropriado, no qual registrar.

O Provedor WMI para eventos de servidor usa um algoritmo ascendente, o primeiro que for válido (first fit), a fim de gerar o escopo mais restrito possível para a EVENT NOTIFICATION subjacente. O algoritmo tenta minimizar a atividade interna no servidor e o tráfego de rede entre a instância do SQL Server e o processo do host WMI. O provedor examina o event_type especificado na cláusula FROM e as condições na cláusula WHERE, e tenta registrar a EVENT NOTIFICATION subjacente com o escopo mais restrito possível. Se o provedor não puder registrar com o escopo mais restrito, ele tentará registrar com escopos sucessivamente superiores, até que um registro finalmente tenha êxito. Se o escopo mais alto (o nível de servidor) for atingido e falhar, um erro será retornado ao consumidor.

Por exemplo, se DatabaseName=**'AdventureWorks2008R2'**for especificado na cláusula WHERE, o provedor tentará registrar uma notificação de eventos no banco de dados AdventureWorks2008R2. Se o banco de dados AdventureWorks2008R2 existir e o cliente que fez a chamada tiver as permissões necessárias para criar uma notificação de eventos em AdventureWorks2008R2, o registro terá êxito. Caso contrário, será feita uma tentativa de registrar a notificação de eventos no nível de servidor. O registro terá êxito se o cliente WMI tiver as permissões necessárias. Porém, neste cenário, os eventos não são retornados ao cliente até que o banco de dados AdventureWorks2008R2 tenha sido criado.

O where_condition também pode atuar como um filtro para limitar adicionalmente a consulta a um banco de dados, esquema ou objeto específico. Por exemplo, considere a seguinte consulta WQL:

SELECT * FROM ALTER_TABLE 
WHERE DatabaseName = 'AdventureWorks2008R2' AND SchemaName = 'Sales' 
    AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'

Dependendo do resultado do processo de registro, essa consulta WQL pode ser registrada no nível de banco de dados ou de servidor. Entretanto, mesmo se registrada no nível de servidor, no final o provedor filtra quaisquer eventos ALTER_TABLE que não se aplicam à tabela AdventureWorks2008R2.Sales.SalesOrderDetail. Em outras palavras, o provedor retorna apenas as propriedades dos eventos ALTER_TABLE que ocorrem naquela tabela específica.

Se uma expressão composta, como DatabaseName='AW1' OR DatabaseName='AW2', for especificada, será feita uma tentativa de registrar uma única notificação de eventos no escopo do servidor, em vez de duas notificações de eventos separadas. O registro terá êxito se o cliente que fez a chamada tiver as permissões.

Se SchemaName='X' AND ObjectType='Y' AND ObjectName='Z' forem todos especificados na cláusula WHERE, será feita uma tentativa de registrar a notificação de eventos diretamente no objeto Z do esquema X. O registro terá êxito se o cliente tiver as permissões. Observe que, no momento, há suporte para eventos em nível de objeto somente em filas, e apenas para event_type QUEUE_ACTIVATION.

Observe que nem todos os eventos podem ser consultados em qualquer escopo específico. Por exemplo, uma consulta WQL em um evento de rastreamento, como Lock_Deadlock, ou um grupo de eventos de rastreamento, como TRC_LOCKS, podem ser registrado apenas no nível de servidor. De forma semelhante, o evento CREATE_ENDPOINT e o grupo de eventos DDL_ENDPOINT_EVENTS também podem ser registrados apenas no nível de servidor. Para obter mais informações sobre o escopo apropriado para o registro de eventos, consulte Criando notificações de eventos. Uma tentativa para registrar uma consulta WQL cujo event_type pode ser registrado apenas no nível de servidor sempre é feita no nível de servidor. O registro terá êxito se o cliente WMI tiver as permissões. Caso contrário, será retornado um erro ao cliente. Entretanto, em alguns casos, você ainda pode usar a cláusula WHERE como um filtro para eventos em nível de servidor com base nas propriedades que correspondem ao evento. Por exemplo, vários eventos de rastreamento têm uma propriedade DatabaseName que pode ser usada na cláusula WHERE como um filtro.

As notificações de eventos no escopo de servidor são criadas no banco de dados mestre e podem ser consultadas quanto a metadados usando a exibição do catálogo sys.server_event_notifications.

As notificações de eventos no escopo de banco de dados ou de objetos são criadas no banco de dados especificado e podem ser consultadas quanto a metadados usando a exibição do catálogo sys.event_notifications. (A exibição do catálogo deve ser prefixada com o nome do banco de dados correspondente.)

Exemplos

A. Consultando eventos no escopo de servidor

SELECT * FROM SERVER_MEMORY_CHANGE

B. Consultando eventos no escopo de banco de dados

SELECT SPID, SQLInstance, DatabaseName FROM DDL_DATABASE_LEVEL_EVENTS 
WHERE DatabaseName = 'AdventureWorks2008R2' 

C. Consultando eventos no escopo de banco de dados, filtrando por esquema e objeto

SELECT * FROM ALTER_TABLE 
WHERE DatabaseName = 'AdventureWorks2008R2' AND SchemaName = 'Sales' 
    AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'

Consulte também

Conceitos

Outros recursos