Aula 22: Backup e Recovery — RMAN, Data Pump Export e Import

Em qualquer ambiente de banco de dados corporativo, a integridade e a disponibilidade dos dados são os ativos mais críticos que existem. Não importa se você administra uma base de produção que suporta uma aplicação financeira, um e-commerce com milhares de transações por minuto ou um data warehouse analítico: sem uma estratégia sólida de Backup e Recovery, sua operação está a um passo do desastre. Nesta aula avançada do curso “Oracle SQL — Do Zero ao Avançado”, você vai dominar as duas principais ferramentas que todo DBA Oracle utiliza diariamente para proteger dados: o RMAN (Recovery Manager), dedicado a backups físicos em nível de bloco, e o Data Pump Export/Import, voltado para backups lógicos, migrações e transferências de esquemas ou tabelas específicas. Esta é uma das aulas mais densas e importantes do curso, pois conecta o conhecimento teórico de SQL com a operação real de administração de banco de dados.

Ao longo deste conteúdo, você não apenas verá a teoria por trás de cada mecanismo, mas também executará, passo a passo, procedimentos completos e funcionais. Vamos configurar o RMAN do zero, definir parâmetros de retenção e automação, gerar um backup físico completo, simular uma falha e executar um processo de restore e recovery. Na parte de Data Pump, você aprenderá a criar diretórios lógicos, exportar schemas inteiros, excluir objetos específicos, importar dados com remapeamento de tablespace e muito mais. Cada comando será explicado linha por linha, com sua finalidade, opções utilizadas e, quando relevante, a saída esperada no terminal.

Os pré-requisitos desta aula são: acesso a uma instância Oracle Database 19c ou superior já instalada e operacional, preferencialmente em Linux (RHEL, CentOS, Rocky Linux ou Oracle Linux), conhecimento intermediário de SQL e arquitetura Oracle (tablespaces, datafiles, control files, redo logs, arquivos de archive), e permissões de administrador (SYSDBA) para executar comandos de backup e recovery. Se você já concluiu as aulas anteriores do curso, especialmente aquelas sobre arquitetura física e estruturas de armazenamento, está mais do que preparado para avançar. Caso não tenha uma instância disponível, é possível utilizar uma máquina virtual ou um ambiente de testes temporário para reproduzir os procedimentos com segurança, desde que não sejam executados em produção sem planejamento prévio.

Ao concluir esta aula, você será capaz de planejar uma estratégia completa de Backup e Recovery, escolher corretamente entre backup físico e lógico para cada cenário, realizar backups consistentes e inconsistentes com o RMAN, restaurar a base após falhas de mídia, extrair e carregar dados com Data Pump de forma eficiente e segura, além de diagnosticar e corrigir os erros mais comuns que um DBA encontra no dia a dia. Em nossos projetos na JRT Technology Solutions, utilizamos estes mesmos procedimentos diariamente em clientes de grande porte, e nossa equipe de especialistas já enfrentou praticamente todos os cenários de falha abordados aqui. A experiência prática que vamos compartilhar é exatamente a mesma que aplicamos em ambientes de missão crítica — adaptada, claro, para que você possa executá-la em um ambiente de laboratório com total controle.

Prepare-se para uma aula intensa e repleta de execução prática. Recomendamos fortemente que você não apenas leia, mas execute cada comando em seu próprio ambiente. Mantenha um caderno de anotações com os eventos, erros e soluções encontrados, pois isso vai acelerar sua curva de aprendizado. Vamos começar pelos fundamentos conceituais e, em seguida, mergulhar nos procedimentos reais de backup físico e lógico. Ao final, você terá uma visão completa e operacional de como proteger seus dados Oracle de forma profissional.

O que você vai aprender nesta aula

Esta aula foi cuidadosamente estruturada para entregar um conhecimento progressivo, partindo da base teórica até a execução avançada de procedimentos de Backup e Recovery. Abaixo está a lista completa dos objetivos de aprendizagem que você dominará ao final do conteúdo:

