A disponibilidade do banco é um fator crítico para aplicações que manipulam bases de dados. Sistemas fora do ar por alguns minutos podem causar o descontentamento de milhares de usuários. Além da infra-estrutura de hardware e software projetada para garantir tal disponibilidade, é necessária a observação atenta e contínua do estado do SGBD. Neste artigo conheceremos algumas ferramentas de monitoração de banco de dados.

Métodos de monitoração de banco de dados

Atividades de monitoramento podem ser efetuadas de duas formas: contínua ou sob demanda. Quando contínuas (ou pró-ativas), as atividades buscam prever e evitar o surgimento de problemas. Já as atividades por demanda (ou reativas) agem após a identificação de um problema já ocorrido.

Um exemplo de utilização do monitoramento por demanda está relacionado a questões de desempenho. Imaginemos que um novo módulo de um aplicativo entrou em produção e em um dado momento o tempo de resposta do sistema aumentou de forma não esperada. Nesse caso, poderia ser detectado que uma determinada consulta foi construída de forma não otimizada.

O monitoramento pró-ativo consiste em fazer previsões baseadas em informações estatísticas extraídas do próprio SGBD e do sistema operacional. De posse desses dados, ele deve decidir se há necessidade de executar uma ação que previna a parada parcial ou total do sistema. Por exemplo, um monitor pró-ativo pode detectar que uma tabela irá alcançar sua alocação máxima e automaticamente estender essa alocação para que o sistema continue funcionado.

Embora o método reativo tenha seu espaço nas atividades de monitoração, o método pró-ativo é, sem dúvida, a forma mais eficaz de monitoramento no que tange a disponibilidade do SGBD. No entanto, é preciso ter cuidado com a utilização indiscriminada desses monitores, pois a verificação contínua do sistema pode causar impacto negativo no desempenho do SGBD. Nesse contexto, a monitoração pode ser classificada em intrusiva e não intrusiva, dependendo da interferência que ela causa no sistema.

Monitoração intrusiva

Em muitos casos, é necessário obter informações internas do SGBD, como a quantidade de blocos ocupados por uma tabela ou como esses blocos estão distribuídos. Essas informações são importantes e necessitam de um acompanhamento periódico. No entanto, sua obtenção consome recursos do SGDB sendo necessário o cuidado para não sobrecarregá-lo. Fica claro que uma definição sensata da periodicidade em que as checagens serão feitas é fundamental. Outros exemplos comuns de monitoração intrusiva são: fazer o acompanhamento das atividades de um usuário ou grupo de usuários em particular para fins de depuração ou auditoria; fazer o acompanhamento em intervalos de tempo da taxa de crescimento de uma tabela e a avaliação do estado de fragmentação dos grupos de arquivos do SGBD.

Monitoração não intrusiva

Como vimos, é muito importante que o monitoramento não afete negativamente o desempenho do SGBD. Para isto, as ferramentas de monitoração devem aproveitar ao máximo os recursos nativos de cada SGDB.

Diversos “fabricantes” de bancos de dados disponibilizam interfaces de programação para o desenvolvimento de mecanismos de monitoração para seu produto. Através dessas interfaces é possível obter informações diretamente da estrutura de memória do SGBD com impacto mínimo de performance. A ORACLE, por exemplo, oferece a visão V$SESSION para verificar as sessões de usuário conectados no SGBD. De forma similar, o MS SQL Server oferece a store procedure sp_who.

Considerando o que foi apresentado até o momento, já é possível fazer uma projeção de um sistema de monitoramento. Porém, surgem algumas questões:

  • Quais dados serão coletados?
  • Como fazer a coleta?
  • Como será criado um repositório centralizado para guardar informações?
  • Como o SGBD será acessado?
  • Como essas informações serão apresentadas?

