Your production database is running in archivelog mode and you are using recovery
manager (RMAN) with recovery catalog to perform the database backup at regular intervals.
When you attempt to restart the database instance after a regular maintenance task on
Sunday, the database fails to open displaying the message that the data file belonging to the
users tablespace are corrupted.
The steps to recover the damaged data files are follows:
1. Mount the database
2. Open the database
3. Recover the data file
4. Restore the data file
5. Make the data file offline
6. Make the data file online
Which option identifies the correct sequence that you must use to recover the data files?
A.
2, 4, 3
B.
1, 4, 3, 2
C.
2, 5, 4, 3, 6
D.
5, 2, 4, 3, 6
E.
1, 5, 4, 3, 6, 2
I think E is correct.
B is correct. You dont have to take datafile offline/online to restore and recover it while database in mount mode.
I agree with you. Clearly B is correct
D makes the most sense since the DB is a production DB and you might have other tablespaces that need to be used. This way the DB is accessible for other users while the recovery of users is done, assuming there are other apps/users other than those using the data in the users tablespace.
@Cuco: “[…]the database fails to open[…]”… i guess no other user can use any other tablespace. 😉
B.
B is incorrect because you don’t have to mount DB which is already mounted: “the database fails to open”.
So D is the most appropriate answer.
Correct answer is B.
If the database is in mount mode you don’t need to put the datafiles offline. It’s enough to do the restore, then the recovery. Finally open the database
B is incorrect because the database is already mounted. Since the tablespace is a user tablespace which belongs to a particular user, you will just take it offline while you open the database for everybody to access, then you can do your restore and recover and bring it back online if the process was successful. D is very correct.
I think you are correct. The DB is already mounted
A. (2, 4, 3) the database fails to open, so this will not work
B. (1, 4, 3, 2) this will definetly work, but it is not the best solution for High Availability reasons, see answer D.
C. (2, 5, 4, 3, 6) the database fails to open, so this will not work
D. (5, 2, 4, 3, 6) we dont know what state the database is in to begin with, assume mount in which case it will work correctly
E. (1, 5, 4, 3, 6, 2) does not make sense to place a datafile online when it is not open
@Wolfsrudel, please note that “cuco” does not open the database without taking the datafile offline first thus solving the reason why we cannot open the database. (Unless you can give us another reason as to why it does not open)
@vasya_pupkin, @ola, through my experience “mounting a database” can also mean “ensuring that the database is mounted”, because sometimes oracle messages can be misleading and reference must be made to the alert log file.