IBAnalyst: Como obter estatísticas de banco de dados InterBase/Firebird da maneira correta

Dmitry Kuzmenko, última atualização 31-03-2014

Resumo

Este documento é dedicado a dicas e truques para coletar e analisar estatísticas de bancos de dados InterBase/Firebird, com ou sem o IBAnalyst.

Momento certo, lugar certo

Parece estranho, mas apenas coletar estatísticas via gstat ou Services API não é suficiente. As estatísticas devem ser coletadas no momento certo para mostrar como os aplicativos afetam os dados e as transações no banco de dados. O pior momento para coletar estatísticas é

• Logo após o restore
• Após o backup (gbak -b db.gdb) sem a opção -g
• Após o sweep manual (gfix -sweep)

Também é correto que, durante o trabalho, pode haver momentos em que o banco de dados está em um estado adequado, por exemplo, quando os aplicativos fazem menos carga no banco de dados do que o normal (usuários no início do expediente, horário de almoço ou em horários específicos de processos de negócios).

Como detectar quando há algo errado no banco de dados?

Sim, seus aplicativos podem ser projetados de forma tão perfeita que sempre trabalharão com transações e dados corretamente, sem gerar lacunas de sweep, muitas transações ativas, snapshots de longa duração e assim por diante. Normalmente, isso não acontece. Pelo menos porque alguns desenvolvedores testam seus aplicativos com 2-3 usuários simultâneos, não mais. Assim, quando configuram aplicativos escritos para 15 ou mais usuários simultâneos, o banco de dados pode se comportar de forma imprevisível. Claro, o modo multiusuário pode funcionar bem, porque a maioria dos conflitos multiusuário pode ser testada com 2-3 aplicativos em execução simultânea. Mas, em seguida, quando mais aplicativos concorrentes forem executados, problemas de coleta de lixo podem surgir (no mínimo). E isso pode ser detectado se você coletar estatísticas nos momentos corretos.

Se você não enfrenta problemas periódicos de desempenho

Isso pode acontecer quando seus aplicativos são projetados corretamente, há baixa carga no banco de dados, ou seu hardware é moderno e muito potente (suficiente para lidar bem com o número atual de usuários e dados).

As informações mais valiosas são a carga de transações e o acúmulo de versões. Isso só pode ser visto se você configurar o salvamento regular de estatísticas.

O InterBase não possui um agendador de tarefas interno, então você é livre para usar qualquer externo, como o Agendador de Tarefas padrão (Windows) ou cron (Unix).

A melhor configuração é obter estatísticas de transações a cada hora. Isso pode ser feito executando

gstat -h db.gdb >db_stat_.txt

onde

db.gdb é o nome do seu banco de dados,

db_stat_.txt é o arquivo de texto onde as estatísticas serão salvas,

- é a data e hora atuais em que as estatísticas foram coletadas.

Se você enfrenta problemas periódicos de desempenho

Esses problemas geralmente são causados pela execução do sweep automático. Primeiro, você precisa determinar o intervalo de tempo entre esses picos de desempenho. Em seguida, divida esse intervalo minimamente por 4 (8, 16 e assim por diante). Hoje, os sistemas de informação têm muitos usuários concorrentes, e a maioria dos problemas de desempenho com servidor e banco de dados não configurados ocorre 2 ou 3 vezes por dia. Por exemplo, se os picos de desempenho ocorrem a cada 3 horas, você precisa coletar

gstat -h db.gdb

estatísticas a cada 30-45 minutos, e

gstat -a -r db.gdb -user SYSDBA -pass masterkey

a cada 1-1,5 hora.

O ideal é coletar estatísticas gstat -a -r logo antes do próximo pico de desempenho. Isso mostrará onde está o lixo real e quantas versões obsoletas de registros foram acumuladas.

O que fazer com essas estatísticas

Se seu aplicativo usa transações explicitamente e as usa bem, ou seja, você sabe o que é read_committed e quando usá-lo, suas transações snapshot não duram mais do que o necessário, e as transações ficam ativas por um período mínimo de tempo, você pode ajustar o intervalo de sweep ou desativá-lo, e então apenas se preocupar com quantas atualizações o(s) aplicativo(s) faz(em) e quais tabelas precisam ser menos atualizadas ou cuidadas em relação a atualizações.

O que isso significa, você pode perguntar? Vamos dar um exemplo de um sistema onde problemas de desempenho ocorriam todas as manhãs por 20-30 minutos. Isso era muito significativo para os aplicativos “matinais” e não podia durar mais.

O administrador do banco de dados foi questionado corretamente, e aqui está o quadro:

O trabalho diário era dividido em seções - analistas trabalham de manhã, depois os dados são inseridos e editados por operadores comuns, e no final do dia procedimentos especiais começavam a coletar dados, que seriam usados para análise no dia seguinte (no mínimo).

O último trabalho no banco de dados no final do dia era muitas atualizações, e atualizações daquelas tabelas que os analistas usavam de manhã. Então, havia muitas versões de lixo, que começavam a ser coletadas pelo aplicativo em execução pela manhã.

E a resposta para esse problema foi encontrada de forma simples - executar gfix -sweep no final do dia.

O sweep lê todas as tabelas no banco de dados e tenta coletar todas as versões de lixo para transações confirmadas e revertidas. Após o sweep, o banco de dados ficou limpo quase como após o restore.

E o “problema matinal” desapareceu.

Então, você precisa considerar as estatísticas com muitos outros fatores:

1. quantos usuários concorrentes (em média) trabalham durante o dia

2. quanto tempo dura o dia de trabalho (8, 12, 16, 24 horas)

3. que tipo de aplicativos estão em execução em diferentes horários do dia, e como eles afetam os dados usados por outros aplicativos, em execução ao mesmo tempo ou em seguida. Ou seja, você deve entender os processos de negócios que ocorrem durante todo o dia e toda a semana.

Quando o DBA não pode fazer nada

Infelizmente, essas situações acontecem. E novamente, um exemplo:

Algum sistema instalado para ~15 usuários. Periodicamente, o desempenho é tão ruim que o DBA precisa reiniciar o servidor. Após a reinicialização do servidor, tudo funciona bem por algum tempo, depois o desempenho piora novamente. As estatísticas mostraram que a média diária de transações é de cerca de 75.000, e há transações ativas desde o início do dia até o momento em que o desempenho cai.

Infelizmente, os aplicativos foram escritos com BDE e sem uso de transações; ou seja, todo o gerenciamento de transações era automático e usado pelo próprio BDE. Isso fez com que algumas transações permanecessem ativas por muito tempo, e o lixo (versões de registros) se acumulasse até o DBA reiniciar o servidor. Após a reinicialização, o sweep automático era executado e o lixo era coletado (eliminado).

Tudo isso foi causado pelos aplicativos, porque eles foram testados apenas com 2-3 usuários concorrentes, e quando se tornaram ~15, os aplicativos começaram a gerar uma carga muito alta.

É preciso dizer que, nessa configuração, 70% dos usuários apenas liam dados, e os outros 30% inseriam e atualizavam alguns (!) dados.

Nessa situação, a única coisa que pode melhorar o desempenho é redesenhar os aplicativos completamente.

Ainda tem dúvidas? Pergunte-nos em [email protected]