Artigo Clube Delphi 83 - Copiando registros de um banco de dados corrompido

Boa Idéia

Copiando registros de um banco de dados corrompido

Recentemente a empresa na qual sou consultor foi contratada pela prefeitura de uma grande capital para prestar treinamento e consultoria em Firebird. O principal trabalho que deveria ser realizado durante a consultoria era o de otimização do banco de dados da instituição.

Para ter uma idéia do tamanho do desafio, o banco tinha aproximadamente 120 milhões de registros armazenados em pouco mais de 30 tabelas, o que gera um arquivo com 19 GB. Como se o volume de informação já não fosse um desafio suficientemente grande, a análise do banco de dados mostrou que o mesmo estava corrompido.

Este artigo descreve o trabalho que foi realizado para que fosse possível copiar as informações do banco de dados corrompido. Antes disso, mostra rapidamente qual o ambiente encontrado e os principais passos que foram tomados antes da cópia dos dados.

Avaliação da estrutura

O primeiro passo a ser feito sempre que se deseja melhorar o desempenho de uma aplicação é avaliar o servidor (hardware) em que ela está rodando. Muitas vezes comprar um novo equipamento, ou melhorar o existente, não gera o ganho de desempenho esperado, fazendo com que o gasto não se justifique.

O servidor usado pelo cliente tinha dois processadores, 2 GB de memória RAM, discos rígidos de 10 mil RPMs e sistema operacional Windows 2000 Server. Ou seja, o equipamento era de alta qualidade e havia pouco o que melhorar.

Avaliação das configurações do banco de dados

A versão instalada do Firebird era a 1.5, rodando como SuperServer. Embora muitos ainda considerem a versão Classic a ideal, testes realizados demonstraram que a arquitetura SuperServer é bastante estável em servidores de alta qualidade. Esse caso é mais um exemplo.

Avaliamos também a forma de gravação dos dados. O banco de dados estava configurado para usar cache de gravação do tipo write throug (padrão de instalação do Firebird em plataforma Windows), onde cada operação de escrita é imediatamente passada para que o SO a processe. Em outras palavras, a opção Enable Forced Writes estava habilitada, fazendo com que o banco gravasse em disco instantaneamente toda atualização feita nos dados, tornando assim as operações de escrita mais lentas.

Outro ponto avaliado foi o tamanho do cache das páginas de dados e de índices. Constatou-se que o tamanho era de 120 MB, dada a quantidade de memória disponível e também o número de usuários conectados, avaliamos que o tamanho estava apropriado.

O penúltimo ponto analisado foi o tamanho das páginas de dados e de índices. Normalmente indicamos aos clientes páginas de dados com 8 Kb. Entretanto, devido ao tamanho do arquivo FDB, optamos por usar páginas de 16 Kb. A lógica é simples, com páginas maiores teremos menos fragmentos de registros divididos, uma melhor utilização dos índices e operações de I/O mais contínuas. Como a mudança no tamanho exige um " [...] continue lendo...