IBAnalyst is a part of HQbird Standard now!

O IBAnalyst é uma ferramenta que o permite ao administrador de banco de dados analisar detalhadamente as estatísticas das bases de dados Firebird ou InterBase e então identificar possíveis problemas com a performance, manutenção e como uma aplicação interage com a base de dados.
 

Documentação

• Entendendo sua base de dados com o IBAnalyst (Inglês)
• Visão Resumida no IBAnalyst

O IBAnalyst mostra graficamente as estatísticas das bases de dados Firebird (ou InterBase) de uma forma amigável ao usuário e destaca os seguintes problemas:

Além disso, o IBAnalyst pode inteligentemente fazer sugestões para melhorar a performance das bases de dados e dicas de manutenção.

O IBAnalyst pode pegar os dados esta'tisticos de bases de dados em produção atrav;es da Service API (recomendado), ou analisar a saída do comando  gstat -a -r ... . Estatísticas no momento de pico de carga pode fornecer muitas informações sobre os atuais problema de performance em bases de dados em produção.

Como o IBAnalyst pode ajudar a identificar problemas na sua base de dados Firebird ou InterBase

Vamos demonstrar as principais fucnionalidades do IBAnalyst. Quando você olha as estatísticas da dua base de dados no IBAnalyst pela primeira vez, as coisas podem não parecer claras, particularmente se o IBAnalyst mostrar muitos avisos coloridos nas células pintadas de vermelho e amarelo na visão do resumo (Summary), das tabelas e índices.Vamos analisar vários exemplosreais de estatísticas.

Visão Resumo (Summary View)

A página de resumo (Summary page) mostra muitas informações, mas a maios valiosa é a do estado das transações (por favor, leia a descrição dos possíveis estados de transações na ajuda do IBAnalyst, está disponível pressionando  F1 ou na opção Help do menu).

Nesta imagem da tela você pode ver que existe uma transação ativa por um longo período, "60% da média diária". O IBAnalyst marca este tipo de estado de transação em vermelho, devido a esta transação inibe que o acumulo versões de registros possa ser limpo pelo servidor (processo de garbage collection). Esta é uma das possíveis razões para lentidão, quanto amis versões existem para um registro mais tempo levará para que seja lido.

Para que possa encontrar esta transação que fica aberta por muito tempo você pode usar o módulo MON$Logger do FBScanner, ou executar pesquisas diretamente nas tabelas de monitoramento (MON$). Então, para encontrar quais tabelas são afetadas por esta transação longa (tabelas com muitas versões de registros) você precisa ir a visão "Tables" (Tabelas) do IBAnalyst.

Visão das Tabelas (Tables view)

Na visão das "tabelas" voce pode ver as tabeas e seus parâmetros mais 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 ordenas os dados apra encontrar as maiores tabelas. Especialmente estamos interessados em tabelas com muitas versões de registros, muitas versões de registros fará o processo de garbage collection ser mais demorado. Geralmente é necessário mudar o algorítimo de atualziação e apagamento (update e delete) para se livrar das muitas versões de registros.

Versões de linhas (Row Versions) mostra a quantidade  total de versões para uma tabela específica e a Quantidade Máxima de Linhas (row Max Vers) mostra a quantiade máxima de versões atingida por um único registro. Por exemplo, se você olhar na tablea NAB, existem 11.9 milhões de registros, a quantidade total de versões é 20932, mas um registro tem 176 versões. Ler e analisar este pacote de dados do disco leva amis tempo, então, ler este registro é mais lento do que ler outros registros desta mesma tabela.

Esta imagem mostra muitas tabelas onde os dados foram apagados, mas por conta de transações longas, o servidor não pode remover estes registros e eles continuam no disco, continuam indexados e continuam sendo lidos pelo servidor quando a é feita a leitura de dados.

Visão dos Índices (Index view)

Algumas bases de dados de produção podem ter índices com apenas um valor de chave indexado, isso pode acontecer porque a base de dados foi desenvolvida "para ser ampliada no futuro", ou, alguém estava fazendo testes com índices durante o desenvolvimento ou testes. Você pode identificar este tipo de índice como "Useless" (Desnecessário) no IBAnalyst:

SKIN04, SKIN05, SKOUT03, etc, criado numa coluna com apenas um valor para todos os registros  (milhões de registros). estes índices são realemnte desnecessários, porque:

• o otimizador poderá usar este índice se você especificar "where field = ...". Uma vez que o campo contém apenas um valor, usar o índice causará leituras denecessárias das páginas de índices do disco pra memória, e consumirá memória (e tempo) quando o servidor analisará quais registros serão retornados pela query.
• criar os índices é parte do processo de restore, adicionando mais índices ao processo adicionará mais tempo.

Claro que isso não é tudo que você poderá saber sobre sua bases de dados no IBAnalyst. Você encontrará também

• quantidade média de transações por dia
• aconteceu rollback ou perda de conexão, e quando
• quão grande (em megabytes) é cada tabela e índice
• tabelas que tem registros intercalados com blobs, portanto a leitura somente dos registros será mais lenta
• tabelas vazias - apenas esquecidas, ou vazias no momento que as estatísticas foram feitas
• índices com muitos valores duplicados (você poderá analisar a distribuição de valores do campo)
• índices com profundiade maior que 4 - pode ser que você precise aumentar o tamanho da página da base de dados para aumentar a velocidade

Recomendações Automatizadas

Se você está confuso pela leitura dos avisos das celulas coloridas, apenas abra a "Reports\View recommendations" (Relatórios\Visualizar Recomendações) - tudo o que preicsa saber sobre a performance da base de dados está dispon;ivel ali. Por favor, sinta-se a vontade para fazer qualquer pergunta ([email protected])