• Compreender a diferença entre backups físicos e lógicos, e quando aplicar cada abordagem na estratégia de proteção de dados Oracle.
• Configurar o RMAN com parâmetros de canal, autobackup de controlfile, política de retenção e otimização.
• Executar um backup completo e consistente da base de dados, incluindo archivelogs e controlfile, com comandos detalhados.
• Executar um processo completo de restore e recovery após simular perda de um ou mais datafiles.
• Utilizar o Data Pump Export (expdp) para exportar schemas, tabelas e objetos específicos com filtros avançados.
• Utilizar o Data Pump Import (impdp) para importar dados, remapear tablespaces, transformar objetos e lidar com dependências.
• Criar e configurar diretórios lógicos do Oracle para hospedar arquivos de dump em locais controlados.
• Verificar a integridade dos backups e a configuração do ambiente após cada procedimento crítico.
• Diagnosticar e corrigir pelo menos cinco erros comuns em rotinas de backup e recuperação.
• Aplicar boas práticas de automação, retenção e validação de backups em ambientes de produção.

Pré-requisitos e Ambiente

Antes de iniciar a execução dos procedimentos desta aula, é essencial que seu ambiente esteja devidamente preparado e validado. Você precisará de uma instância Oracle Database 19c ou superior em funcionamento, com o parâmetro ARCHIVELOG habilitado — explicaremos o porquê nas próximas seções. O acesso ao servidor deve ser feito com o usuário oracle (ou outro proprietário do software Oracle) no sistema operacional, e você deve possuir credenciais com privilégio SYSDBA para conectar-se ao banco via sqlplus e RMAN. Se você ainda não habilitou o modo ARCHIVELOG, faremos a configuração durante a aula, pois backups online consistentes dependem desse recurso.

Em relação ao sistema operacional, nossas instruções de linha de comando são apresentadas para ambientes Linux, especificamente RHEL/CentOS/Rocky Linux e Oracle Linux, que são as distribuições mais comuns para servidores Oracle. Para essas plataformas, os caminhos padrão de instalação do Oracle são normalmente /u01/app/oracle/product/19.0.0/dbhome_1 e o arquivo de variáveis de ambiente fica em /etc/oratab ou no perfil do usuário. Se você estiver utilizando Ubuntu/Debian, os conceitos e comandos Oracle são idênticos — apenas os diretórios de instalação e os comandos de gestão de serviços podem variar, como systemctl versus service. Ao longo da aula, destacaremos essas diferenças quando aplicável.

Outro pré-requisito importante é espaço em disco. Backups físicos com RMAN podem consumir uma quantidade significativa de armazenamento, equivalente ao tamanho total da base de dados mais os archivelogs. Recomendamos pelo menos 1,5 a 2 vezes o tamanho da base para testes confortáveis. Verifique também se as variáveis de ambiente ORACLE_HOME e ORACLE_SID estão corretamente definidas, pois o RMAN e o Data Pump dependem delas para localizar os binários e a instância alvo. Por fim, certifique-se de ter um diretório dedicado para os arquivos de backup, como /u01/app/oracle/backup, com permissões adequadas para o usuário oracle.

Para esta aula, utilizaremos um ambiente hipotético com os seguintes identificadores: banco de dados ORCLPDB1 (plugable database) no CDB ORCLCDB, usuário de teste chamado hr com tabelas no schema HR, e diretórios de backup localizados em /u01/app/oracle/backup. Você pode adaptar esses nomes para a realidade do seu ambiente. Em nossos projetos na JRT Technology Solutions, padronizamos a configuração dos ambientes dos clientes antes de qualquer intervenção de backup, garantindo que todas as variáveis estejam documentadas e os caminhos sejam consistentes. Este é um passo que evita erros simples, mas potencialmente desastrosos, como apontar um backup para um diretório sem permissão ou com espaço insuficiente.

