Recursos diversos do RMAN

Recursos diversos do RMAN

• Este resumo cobre 2 assuntos muito importantes: a duplicação de um banco de dados através do RMAN e também o TSPITR (Tablespace Point-in-time Recovery). Estes tópicos parecem não estar relacionados, mas eles têm um aspecto em comum: ambos precisam da criação de uma instância auxiliar para executar a tarefa solicitada. Após duplicar um banco de dados, o RMAN mantém a instância temporária e o banco de dados; ao contrário, no caso da TSPITR, o RMAN elimina a instância auxiliar após a operação de recovery.
• A maior parte da duplicação de um banco de dados usando o RMAN é automatizada, exceto em algumas etapas de configuração manuais. Essas etapas incluem tarefas como criar um arquivo de senhas, configurar a conectividade de rede, e criar um arquivo de parâmetros de inicialização baseado em texto contendo apenas alguns parâmetros obrigatórios, como o DB_NAME. A especificação de outros parâmetros de inicialização depende de você especificar explicitamente DB_BLOCK_SIZE no banco de dados de origem e do mapeamento de nome de caminho necessário para especificar corretamente as localizações dos datafiles, controlfiles, e redo log files. Usar o Enterprise Manager para duplicar um banco de dados é um método mais fácil, mas talvez não propicie a personalização disponível com o uso dos comandos de linha de comando do RMAN e SQL.
• A segunda metade do capítulo abordou a TSPITR. Estão disponíveis diversas técnicas de recuperação. A técnica a ser aplicada vai depender do tipo de dano ocorrido no banco de dados. Se esse dano estiver limitado às tabelas de um único tablespace com pouca ou nenhuma dependência com objetos de outros, a TSPITR provavelmente será sua melhor opção. Além disso, o banco de dados e todos os outros tablespaces continuam disponíveis para os usuários durante a operação da TSPITR.

Criar um banco de dados duplicado no RMAN

• Quando você duplica um banco de dados, o banco de dados de origem é copiado para o banco de dados duplicado.
• O banco de dados de origem também é conhecido como banco de dados target.
• O banco de dados duplicado também é conhecido como banco de dados auxiliar.
• A preparação para criar um banco de dados duplicado inclui a criação de um arquivo de senhas, a verificação da conectividade da rede e a criação do arquivo de parâmetros de inicialização para a instância auxiliar.
• Você deve, no mínimo, especificar o parâmetro DB_NAME no arquivo de parâmetros inicialização da instância auxiliar. Especifique também o parâmetro DB_DLOCK_SIZE se ele estiver definido explicitamente no banco de dados de destino.
• O parâmetro de inicialização DB_FILE_NAME_CONVERT especifica o mapeamento do sistema de arquivos para nomes de datafiles e arquivos temporários.
• O parâmetro de inicialização LOG_FILE_NAME_CONVERT especifica o mapeamento do sistema de arquivos para os redo log files.
• O parâmetro CONTROL_FILES especifica os novos nomes para todos os controlfiles, a menos que você esteja utilizando OMF’s (Oracle Managed Files), uma vez que o OMF nomeará os arquivos para você.
• O comando do RMAN para executar a duplicação do database é DUPLICATE TARGET DATABASE.
• É possível especificar FROM ACTIVE DATABASE no comando DUPLICATE para criar a cópia a partir de um banco de dados online, em vez de um backup de banco de dados.
• O banco de dados duplicado tem um novo DBID, mesmo que ele tenha o mesmo nome do banco de dados de origem.

Usar um banco de dados duplicado

• Um banco de dados duplicado pode ser utilizado para testar os procedimentos de backup e recovery, sem afetar a disponibilidade do banco de dados de origem.
• Você pode usar um banco de dados duplicado para testar um upgrade do banco de dados ou o desempenho de upgrades dos aplicativos.
• Você pode exportar uma ou mais tabelas de um banco de dados duplicado e importar novamente no banco de dados de produção como um método de recovery secundário.

Identificar as situações que exigem TSPITR

• O TSPITR é útil quando uma ou mais tabelas danificadas ou ausentes são isoladas em um único tablespace e têm dependências mínimas ou nenhuma dependência com objetos existentes em outros tablespaces.
• Você pode utilizar o TSPITR quando as mudanças por DDL impedirem o uso de Flashback Table para recuperar os objetos.
• Não é possível utilizar a TSPITR para recuperar um tablespace eliminado ou recuperar um tablespace renomeado até um ponto no tempo anterior à sua renomeação.

Fazer uma TSPITR automatizada

• O Target Time é o ponto no tempo até o qual o tablespace será recuperado.
• O Recovery Set é um grupo de datafiles contendo os tablespaces a serem recuperados.
• O conjunto auxiliar é um conjunto de outros datafiles necessários para recuperar aqueles contidos no Recovery Set, como o tablespace SYSTEM.
• O destino auxiliar é uma área de trabalho temporária usada pelo RMAN para armazenar conjuntos auxiliares de arquivos, arquivos de log e uma cópia do controlfile.
• O RMAN elimina a instância auxiliar e exclui todos os arquivos auxiliares por ocasião do término da TSPITR.
• Use a view do dicionário de dados TS_PITR_CHECK para descobrir as dependências existentes entre os objetos contidos no tablespace a ser recuperado e os objetos em outros tablespaces.
• Use a view do dicionário de dados TS_PITR_OBJECTS_TO_BE_DROPPED para conhecer os objetos que você perderá após a TSPITR.
• Execute uma TSPITR no RMAN usando o comando RECOVER TABLESPACE com as cláusulas UNTIL TIME e AUXILIARY DESTINATION.
• Após o término da TSPITR, você deve fazer o backup do tablespace recuperado e restaurá-lo online.