Questão de Banco de Dados — Recuperação de Dados em SGBDs — FCC 2026

Backup e recuperação no Oracle: ARCHIVELOG + RMAN para alta disponibilidade

Gabarito: letra C. A estratégia mais adequada para minimizar o RTO e permitir recuperação pontual (Point-In-Time Recovery) é operar o banco no modo ARCHIVELOG e usar o Recovery Manager (RMAN) para backups incrementais diários — o RMAN é o utilitário nativo do Oracle para gerenciar cópias físicas e logs de redo, e o modo ARCHIVELOG preserva os archive logs necessários para refazer transações até o último ponto no tempo.

O problema central aqui é entender o que cada modo de operação e cada ferramenta de backup oferece em termos de recuperabilidade. O Oracle trabalha com dois modos fundamentais: NOARCHIVELOG e ARCHIVELOG. No modo NOARCHIVELOG, os redo logs são sobrescritos ciclicamente — quando um log fica cheio, ele é reutilizado, e as transações ali registradas se perdem para fins de recuperação. Isso significa que, após uma falha, você só consegue restaurar o banco até o momento do último backup completo; qualquer transação posterior ao backup é perdida. Já no modo ARCHIVELOG, os redo logs são arquivados (archive logs) antes de serem reutilizados, criando um histórico contínuo de todas as alterações. Com esse histórico, é possível aplicar os logs arquivados sobre um backup e recuperar o banco até qualquer ponto no tempo — inclusive o último commit antes da falha.

O RMAN (Recovery Manager) é a ferramenta nativa do Oracle para backup e recuperação. Ele trabalha com backups físicos (datafiles, control files, archive logs) e oferece recursos como backups incrementais (nível 0 e nível 1), que copiam apenas os blocos alterados desde o último backup, reduzindo drasticamente o volume de dados e o tempo de execução. O RMAN também gerencia um catálogo de recuperação (ou usa o control file) para rastrear backups e facilitar a restauração. Combinar RMAN com ARCHIVELOG é a prática recomendada para ambientes de produção com alta taxa de transações: os backups incrementais diários reduzem o RTO (tempo de recuperação), e os archive logs permitem a recuperação pontual (RPO próximo de zero).

Vamos comparar as alternativas para ver por que as outras falham:

A pegadinha da banca está em confundir backup lógico (Data Pump) com backup físico (RMAN), e em achar que NOARCHIVELOG permite recuperação pontual. O Data Pump (expdp/impdp) exporta dados em formato lógico (arquivos dump), útil para migração ou recuperação de objetos específicos, mas não captura o estado consistente do banco com todos os logs — não serve para recuperação pontual em caso de falha. Já o cold backup (cópia dos arquivos com banco parado) só é válido no momento em que é feito; sem archive logs, qualquer transação posterior é perdida.

Guarde a fronteira decisiva: ARCHIVELOG = recuperação pontual; NOARCHIVELOG = recuperação até o último backup. É exatamente nessa distinção que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O erro está em combinar backup lógico (Data Pump) com NOARCHIVELOG. O Data Pump exporta dados em formato lógico (arquivos dump), útil para migração ou recuperação de objetos específicos, mas não captura o estado consistente do banco com todos os logs — não serve para recuperação pontual em caso de falha. Além disso, o modo NOARCHIVELOG não preserva os redo logs arquivados, então qualquer transação após o último backup é perdida. A alternativa até menciona uma vantagem real do Data Pump (recuperar objetos específicos), mas isso não atende aos requisitos de RTO baixo e recuperação pontual.

Alternativa B — ❌ Incorreta

O cold backup (cópia dos arquivos com banco parado) é um backup físico válido, mas combinado com NOARCHIVELOG limita a recuperação ao momento do último backup. A alternativa reconhece essa limitação, mas a estratégia não atende ao requisito de recuperação pontual — que exige ARCHIVELOG. Além disso, cold backups exigem parar o banco, aumentando o tempo de indisponibilidade (RTO), o que contraria o objetivo de minimizar o RTO.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a combinação correta. O modo ARCHIVELOG preserva os archive logs, permitindo recuperação pontual (Point-In-Time Recovery) até o último commit. O RMAN é o utilitário nativo do Oracle para backups físicos, e os backups incrementais diários (nível 0 e nível 1) reduzem o volume de dados e o tempo de execução, minimizando o RTO. O RMAN também gerencia o catálogo de recuperação, facilitando a restauração. Essa é a prática recomendada para ambientes de produção com alta taxa de transações.

Alternativa D — ❌ Incorreta

O RMAN é a ferramenta certa, mas combinado com NOARCHIVELOG não permite recuperação pontual — a recuperação fica limitada ao último backup. A alternativa menciona o catálogo do RMAN, mas a afirmação de que a recuperação só pode ser feita com o servidor totalmente fora de operação é incorreta: o RMAN pode restaurar com o banco montado ou desmontado, e o problema real é a falta de archive logs para refazer transações.

Alternativa E — ❌ Incorreta

Snapshots de storage são rápidos, mas desabilitar a geração de archive logs elimina a possibilidade de recuperação pontual. O snapshot captura o estado do banco em um momento específico, mas sem archive logs, qualquer transação posterior é perdida. Além disso, a alternativa afirma que a abordagem "não faz uso de RMAN" como se fosse uma vantagem, mas o RMAN é justamente a ferramenta nativa mais eficiente para gerenciar backups e recuperação. A estratégia não atende aos requisitos de RTO baixo e recuperação pontual.

Gabarito: letra C