You use RMAN with a recovery catalog to back up your database. The backups and the
archived redo log files are backed up to media daily. Because of a media failure, the entire
database along with the recovery catalog database is lost.
Examine the steps required to recover the database:
1.Restore an autobackup of the server parameter file.
2.Restore the control file.
3. Start up the database instance in nomount state.
4.Mount the database.
5.Restore the data files.
6.Open the database with the resetlogs option.
7.Recover the data files.
8.Set D3ID for the database.
Identify the required steps in the correct order.
A.
1, 8, 3, 2, 4, 5, 7, 6
B.
8, 1, 3, 2, 4, 5, 7, 6
C.
1, 3, 2, 4, 8, 5, 6, 7
D.
8, 3, 2, 4, 5, 7, 6
E.
8, 1, 3, 2, 4, 5, 6
D
Why..
I think it’s D because you can’t restore an autobackup of the server parameter file without startup nomount database… but it can also be A or B according to this parameter of Oracle Documentation .
The basic procedure for disaster recovery is found in “Performing Recovery with a Backup Control File”, with an additional first step of restoring an autobackup of the server parameter file. Another Oracle “trap” for us.
One thing is for sure : C AND E ARE NOT!
Read carefull and tell what you guys think of it.
Performing Disaster Recovery
If you are in a disaster recovery scenario, then presumably you have lost the target database, the recovery catalog database, all control files, all online redo logs, and all parameter files. At minimum, you must have backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.
See Also:
“Control File and Server Parameter File Autobackups”
The basic procedure for disaster recovery is found in “Performing Recovery with a Backup Control File”, with an additional first step of restoring an autobackup of the server parameter file. -1 ?
After the instance is started, you can restore an autobackup of the control file, mount it, then restore and recover the datafiles. Because you are restoring to a new host, you should review the considerations described in “Restoring the Database to a New Host”.
The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:
You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.
In this scenario, you perform the following steps:
If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.
Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect through operating system authentication.
Specify the DBID for the target database with the SET DBID command, as described in “Performing Recovery with a Backup Control File and No Recovery Catalog”. – 8
Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file. – 3
Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command. – 1
Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file. – 3
Allocate a channel to the media manager and then restore a control file autobackup (refer to”Performing Recovery with a Backup Control File and No Recovery Catalog”). – 2
Mount the restored control file. – 4
Catalog any archived logs not recorded in the repository with the CATALOG command (refer to”Cataloging Archived Logs and User-Managed Copies”). – where’s this step in the question ?
Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to”Restoring Files to a New Location”). – 5
Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified. – 7
Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied. – 6
Note:
Oracle Corporation recommends that you back up the database after the RESETLOGS operation (not shown in the example).
# Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# set the DBID for the target database
SET DBID 676549873;
STARTUP FORCE NOMOUNT; # rman starts instance with dummy parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
STARTUP FORCE NOMOUNT;
RUN
{
# manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore an autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you wish to
# recover to that point-in-time. In this way RMAN restores
# the database to the same structure that the database had at the specified time.
SET UNTIL SEQUENCE 1124 THREAD 1;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery completes
This link is better : https://docs.oracle.com/database/121/BRADV/rcmadvre.htm#BRADV89839
Recovering the Database After a Disaster
The procedure for disaster recovery is similar to the procedure for recovering the database with a backup control file in NOCATALOG mode. If you are restoring the database to a new host, then review the considerations described in “Restoring a Database on a New Host”.
This scenario assumes that the Linux server on which your database was running has been damaged beyond repair. Fortunately, you backed up the database to Oracle Secure Backup and have the tapes available. The scenario assumes the following:
Oracle Database is installed on the new host.
You are restoring the database to a new Linux host with the same directory structure as the old host.
You have one tape drive containing backups of all the data files and archived redo logs through log 1124, and autobackups of the control file and server parameter file.
You do not use a recovery catalog with the database.
To recover the database on the new host:
If possible, restore or re-create all relevant network files such as tnsnames.ora and listener.ora and a password file.
Start RMAN and connect to the target database instance.
At this stage, no initialization parameter file exists. If you have set ORACLE_SID and ORACLE_HOME, then you can use operating system authentication to connect as SYSDBA or SYSBACKUP.
See Also:
“Making Database Connections with RMAN”
Specify the DBID for the target database with the SET DBID command, as described in “Restoring the Server Parameter File”.
For example, enter the following command:
SET DBID 676549873;
Run the STARTUP NOMOUNT command.
When the server parameter file is not available, RMAN attempts to start the instance with a dummy server parameter file.
Allocate a channel to the media manager and then restore the server parameter file from autobackup.
For example, enter the following command to restore the server parameter file from Oracle Secure Backup:
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
Restart the instance with the restored server parameter file.
STARTUP FORCE NOMOUNT;
Write a command file to perform the restore and recovery operation, and then execute the command file. The command file must do the following:
Allocate a channel to the media manager.
Restore a control file autobackup (see “Performing Recovery with a Backup Control File and No Recovery Catalog”).
Mount the restored control file.
Catalog any backups not recorded in the repository with the CATALOG command.
Restore the data files to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore operation and perform a switch after the restore operation to update the control file with the new locations for the data files, as shown in the following example.
Recover the data files. RMAN stops recovery when it reaches the log sequence number specified.
RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you want to
# recover to that point in time. In this way RMAN restores the database
# to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
The following example of the RUN command shows the same scenario except with new file names for the restored data files:
RMAN> RUN
{
# If you must restore the files to new locations,
# use SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO ‘/dev/vgd_1_0/rlvt5_500M_1’;
SET NEWNAME FOR DATAFILE 2 TO ‘/dev/vgd_1_0/rlvt5_500M_2’;
SET NEWNAME FOR DATAFILE 3 TO ‘/dev/vgd_1_0/rlvt5_500M_3’;
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of data files.
RECOVER DATABASE;
}
If recovery was successful, then open the database and reset the online logs:
ALTER DATABASE OPEN RESETLOGS;
B
Maybe they’re skipping the first STARTUP NOMOUNT before restoring the spfile?
But you can mount the database with a dummy spfile…
So I dont know for sure.
They only said:
“the steps required to recover the database”
So if you look it at that way why do than have to recover the data point 5 and 7?
Not, so in that case it would only leave E as option..
B
Why B? Could you explain KRA?
I tested (11.0.2.0.4)
step 1: RMAN>set dbid –> 8
step 2: RMAN>startup nomount –> 3
step 3: RMAN>restore spfile from autobackup; –> 1
step 4: RMAN>startup force nomount; –> not present in the answers
–> Step 4 is necessary, because the instance was started with an DUMMY-spfile
step 5: RMAN>restore controlfile from autobackup; –> 2
step 6: RMAN>alter database mount; –> 4
–> without step 4 you’ll get the error after restoring controlfile and trying to mount the database:
“ORA-01103:database name ” in control file is not ‘DUMMY'”
step 7: RMAN>restore database; –> 5
step 8: RMAN>recover database; –> 7
step 9: RMAN>alter database open resetlogs; –> 6
So the answer should be:
8.Set D3ID for the database.
3.Start up the database instance in nomount state.
1.Restore an autobackup of the server parameter file.
3.Start up the database instance in nomount state.
2.Restore the control file.
4.Mount the database.
5.Restore the data files.
7.Recover the data files.
6.Open the database with the resetlogs option.
But the second time of the restart is not in the answers, so I prefer:
Answer: B
8,1,3,2,4,5,7,6
If they missed the first “startup nomount” for restoring the spfile.
Don’t answer this question 🙂
B
http://oracle-pub.wikidot.com/rman-restore-controlfile
D is the most correct ans out of B and D.
This exhibit states that recovery catalog is also lost so we cannot connect to catalog and we must set dbid to do controlfile restore.
First, we start the RMAN without catalog –
C:\Users\10>rman target /
If exhibit assumes that the SPFILE is not lost – then the recovery steps will be (As in D)
1. RMAN> set dbid 1456397510;
2. RMAN> startup nomount;
3. RMAN> restore controlfile from autobackup;
4. RMAN> alter database mount;
5. RMAN> restore database;
6. RMAN> recover database;
7. RMAN> alter database open resetlogs;
If exhibit assumes that even SPFILE is lost – then the recovery steps will be (None of the Options – with 2 startup’s)
1. RMAN> set dbid 1456397510;
2. RMAN> startup nomount; –start instance using dummy pfile for retrieval of SPFILE
3. RMAN> restore spfile from autobackup;
4. RMAN> startup force nomount; — restart the instance to start the instance using restored SPFILE
5. RMAN> restore controlfile from autobackup;
6. RMAN> alter database mount;
7. RMAN> restore database;
8. RMAN> recover database;
9. RMAN> alter database open resetlogs;
Option B is incorrect because it is trying to restore SPFILE from autobackup (1) without starting instance (3). RMAN restore operation is not possible without instance.
I prefer B
I think performing a disaster recovery must includes recovering spfile. The question may omit some steps, like startup force nomount, but we have to recover spfile, we cannot use the dummy spfile to perform the rest steps.
B