Na maioria dos livros e manuais de SGBD, monitoração é um tema intimamente ligado a refinamento, ou seja, monitorar para otimizar performance. No entanto, sabe-se que o refinamento tende a ser muito mais eficiente na fase de projeto e desenvolvimento de um sistema do que durante a produção. Ou seja, quando um sistema entra em produção, é desejável que ele já esteja otimizado, restando para a monitoração o papel de identificar fatores que venham a comprometer sua disponibilidade.

Pensando assim, um bom monitor pró-ativo tem como componente fundamental o repositório de dados. O principal objetivo desse repositório é indicar tendências comportamentais do SGBD, como taxa de crescimento de usuários simultâneos, taxa de crescimento de dados, consumo de recursos do sistema e horários de pico. Dessa forma, uma análise temporal das informações do repositório poderá apoiar as tomadas de decisão do DBA.

Considerando que um DBA não está 24h no ambiente de trabalho, um bom monitor deverá tomar ações para impedir a parada do sistema sem a intervenção imediata do DBA. Por exemplo, ao coletar a informação de espaço disponível no disco, caso o valor atual não esteja dentro do limite considerado crítico, o monitor poderia efetuar determinadas ações como enviar uma mensagem de alerta para o DBA ou remover arquivos temporários para liberar mais espaço. A seguir são apresentadas algumas informações importantes a serem coletadas pelo monitor:

  • SGBD: Sessão de usuário, utilização de memória, utilização de espaço de armazenamento, performance geral do sistema, atividades de backup e recovery, contenção de bloqueios (locks) e transações por minuto.?
  • NO-BREAK: Os NO-BREAKs modernos possuem uma interface de comunicação com o computador, sendo possível monitorar as condições das baterias, temperatura interna, oscilação e falta de energia elétrica.
  • SISTEMA OPERACIONAL: CPU, memória, espaço em disco, processos de usuário e rede.

O monitoramento do sistema operacional é importante, pois em muitos casos um problema pode estar mais relacionado aos recursos gerenciados por ele do que pelo SGDB. Considere, por exemplo, um processo “pesado” sendo executado pelo usuário em horário de pico (um antivírus, por exemplo).

A ampla gama de sensores de monitoração disponíveis atualmente permite que fatores externos ao computador sejam também monitorados, como:

  • Temperatura do ambiente: Caso exista alguma falha no sistema de refrigeração, a temperatura poderá subir de forma que possa comprometer o funcionamento dos computadores.
  • Umidade do ambiente: Ambientes muito úmidos podem prejudicar o funcionamento do computador.
  • Temperatura interna da CPU: Por mau funcionamento ou condições extremas, a temperatura da CPU poderá subir para valores críticos.
  • Temperatura dos Arrays de Discos: O uso intenso de I/O poderá superaquecer os discos.
  • Falha em algum disco do Array: Os atuais sistemas de array de discos possibilitam realizar manutenções sem necessidade de parar o sistema. Assim, monitorar as condições dos discos é importante e desejável.
  • Fontes de alimentação: Computadores projetados para alta disponibilidade vêm com duas ou mais fontes de alimentação permitindo que uma entre em funcionamento caso a outra falhe.

Onde encontrar ferramentas de monitoração

Alguns SGBDs já trazem ferramentas de monitoração em seu pacote. Existem também fabricantes de softwares especializados nessa tarefa, como por exemplo a BMC Software , Quest Software e Veritas . Essas ferramentas estão disponíveis para os principais SGBD comerciais e podem ser consultadas nos sites apresentados. Algumas características dessas ferramentas são mostradas a seguir.

Ferramenta da Quest Software

