Não é novidade que nada no mundo é perfeito e, obviamente, os bancos de dados não são exceção. Seja por falhas no próprio SGBD (bugs), ou por fatores externos (sistema operacional, hardware, faxineira, etc.), é imprescindível adotar uma política de backups para se precaver de acontecimentos e surpresas indesejáveis.
O Firebird oferece dois métodos nativos de backup: o bom e velho gbak, e o mais recente, nbackup. A diferença básica entre eles é que o gbak realiza sempre um backup completo da base de dados, armazenando a estrutura do banco e os dados das tabelas. Já o nbackup permite a realização de backups incrementais, sendo que os arquivos gerados contêm cópias exatas das páginas do banco de dados. No backup é incremental, apenas as páginas que foram alteradas desde o último backup de nível anterior são gravadas.
Uma diferença importante é que o gbak não armazena no arquivo de backup o “lixo” que pode existir no banco, como versões temporárias e registros apagados, árvores de índices, páginas de inventário de transações, etc. Já o nbackup, por fazer uma cópia das páginas do banco, leva também todo o lixo junto, e qualquer outra coisa que esteja gravada nelas. Tanto é verdade, que um backup de nível zero no nbackup terá exatamente o mesmo tamanho do arquivo do banco de dados. É praticamente uma cópia do arquivo, com apenas alguns bytes de diferença no header, indicando que é um arquivo de backup. Já um backup gerado pelo gbak produz um arquivo geralmente muito menor do que o banco de dados, pois todo o lixo e as árvores de índices são descartados.
Mas se você pensa que backups servem somente para te salvar em alguma situação de emergência, está enganado! Os backups podem ajudar também para manter a boa “saúde” do banco de dados. Como? Vejamos:
Uma forma pouco conhecida de se fazer um backup/restore em um único passo é:
A linha de comando acima faz com que o gbak desvie a saída para a stdout (ao invés de um arquivo), redirecionando para a stdin. Ou seja, o comando acima não produz um arquivo de backup, mas sim um banco de dados operacional (BD_backup.fdb). Qualquer problema durante o processo retornará um erro imediatamente, ou seja, se nenhum erro ocorreu, você pode ter certeza que o banco restaurado está ok.
É altamente aconselhável NUNCA sobrescrever um banco de dados existente durante o processo de restore. Primeiro, restaure usando um nome temporário. Se tudo deu certo, apague o arquivo do BD e renomeie o recém-restaurado usando o nome correto. Certifique-se também de que não há conexões ativas no banco de dados quando for substituí-lo por um novo, especialmente se estiver usando o Firebird no Linux. Para fazer o backup, seja com o gbak ou com o nbackup, não é necessário acesso exclusivo no banco de dados.
Se estiver usando o nbackup para fazer backups incrementais, tenha certeza de armazenar os arquivos dos diferentes níveis de backup em um local seguro. Se você perder qualquer arquivo de nível intermediário, só conseguirá restaurar o backup até o nível anterior ao arquivo perdido. Certifique-se também de estar usando a versão mais recente do Firebird, pois algumas versões mais antigas traziam um nbackup com vários bugs.
Para ter uma visão geral e saber como utilizar o gbak e o nbackup, recomendo a leitura do recém produzido manual do gbak, em http://www.firebirdsql.org/manual/gbak.html e o do nBackp em http://www.firebirdsql.org/manual/nbackup.html, além de outros artigos e livros disponíveis.
Este artigo mostrou que o processo de backup tem papel importante, não só como garantia contra catástrofes, mas como parte do processo de manutenção do banco de dados. Tão importante quanto fazer o backup, é se certificar que o backup gerado pode ser restaurado.
Matéria originalmente publicada na revista ActiveDelphi.
O Firebird oferece dois métodos nativos de backup: o bom e velho gbak, e o mais recente, nbackup. A diferença básica entre eles é que o gbak realiza sempre um backup completo da base de dados, armazenando a estrutura do banco e os dados das tabelas. Já o nbackup permite a realização de backups incrementais, sendo que os arquivos gerados contêm cópias exatas das páginas do banco de dados. No backup é incremental, apenas as páginas que foram alteradas desde o último backup de nível anterior são gravadas.
Uma diferença importante é que o gbak não armazena no arquivo de backup o “lixo” que pode existir no banco, como versões temporárias e registros apagados, árvores de índices, páginas de inventário de transações, etc. Já o nbackup, por fazer uma cópia das páginas do banco, leva também todo o lixo junto, e qualquer outra coisa que esteja gravada nelas. Tanto é verdade, que um backup de nível zero no nbackup terá exatamente o mesmo tamanho do arquivo do banco de dados. É praticamente uma cópia do arquivo, com apenas alguns bytes de diferença no header, indicando que é um arquivo de backup. Já um backup gerado pelo gbak produz um arquivo geralmente muito menor do que o banco de dados, pois todo o lixo e as árvores de índices são descartados.
Mas se você pensa que backups servem somente para te salvar em alguma situação de emergência, está enganado! Os backups podem ajudar também para manter a boa “saúde” do banco de dados. Como? Vejamos:
- Resetando o contador de alterações dos objetos do banco. Cada objeto que compõe o banco de dados (ex: tabela, triggers, procedure, etc.) pode ser alterado até 255 vezes. Quando atingir este valor, o Firebird não permitirá que se altere o objeto mais uma vez. Para resolver essa situação, somente através de um backup/restore com o gbak. O banco restaurado terá os contadores reiniciados (zerados).
- Desfragmentar o arquivo de banco de dados. Em um ambiente de uso real, os dados de diferentes tabelas são inseridos no arquivo de forma não seqüencial. Páginas vão sendo alocadas conforme a necessidade, o que acaba fragmentando o arquivo, fazendo com que o acesso se torne mais lento, pois a cabeça do HD tem que saltar mais e viajar por mais lugares para recuperar a informação desejada. Fazendo um backup/restore, o novo arquivo gerado será praticamente contínuo (obviamente, o quão contínuo depende da existência de espaço sequencial livre no HD), zerando ou diminuindo muito a fragmentação, e aumentando a performance.
- Balanceamento dos índices. O Firebird usa uma versão modificada do BTree para montar as árvores de índices. Com o passar do tempo, as árvores tendem a ficar desbalanceadas, fazendo que pesquisas que utilizem índices demorem mais do que deveriam para retornar os dados. Quando um backup é restaurado pelo gbak, um novo banco de dados é criado, sendo todos índices recriados, ficando perfeitamente balanceados. Note que, também é possível reconstruir um índice, desativando e ativando o mesmo no BD, mas isso nem sempre é possível, como, por exemplo, nos índices que estão associados às regras de integridade.
- Coleta de lixo. Ao se fazer um backup com o gbak, todas as tabelas do BD são percorridas (lidas). Esse processo acaba disparando a coleta de lixo, marcando todos os registros que não são mais utilizados para serem reaproveitados. Dica: Quanto estiver fazendo um backup com a intenção de logo em seguida fazer um restore, utilize o parâmetro –g durante o backup, instruindo o gbak para não disparar a coleta de lixo. Geralmente, isso acelera consideravelmente o tempo necessário para criar o backup. O ganho depende diretamente da quantidade de lixo existente no banco.
Uma forma pouco conhecida de se fazer um backup/restore em um único passo é:
GBAK -B -G –user SYSDBA –pas xxxx C:\BD.FDB stdout | GBAK -C –user SYSDBA –pas xxxx stdin C:\BD_BACKUP.FDB
A linha de comando acima faz com que o gbak desvie a saída para a stdout (ao invés de um arquivo), redirecionando para a stdin. Ou seja, o comando acima não produz um arquivo de backup, mas sim um banco de dados operacional (BD_backup.fdb). Qualquer problema durante o processo retornará um erro imediatamente, ou seja, se nenhum erro ocorreu, você pode ter certeza que o banco restaurado está ok.
É altamente aconselhável NUNCA sobrescrever um banco de dados existente durante o processo de restore. Primeiro, restaure usando um nome temporário. Se tudo deu certo, apague o arquivo do BD e renomeie o recém-restaurado usando o nome correto. Certifique-se também de que não há conexões ativas no banco de dados quando for substituí-lo por um novo, especialmente se estiver usando o Firebird no Linux. Para fazer o backup, seja com o gbak ou com o nbackup, não é necessário acesso exclusivo no banco de dados.
Se estiver usando o nbackup para fazer backups incrementais, tenha certeza de armazenar os arquivos dos diferentes níveis de backup em um local seguro. Se você perder qualquer arquivo de nível intermediário, só conseguirá restaurar o backup até o nível anterior ao arquivo perdido. Certifique-se também de estar usando a versão mais recente do Firebird, pois algumas versões mais antigas traziam um nbackup com vários bugs.
Para ter uma visão geral e saber como utilizar o gbak e o nbackup, recomendo a leitura do recém produzido manual do gbak, em http://www.firebirdsql.org/manual/gbak.html e o do nBackp em http://www.firebirdsql.org/manual/nbackup.html, além de outros artigos e livros disponíveis.
Este artigo mostrou que o processo de backup tem papel importante, não só como garantia contra catástrofes, mas como parte do processo de manutenção do banco de dados. Tão importante quanto fazer o backup, é se certificar que o backup gerado pode ser restaurado.
Matéria originalmente publicada na revista ActiveDelphi.
Nenhum comentário:
Postar um comentário