Antes de prosseguir, execute os comandos básicos de verificação abaixo no seu servidor para confirmar que o ambiente está pronto. Estes comandos são executados no shell do Linux, não dentro do SQL*Plus:

# Verificar o usuário atual (deve ser oracle ou dono do software Oracle)
whoami

# Verificar as variáveis de ambiente do Oracle
echo $ORACLE_HOME
echo $ORACLE_SID

# Verificar espaço em disco no diretório de backup
df -h /u01/app/oracle/backup

# Listar os serviços Oracle em execução (RHEL/CentOS/Oracle Linux)
systemctl status oracle

# Em Ubuntu/Debian, o serviço pode ser verificado com:
service oracle status

oracle
/u01/app/oracle/product/19.0.0/dbhome_1
ORCLCDB
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       200G   80G  120G  40% /u01
● oracle.service - LSB: Start and stop Oracle Database
   Loaded: loaded (/etc/init.d/oracle)
   Active: active (running) since Thu 2026-09-03 08:30:15 UTC; 2h 05min ago

Com o ambiente validado, estamos prontos para avançar para os fundamentos conceituais. Não pule essa etapa, pois ela embasa todas as decisões que você tomará ao escolher entre RMAN e Data Pump, bem como na definição dos parâmetros de backup.

Fundamentos de Backup e Recovery: Físico vs. Lógico, RMAN vs. Data Pump

O Oracle Database suporta duas grandes categorias de backup: os físicos e os lógicos. Um backup físico consiste na cópia bit a bit dos arquivos que compõem a base de dados — datafiles, control files, redo logs e, quando habilitado, archivelogs. Esse tipo de backup é feito em nível de bloco do sistema operacional e é exatamente o que o RMAN (Recovery Manager) automatiza e gerencia. Já um backup lógico extrai o conteúdo dos objetos — como tabelas, índices, procedures e packages — na forma de comandos SQL e dados, produzindo arquivos de dump que podem ser importados posteriormente. O Data Pump Export (expdp) e o Data Pump Import (impdp) são as ferramentas nativas do Oracle para backups lógicos, substituindo os antigos exp e imp desde a versão 10g.

A diferença fundamental entre essas abordagens está no nível de recuperação e na flexibilidade de uso. O RMAN é a única ferramenta capaz de realizar um backup consistente da base inteira enquanto ela está online, utilizando o ARCHIVELOG para registrar todas as mudanças e permitir recuperação até um ponto no tempo (PITR). Com RMAN, você pode restaurar a base para o estado exato em que estava segundos antes de uma falha, recuperando transações não commitadas a partir dos redo logs. Isso é essencial para estratégias de disaster recovery e para cumprir acordos de nível de serviço (SLA) com RPO (Recovery Point Objective) próximo de zero. Em nossos projetos na JRT Technology Solutions, sempre configuramos o RMAN como a espinha dorsal das políticas de backup de produção, complementado por rotinas de Data Pump para extrações lógicas pontuais.

O Data Pump, por outro lado, brilha em cenários de migração de schemas, refresh de ambientes de teste, transferência de objetos específicos entre bancos e extração de dados para análise. Ele não trabalha em nível de bloco, mas sim no nível lógico de objetos, o que significa que você pode exportar apenas uma tabela, um conjunto de tabelas com cláusula WHERE, um schema inteiro ou mesmo a base inteira, com metadados completos. O Data Pump é extremamente eficiente em comparação com os antigos exp/imp, pois utiliza job master/worker e pode executar em paralelo, com compressão e encriptação. No entanto, ele não substitui o RMAN para recuperação física completa, pois não captura a estrutura de blocos dos datafiles nem registra as mudanças transacionais no mesmo nível que o RMAN faz.

A tabela abaixo resume as principais diferenças entre RMAN e Data Pump, ajudando você a decidir qual ferramenta utilizar em cada situação:

