Which statement about recovering from the loss of a redo log group is true?
A.
If the lost redo log group is ACTIVE, you should first attempt to clear the log file.
B.
If the lost redo log group is CURRENT, you must clear the log file.
C.
If the lost redo log group is ACTIVE, you must restore, perform cancel-based incomplete
recovery, and open the database using the RESETLOGS option.
D.
If the lost redo log group is CURRENT, you must restore, perform cancel-based
incomplete recovery, and open the database using the RESETLOGS option.
LOST REDO
CURRENT – Must restore, cancel-based incomplete recovery, open with reset log
ACTIVE – Checkpoint
INACITVE – Clear logfile
Yes D is the best answer, but for it to be the correct answer then I would suggest you proceed as follows
So the lost redo log group is CURRENT…
your instance may shut down in which case if the problem was temporary then just restart and instance recovery will take care of the rest, so you can continue to work as normal.
However if the instance does not restart correctly then you must either
1. restore, perform cancel-based incomplete recovery, and open the database using the RESETLOGS option
or
2. Flashback database to a point before the loss of the redo log group
In the end you also must backup immediately.
Comments would be appreciated.
Yes D is the best answer, but for it to be the correct answer then I would suggest you proceed as follows
So the lost redo log group is CURRENT…
If your database does not stop then attempt a
ALTER SYSTEM SWITCH LOGFILE;
then
ALTER SYSTEM CHECKPOINT;
if CHECKPOINT works then
ALTER DATABASE CLEAR LOGFILE GROUP x;
otherwise go to (A) below.
If your instance shuts down in which case if the problem was temporary then just restart and instance recovery will take care of the rest, so you can continue to work as normal.
However if the instance does not restart correctly then you must either
(A)
1. restore, perform cancel-based incomplete recovery, and open the database using the RESETLOGS option
or
2. Flashback database to a point before the loss of the redo log group
In the end you also must backup immediately.
Comments would be appreciated.
D is the most correct.
https://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo008.htm
Recovering After the Loss of All Members of an Online Redo Log Group
If a media failure damages all members of an online redo log group, then different scenarios can occur depending on the type of online redo log group affected by the failure and the archiving mode of the database.
If the damaged log group is active, then it is needed for crash recovery; otherwise, it is not.
If the group is…
Inactive
Then…
It is not needed for crash recovery
And you should…
Clear the archived or unarchived group.
If the group is . . .
Active
Then…
It is needed for crash recovery
And you should…
Attempt to issue a checkpoint and clear the log; if impossible, then you must restore a backup and perform incomplete recovery up to the most recent available redo log.
If the group is . . .
Current
Then…
It is the log that the database is currently writing to
And you should…
Attempt to clear the log; if impossible, then you must restore a backup and perform incomplete recovery up to the most recent available redo log.
Incomplete Recovery:
https://docs.oracle.com/cd/B19306_01/server.102/b14220/backrec.htm
Incomplete Recovery
Incomplete recovery, or point-in-time recovery, uses a backup to produce a noncurrent version of the database. In other words, you do not apply all of the redo records generated after the most recent backup. You usually perform incomplete recovery of the whole database in the following situations:
Media failure destroys some or all of the online redo logs.
A user error causes data loss, for example, a user inadvertently drops a table.
You cannot perform complete recovery because an archived redo log is missing.
You lose your current control file and must use a backup control file to open the database.
To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. The RESETLOGS operation creates a new incarnation of the database—in other words, a database with a new stream of log sequence numbers starting with log sequence 1.
Before using the OPEN RESETLOGS command to open the database in read/write mode after an incomplete recovery, it is a good idea to first open the database in read-only mode, and inspect the data to make sure that the database was recovered to the correct point. If the recovery was done to the wrong point, then it is easier to re-run the recovery if no OPEN RESETLOGS has been done. If you open the database read-only and discover that not enough recovery was done, then just run the recovery again to the desired time. If you discover that too much recovery was done, then you must restore the database again and re-run the recovery.