Este é mais um artigo da série de dez aulas sobre conceitos de administração do DB2 em ambiente UNIX, conhecido oficialmente como DB2 LUW. Esta é a última aula do capítulo sobre armazenamento e prevenção de perda de dados e trata da restauração de bancos de dados do DB2 LUW.

Recomendo ao leitor interessado em acompanhar o curso que acesse o portal do DB2 para abaixar uma cópia do DB2 Express-C, edição gratuita do produto, ou então para obter instruções de como acessar e configurar uma instalação do DB2 rodando na nuvem. Para mais detalhes, clique aqui.

AULA 4 – Restaurando Backups do DB2

Eu costumo fazer piada que a operação de backup nunca me amedronta; quem me deixa de cabelo em pé é a restauração do banco. Muitas vezes a restauração acontece em momentos em que se está recuperando o banco de dados de um desastre e, nestas situações, a tensão é muito grande e os nervos de todo mundo estão à flor da pele, inclusive do seu gerente ou diretor.

Não é pra menos. Perder dados da empresa é prejuízo na certa. E nós temos dois caminhos:

1. Planejamos muito bem as políticas de backup e avaliação de integridade
2. Ou corremos o risco de descobrir problemas imprevistos exatamente no momento em que a empresa precisa restaurar o banco de dados o mais rápido possível

No artigo anterior eu apresentei os tipos de backup do DB2 e apresentei exemplos de combinações de backup para minimizar o tempo em que o banco fica fora do ar para execução de backups. Mas a política de backup da empresa deve prever também a frequência destes backups, em que tipo de mídia devem ser gravados, qual é a tolerância de transações perdidas para o caso de um desastre, em quanto tempo o banco de dados deve voltar ao ar em caso de desastre, etc.

Existe um cuidado adicional que se deve ter em relação aos backups sob pena de comprometer toda a ação de restauração do banco de dados: a checagem da integridade do arquivo de backup, que deve ser feita logo após a criação do backup. O utilitário que faz esta operação é o “db2ckbkp”. Veja exemplo:

Cuidados antes de depois da restauração de um backup

Toda operação de restauração é feita com a base fora do ar. Caso ela não esteja fora do ar, deve-se alterar o status da base com os seguintes comandos:

Após a restauração do banco de dados, ele ainda estará offline. Portanto sempre será necessário ativá-lo. Os comandos a seguir resolvem o problema:

Restaurando backups do DB2

Deve-se observar a sequência de restauração dos arquivos de backup.

Ao final da restauração, é necessário reprocessar na base todas as transações realizadas com sucesso desde o último backup. Estas transações todas estão obviamente gravadas nos arquivos de log do DB2 (comando rollforward).

Para ilustrar este trabalho, eu vou retomar o exemplo do artigo anterior, sobre as três empresas com políticas de backup distintas:

1. Empresa A faz backup completo aos domingos e backups online diários no resto da semana;
2. Empresa B faz backup completo aos domingos e faz diariamente backups incrementais cumulativos no resto da semana;
3. Empresa C faz backup completo aos domingos e backups incrementais delta nos outros dias da semana.

Considerando que todos os backups são feitos diariamente às 23:59 e que aconteceu um desastre ao 12:00 da sexta-feira. Veja as ações que são necessárias para restaurar a base de dados em cada uma destas empresas.

• Empresa A (backup full + online):

• Empresa B (backup full + incremental cumulativo):

• Empresa B (backup full + incremental delta):

Note que o comando RESTORE usado foi o mesmo tanto no caso do backup cumulativo como no backup delta. A instrução INCREMENTAL AUTOMATIC deixa o DB2 localizar os backups incrementais necessários, bastando que sejam backups incrementais.

Exemplos de uso e solução de problemas

Problema 1:

Ao fazer a restauração de um backup delta, o penúltimo arquivo estava corrompido. Qual impacto disso na restauração?

Solução: Se o penúltimo backup delta está corrompido, o último deles não vai servir pra nada. Será necessário restaurar todos os backups íntegros. Depois disso, você terá que torcer para que todos os arquivos de log que registraram as transações ocorridas desde então estejam íntegros e disponíveis. Então, você executará um ROLLFORWARD, como nos exemplos mostrados aqui.

Se um único arquivo de log também estiver corrompido, todas as transações acontecidas desde então serão perdidas permanentemente!

Problema 2

Devo fazer a restauração de um backup incremental cumulativo, mas sei que não houve backup na penúltima data antes do backup. Qual impacto disso na restauração?

Solução: Desde que o último backup completo esteja íntegro, não tem problema nenhum que não exista o penúltimo backup incremental cumulativo. O último deles conterá todas as páginas modificadas desde o último backup completo.

Referências

O leitor interessado encontrará informações mais detalhadas nas seguintes referências.

• DBA 101: administrando estruturas de dados do DB2: http://www.ibm.com/developerworks/br/local/data/dba_101_administrando_estruturas_dados_db2/index.html
• DB2 Essential Training I: http://bigdatauniversity.com/courses/course/view.php?id=121
• DB2 Essential Training II: http://bigdatauniversity.com/courses/course/view.php?id=243
• DB2 Academic Training – 302A Exam preparation: http://bigdatauniversity.com/courses/course/view.php?id=272
• DB2 9.5 Backup and Recovery: Basics: http://www.channeldb2.com/group/db2UDBstudyDOC/forum/topics/difference-between-full-online
• Using DB2 Incremental Backup: http://www.ibm.com/developerworks/data/library/techarticle/dm-0910db2incrementalbackup/

Na semana que vem tem mais sobre DB2. Até lá!