Outro ponto essencial para entender o RMAN é o papel do catalog e do controlfile como repositório de metadados de backup. Por padrão, o RMAN armazena todas as informações sobre backups realizados no controlfile do banco, incluindo nomes de arquivos, timestamps, sequências de archivelogs e checksums. Isso permite que o RMAN saiba exatamente quais peças compõem cada backup e como montá-las durante uma restauração. O controlfile é atualizado automaticamente a cada backup e, para maior segurança, é altamente recomendável configurar o CONTROLFILE AUTOBACKUP, que cria uma cópia separada do controlfile a cada backup. Alternativamente, você pode utilizar um RMAN Catalog, que é um schema dedicado em outro banco de dados para armazenar esses metadados de forma centralizada e histórica, ideal para ambientes com múltiplas bases.

Já o Data Pump, por sua vez, opera com uma arquitetura baseada em diretórios lógicos do Oracle. Antes de executar qualquer export ou import, você precisa criar um objeto DIRECTORY no banco apontando para um diretório físico no sistema operacional, e conceder permissões de leitura/escrita sobre esse objeto ao usuário que executará o job. O Data Pump gera arquivos de dump com extensão .dmp e arquivos de log .log. Esses arquivos são gravados no diretório físico associado ao objeto DIRECTORY. Compreender essa separação entre o nome lógico (no Oracle) e o caminho físico (no sistema) é fundamental para evitar um dos erros mais comuns: ORA-39002, que discutiremos na seção de erros.

Configuração Inicial do RMAN: Parâmetros e Repositório

Antes de executar o primeiro backup com o RMAN, é necessário configurar alguns parâmetros essenciais que controlam como os backups serão gravados, retidos e protegidos. O RMAN mantém essas configurações persistentes em seu repositório (no controlfile ou no catálogo, se configurado), e elas podem ser consultadas a qualquer momento com o comando SHOW ALL. Ajustar esses parâmetros corretamente desde o início evita retrabalho e garante que suas rotinas de backup sigam políticas consistentes. Em nossos projetos na JRT Technology Solutions, padronizamos a configuração inicial do RMAN como um checklist obrigatório antes de colocar qualquer banco em produção.

O primeiro parâmetro que recomendamos configurar é o DEVICE TYPE DISK, que define o tipo de mídia de armazenamento dos backups. Para ambientes de laboratório e pequenos servidores, o armazenamento em disco é o padrão. Também definimos o CONTROLFILE AUTOBACKUP como ON, garantindo que, a cada backup, uma cópia independente do controlfile seja gerada. Essa cópia é vital para a recuperação em cenários de perda total, pois sem o controlfile não é possível montar a base para restaurar os datafiles. Outra configuração importante é o CONTROLFILE AUTOBACKUP FORMAT, que especifica o padrão de nomeação dos arquivos de autobackup. Recomendamos usar um caminho fixo com variáveis como %F, que garante nomes únicos.

A política de retenção é outro pilar da configuração. O parâmetro CONFIGURE RETENTION POLICY define quantos backups serão mantidos antes de serem considerados obsoletos. Existem duas abordagens principais: REDUNDANCY, que define um número fixo de cópias (por exemplo, manter as últimas 3), e RECOVERY WINDOW, que define um período no tempo (por exemplo, manter backups suficientes para recuperar qualquer ponto nos últimos 7 dias). A escolha depende do requisito de RPO e do espaço em disco disponível. Para ambientes de teste, a redundância de 2 cópias já é suficiente; para produção, geralmente configuramos uma janela de recuperação de 7 a 14 dias, dependendo do SLA.

Para executar a configuração inicial, abra um terminal como usuário oracle, defina as variáveis de ambiente e inicie o RMAN apontando para o banco alvo com privilégio SYSDBA. Em sistemas RHEL/CentOS/Oracle Linux, o binário do RMAN fica em $ORACLE_HOME/bin/rman. No Ubuntu/Debian, o caminho é o mesmo, porém a instalação pode estar em diretórios como /opt/oracle. Vamos executar os seguintes comandos:

