Sessões de eventos estendidos

  • Artigo

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

Uma sessão de Eventos Estendidos é criada no processo do Mecanismo de Banco de Dados do SQL Server que hospeda o mecanismo de Eventos Estendidos. Os seguintes aspectos de uma sessão de eventos estendidos fornecem um contexto para entender a infraestrutura de eventos estendidos e o processamento que ocorre:

  • Estados de sessão. Os diferentes estados em que uma sessão de Eventos Estendidos se encontra quando os comandos CREATE EVENT SESSION e ALTER EVENT SESSION são executados.

  • Conteúdo de sessão e características. O conteúdo de uma sessão do Extended Events, como destinos e eventos, e o modo como esses objetos estão relacionados em uma sessão ou entre sessões.

Estados de sessão

A ilustração a seguir mostra os vários estados de uma sessão de eventos estendidos.

Diagram showing Extended Events session state.

Com relação à figura anterior, observe que o estado da sessão muda à medida que os diferentes comandos da linguagem de definição de dados (DDL) são emitidos para uma sessão de evento. Essas alterações de estado são descritas na tabela a seguir.

Rótulo de ilustração instrução DDL Descrição
Criar CREATE EVENT SESSION O processo do host cria um objeto de sessão que contém os metadados fornecidos por CREATE EVENT SESSION. O processo do host valida a definição de sessão, valida o nível de permissão do usuário, e armazena os metadados no banco de dados master. Neste momento a sessão não está ativa.
Alter ALTER EVENT SESSION, STATE=START O processo do host inicia a sessão. O processo do host lê os metadados armazenados, valida a definição da sessão, verifica o nível de permissão do usuário e cria a sessão. Objetos de sessão, como eventos e destinos, são carregados e a manipulação de eventos está ativa.
Alter ALTER EVENT SESSION, STATE=STOP O processo do host para a sessão ativa, mas retém os metadados.
Drop DROP EVENT SESSION Dependendo se a sessão está ativa ou não, Descartar (DROP SESSION) exclui os metadados e fecha a sessão ativa, ou exclui os metadados da sessão.

Conteúdo da sessão e características

Sessões de Eventos Estendidos têm limites implícitos sendo que a configuração de uma sessão não altera a configuração de outra sessão. Contudo, esses limites não impedem que um evento ou tipo de destino seja usado em mais de uma sessão.

A ilustração a seguir mostra o conteúdo da sessão e a relação entre pacotes e sessões.

Diagram showing object coexistence and sharing in sessions.

Em relação à ilustração anterior, lembre-se de que:

  • O mapeamento entre objetos de pacote e sessões é de muitos para muitos, o que significa que um objeto de um tipo em particular pode aparecer em várias sessões, e uma sessão pode conter vários objetos.
  • O mesmo evento (Evento 1) ou tipo de destino (Destino 1) pode ser usado em mais de uma sessão.

As sessões têm as seguintes características:

  • Ações e predicados estão associados a eventos em uma base por sessão. Se você tem o Evento 1 na Sessão A com a Ação 1 e o Predicado Z, isso de forma alguma impede que você tenha o Evento 1 na Sessão B com a Ação 2 e a Ação 3 sem nenhum predicado.
  • As políticas são anexadas a sessões para controlar a utilização de buffer e expedição, e rastreamento de causalidade.

Utilização de buffer refere-se a como os dados de evento serão armazenados enquanto uma sessão de evento estiver em execução. As políticas de utilização de buffer especificam o volume de memória a ser usado para dados de evento e a política de perda para os eventos. Expedição refere-se ao tempo que os eventos permanecerão nos buffers antes de serem entregues aos destinos para processamento.

Rastreamento de causalidade rastreaia o trabalho entre várias tarefas. Quando o rastreamento de causalidade é habilitado, cada evento disparado tem uma ID exclusiva de atividade no sistema. A ID de atividade é uma combinação de um valor GUID que permanece constante em todos os eventos de uma tarefa e um número de sequência que é incrementado toda vez que um evento é disparado. Quando uma tarefa gera trabalho em outra, a ID de atividade da tarefa pai é enviada à tarefa filho. A tarefa filho produz a ID de atividade do pai na primeira vez dispara um evento.

Conteúdo relacionado