nerdexam
Oracle

1Z0-052 · Question #257

You are working on a very large database. You had performed a binary backup of the control file a month ago. After this you added a few tablespaces, and dropped a couple of tablespaces. This…

The correct answer is E. restore the binary copy of the control file to the correct location, start up the instance in the mount. When control files are lost and the binary backup predates structural changes like tablespace additions and drops, you must restore the backup and then recover the database to reconcile the control file with the current datafiles.

Performing Backup and Recovery

Question

You are working on a very large database. You had performed a binary backup of the control file a month ago. After this you added a few tablespaces, and dropped a couple of tablespaces. This morning, due to hardware failure, you lost all your control files. How would you recover the database from this situation?

Options

  • Aexecute the CREATE CONTROLFILE FROM BACKUP.. command
  • Brestore all database files from the last backup and apply redo logs till the point of failure
  • Crestore the binary copy of the control file to the respective location and start up the database
  • Dstart up the database in the NOMOUNT state, generate the trace file from binary backup, and re-
  • Erestore the binary copy of the control file to the correct location, start up the instance in the mount

How the community answered

(61 responses)
  • A
    10% (6)
  • B
    21% (13)
  • C
    7% (4)
  • D
    2% (1)
  • E
    61% (37)

Why each option

When control files are lost and the binary backup predates structural changes like tablespace additions and drops, you must restore the backup and then recover the database to reconcile the control file with the current datafiles.

Aexecute the CREATE CONTROLFILE FROM BACKUP.. command

CREATE CONTROLFILE FROM BACKUP is not a valid Oracle SQL command; the correct approach for recreating a control file from a trace is the CREATE CONTROLFILE statement generated via ALTER DATABASE BACKUP CONTROLFILE TO TRACE.

Brestore all database files from the last backup and apply redo logs till the point of failure

Restoring all database files is unnecessarily disruptive because only the control files were lost and the datafiles remain intact on disk.

Crestore the binary copy of the control file to the respective location and start up the database

Simply restoring the binary control file and starting the database will fail because the one-month-old control file does not reflect the tablespace changes made afterward, causing a structural mismatch with the current datafiles.

Dstart up the database in the NOMOUNT state, generate the trace file from binary backup, and re-

Generating a trace file from the binary backup and recreating the control file in NOMOUNT state alone does not reconcile the tablespace changes made after the backup, leaving the resulting control file incomplete without a subsequent recovery step.

Erestore the binary copy of the control file to the correct location, start up the instance in the mountCorrect

Restoring the binary control file and starting the instance in MOUNT state allows Oracle to apply redo logs to reconcile the outdated control file with all tablespace changes made after the backup. Because the control file is a month old and structural changes occurred afterward, a simple restore without recovery will result in a mismatch between the control file and the actual datafiles. Performing recovery in MOUNT state updates the control file's internal records to reflect the current state of the database.

Concept tested: Oracle control file recovery after structural database changes

Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/user-managed-flashback-dbpitr.html

Topics

#control file recovery#binary backup#MOUNT state#media recovery after restore

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full 1Z0-052 Practice