# Definir variáveis de ambiente (RHEL/CentOS/Oracle Linux)
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_SID=ORCLCDB
export PATH=$ORACLE_HOME/bin:$PATH

# Iniciar o RMAN conectando-se ao banco alvo
rman target /

# Dentro do prompt RMAN, executar as configurações:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/%U';
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/app/oracle/backup/autobackup_%F';
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
SHOW ALL;

using target database control file instead of recovery catalog
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/%U';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/%U';
new RMAN configuration parameters are successfully stored

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/app/oracle/backup/autobackup_%F';
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/app/oracle/backup/autobackup_%F';
new RMAN configuration parameters are successfully stored

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters are successfully stored

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters:
CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters are successfully stored

RMAN> SHOW ALL;

Ánalise linha por linha o que cada comando executou. CONFIGURE DEVICE TYPE DISK PARALLELISM 2 define que os backups em disco utilizarão dois canais paralelos, acelerando a leitura dos datafiles. A opção BACKUP TYPE TO COMPRESSED BACKUPSET é ativada automaticamente quando o paralelismo é configurado em algumas versões — se não for desejada, você pode definir CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET. O comando CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/u01/app/oracle/backup/%U’ define o formato padrão dos nomes dos arquivos de backup: a variável %U gera um nome único para cada backup piece, evitando colisões. O CONTROLFILE AUTOBACKUP ON habilita o backup automático do controlfile e do spfile após cada operação de backup estrutural. O formato autobackup_%F usa a variável %F, que combina DBID, timestamp e sequência, resultando em nomes exclusivos e facilmente rastreáveis.

A política de retenção com RECOVERY WINDOW OF 7 DAYS instrui o RMAN a manter todos os backups e archivelogs necessários para permitir a recuperação até qualquer ponto nos últimos sete dias. Backups fora dessa janela são marcados como obsoletos e podem ser removidos com DELETE OBSOLETE. Por fim, BACKUP OPTIMIZATION ON faz com que o RMAN pule a cópia de arquivos que já foram incluídos em backups anteriores e não sofreram alterações, economizando espaço e tempo. Se você estiver usando um catálogo RMAN externo, o comando de conexão seria rman target / catalog rman_cat/password@catalog_db; no nosso laboratório, o CONTROLFILE local é suficiente e recomendado para cenários de base única.

Passo a Passo: Backup Completo Físico com RMAN

Agora que o RMAN está configurado, vamos executar o primeiro backup físico completo da base de dados. Este procedimento é o coração de qualquer estratégia de Backup e Recovery e deve ser executado regularmente em produção. O comando que utilizaremos é BACKUP DATABASE PLUS ARCHIVELOG, que combina três operações: backup dos datafiles, backup dos archivelogs gerados durante o processo e backup do controlfile e spfile (se CONTROLFILE AUTOBACKUP estiver habilitado). Esse comando garante que o backup seja consistente mesmo com a base online, pois os archivelogs capturam as transações ocorridas durante a cópia dos datafiles.

Antes de executar o backup, é importante confirmar que o banco está em modo ARCHIVELOG. Esse modo garante que os redo logs preenchidos sejam arquivados antes de serem sobrescritos, permitindo a aplicação de mudanças nos datafiles restaurados até um ponto consistente. Sem o ARCHIVELOG, backups online não são possíveis de forma consistente — apenas backups offline (com a base desligada). Para verificar e, se necessário, habilitar, siga os passos abaixo:

1. Conecte-se ao banco com sqlplus / as sysdba.
2. Execute SELECT log_mode FROM v$database; — o resultado deve ser ARCHIVELOG.
3. Se estiver NOARCHIVELOG, será necessário desligar a base limpa (SHUTDOWN IMMEDIATE), montar (STARTUP MOUNT), executar ALTER DATABASE ARCHIVELOG;, e abrir (ALTER DATABASE OPEN;).
4. Verifique novamente o modo de log.

