Atenção: esse artigo tem uma palestra complementar. Clique e assista!

A principal responsabilidade de um DBA é a recuperação de dados, mais conhecida pelo termo em inglês Recovery.

Reparem que eu nem disse Backup & Recovery, e sim, apenas a segunda parte. Backup é uma parte do processo de Recovery, é apenas um meio, e não o fim. O objetivo é garantir a recuperabilidade de seus dados. Pense no Recovery, e não no Backup.

O RMAN – Recovery Manager (“Gerenciador de Recuperação”) - é a ferramenta recomendada pela Oracle para executar Backups dos bancos de dados gerenciados por seu principal produto, o Oracle Database, e existe desde a versão 8.0.3.

Não adianta fugir. Se você pretende administrar seriamente um banco de dados Oracle, terá que dominar esta ferramenta. E se pretende usar seriamente RMAN, deverá usar o modo ARCHIVELOG e um Catalog (“Catálogo”), como veremos mais adiante.

Outra razão para utilizar o RMAN é que ele é grátis. Se você pagou pelo Oracle, já pagou pelo RMAN. Para que então ter mais trabalho, ou tentar reinventar a roda?

Se você ainda considera outros métodos de Backup, veja as desvantagens em fazê-los sem o RMAN:

• Manual Cold Backup (“Cópia Manual a Frio”). É o Backup executado copiando-se todos os arquivos do banco de dados para outro local, com a instância desligada, via sistema operacional. Tem a seguinte desvantagem:

o Necessita que a instância seja desligada. Além do tempo de indisponibilidade do banco de dados durante o Backup, quando uma instância é religada, todo seu Caché está limpo, tanto de dados quanto de comandos SQL. Ou seja, todo o trabalho que o Oracle teve para ter uma boa performance de acordo com o uso do banco de dados é destruído.

• User Managed Backups (“Cópias Gerenciadas por Usuário”). É o backup executado copiando-se todos os datafiles (“arquivos de dados”) do banco de dados para outro local, utilizando-se os comandos BEGIN BACKUP e END BACKUP. Possui a seguinte desvantagem:

o Quando uma tablespace é colocada em modo BEGIN BACKUP, o Oracle grava blocos inteiros nos REDO LOGs, ao invés de apenas os vetores alterados. Isto pode fazer com que a geração de REDO durante o backup seja muito maior do que com Backups feitos por RMAN.

• Logical Backup (“Backup Lógico”): é o backup executado utilizado as ferramentas de exportação do Oracle - o exp (todas as versões) ou expdp (versão 10g ou superior). Possui as seguintes desvantagens:

o Não permite recuperação em um ponto do tempo determinado. Você só pode voltar para o momento onde o Backup foi feito;

o Como o processo de Recovery (utilizando as ferramentas de imp / impdp) praticamente reinsere os dados, o tempo será maior do que um Recovery via RMAN. Adicionalmente, ao término do processo de Logical Recovery, os índices são recriados, o que leva mais tempo ainda;

o Integridade: utilizando-se as opções padrão, um Logical Backup pode não ser íntegro, pois, como uma tabela é exportada em seguida da outra, um registro de uma tabela que depende de um registro de outra tabela via Foreign Keys (“Chave Estrangeira”) pode não existir mais, o que invalidará a recriação da Foreign Key ao término do processo de Recovery.

Além disso, os Backups executados com estas opções não podem ser registrados em um Catalog, o que inviabiliza várias funcionalidades, e torna mais difícil a administração de muitos bancos de dados. Além disso, obviamente, todas as funcionalidades do RMAN não poderão ser utilizadas.

O Catalog, em especial, é uma funcionalidade importante do RMAN. Várias funcionalidades do RMAN, como Stored Scripts, só podem ser utilizadas com um Catalog, como demonstraremos a seguir. Um banco de dados Oracle de produção deve utilizar um Catalog para registro de seus Backups.

Outro ponto importante a considerar é que você deve treinar os procedimentos de Recovery. Em situações de estresse, tendemos naturalmente a não considerar as opções com as quais não estamos familiarizados. E uma situação onde um Recovery é necessário geralmente é uma situação de estresse.

Se você é DBA, um dia você precisará fazer um Recovery. A questão não é SE você vai, e sim QUANDO você vai. Esteja preparado.

Mas reconheço que o RMAN não é uma ferramenta muito amigável, assim como o Oracle não é um banco muito amigável aos iniciantes. Mas isto está mudando.

Na versão 11g, foi introduzido o Data Recovery Advisor, que como outros Advisors que o Oracle já tem, procura auxiliar o DBA menos experiente a executar tarefas complexas, como um Recovery. Iremos, neste artigo, configurar o RMAN para executar Backups, e depois iremos simular uma situação onde um Recovery é necessário, e deixar o Data Recovery Advisor fazer este Recovery.

A versão 11g do Oracle trouxe várias melhorias ao RMAN, e embora não possamos explicar todas detalhadamente neste espaço, listamos todas a seguir, com uma pequena explicação:

RMAN 11gR1:

• Archive Log Management Improvements: garante que ARCHIVED REDO LOGs só são removidos quando não são mais necessários (por exemplo, para Data Guard – Nota DevMan 1 - , Streams, ou Flashback);

• Fast Incremental Backups on Physical Standby Database: Faz com que Backups que utilizam Block Change Tracking (Nota DevMan 2) possam ser feitos no Data Guard;

• Improved Backup Compression Performance: permite a utilização do algoritmo de compressão BZIP2, como demonstraremos neste artigo;

• Improved Integration with Data Guard: traz várias melhorias, como poder manter um backup só para o ambiente de produção e para o Data Guard;

• Network-Aware DUPLICATE Command: não é mais necessário ter um backup pronto para criar-se um clone de um banco de dados;

• Optimized Undo Backup: só é feito Backup do que é necessário de uma tablespace de UNDO, diminuindo seu tamanho total e tempo de execução;