1Z0-052 · Question #219
Your database is in NOARCHIVELOG mode and a logswitch happens every 20 minutes. On Thursday morning, media failure resulted in corruption of a data file belonging to the TOOLS tablespace. Backups…
The correct answer is E. restore the entire database from the most recent backup and start the instance and open the. In NOARCHIVELOG mode, Oracle does not retain archived redo logs, making media recovery impossible - the only option is to restore the entire database from the last full backup and accept data loss up to that backup point.
Question
Your database is in NOARCHIVELOG mode and a logswitch happens every 20 minutes. On Thursday morning, media failure resulted in corruption of a data file belonging to the TOOLS tablespace. Backups are taken on every Sunday. What would you do in this situation?
Options
- Arecover using Oracle Flashback Database technology
- Brestore the data files from backup and perform a complete recovery
- Crestore only the corrupted data file and perform tablespace recovery
- Drestore the data files from backup and perform cancel-based recovery
- Erestore the entire database from the most recent backup and start the instance and open the
How the community answered
(13 responses)- A15% (2)
- B23% (3)
- C8% (1)
- E54% (7)
Why each option
In NOARCHIVELOG mode, Oracle does not retain archived redo logs, making media recovery impossible - the only option is to restore the entire database from the last full backup and accept data loss up to that backup point.
Oracle Flashback Database relies on flashback logs written to the Fast Recovery Area and requires ARCHIVELOG mode to be enabled - neither condition is met in this scenario.
Complete recovery applies all archived redo logs after restoring data files to bring the database fully current, but this requires archived logs that do not exist in NOARCHIVELOG mode.
Tablespace-level recovery restores only affected data files and applies archived redo logs to re-sync them with the rest of the database, which is not possible without archived logs.
Cancel-based recovery is a form of incomplete recovery that still requires archived redo logs to apply redo up to a user-specified point, making it unavailable in NOARCHIVELOG mode.
NOARCHIVELOG mode means online redo logs are overwritten without being archived, so there are no logs available to roll forward a restored backup past Sunday. The DBA must restore all data files from Sunday's backup and open the database, which will use RESETLOGS and permanently lose all transactions from Sunday through Thursday's failure.
Concept tested: Database media recovery limitations in NOARCHIVELOG mode
Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/introduction-backup-recovery.html
Topics
Community Discussion
3Our group kept coming back to B on this one. In NOARCHIVELOG mode you cannot roll forward with archived logs since they are not being retained, so a tablespace-level or cancel-based recovery is off the table, and Flashback Database also requires archiving to be enabled, but restoring the data files from that Sunday backup and letting Oracle complete the recovery with the online redo logs that are still intact is exactly the path the documentation describes for this scenario. Anyone see it differently, or did someone land on E and want to make the case for that?
You restore the data files from Sunday's backup and then perform a complete recovery, end of story. The keyword people keep tripping over is "complete" and they assume you need archivelog mode for that, but you still have the online redo logs and the backup controlfile to work with, and a complete recovery just means you bring the database to a consistent state with no data loss left on the table. Option E is a trap for people who panic and think NOARCHIVELOG means you just open and pray.
Viktor, I actually think E is right here, because in NOARCHIVELOG mode the archived redo logs were never saved, so there is nothing to apply after the restore, and that is exactly why a complete recovery is not possible, only an open after restore with data loss back to the last backup.