Atenção: esse artigo tem uma palestra complementar. Clique e assista!
De que trata o artigo?
O artigo trata das novas funcionalidades da ferramenta de backup da Oracle, o RMAN (Recovery Manager), em sua versão 11g. Trata também de como utilizar algumas das funcionalidades para efetuar backup e recovery em caso de falha do banco de dados.
Para que serve?
O RMAN (Recovery Manager) é a ferramenta Oracle, parte integrante do banco de dados, que permite a execução de backups do banco de dados Oracle e, principalmente, a recuperação de dados em caso de falha do banco de dados. Este artigo serve para que o leitor tenha conhecimento das principais características da ferramenta e seja capaz de efetuar backups e recuperação em bases de dados de sua responsabilidade.
Em que situação o tema é útil?
Em casos de administradores de bancos de dados que queiram garantir a disponibilidade de dados, executando seus backups com o RMAN 11g. 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.
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);
Oracle Data Guard garante alta disponibilidade, proteção dos dados e recuperação de dados em caso de desastre.
Data Guard fornece um conjunto abrangente de serviços para criar, manter, gerenciar e monitorar um ou mais bancos de dados em standby para permitir que bancos de dados de produção sobrevivam a desastres e corrupção de dados.
Data Guard mantém esses bancos de dados standby como cópias do banco de dados de produção. Com isso, se os dados de produção ficarem indisponíveis por uma parada planejada ou não planejada, o Data Guard pode mudar qualquer banco em standby para o papel de produção, minimizando o tempo de inatividade associado a interrupção.
• 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;
Uma opção do banco de dados que faz com que o Oracle rastreie os blocos afetados por cada atualização de banco de dados.
As informações de rastreamento são armazenadas em um arquivo de rastreamento chamado Change Tracking File.
Quando o Block Change Tracking está habilitado, o RMAN usa o registro de blocos alterados a partir do Change Tracking File para melhorar o desempenho de backups incrementais somente lendo as informações dos blocos que foram alterados, ao invés de ler todo o datafile.
• 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;
...