No nosso ambiente, assumiremos que o ARCHIVELOG já está habilitado, pois é um pré-requisito desta aula. Vamos executar o backup completo. O comando BACKUP DATABASE PLUS ARCHIVELOG realiza, na ordem: backup dos archivelogs existentes, backup dos datafiles, backup dos archivelogs gerados durante o backup dos datafiles, e backup do controlfile/spfile automaticamente. Esse fluxo elimina a necessidade de comandos separados e garante a consistência total. Vamos executar e analisar a saída:

# Ainda no prompt do RMAN
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
LIST BACKUP SUMMARY;

Starting backup at 03-SEP-26
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=22 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=120 RECID=118 STAMP=1192546213
input archived log thread=1 sequence=121 RECID=119 STAMP=1192546301
channel ORA_DISK_1: starting piece 1 at 03-SEP-26
channel ORA_DISK_1: finished piece 1 at 03-SEP-26
piece handle=/u01/app/oracle/backup/0r5d7k2v_1_1 tag=TAG20260903T093012 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
deleted archived log
archived log file name=/u01/app/oracle/fast_recovery_area/ORCLCDB/archivelog/2026_09_03/o1_mf_1_120_lp7x2y0g_.arc RECID=118 STAMP=1192546213
deleted archived log
archived log file name=/u01/app/oracle/fast_recovery_area/ORCLCDB/archivelog/2026_09_03/o1_mf_1_121_lp7y4h0t_.arc RECID=119 STAMP=1192546301
channel ORA_DISK_1: starting datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/ORCLCDB/system01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/ORCLCDB/sysaux01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/ORCLCDB/undotbs01.dbf
input datafile file number=00007 name=/u01/app/oracle/oradata/ORCLCDB/users01.dbf
channel ORA_DISK_1: starting piece 1 at 03-SEP-26
channel ORA_DISK_2: starting datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00009 name=/u01/app/oracle/oradata/ORCLCDB/pdbseed/system01.dbf
input datafile file number=00010 name=/u01/app/oracle/oradata/ORCLCDB/pdbseed/sysaux01.dbf
channel ORA_DISK_2: starting piece 1 at 03-SEP-26
channel ORA_DISK_1: finished piece 1 at 03-SEP-26
piece handle=/u01/app/oracle/backup/0s5d7k31_1_1 tag=TAG20260903T093027 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:35
channel ORA_DISK_2: finished piece 1 at 03-SEP-26
piece handle=/u01/app/oracle/backup/0t5d7k31_1_1 tag=TAG20260903T093027 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:38
starting full resync of recovery catalog
full resync complete
Finished backup at 03-SEP-26

Starting Control File and SPFILE Autobackup at 03-SEP-26
piece handle=/u01/app/oracle/backup/autobackup_c-1234567890-20260903-00 comment=NONE
Finished Control File and SPFILE Autobackup at 03-SEP-26

Observe na saída o uso dos canais paralelos ORA_DISK_1 e ORA_DISK_2, cada um copiando datafiles diferentes simultaneamente, o que acelera o processo. O comando DELETE INPUT após PLUS ARCHIVELOG remove os archivelogs que foram copiados para o backup, evitando consumo desnecessário de espaço na área de archivelog. No entanto, em produção, é comum manter os archivelogs por um período para recuperações rápidas; por isso, muitos DBAs omitem o DELETE INPUT e gerenciam a retenção separadamente. O autobackup do controlfile e spfile foi gerado automaticamente ao final, como configurado anteriormente. Para confirmar que o backup foi registrado corretamente, o comando LIST BACKUP SUMMARY exibe um resumo de todos os backups existentes.

