Artigo SQL Magazine 61 - Oracle 11g New Features - Parte 3

Novidades na ferramenta Recovery Manager - RMAN

O Recovery Manager (RMAN) é a ferramenta da Oracle para gerenciamento e execução de todo o processo de backup e recovery. Esta ferramenta já esta disponível juntamente com a aquisição do próprio banco de dados, ou seja, sua empresa não precisará pagar nada a mais para utilizar a ferramenta.

Até a versão 9i, o RMAN possuía uma série de limitações que, em alguns casos, tornava o processo de backup um tanto quanto inviável, principalmente no tocante a gerenciamento de espaço ocupado pelo backup.

Mas isso já é passado. A partir da versão 10g, o RMAN ficou realmente muito poderoso e definitivamente uma opção bastante viável para diferentes situações encontradas nas empresas. Podemos citar como exemplo uma das empresas que prestamos serviço em que existe uma recomendação para que, qualquer banco de dados que já esteja na versão 10g deva ser utilizado o RMAN como ferramenta de backup e já os bancos de dados nas versões anteriores com tamanho acima de 1T (TeraByte) a recomendação ou melhor, definição, é que seja utilizada uma certa ferramenta de backup proprietária (e paga).

E se na versão 10g a ferramenta já se tornou muito confiável, imagine agora, com novas funcionalidades na versão 11g.

Novas funcionalidades de Backup e Recovery.

Nesta seção descreveremos algumas das novidades presentes na nova versão do RMAN:

Conselheiro de Recuperação de Dados (Data Recovery Advisor)

O Data Recovery Advisor é uma ferramenta para diagnosticar automaticamente falhas nos dados e recomendar os reparos. As falhas poderão ser reparadas manualmente, com base nas recomendações, ou você poderá pedir para que sejam reparadas automaticamente. O Data Recovery Advisor suporta os comandos LIST FAILURE para listar as falhas, CHANGE FAILURE para alterar a prioridade ou abrir/fechar uma falha, ADVISE FAILURE para recomendar a reparação das falhas e REPAIR FAILURE para efetivamente reparar as falhas. Este conselheiro é baseado no Health Check Monitor (visto na Parte 2 deste artigo).

Backup de tablespaces “transportáveis” somente-leitura (read-only transportable tablespaces)

Nas versões anteriores, o RMAN não era capaz de fazer o backup de transportable tablespaces até que elas fossem convertidas para leitura/escrita (read/write) no banco de dados de destino. Agora, na versão 11g, o RMAN já pode fazer o backup de transportable tablespaces mesmo em estado read-only e restaurar normalmente estes backups.

Melhorias de backup e recovery no Oracle Enterprise Manager

Agora, na versão 11g, o Oracle Enterprise Manager possui uma interface gráfica para o Data Recovery Advisor.

Backups em multi-seções

O RMAN pode agora efetuar o backup de um único arquivo do banco de dados (por exemplo) em paralelo, dividindo a tarefa em múltiplos canais. Cada canal fará o backup de uma seção (ou parte) do arquivo. Você poderá criar um backup multi-seção especificando a opção SECTION SIZE no comando de backup. Para restaurar um backup multi-seção não é necessário adicionar nenhuma opção ao comando, o processo é automático.

Pode-se ainda paralelizar a validação do arquivo através da opção VALIDATE ... SECTION SIZE.

Otimização de Undo

O comando BACKUP não efetua mais o backup de informações de Undo que não sejam mais necessárias para a recuperação deste backup. Uma informação de Undo não é mais necessária caso ela tenha sido gerada por uma transação que já foi efetivada (commit) e este tipo de informação representa a maior parte de informações de Undo de todo o banco de dados. É bom lembra que este tipo de comportamento passou a ser o comportamento padrão do RMAN na versão 11g do Oracle e não há como desabilitar.

Melhoria no desempenho de recuperação de blocos

Ao executar uma recuperação de bloco (Block Media Recovery), o RMAN automaticamente procura por flashback logs (Nota DevMan 1), caso estejam disponíveis, para o bloco em questão a ser recuperado antes de procurar pelo bloco no backup. Ao utilizar os blocos encontrados no flashback log, a recuperação terá o seu desempenho sensivelmente melhor.

Melhoria na detecção de corrupção de blocos

Vários componentes e utilitários de banco de dados, incluindo o RMAN, agora podem detectar uma corrupção de bloco e armazenar estas informações na view V$DATABASE_BLOCK_CORRUPTION.

Quando a recuperação da instância (instance recovery) detecta um bloco corrompido, automaticamente a informação é armazenada na view. O Oracle automaticamente atualiza esta view quando uma corrupção de bloco é detectada ou reparada. Finalmente, o comando VALIDATE foi melhorado com algumas novas opções como VALIDATE ... BLOCK e VALIDATE DATABASE.

Compressão de backup mais rápida

