Examine the following scenario:
Database is running in ARCHIVELOG mode.
Complete consistent backup is taken every Sunday.
On Tuesday the instance terminates abnormally because the disk on which control files are
located gets corrupted
The disk having active online redo log files is also corrupted.
The hardware is repaired and the paths for online redo log files and control files are still
valid.
Which option would you use to perform the recovery of database till the point of failure?
A.
Restore the latest whole backup, perform complete recovery, and open the database
normally
B.
Restore the latest whole backup, perform incomplete recovery, and open the database
with the RESETLOGS option.
C.
Restore the latest backups control file, perform complete recovery, and open the
database with the RESETLOGS option.
D.
Restore the latest backup control file, perform incomplete recovery using backup control
file, and open the database with the RESETLOG option.
I think the answer is B.
All controlfiles and online redo logfiles are lost due to hardware corruption. In this case, you can not use a backup controlfile and the current datafiles to complete the recovery. Because the datafiles are newer than the backup controlfiles and there is not enough redo to make them consistent as the online redo logfiles are lost. When you try to open the database with resetlogs option after applying all archived logs, an error raises:
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: ‘/u01/app/oracle/oradata/ora11g/system01.dbf’
Answer is D, here is why …
This question is ambiguous …
“The hardware is repaired and the paths for online redo log files and control files are still
valid.”
I can only assume that the paths are OK but the files themselves have disappeared, right?
So we have no
– control files : we must restore the “backup control file”, and ALTER DATABASE OPEM RESETLOGS
– online redo logs files : requires a DPITR also requires RESETLOGs to recreate the online redo log files
Answer …
A. has no RESETLOGS, i.e. wrong
B. does not restore the “backup control file”, i.e. wrong
C. we cant perform complete recovery as we have no online redos, i.e. wrong
D. Correct answer
Correct answer has to be the B.
There’s no way you cannot not restore the datafiles if you lost an active log file
Ever hear of DPITR?
Eamon, don´t you need actually the datafiles themselves to perform DPITR? As you have lost your online redo, you can forget your current datafiles. You need to restore them and that´t not what D option does. Of course you will also need control file backup and you have it in B option. If Control file Autobackup is on, it is done wherever you backup your database, so it is included in optin B.
after further consideration …
Answer is D, here is why …
So we have no
– control files : we must recreate the control file (as opposed to restoring it because we have no online redos to restore it with), and afterwards do a
ALTER DATABASE OPEM RESETLOGS
take a look at
http://oracle.su/docs/11g/backup.112/e10642/osadvsce.htm#CHDHFGEI
– online redo logs files : requires a DPITR also requires RESETLOGs to recreate the online redo log files. Also (and this is a very interesting point) because online redo logs are never backed up, you cannot restore them, to allow the database to reset the online redo logs, we must mimic incomplete recovery: (By the way any comments on this precise point would be very wellcome)
RECOVER DATABASE UNTIL CANCEL
CANCEL
ALTER DATABASE OPEN RESETLOGS;
Put it another way we have lost our CURRENT online redo logs therefore we need to do a DPITR (an alternative method would use FLASHBACK DATABASE). Take a look at
http://oracle.su/docs/11g/backup.112/e10642/osadvsce.htm
you can find the following text…
Loss of Multiple Redo Log Groups
If you have lost multiple groups of the online redo log, then use the recovery method for the most difficult log to recover. The order of difficulty, from most difficult to least difficult, is as follows:
The current online redo log
An active online redo log
An unarchived online redo log
An inactive online redo log
So now to the possible answers …
A. has no RESETLOGS, i.e. wrong
B. does not recreate nor restore the “backup control file”, i.e. wrong
C. we cant perform complete recovery as we have, for example no online redos, i.e. wrong
D. Maybe best answer, however not the correct answer, why? well because we should be recreating the control file and not restoring it as I mentioned above.