Uma variação importante é o backup incremental, que copia apenas os blocos alterados desde o último backup. Isso reduz drasticamente o tempo e o espaço necessário em bases grandes. O RMAN suporta INCREMENTAL LEVEL 0 (equivalente a um backup completo, mas que serve como base para incrementais) e INCREMENTAL LEVEL 1 (copia apenas blocos alterados desde o último nível 0 ou nível 1 cumulativo/diferencial). A implementação de estratégias incrementais é um tópico avançado que abordaremos nas boas práticas, mas o comando básico seria BACKUP INCREMENTAL LEVEL 0 DATABASE;. Para esta aula, o backup completo com archivelogs é suficiente para demonstrar o ciclo completo de Backup e Recovery.

Após a conclusão do backup, recomendamos validar a integridade do backup com o comando VALIDATE BACKUP ou RESTORE DATABASE VALIDATE. Esse comando verifica se os backup pieces estão íntegros e se podem ser restaurados, sem realmente restaurar os arquivos. Isso é uma etapa crítica de verificação que muitos DBAs ignoram até precisarem do backup em uma emergência. Execute RESTORE DATABASE VALIDATE; e observe se não há erros. Se a validação retornar sucesso, seu backup físico está pronto para uso.

Passo a Passo: Restore e Recovery com RMAN

A verdadeira prova de uma estratégia de Backup e Recovery é a capacidade de restaurar os dados após uma falha. Nesta seção, vamos simular um cenário de perda de um datafile e executar o processo completo de restore (restauração física dos arquivos) e recovery (aplicação das mudanças registradas nos archivelogs e redo logs) para trazer o banco de volta ao estado consistente. Esse procedimento é frequentemente chamado de complete recovery, pois recupera o banco até o momento atual, sem perda de transações confirmadas.

Para simular a falha, vamos identificar um datafile não essencial e removê-lo do sistema operacional. Em um ambiente de laboratório, recomendamos usar o tablespace USERS para este teste, pois ele geralmente contém dados de usuários e é menor que os tablespaces SYSTEM ou SYSAUX. Antes de remover o arquivo, certifique-se de que ele está listado na visão DBA_DATA_FILES e anote o caminho completo. Em nosso ambiente hipotético, o arquivo é /u01/app/oracle/oradata/ORCLCDB/users01.dbf. O teste deve ser feito com extremo cuidado e nunca em produção.

1. Conecte-se ao SQL*Plus como SYSDBA e consulte os datafiles: SELECT file_id, file_name, tablespace_name FROM dba_data_files;
2. Copie o arquivo para um local seguro (backup manual) antes de removê-lo, por precaução: cp /u01/app/oracle/oradata/ORCLCDB/users01.dbf /tmp/users01.dbf.bak
3. Remova o arquivo original: rm /u01/app/oracle/oradata/ORCLCDB/users01.dbf
4. Tente acessar uma consulta que leia dados desse tablespace — a instância pode reportar ORA-01116 ou ORA-01110 indicando falha no arquivo.
5. Inicie o RMAN e execute o restore e recovery.

Com o arquivo removido, o banco continua operando para objetos que não dependem desse datafile, mas qualquer acesso aos dados do tablespace USERS resultará em erro. Agora vamos executar o processo de recuperação. No prompt do RMAN, execute:

# Conectando ao RMAN
rman target /

# Dentro do RMAN, executar os comandos:
RUN {
  SQL 'ALTER TABLESPACE USERS OFFLINE IMMEDIATE';
  RESTORE TABLESPACE USERS;
  RECOVER TABLESPACE USERS;
  SQL 'ALTER TABLESPACE USERS ONLINE';
}

Starting restore at 03-SEP-26
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=25 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=26 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/oradata/ORCLCDB/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/0s5d7k31_1_1
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/0s5d7k31_1_1 tag=TAG20260903T093027
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:12
Finished restore at 03-SEP-26