A Quest Software possui um conjunto de ferramentas que possibilitam ao DBA monitorar e diagnosticar, em tempo real, várias condições de estado do SGBD. As principais características dessas ferramentas são:

  • Representação visual dos fluxos das atividades do SGBD;
  • Suporte a monitoração de múltiplos serviços de banco de dados ao mesmo tempo;
  • Suporte a monitoração de sistema operacional;
  • Suporte a identificação de gargalos;
  • Visualização imediata de áreas e situações problemáticas;
  • Alerta de contenção de recursos de SGBD;
  • Assistente que ajuda em reparos e refinamentos on-line;
  • Integração com outras ferramentas para suporte a monitoração pró-ativa em SGBD 24/7. Isso inclui envio de mensagens ao DBA via celular, page ou e-mail;
  • Apresentação detalhada de consultas em SQL ineficientes, utilização de memória, utilização de I/O, transações e bloqueios (locks).

A figura 1 apresenta a interface principal do monitor Spotlight da Quest Software. Nele é possível identificar o estado geral do SGBD e de seus componentes. Neste exemplo estão sendo monitorados três servidores de banco de dados ao mesmo tempo, um SGBD ORACLE, denominado NEWTON, e dois MS SQL Server, denominados PITOLOMEU e WEBER, todos em máquinas distintas. Observe ainda que o banco que está sendo visualizado no momento é o NEWTON. Note que a tela foi organizada obedecendo à estrutura modular do ORACLE, ou seja: sessões de usuário (Sessions); processos servidores com informações sobre o espaço em memória ocupada pela PGA, quantidade de conexões dedicadas e compartilhadas (MTS); a estrutura de memória cache (SGA) com seus componentes e indicadores de performance (Buffer Cache hit rate); os processos responsáveis pela escrita (Database Writes, Redo Log Writer e Archiver) e finalmente, as unidades de armazenamento.

Uma característica importante dessa ferramenta é a possibilidade de verificar o fluxo de informações (em Kbytes/Seg) de uma região para outra (veja as regiões circuladas em vermelho). Com isso é possível identificar gargalos potenciais em todo o sistema computacional. Caso algum componente do SGBD alcance um valor não desejado ou de alerta, a cor da região correspondente mudará de verde para vermelho como veremos mais adiante.

Spotlight-monitorando-duas-instâncias-ORACLE
Figura 1. Spotlight monitorando duas instâncias ORACLE.

Observe na figura 1 que o servidor NEWTON não apresenta no momento nenhum problema. Ainda nessa figura, veja os destaques 1 e 2 representando respectivamente as atividades dos processos de escrita em discos (DBWR1 e LGWR1) e o estado dos componentes da SGA do ORACLE (Buffer Cache, Redo Buffer, Shared Pool, Java Poll e Large Pool). Já o PITOLOMEU e WEBER estão na cor vermelha (ver destaque 3) indicando que algo pode não estar indo bem. Nesse momento o DBA poderá selecionar o SGBD a ser analisado. A figura 2 mostra três regiões em vermelho indicando o que pode estar acontecendo de errado no PITOLOMEU. Note que o número de paginações (Paging) atingiu o valor de 99 por segundo indicando que, provavelmente, a quantidade de memória principal (RAM) não é suficiente para executar os serviços necessários. Isso obriga o sistema operacional a fazer a paginação, aumentando assim a utilização dos recursos de I/O e conseqüentemente diminuindo a performance geral do sistema.

Note que a região “OS Status” também está em vermelho, confirmando que algo não está indo muito bem com o sistema operacional. Por fim, observe a região em vermelho denominada “Disk Storage” indicando que a capacidade máxima de alguma estrutura de armazenamento pode está chegando ao seu valor limite.

Caso o DBA precise de maiores detalhes sobre os problemas identificados, é possível fazer uma análise mais profunda clicando nas regiões indicadas em vermelho. Se a região “Paging” for selecionada, é possível observar os recursos utilizados pelo sistema operacional como mostra a figura 3.

Spotlight-monitorando-o-SGBD-PITOLOMEU-com-alguns-problemas
Figura 2. Spotlight monitorando o SGBD PITOLOMEU (MS SQL Server) com alguns problemas
Spotlight-mostrando-com-mais-detalhes-o-problema-da-Paginação.
Figura 3. Spotlight mostrando com mais detalhes o problema da Paginação.