Além do algoritmo BZIP2 para compressão binária de backups, o RMAN agora suporta também o algoritmo ZLIB. Este algoritmo é executado mais rapidamente que o BZIP2, porém produz arquivos maiores. Você poderá utilizar o comando CONFIGURE COMPRESSION ALGORITHM para escolher entre o BZIP2 (padrão) e o ZLIB para os backups do RMAN. Perceba que a escolha será entre uma compressão maior porém mais lenta e uma compressão menor porém mais rápida.

Melhoria nos scripts do RMAN através da utilização de variáveis de substituição

Podemos agora criar arquivos de comandos do RMAN e armazená-los em scripts que aceitam entradas do usuário no momento da execução, por exemplo. Desta forma, scripts de backup do RMAN podem utilizar variáveis de substituição para tags, nomes de arquivos, nomes para pontos de restauração (restore point) e tudo o mais.

Backup failover para archived redo logs na flash recovery area

Ao executar o backup de archived redo log files (Nota DevMan 2) localizados na flash recovery area (Nota DevMan 3), o RMAN pode efetuar um failover (Nota DevMan 4) para armazenar os archived redo log files em um local fora da flash recovery area. O RMAN tem a capacidade de usar uma cópia que esteja perfeita de um archived redo log em um local alternativo para continuar “escrevendo” o backup caso o log esteja faltando ou corrompido na flash recovery area.

Melhoria na política de exclusão de Archived redo log

Quando você configura a política de exclusão de archived redo log, a configuração é aplicada a todos os destinos de armazenamento, inclusive a flashback recovery area. Ambos os comandos BACKUP ... DELETE INPUT e DELETE ... ARCHIVELOG obedecem esta configuração da mesma forma que a flashback recovery area. É possível também configurar uma política de exclusão de archived redo log de tal forma que o log esteja disponível para exclusão somente após ter sido aplicado ou transferido para um banco de dados em standby. A Listagem 1 mostra um exemplo de configuração.

Listagem 1. Configuração de política de exclusão de archived redo log.

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

Neste caso, mostrado na Listagem 1, a exclusão somente ocorrerá para os archived redo logs que tiverem sidos copiados 2 vezes (por exemplo em dois locais diferentes).

Melhorias na gestão de backups de longo prazo

Você poderá criar um backup de longo prazo ou “histórico” através do comando BACKUP ... KEEP, que irá reter apenas os archived redo logs necessários para manter o backup consistente.

Juntamente com este conceito ele traz a idéia de ponto de recuperação, que é basicamente uma recuperação do banco de dados em um ponto do tempo (database point in time recovery) que pode ser criado para garantir recuperações pontuais. Veja um exemplo de como efetuar este backup na Listagem 2.

Listagem 2. Efetuando um backup de longo prazo.

1.      RMAN> backup database format '/oracle/keep%u'

2.      2> tag before_patch_10203

3.      3> keep until time 'sysdate+3'

4.      4> restore point bef_patch_10203;

5.      Starting backup at 28-AUG-07

6.      current log archived

7.      using channel ORA_DISK_1

8.      backup will be obsolete on date 31-AUG-07

9.      archived logs required to recover from this backup will be backed up

10.  channel ORA_DISK_1: starting compressed full datafile backup set

11.  channel ORA_DISK_1: specifying datafile(s) in backup set

12.  ….

13.  piece handle=/oracle/keep2piqh08t tag=BEFORE_PATCH_10203 comment=NONE

14.  channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

15.  Finished backup at 28-AUG-07

16.  RMAN> list restore point all;

17.  SCN RSP Time Type Time Name

18.  ---------------- --------- ---------- --------- ----

19.  18443737 28-AUG-07 BEF_PATCH_10203

Basicamente, foi definido o formato do backup (linha 2 da Listagem 2), criado um rótulo (tag) para identificar o backup (linha 2), definida uma política de retenção do backup (linha 3) e finalmente definido o rótulo do ponto de restauração (linha 4).

Agora, a Listagem 3 mostra como fazer a recuperação do backup para este ponto de restauração.

Listagem 3. Recuperando o backup a um ponto de restauração.

RMAN> restore database to restore point 'BEF_PATCH_10203';

RMAN> recover database to restore point 'BEF_PATCH_10203';

Melhoria no catálogo (Recovery catalog)

O “dono” do catálogo do RMAN (recovery catalog) pode conceder ou revogar (GRANT ou REVOKE) acesso à parte do catálogo para outros usuários do banco de dados. Esta parte do catálogo é chamada de catálogo virtual privado (virtual private catalog). O comando IMPORT CATALOG pode ser usado para mesclar um catálogo (ou metadados para um banco de dados no catálogo) em outro.

Melhorias na integração com o Data Guard

Agora você pode criar configurações do RMAN para um banco primário ou standby físico mesmo quando o RMAN não está conectado como destino (target) para o banco de dados. O RMAN trabalha transparentemente em todos os bancos de dados de um ambiente em Data Guard (Nota DevMan 5), permitindo que você utilize um backup feito em um banco de dados para ser restaurado e recuperado em outro banco de dados. O mesmo recovery catalog pode gerenciar os metadados do banco de dados primário ou standby.