Monitoramento de Banco de Dados

Logo-Statum-3

Monitoramento de Banco de Dados
e Armazenagem em Cloud

Receba mais informações

Preencha os campos abaixo que entraremos em contato.

Análise e ajustes de desempenho do Banco de Dados.

  • Alocação de memória do gerenciador
    São monitoradas as estruturas de buffer do Oracle (Shared Pool, Database Buffer Cache e Redo Log Buffers) com objetivo de aumentar ou diminuir a memória RAM (física) do servidor com reflexos na carga de I/O (leitura e gravação em disco/HD).
  • Atividades de segmentos de rollback / segmentos de undo.
    Quando ocorre execução de inserções, atualizações ou exclusões maciças as áreas de undo são expressivamente aumentadas de modo a permitir operação de rollback, assim, faz-se necessário avaliar a frequência das operações que causam este comportamento e a partir daí dimensioná-las de maneira a não impactar o desempenho de novas transações.
  • Atividade da área de classificação.
    Toda sentença SQL que utilize a clásula “ORDER BY” faz uso da área de sort em memória RAM e caso não esteja devidamente dimensionada fará seu trabalho através de aumento de I/O (leitura e gravação em disco)
  • Identificação e ajustes das áreas e eventos com contenção de recursos.
    Mapeia os recursos que possam estar estressando do banco de dados como atividades frequentes de lock em objetos, gargalos em uso de processador, I/O, memória RAM, tráfego de rede, etc.
  • Monitoramento e configuração de servidores dedicados e compartilhados.
    Comportamentos anômalos como crescimento repentino de estruturas de armazenamento de estruturas de dados (tablespaces, segmentos de dados e de índices) podem coprometer o volume do banco de dados e a performance na busca dos dados.
  • Estatísticas de leitura/gravação do banco de dados.
    Uma das métricas mais importantes visto que o HD é o dispositivo mais lento por sua arquitetura eletro-mecânica, assim, esta atividade visa monitorar e corrigir excessivos acessos a disco através dos ajustes nas áreas de bufferização do banco de dados.
  • Características de tablespaces, datafiles e tempfiles.
    Dimensionamento e redimensionamento constante dos tablespaces, datafiles e tempfiles de modo a otimizar seus volumes/tamanhos evitando-se, desta maneira, que seu crescimento prejudique o tempo de resposta das consultas.
  • Estatísticas da geração de transaction log.
    A métrica TPM(Transaction Per Minute) é a mais importante informação em um ambiente de banco de dados, didaticamente pode-se dizer que marca sua pulsação, assim, quanto maior o valor de TPM mais ajustes e cuidados são necessários a fim de manter o desempenho de forma aceitável.
  • Estatísticas gerais do gerenciador.
    Centenas de variáveis devem ser avaliadas de maneira que indiquem ajustes nos chamados parâmetros de inicialização discutidos abaixo.
  • Parâmetros de inicialização.
    São os chamados parâmetros de ajustes (tuning) que devem ser constantemente monitorados e alterados de maneira prover a otimização de recursos que garantam desempenho e segurança ao banco de dados.
  • Identificação de instruções SQL que consomem mais recursos.
    Grande parte dos problemas de desempenho de processos no banco de dados está relacionada a consultas com problemas de formulação ou sem os devidos índices. Esta atividade periodicamente as captura e após análises índices são criados ou laudos técnicos são gerados e encaminhados para o fornecedor do ERP.

Análise e ajustes das áreas físicas do Banco de Dados nos itens:

  • Alocação e crescimento de objetos do banco de dados.
    Particionamento de tablespaces e mapeamento do volume diário, semanal, mensal de dados gerados são capazes de compor base de conhecimento para dimensionamento constante de estruturas de dados internas, bem como, o planejamento de melhorias de hardware e software dos servidores.
  • Fragmentação de objetos, tablespaces e datafiles.
    O armazenamento dos dados se faz da maneira mais rápida possível, assim, uma inserção de itens de uma determinada nota fiscal deve ocorrer de forma, praticamente, instantânea, contudo, na maioria das vezes o local (arquivo e bloco) não é ideal para a recuperação por consulta, visto que o algoritmo privilegia o tempo de resposta da inserção, atualização ou exclusão, em detrimento da consulta. Outro fator causador da fragmentação é a atualização de dados de um registro que não mais cabe no bloco de dados de origem, assim, o SGBD o migra para outro bloco mantendo nos seus índices o endereço anterior e ao acesso um ponteiro o remete para o local devido. Isto provoca um forte impacto no desempenho das consultas.

Verificação da segurança de acesso do Banco de Dados no item:

  • Validação dos privilégios concedidos para usuários e grupo de usuários.
    O banco de dados provê um forte sistema de segurança de acesso e auditoria de alteração de dados, contudo, esta deve ser habilitada para que seja capaz de executar seus propósitos.

Monitoramento das rotinas de backup:

  • Checagem dos logs de backup.
    Diariamente os logs dos backups lógicos e físicos devem ser checados de modo que ações sejam imediatamente tomadas em caso de falhas.
  • Teste de restauração de backup físico e lógico.
    Frequentemente deve-se baixar e restaurar os backups de maneira a garantir sua plena funcionalidade.

Monitoramento e checagem dos logs do banco de dados

  • Eventos de erros.
    Há dezenas de arquivos que são gerados automaticamente e que devem ser observados porque alguns erros não são críticos de imediato, contudo, se nenhuma ação for tomada pode haver agravamento da situação e consequências mais graves.
  • Análise de logs
    Há também outra dezena de arquivos que registram atividades relativas a processos como utilização de cursores (PGA) cujas análise pode remeter a ajustes de parâmetros de sessão.
  • Corrupção lógica e física
    Há que observar constantemente blocos que possam apresentar corrupção física(bad block no HD) ou lógica (em nível de banco de dados). Caso seja detectado deve se fazer uso de restauração por backup. Muitas vezes estas corrupções passam desapercebidas por conta de dados históricos passados serem pouco acessados em ambientes OLTP.

Aplicação de patches de correção (quando identificada a necessidade)

  • Frequentemente a Oracle disponibiliza atualizações do banco de dados que visam corrigir erros lógicos, de segurança e de performance. Grande parte deles sua aplicação é altamente recomendada pelo fabricante. Hoje mesmo um de nossos clientes estava com o aplicativo abortando quando um determinado importante relatório do ERP era executado. Diagnosticamos o problema como um bug, aplicamos o patch e o problema foi corrigido.

Checagem diária dos itens:

  • Alocação do espaço interna no Oracle.
  • Alocação de espaço nos servidores.
  • Checagem dos log’s de backup.
  • Checagem dos log’s dos bancos de dados.
  • Checagem da atualização do Standby Database (Servidor de contingência).
  • Estatísticas de acesso/plano de execução
    Deve ser executada, se possível, diariamente rotina para atualização das estatísticas de acesso aos dados o chamado plano de execução de modo que o banco de dados mantenha a chamada heurística (aprendizado sobre o menor caminho para se chegar a uma informação).

Validação dos backups que passa a assumir dois papéis

  • Recuperação frequente dos backups não apenas garante sua plena funcionalidade como mantém o ambiente de homologação/testes mais próximo do ambiente de produção.

Apoio aos desenvolvedores do software através de sugestão de melhorias em instruções SQL, sugestão para criação de índice, análise de desempenho de processos e geração de arquivos para análise desempenho.

  • O tuning de instruções SQL é a atividade que mais influencia no desempenho de consultas no banco de dados. É comum análises de instruções SQL a sugestão de reescrita das mesmas ou ainda a criação de índices

Criação e Monitoramento do funcionamento Mirror