L ES MODÈLES DE TOURS DE PAROLE

Conforme citamos anteriormente, iremos apresentar um exemplo do funcionamento do sistema. A Tabela 5.1 a seguir descreve sucintamente alguns tipos de sensores do ambiente (Agentes Sensores). Na Tabela 5.2, mostramos alguns exemplos de Agentes Atuadores com o tipo de script que eles iriam utilizar quando fossem acionados. Na Tabela 5.3, apresentamos alguns exemplos de informações sobre alguns casos que foram catalogados no DBSitter. Nesta Tabela 5.3, incluímos a expressão que caracteriza cada caso e o nome do Agente Atuador que será chamado pelo sistema quando o caso for detectado.

O script associado a cada Agente Atuador contém a sequência de comandos ou instruções específicas para a resolução do problema, levando em consideração todo o seu contexto (sistema operacional, fabricante do SGBD, versão do SGBD, versão do sistema Operacional, etc).

Para facilitar o entendimento, adotamos o seguinte padrão para os identificadores das tabelas que virão a seguir:

Sn - para indicar o nome de um Agente Sensor (S1, S2, ... Sn) An - para indicar o nome de um Agente Atuador (A1, A2, ... An) Cn - para indicar o nome de um caso (C1, C2, ... Cn)

Tabela 5.1 - - Exemplo de Agentes Sensores do DBSitter

Identificador Nome do Sensor

S1 Sensor de rede

S2 Sensor de utilização de memória

S3 Sensor de uso da CPU

S4 Sensor de quantidade de usuários conectados ao SGBD

S5 Sensor de fragmentação das tabelas Oracle

S6 Sensor de quantidade de cursores abertos S7 Sensor do processo do SGBD Oracle S8 Sensor de espaço disponível em disco

S9 Sensor de multi-thread

S10 Sensor de deadlock

S11 Sensor de hit ratio4 na memória Oracle S12 Sensor de processo vital do SQL Server S13 Sensor de erros padrão Oracle

S14 Sensor de erro específico do SO S15 Sensor de fragmentação das tabelas

SqlServer

Tabela 5.2 - Exemplo de Agentes Atuadores do DBSitter

Identificador Nome do atuador Tipo de Script de Atuação

A1 Põe SGBD x no ar Script shell

A2 Ajusta fragmentação de tabelas Shell com comandos SQL

A3 Interrompe processo do SGBD Shell

A4 Ativa processo X Comando do SO

A5 Envia mensagem com erro padrão do

SGBD e respectiva solução Comando do SO

A6 Aumenta área de memória Comando do SO

A7 Envia mensagem genérica de erro Comando do SO

Tabela 5.3 - Exemplos de Casos do DBSitter

ID Nome Expressão Atuadores

C1 Rede lenta S1 > 75 A7

C2 Fragmentação alta S5 > 10 A2

C3 Memória alta em multi-thread S2 > 60 e S8 = 1 A3 C4 Memória alta em single-thread S2 > 80 e S8 <> 1 A3

C5 SQL Server fora do ar S7 = 0 A1

C6 Processamento alto S3 > 95 A5

C7 Pouco espaço disponível S8 > 98 A5

4 _{Hit Ratio corresponde ao percentual de vezes que o SGBD Oracle buscou um dado em memória e} encontrou.

C8 Desempenho baixo S6 > 40 A5

C9 Quantidade alta de usuários S4 > 95 A5

C10 Baixo hit ratio na memória (S11 < 80) e (S4 > 50) A6

C11 Processo vital saiu do ar S12 = 0 A4

C12 Tabela corrompida S13 = ORA-01586 A5

C13 Estouro de Tablespace S13 = ORA-09888 A5

C14 Transação muito longa S13 = ORA-01555 A5

C15 Banco travado S7 = 2 A1

C16 Falha – Erro da Aplicação S14 = 1002 A5

C17 Falha – Application Hang up S14 = 1003 A5

C18 Dll corrompida S14 = 3069 A5

C20 Tabela SQL Server fragmentada S15 > 80 A2

Um exemplo das informações de log encontradas no Repositório de Histórico do DBSitter é representado na Tabela 5.4 O log consiste em uma tabela simples contendo

timestamps e os valores de cada sensor.

Tabela 5.4- Exemplo de uma estrutura de log do DBSitter

Sensores Timestamp S1 S2 S3 ... Sn T1 8 100 4 True T2 8 101 50 True ... 9 102 1 True tn 10 103 70 True

Neste exemplo de log, observamos que os sensores S1, S2 e Sn mantiveram um padrão uniforme de comportamento no tempo, enquanto que o sensor S3 esteve instável durante o período monitorado.

De acordo com a representação dos agentes descrita nesta seção, é necessário esclarecer algumas decisões de projeto a fim de viabilizar o uso da solução em qualquer ambiente de SGBD.

Um primeiro ponto que deve ser observado é que a customização dos Agentes Sensores e Atuadores é específica para cada contexto, ou seja, se estivermos utilizando o DBSitter para detectar fragmentação de tabelas nos SGBD Oracle e SQL Server teremos que criar dois Agentes Sensores distintos para cada plataforma. Isto é necessário porque a forma de monitoração da fragmentação de tabelas é diferente para cada SGBD bem como a forma de resolver este problema. Assim a ação de cada agente atuador também é diferente (com comandos diferentes) em cada SGBD.

Outra questão importante é a forma como é feita a definição das regras de cada caso. Como foi dito anteriormente, é no atributo expressão da representação dos casos onde é definida a expressão que será usada para que o Agente Raciocínio identifique que um determinado caso ocorreu (funcionalidade de detecção de falhas) ou está para ocorrer (previsão de falhas) no ambiente. Esta expressão atualmente é definida de forma manual pelo ABD no sistema quando da criação ou inserção de novos casos no catálogo.

Conforme apontado por Richter (1991), o perigo da má representação de um caso (seja por uma caracterização incompleta, imprecisa ou redundante do mesmo) demonstra o grau de dificuldade e importância que é a tarefa de definir a expressão que caracteriza cada caso, pois é baseado nesta definição, que se determina o nível de sucesso do diagnóstico do sistema.

Existe ainda a seguinte questão (típica de um sistema com RBC): como garantir que dois problemas são similares a ponto da solução de um poder ser utilizada pelo outro? Esta última questão agrava-se mais ainda quando o contexto onde os problemas estão inseridos muda continuamente, como é o caso do ambiente do DBSitter.

No contexto do DBSitter, uma solução proposta em um caso que está sendo oferecida para outro caso encontrado como similar só é aceita (e eventualmente cadastrada juntamente com o caso no sistema ou feita a generalização para catalogar em apenas um único caso) depois de ter sido validada pelo ABD (possivelmente através de uma análise ou depois de ter sido testada). Esta foi a forma mais garantida que encontramos de evitar que soluções erradas sejam atribuídas aos casos.