O IBAnalyst agora faz parte do HQbird Standard!

O IBAnalyst é uma ferramenta que permite ao administrador de banco de dados analisar estatísticas detalhadas do Firebird ou InterBase e, em seguida, identificar possíveis problemas de desempenho do banco de dados, manutenção e como um aplicativo interage com o banco de dados.

Documentação

O IBAnalyst exibe graficamente as estatísticas do banco de dados Firebird (ou InterBase) de forma amigável e destaca os seguintes problemas:

fragmentação de tabelas e BLOBs,
versionamento de registros,
coleta de lixo (garbage collection),
eficácia dos índices, etc.

Além disso, o IBAnalyst pode automaticamente fazer sugestões inteligentes sobre como melhorar o desempenho e a manutenção do banco de dados.

O IBAnalyst pode obter estatísticas de bancos de dados de produção ativos através da Services API (recomendado), ou analisar a saída de texto dos comandos gstat -a -r …. Estatísticas dos períodos de pico de carga podem fornecer muitas informações sobre problemas reais de desempenho em bancos de dados de produção.

Como o IBAnalyst pode ajudar a encontrar problemas no seu banco de dados Firebird ou InterBase

Vamos analisar os principais recursos do IBAnalyst. Quando você olha as estatísticas do seu banco de dados no IBAnalyst pela primeira vez, as coisas podem não estar claras, especialmente se o IBAnalyst mostrar muitos avisos com células coloridas em vermelho e amarelo nas visões de Resumo, Tabelas e Índices. Vamos considerar vários exemplos reais de estatísticas.

Visão de Resumo

A página de Resumo mostra muitas informações, mas a mais valiosa é o estado das transações ( por favor, leia a descrição dos possíveis estados de transação na ajuda do IBAnalyst, disponível pressionando F1 ou no menu Ajuda).

Nesta captura de tela, você pode ver que alguma transação está ativa há muito tempo, “60% da média diária”. O IBAnalyst marca o estado dessa transação em vermelho, porque essa transação pode impedir que versões acumuladas sejam consideradas lixo pelo servidor e, portanto, sejam coletadas como lixo. Esta é uma possível causa de lentidão: quanto mais versões existirem para um registro, mais tempo levará para lê-lo.

Para encontrar essa transação de longa duração, você pode usar o módulo MON$Logger do FBScanner, ou executar uma consulta direta nas tabelas MON$. Em seguida, para descobrir quais tabelas foram afetadas por transações de longa duração (tabelas com muitas versões de registros), você precisa ir para a visão “Tabelas” do IBAnalyst.

Visão de Tabelas

Na visão “Tabelas”, você pode ver as tabelas e seus parâmetros importantes: número de registros, número de versões de registros, tamanho do registro, número máximo de versões, etc.

Você pode ordenar esta visão para encontrar as maiores tabelas. Estamos especialmente interessados em tabelas com muitas versões de registros - muitas versões de registros tornarão a coleta de lixo mais demorada para as tabelas afetadas. Normalmente, é necessário alterar os algoritmos de atualização e exclusão para eliminar muitas versões de registros.

A linha Versões mostra a contagem total de versões para uma tabela específica, e a linha Máx Vers mostra o máximo de versões alcançado por algum registro. Por exemplo, se você olhar a tabela NAB, há 11,9 milhões de registros, o total de versões é 20.932, mas um registro tem 176 versões. Ler e analisar esse pacote do disco leva mais tempo, portanto, ler esse registro é mais lento do que ler outros.

Esta imagem também mostra muitas tabelas onde os dados foram excluídos. Mas, por causa da transação de longa duração, o servidor não pode excluir essas versões, e elas ainda estão no disco, ainda indexadas, e ainda sendo lidas pelo servidor ao ler dados.

Visão de Índices

Alguns bancos de dados de produção podem ter índices com apenas um valor de chave indexado. Isso pode acontecer porque o banco de dados foi desenvolvido “para ser estendido no futuro”, ou alguém apenas experimentou com os índices durante o desenvolvimento ou testes. Você pode ver esses índices como “Inúteis” no IBAnalyst:

SKIN04, SKIN05, SKOUT03, etc., construídos na coluna que tem apenas um valor para todas as linhas (milhões de linhas). Esses índices são realmente inúteis, porque

o otimizador pode usar este índice se você especificar “where campo = …”. Como o campo contém apenas um valor, usar o índice causará leitura inútil de páginas de índice do disco para a memória, e consumirá memória (e tempo) quando o servidor preparar quais linhas mostrar para essa consulta.
criar índices faz parte do processo de restauração. Índices extras adicionam tempo extra.

Claro, isso não é tudo que você pode descobrir sobre seu banco de dados no IBAnalyst. Você também pode encontrar

número médio de transações por dia
se houve rollbacks ou conexões perdidas, e quando
o tamanho (em megabytes) de cada tabela e índice
tabelas que têm registros intercalados com blobs, e assim a leitura apenas dos registros é mais lenta
tabelas vazias - apenas esquecidas, ou vazias no momento em que as estatísticas foram coletadas
índices com muitas chaves duplicadas (você pode considerar a distribuição de valores da coluna)
índices com profundidade 4 ou maior - talvez você precise aumentar o tamanho da página para acelerar

Recomendações automáticas

Se você está confuso ao ler os avisos das células coloridas, basta abrir “Relatórios\Ver recomendações” - tudo que é suficiente para o desempenho do banco de dados está reunido aqui. Sinta-se à vontade para fazer qualquer pergunta ( [email protected])