Tabelas de destino, tabelas de controle e gerenciamento de tabela do monitor de eventos

É possível definir um monitor de eventos para que ele armazene seus registros de eventos em tabelas SQL. Para fazer isso, use a instrução CREATE EVENT MONITOR com a cláusula WRITE TO TABLE.

Quando se cria um monitor de eventos write-to-table, o monitor de eventos cria tabelas de destino para armazenar registros para cada um dos grupos de dados lógicos que retornam dados. Em cada tabela, os nomes das colunas correspondem aos nomes dos elementos do monitor que elas representam. Por padrão, o monitor de eventos cria as tabelas no esquema do criador do monitor de eventos e nomeia as tabelas concatenando o nome do grupo de dados lógico correspondente ao nome do monitor de eventos.

Por exemplo, considere a seguinte instrução, que cria um monitor de eventos que captura eventos STATEMENTS:

CREATE EVENT MONITOR test FOR STATEMENTS WRITE TO TABLE

Os monitores de eventos que usam o tipo de evento STATEMENTS coletam dados dos grupos de dados lógicos event_connheader, event_stmt e event_subsection. São criadas tabelas que representam grupos de dados lógicos específicos para tipos de eventos individuais, juntamente com uma tabela de controle para cada monitor de eventos write-to-table. Para o monitor de eventos test, criado pelo usuário riihi, o gerenciador de banco de dados cria as seguintes tabelas:

riihi.connheader_test
riihi.stmt_test
riihi.subsection_test
riihi.control_test

As três primeiras tabelas correspondem a cada um dos grupos de dados lógicos event_connheader, event_stmt e event_subsection. A última tabela, riihi.control_test, é a tabela de controle. A tabela de controle contém metadados do monitor de eventos, especificamente dos grupos de dados lógicos event_start, event_dbheader (somente o elemento do monitor conn_time) e event_overflow.

Os elementos do monitor são gravados no grupo de estouro somente para monitores de eventos não bloqueados. Com monitores de eventos não bloqueados, os agentes que geram eventos não esperam que os buffers de eventos sejam gravados na tabela se os buffers estiverem cheios. Em vez disso, eles descartam os dados do monitor provenientes dos agentes quando os dados estão chegando mais rápido do que o monitor de eventos pode gravar os dados. Nesse caso, o monitor de eventos registra informações na tabela de controle para indicar que ocorreu um estouro. Incluído nessas informações está o elemento monitor messageque, no caso de um estouro, contém o texto OVERFLOW:n, em que n representa o número de registros de eventos que foram descartados porque os buffers de eventos estavam cheios.

Sempre que um monitor de eventos write-to-table é ativado, ele adquire um bloqueio de tabela IN ou IX em cada tabela de destino para impedir que a tabela seja modificada enquanto o monitor de eventos estiver ativo. Os bloqueios de tabela são mantidos em todas as tabelas enquanto o monitor de eventos estiver ativo. Se for necessário acesso exclusivo a qualquer uma das tabelas de destino (por exemplo, para executar um utilitário), desative o monitor de eventos para liberar os bloqueios de tabela antes de tentar esse acesso.

Cada nome de coluna em uma tabela de destino corresponde a um identificador de elemento do monitor de eventos. Qualquer elemento do monitor de eventos que não tenha uma coluna de tabela de destino correspondente é ignorado.

Você deve podar manualmente as tabelas de destino do monitor de eventos de gravação para tabela, inclusive as tabelas de eventos não formatados (UE). Em sistemas altamente ativos, os monitores de eventos podem preencher rapidamente o espaço em disco devido ao alto volume de dados que registram. Ao contrário da definição de monitores de eventos que gravam em arquivos ou pipes nomeados, é possível definir monitores de eventos de gravação em tabela para registrar informações apenas de determinados grupos de dados lógicos ou elementos do monitor. Você pode usar esse recurso para coletar apenas os dados relevantes para seus objetivos e reduzir o volume de dados gerados pelos monitores de eventos. Por exemplo, a instrução a seguir define um monitor de eventos que captura eventos de conexão somente do grupo de dados lógicos event_conn e inclui somente o elemento de monitor lock_waits :

