1Z0-060 · Question #230
Your database runs in mode. NOARCHIVELOG Whole database backups are taken daily. A media failure damages data files belonging to the USERS tablespace and the online redo log files. The hardware that…
The correct answer is B. 1, 4, 7, 8, 9. In NOARCHIVELOG mode with hardware failure requiring relocation, restore only damaged files to new location, mount the database, rename file locations in the control file, then open the database.
Question
Options
- A1, 3, 5, 8, 9
- B1, 4, 7, 8, 9
- C1, 3, 4, 6
- D2, 5, 6, 7, 9
How the community answered
(29 responses)- A3% (1)
- B69% (20)
- C17% (5)
- D10% (3)
Why each option
In NOARCHIVELOG mode with hardware failure requiring relocation, restore only damaged files to new location, mount the database, rename file locations in the control file, then open the database.
Step 5 (STARTUP NOMOUNT) and step 3 (editing the init parameter file for control file location) are only required when control files are also lost and must be restored or recreated; since control files are not damaged here, STARTUP MOUNT is the correct command.
Because the hardware is not repairable, step 1 restores only the damaged data files and redo logs to a new location. Step 4 (STARTUP MOUNT) is correct because the control files are intact and the database can be mounted without restoring them. Step 7 (ALTER DATABASE RENAME FILE) updates the control file to reflect the new physical paths of the restored files, and steps 8 and 9 complete the process of specifying new redo log locations and opening the database.
Step 6 (RECOVER DATABASE) requires archive log files, which do not exist in NOARCHIVELOG mode; media recovery is not possible without archive logs, making this step invalid in this scenario.
Step 2 (restore entire database) is unnecessary because only the USERS tablespace and redo log files are damaged; restoring the full backup wastes time and step 6 (RECOVER DATABASE) is inapplicable in NOARCHIVELOG mode.
Concept tested: Oracle incomplete recovery in NOARCHIVELOG mode
Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/user-managed-database-flashback-recovery.html
Topics
Community Discussion
9
Brenda K.Mar 19, 2026This is a NOARCHIVELOG scenario with hardware damage forcing a relocation, so your recovery path is tighter than people expect. You only restore the damaged files, not the whole database, which rules out D immediately. A fails because you do not need to edit the init parameter file or use STARTUP NOMOUNT here, those steps are for recreating a control file from scratch, and your control file is fine. C fails because RECOVER DATABASE without RESETLOGS is not valid when you have damaged online redo logs in NOARCHIVELOG mode, you cannot apply archive logs that do not exist. The correct answer is B, steps 1, 4, 7, 8, 9. You restore only the damaged files from backup (step 1), mount the database with STARTUP MOUNT (step 4) so Oracle can read the control file but not open, use ALTER DATABASE RENAME FILE (step 7) to point the control file at the new locations, specify new log locations via RECOVER DATABASE UNTIL CANCEL (step 8) which handles the redo log relocation in NOARCHIVELOG mode, then open with RESETLOGS (step 9) to reset the log sequence. Clock yourself on this one, the wording is dense but once you see that hardware relocation plus NOARCHIVELOG equals rename-plus-cancel-recovery, you should be able to lock in B in under 90 seconds and move on.
Viktor S.Mar 20, 2026Solid breakdown, but step 8 does not handle the redo log relocation, that is step 7's job, and RECOVER DATABASE UNTIL CANCEL in NOARCHIVELOG just means you issue CANCEL immediately because there are no archivelogs to apply, which is worth knowing separately so you do not confuse the rename mechanic with the recovery mechanic on a different question.
Viktor S.Mar 11, 2026B, and I almost picked C the first time through. Sat the 1Z0-060 in 2018, saw this exact scenario, spent two minutes second-guessing myself. Control files are not damaged, so you do not need STARTUP NOMOUNT or a full restore. You restore only the broken files to a new location, mount the database using the intact control file, rename the paths with ALTER DATABASE RENAME FILE so the control file knows where things actually live now, then run RECOVER DATABASE UNTIL CANCEL because you are in NOARCHIVELOG and have nothing to apply, and finally open with RESETLOGS. C looks tempting until you remember the online redo logs are also gone, which means a clean recovery with RECOVER DATABASE is not happening. Picked B, passed by four points.
Brenda K.Mar 13, 2026Viktor, RECOVER DATABASE UNTIL CANCEL is the right call but worth flagging for newer folks that RESETLOGS is not optional here, it resets the log sequence because those online redo logs are gone and the database cannot open any other way.
Marisol N.Mar 15, 2026Saw this exact scenario on my 1Z0-060, trusted step 4 over 5, picked B, passed.
Prof. SaraMar 17, 2026Solid instinct on step 4, though on 12c and later you want to confirm that the CDB versus PDB context is resolved before that step even runs, since a wrong container flips the whole outcome.
Fatima Z.Mar 12, 2026B is right, NOARCHIVELOG plus busted redo logs means UNTIL CANCEL is your only play, and you rename files instead of restoring the whole thing since only USERS tablespace got hit.
Brenda K.Mar 13, 2026Fatima nailed the UNTIL CANCEL call, but do not sleep on verifying SCN consistency after the rename or you will burn five extra minutes mid-exam hunting a datafile header mismatch that RECOVER will throw right in your face.
Prof. SaraMar 1, 2026B is the move here, and the hinge is that the control files survived intact, so you go straight to STARTUP MOUNT rather than NOMOUNT, making step 3 irrelevant. The damaged online redo logs force incomplete recovery via UNTIL CANCEL instead of a clean RECOVER DATABASE, which is exactly why RESETLOGS is mandatory at the end.