Starting recover at 03-SEP-26
using channel ORA_DISK_1
using channel ORA_DISK_2

starting media recovery
archived log for thread 1 with sequence 121 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCLCDB/archivelog/2026_09_03/o1_mf_1_121_lp7y4h0t_.arc
archived log for thread 1 with sequence 122 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCLCDB/archivelog/2026_09_03/o1_mf_1_122_lp7y5k2z_.arc
media recovery complete, elapsed time: 00:00:03
Finished recover at 03-SEP-26

Statement processed

O comando RUN { … } agrupa múltiplos comandos em um bloco atômico para execução sequencial no RMAN. Primeiro, colocamos o tablespace USERS offline immediate para que o Oracle não tente escrever nele durante o processo. Em seguida, RESTORE TABLESPACE USERS copia os datafiles do backup de volta ao destino original. Finalmente, RECOVER TABLESPACE USERS aplica os archivelogs para sincronizar o arquivo restaurado ao estado mais recente possível. Após a recuperação, colocamos o tablespace online novamente. Neste cenário, como todos os archivelogs necessários estavam disponíveis no disco, o recovery foi complete e não houve perda de dados.

Para um cenário de perda mais severa, como a falha de todo o datafile SYSTEM ou até mesmo do controlfile, o processo é semelhante, mas exige que o banco esteja em estado NOMOUNT ou MOUNT para restaurar o controlfile antes dos datafiles. Nesses casos, o RMAN pode ser iniciado a partir de um backup do controlfile usando RESTORE CONTROLFILE FROM AUTOBACKUP e depois RESTORE DATABASE e RECOVER DATABASE. Essas variações são essenciais para o exame de certificação e para a rotina de DBAs sêniores. Em nossos projetos na JRT Technology Solutions, realizamos testes periódicos de restore em ambientes de homologação para garantir que os procedimentos documentados realmente funcionam quando necessários — uma prática que recomendamos fortemente.

Após o restore, valide a integridade do tablespace recuperado consultando a visão DBA_TABLESPACES e executando uma consulta em uma tabela do schema de teste. Se a consulta retornar dados sem erros, o processo foi bem-sucedido. Esta é a essência do backup físico: a capacidade de recuperar dados após falhas de mídia. Lembre-se de que o RMAN também suporta point-in-time recovery (PITR) com a cláusula UNTIL TIME ou UNTIL SCN, permitindo voltar o banco para um estado anterior a um erro lógico (como um DROP TABLE acidental) — esse será um tópico avançado na seção de boas práticas.

Passo a Passo: Data Pump Export e Import

Enquanto o RMAN protege contra falhas físicas, o Data Pump é a ferramenta definitiva para movimentação lógica de dados. Com ele, você pode exportar schemas completos, tabelas específicas, metadados de procedimentos ou até mesmo a base inteira para arquivos de dump portáteis, e importá-los em outro banco Oracle, na mesma ou em outra versão. O Data Pump substitui o antigo exp/imp com vantagens significativas de desempenho, paralelismo, compressão e encriptação. Os binários são expdp para exportação e impdp para importação, ambos localizados em $ORACLE_HOME/bin.

Antes de executar qualquer job do Data Pump, é obrigatório criar um objeto DIRECTORY no Oracle apontando para um caminho físico no sistema operacional, e conceder permissões a ele. O Data Pump não escreve arquivos diretamente a partir do cliente; ele grava no servidor onde o banco está rodando, usando o objeto DIRECTORY como referência. Esse design é mais seguro e evita caminhos arbitrários no sistema. Vamos criar o diretório /u01/app/oracle/dpump no Linux e o objeto lógico DP_DIR no banco:

# No shell Linux (RHEL/CentOS/Oracle Linux)

mkdir -p /u01/app/oracle/dpump

chown oracle:oinstall /u01/app/oracle


Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Oracle SQL para equipes corporativas.
  

    

    Falar no WhatsApp