CREATE EVENT MONITOR conn_monitor FOR CONNECTIONS WRITE TO TABLE
                     CONN(INCLUDES(lock_waits))

Talvez você não queira ter as tabelas de destino de um monitor de eventos no esquema padrão, com nomes de tabela padrão, no espaço de tabela padrão. Se você prevê grandes volumes de dados de monitoramento, talvez queira que as tabelas de destino existam em seu próprio espaço de tabela. Você pode especificar os nomes do esquema, da tabela e do espaço de tabela para a instrução CREATE EVENT MONITOR. O nome do esquema e o nome da tabela formam um nome derivado para a tabela. Você pode adicionar o nome do espaço da tabela após o nome da tabela usando a cláusula IN opcional. Ao contrário das tabelas de destino, que o gerenciador de banco de dados cria automaticamente, um espaço de tabela deve existir se você o incluir em uma definição de monitor de eventos. Se você não especificar um espaço de tabela, será atribuído um espaço de tabela para o qual você tem privilégios USE.

Uma tabela de destino pode ser usada apenas por um único monitor de eventos. Se você definir uma tabela de destino para outro monitor de eventos ou se ela não puder ser criada por qualquer outro motivo, o comando CREATE EVENT MONITOR falhará.

Em um ambiente de banco de dados particionado, um monitor de eventos write-to-table está ativo somente nas partições do banco de dados em que existe o espaço de tabela que contém a tabela do monitor de eventos. Se o espaço da tabela de destino para um monitor de eventos ativo não existir em uma partição de banco de dados específica, o monitor de eventos será desativado nessa partição de banco de dados e um erro será gravado no arquivo de registro de comandos db2diag.

Para aumentar o desempenho na recuperação de dados do monitor de eventos, você pode criar índices para as tabelas de eventos. Se você adicionar atributos de tabela, como acionadores, integridade relacional e restrições, o monitor de eventos os ignorará.

Por exemplo, a instrução a seguir define um monitor de eventos que captura eventos STATEMENTS, usando os grupos de dados lógicos event_connheader, event_stmt e event_subsection. Cada uma das três tabelas de destino tem combinações diferentes de esquema, tabela e espaço de tabela:

CREATE EVENT MONITOR test FOR STATEMENTS
WRITE TO TABLE CONNHEADER,
STMT (TABLE mydept.statements),
SUBSECTION (TABLE subsections, IN mytablespace)

Supondo que o usuário riihi tenha emitido a instrução anterior, os nomes derivados e os espaços de tabela das tabelas de destino são os seguintes:

CONNHEADER: riihi.connheader_test no espaço de tabela padrão
STMT: mydept.statements no espaço de tabela padrão
SUBSECTION: riihi.subsections no espaço de tabela mytablespace

Se uma tabela de destino não existir quando o monitor de eventos for ativado, a ativação continuará e os dados que, de outra forma, seriam inseridos na tabela de destino serão ignorados. Da mesma forma, se um elemento do monitor não tiver uma coluna dedicada na tabela de destino, ele será ignorado.

Para monitores de eventos de gravação em tabela ativos, existe o risco de que os espaços de tabela que armazenam registros de eventos possam atingir sua capacidade. Para controlar esse risco nos espaços de mesa do DMS, é possível definir a porcentagem da capacidade do espaço de mesa na qual o monitor de eventos é desativado. Você pode especificar esse valor na cláusula PCTDEACTIVATE do comando CREATE EVENT MONITOR. Para espaços de tabela de SMS, o valor é definido como 100. Se você tiver ativado o recurso de redimensionamento automático para o espaço da tabela de destino, deverá definir o valor PCTDEACTIVATE como 100.

Em um ambiente de banco de dados não particionado, todos os monitores de eventos de gravação em tabela são desativados quando o último aplicativo é encerrado (e o banco de dados não foi ativado explicitamente). Em um ambiente de banco de dados particionado, os monitores de eventos de gravação em tabela são desativados quando a partição do catálogo é desativada.