In Recovery Manager (RMAN), you are taking image copies of the datafiles of your
production database and rolling them forward as regular intervals. You attempt to restart
your database instance after a regular maintenance task, you realize that one of the data
files that belongs to the USERS tablespace is damaged and you need to recover the datafile
by using the image copy. You could perform the following steps to accomplish this:
1) Mount the database
2) Take the data file offline
3) Bring the data file online
4) Use the RMAN SWITCH TO command to switch the image copy
5) Apply the archived redo logs
6) Open the database
7) Use the RMAN RESTORE TO command to switch to the image copy
Which two options illustrate the correct sequence of steps that you could follow? (Choose
two.)
A.
2, 6, 4, 5, 3
B.
1, 2, 4, 5, 3, 6
C.
1, 2, 4, 6, 3
D.
1, 2, 7, 5, 3, 6
In my opinion the options/answers are totally incorrect.
If you mount to database no need to take datafile or tablespace offline mode
OR reverse
If you take datafile, tablespace offline mode no need to mount to database
Exm
# RMAN> sql ‘alter database datafile ‘/home/oracle/test01.dbf’ offline immediate’;
# RMAN> SWITCH datafile ‘/home/oracle/test01.dbf’ TO COPY;
# RMAN> recover datafile ‘/home/oracle/test01.dbf’;
# RMAN> sql ‘alter database datafile ‘/home/oracle/test01.dbf’ online;
true
I think the correct answer is AB.
D is wrong. RESTORE TO command can NOT switch a datafile to its copy.
The problem isn’t to “switch” but “recover the datafile by using the image copy”
So “B” switch to the image copy and “D” use the image copy to restore image copy to (maybe) his original location.
“A” … after “Take the data file offline”, you “Open the database” ?
So “A” is wrong
>>after “Take the data file offline”, you “Open the database” ?
bullshit… RTFM
http://docs.oracle.com/database/121/BRADV/rcmcomre.htm#CHDHICDF
Yes you could OPEN the database after you bring the datafile ONLINE as you can also bring a datafile OFFLINE when DB is open and do restore/recovery! Have you ever tried that? So A and B
Yes you could OPEN the database after you bring the datafile OFFLINE (sorry for previous one), as you can also bring a datafile OFFLINE when DB is open and do restore/recovery! Have you ever tried that? So A and B
RTFM……yeah if yours was the right manual, lets think here, are we doing an exam on Oracle 12.1 or 11.2? hmmmmm
I agree
With Lei
IMO A&B
I think that there are 2 techniques for repairing damaged datafiles.
A. The “High Availability” approach so the rest of the database is available meanwhile (sounds great! but believe me I would do my homework before using this technique), this is the same technique as can be seen in the documentation for recovering from the loss of a “non critical datafile”
1) Mount the database
STARTUP MOUNT
2) Take the data file offline
SQL “ALTER DATABASE DATAFILE 4 OFFLINE”;
6) Open the database
SQL “ALTER DATABASE OPEN”;
4) Use the RMAN SWITCH TO command to switch the image copy
SWITCH DATAFILE 4 TO COPY;
5) Apply the archived redo logs
RECOVER DATAFILE 4;
3) Bring the data file online
SQL “ALTER DATABASE DATAFILE 4 ONLINE”;
B. The Non High Availability approach, this is the same technique as can be seen in the documentation for recovering from the loss of a “critical datafile”. Therefore this means that the database is unavailable for the duration of the repair, but it is all the same a very useful technique if there are any objects in the user tablespace that have dependencies on them from objects in other tablespaces. More than likely the answer to this question is yes. That is why this technique is very useful.
1) Mount the database
STARTUP MOUNT
4) Use the RMAN SWITCH TO command to switch the image copy
SWITCH DATAFILE 4 TO COPY;
5) Apply the archived redo logs
RECOVER DATAFILE 4;
6) Open the database
SQL “ALTER DATABASE OPEN”;
After further consideration
I think that there are 2 techniques for repairing damaged datafiles. (as oppose to the options of using an image copy in place or restoring an image copy to an alternative location)
A. The “High Availability” approach so the rest of the database is available while we fix the problem. Only use this technique if the problem is with a “non critical datafile”. Therefore this means that the rest of the database is available for the duration of the repair. Use this technique if there are no objects in the user tablespace that have dependencies with objects in other tablespaces.
1) start the database
STARTUP MOUNT
2) Take the data file offline
SQL “ALTER DATABASE DATAFILE 4 OFFLINE”;
6) Open the database
SQL “ALTER DATABASE OPEN”;
4) Use the RMAN SWITCH TO command to switch the image copy
SWITCH DATAFILE 4 TO COPY;
5) Apply the archived redo logs
RECOVER DATAFILE 4;
3) Bring the data file online
SQL “ALTER DATABASE DATAFILE 4 ONLINE”;
B. The Non High Availability approach, this is the same technique as can be seen in the documentation for recovering from the loss of a “critical datafile”. Therefore this means that the rest of the database is unavailable for the duration of the repair. Use this technique if there are any objects in the user tablespace that have dependencies with objects in other tablespaces.
1) Mount the database
STARTUP MOUNT
4) Use the RMAN SWITCH TO command to switch the image copy
SWITCH DATAFILE 4 TO COPY;
5) Apply the archived redo logs
RECOVER DATAFILE 4;
6) Open the database
SQL “ALTER DATABASE OPEN”;