O setor de tecnologia da informação está em processo de otimização de sua infraestrutura de banco de dados, que utiliza o Oracle Database. O responsável pela administração do sistema precisa garantir a alta disponibilidade, o desempenho e a segurança dos dados processuais.
Diante dos métodos disponíveis no Oracle para backup e recuperação, a abordagem mais adequada para garantir a consistência e a recuperação completa dos dados em caso de falha é
Aignorar o uso de backups lógicos e físicos, pois a alta disponibilidade do Oracle Data Guard garante que não haverá perda de dados em nenhuma circunstância.
Brealizar um backup em frio (cold backup) com o banco de dados aberto, utilizando a ferramenta Data Pump para exportar apenas as tabelas alteradas desde o último backup.
Cconfigurar o banco de dados em NOARCHIVELOG mode, pois essa configuração otimiza o desempenho das transações, tornando o processo de backup mais rápido e dispensando a necessidade de arquivos de redo logs.
Dutilizar a ferramenta Recovery Manager (RMAN) para realizar backups incrementais periódicos em um banco de dados em ARCHIVELOG mode, combinando-os com backups completos para permitir uma recuperação pontual (point-in-time recovery) e assegurar a integridade total dos dados.
Edepender exclusivamente dos arquivos de redo logs online para restaurar o banco de dados, pois eles contêm todas as informações de transação e são suficientes para qualquer tipo de recuperação.
Revelar gabarito e comentário▾
GabaritoD — utilizar a ferramenta Recovery Manager (RMAN) para realizar backups incrementais periódicos em um banco de dados em ARCHIVELOG mode, combinando-os com backups completos para permitir uma recuperação pontual (point-in-time recovery) e assegurar a integridade total dos dados.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Backup e recuperação no Oracle Database
Gabarito: letra D. A abordagem mais robusta para garantir consistência e recuperação completa em caso de falha é usar o Recovery Manager (RMAN) com backups incrementais periódicos em um banco em ARCHIVELOG mode, combinados com backups completos — isso permite a recuperação pontual (point-in-time recovery) e assegura a integridade dos dados. As demais alternativas contêm erros conceituais graves sobre backup, redo logs e modos de arquivamento.
O tema central é a estratégia de backup e recuperação em bancos Oracle. Para entender por que a letra D é a correta, é preciso dominar alguns conceitos fundamentais da arquitetura Oracle: os arquivos de redo log, o modo ARCHIVELOG/NOARCHIVELOG, os tipos de backup (físico/lógico, completo/incremental) e a ferramenta RMAN.
O que são os redo logs e por que eles importam? Os redo logs são arquivos que registram todas as alterações feitas no banco de dados — antes mesmo de serem gravadas nos datafiles. Esse registro é chamado de redo entry e permite que o Oracle refaça (redo) qualquer transação em caso de falha, como uma queda de energia ou travamento do servidor. Eles são essenciais para a recuperação de falhas.
ARCHIVELOG vs. NOARCHIVELOG: No modo NOARCHIVELOG, os redo logs online são sobrescritos quando cheios, sem gerar cópias arquivadas. Isso significa que só é possível recuperar o banco até o último backup — qualquer transação posterior ao backup é perdida. Já no modo ARCHIVELOG, os redo logs são arquivados (archived redo log files), permitindo recuperação completa até o momento da falha, inclusive com point-in-time recovery. Por isso, para alta disponibilidade e recuperação completa, o modo ARCHIVELOG é obrigatório.
Backup físico vs. lógico: O backup físico copia os arquivos do banco (datafiles, control files, archived redo logs), enquanto o backup lógico (como o Data Pump) exporta objetos lógicos (tabelas, esquemas). O backup físico é a base para recuperação completa do banco; o lógico é complementar, para recuperação de objetos específicos.
RMAN (Recovery Manager): É a ferramenta nativa do Oracle para backup e recuperação. Com o RMAN, é possível fazer backups completos e incrementais (que copiam apenas os blocos alterados desde o último backup), gerenciar arquivos de backup, validar backups e executar recuperações complexas, incluindo point-in-time recovery. Combinar backups incrementais periódicos com backups completos é a prática recomendada para minimizar a janela de backup e garantir recuperação rápida e completa.
A pegadinha da banca: A questão explora a confusão entre backup lógico e físico, entre cold backup e hot backup, e entre os modos ARCHIVELOG e NOARCHIVELOG. O candidato que não domina esses conceitos pode cair em alternativas que parecem plausíveis, mas contêm erros técnicos graves.
Guarde a fronteira entre o que cada ferramenta faz e o que cada modo de arquivamento permite: é exatamente nela que as alternativas se dividem.
Backup e recuperação Oracle
1Redo logs
Registram alterações
Online (sempre necessários)
Arquivados (ARCHIVELOG)
2Modos de arquivamento
NOARCHIVELOG
Recupera só até último backup
ARCHIVELOG
Recuperação completa
Point-in-time recovery
3Tipos de backup
Físico (datafiles, control files)
Lógico (Data Pump — objetos)
4RMAN
Backups completos
Backups incrementais
Combinação permite recuperação pontual
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que ignorar backups lógicos e físicos é aceitável porque o Oracle Data Guard garante que não haverá perda de dados em nenhuma circunstância. O erro está em tratar o Data Guard como substituto de backup. O Data Guard é uma solução de alta disponibilidade e disaster recovery que mantém um banco standby, mas não elimina a necessidade de backups. Backups são essenciais para recuperação de erros lógicos (como um DROP acidental), corrupção de dados ou desastres que afetem ambos os bancos. Além disso, a afirmação "não haverá perda de dados em nenhuma circunstância" é uma generalização indevida — mesmo com Data Guard, há cenários de perda de dados (por exemplo, em configurações de proteção máxima de performance).
Alternativa B — ❌ Incorreta
Propõe um "backup em frio (cold backup) com o banco de dados aberto, utilizando a ferramenta Data Pump para exportar apenas as tabelas alteradas desde o último backup". Há dois erros graves: (1) cold backup é feito com o banco fechado (offline), não aberto — com o banco aberto, o backup é chamado de hot backup (online); (2) o Data Pump é uma ferramenta de backup lógico, que exporta objetos, mas não faz backup físico incremental de blocos. O Data Pump não é a ferramenta adequada para backups incrementais físicos — essa é a função do RMAN. Além disso, exportar "apenas as tabelas alteradas" não garante consistência do banco como um todo.
Alternativa C — ❌ Incorreta
Afirma que configurar o banco em NOARCHIVELOG mode otimiza o desempenho, torna o backup mais rápido e dispensa a necessidade de redo logs. O erro está em afirmar que o NOARCHIVELOG dispensa redo logs — os redo logs online são sempre necessários para a operação do banco; o que muda é que, nesse modo, eles não são arquivados. Além disso, o NOARCHIVELOG não otimiza o desempenho de forma significativa e, principalmente, impede a recuperação completa: só é possível recuperar até o último backup, perdendo todas as transações posteriores. Para garantir consistência e recuperação completa, o modo correto é ARCHIVELOG.
Alternativa D — ✅ Correta ⟵ GABARITO
A alternativa descreve a prática recomendada: utilizar o RMAN para backups incrementais periódicos em um banco em ARCHIVELOG mode, combinando-os com backups completos. Isso permite a recuperação pontual (point-in-time recovery) e assegura a integridade total dos dados. O RMAN é a ferramenta nativa do Oracle para backup e recuperação, e o modo ARCHIVELOG garante que todos os redo logs sejam arquivados, permitindo recuperação completa até o momento da falha. A combinação de backups completos e incrementais otimiza o processo, reduzindo o tempo de backup e o espaço de armazenamento, sem comprometer a capacidade de recuperação.
Alternativa E — ❌ Incorreta
Afirma que depender exclusivamente dos redo logs online é suficiente para restaurar o banco de dados. O erro está em ignorar que os redo logs online são sobrescritos quando cheios (em NOARCHIVELOG) ou arquivados (em ARCHIVELOG). Eles registram as alterações, mas não contêm uma cópia completa dos dados — os datafiles são a fonte primária. Para recuperar um banco, é necessário ter um backup dos datafiles (completo ou incremental) e, a partir daí, aplicar os redo logs (online e arquivados) para refazer as transações. Sem um backup, os redo logs sozinhos não são suficientes para reconstruir o banco.
Conclusão: A alternativa correta é a letra D, pois descreve a estratégia de backup e recuperação mais adequada no Oracle: RMAN com backups incrementais em ARCHIVELOG mode, combinados com backups completos, permitindo recuperação pontual e integridade total dos dados.