Ainda na Figura 3 observe que quase toda a memória RAM (região “Memory” circulada em vermelho) do sistema está ocupada (somente 8,69 MB livre de um total 1GB) justificando a quantidade de paginações por segundo. Mais uma vez, clicando na região “Memory”, é possível aumentar ainda mais o nível de detalhe. A figura 4 mostra os processos e a quantidade de recursos consumidos por eles. Observe na coluna “Physical MB” (circulada em vermelho) que só o serviço sqlservr consome 871,73 MB.

Spotlight-mostrando-o-consumo-de-recursos-dos-processos-ativos.
Figura 4. SSpotlight mostrando o consumo de recursos dos processos ativos..

A Quest também possui uma ferramenta denominada Iwhatch que permite coletar informações e armazená-las em um repositório. Essa ferramenta é, em geral, executada juntamente com os serviços do SGBD permitindo análise temporal dos dados. O Iwhatch destaca-se pela baixa intrusão no sistema.

Ferramenta da Patrol (BMC Software)

A Patrol também possui um conjunto de ferramentas que, na mesma linha da Quest Software, possibilitam a monitoração do SGBD e sistema operacional. Suas principais características são:

  • Condição de performance em tempo real dos servidores de banco de dados;
  • Visualização imediata de áreas e situações problemáticas;
  • Isolamento da causa do problema;
  • Análise de performance;
  • Dados estatísticos acumulados em repositório;
  • Alerta de contenção de recursos de SGBD;
  • Alerta de falta de espaço;
  • Condição e utilização de memória.

As figuras 5 e 6 mostram a ferramenta DBXray monitorando o NEWTON (Servidor ORACLE)e o WEBER (Servidor MS SQL Server), respectivamente. As mesmas observações aplicadas ao Spotlight também podem ser consideradas aqui, tanto no que se refere à estratégia de visualização como à possibilidade de aumentar o nível de detalhe até chegar ao foco do problema.

DBXray-mostrando-o-estadogeral-de-funcionamento-de-um-SGBD-ORACLE
Figura 5. DBXray mostrando o estado geral de funcionamento de um SGBD ORACLE.
DBXray-mostrando-o-estadogeral-de-funcionamento-de-um-SGBD-MS-SQL-Server
Figura 6. DBXray mostrando o estado geral de funcionamento de um SGBD MS SQL Server

Conclusão

Vimos neste artigo uma introdução a algumas ferramentas para monitoração de banco de dados. Infelizmente não tive oportunidade de avaliar a ferramenta da Precise (Indepth). Porém, pelo que pude ver no site , ela possui funcionalidades equivalentes às apresentadas pela Quest e Patrol. Gostaria de complementar dizendo que as observações sobre as ferramentas apresentadas aqui são superficiais e servem apenas para dar uma idéia ao leitor das facilidades presentes nelas.

Referências

  • ARONOFF, Eyal, LONEY, Kevin, SANAWALLA, Noorali, ORACLE 8 Advanced Tuning & Administration, Berkeley, California, Oracle Press, 1998
  • CYRAN, Michele, Desinginig and Tuning for Performance, Release 2 (8.1.6), Oracle Corporation, 1999.
  • DATE, C. J., Introdução a Sistema de Banco de Dados, 7ª ed. [Tradução: Vandenberg D. de Souza], Rio de Janeiro, 2000.
  • MOLINA, Hector Garcia, ULMAN Jeffrey D., WIDON, Jennifer, Implementação de Sistemas de Banco de Dados, 1ª ed. [Tradução: Vandenberg D. de Souza], Rio de Janeiro, CAMPUS, 2001.
  • SHAPIRO, Jeffrey R., SQL Server 2000, 1ª ed. [Tradução: Aldair José Coelho Corrêa da Silva], São Paulo, MAKRON Books, 2002.
  • Quest Software
  • Patrol
  • Veritas
revista
Clique aqui para ler todos os artigos desta edição