| Lesson 9 || Recovering without the current redo log |
| Objective || Demonstrate how to recover when the current redo log is lost. |
Recovering without current redo log
Current redo log is corrupt or lost
Sometimes, a current redo log is corrupt or lost due to a media failure. When the current redo log is lost, your database can be in either of the following states:
- The database is open, yet is in a "hung&qout; state
- The database is closed because of the media failure or a terminated background process
The first situation involves more troubleshooting than recovery. In the second situation, you need to perform an incomplete recovery.
Database open yet hung
If your database is still open, yet in a "hung" state, this indicates that the current redo log is either damaged or lost. You need to find the current log file and replace it as shown in the steps below:
SVRMGR>select * from V$log;
GROUP#...SEQUENCE# BYTES MEMBERS ARC STATUS ... FIRST_TIME
------ --------- ------- ------- --- -------- ---------------
1... 74 1048576 1 NO INACTIVE ...18-JAN-00:11:50
2... 75 1048576 1 NO CURRENT ...18-JAN-00:11:55
- Determine which log file group is the current one by querying V$LOG view. Click the View Code button.
The log file group 2 is the current log file
- Get rid of the damaged current log file by issuing the
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;statement.
Your database should function properly now. The log file will be overwritten if it is corrupt or recreated if it is lost. Remember, you need to make a whole database backup immediately in case your database needs another recovery.
The following SlideShow shows you the steps to perform a recovery without the current redo log in a situation where the database is closed due to media failure or a terminated background process.
You may also preview
all the steps.
- The DBA is informed that the database is not available
- The DBA tries to open the database(3) but fails. The message says that something is wrong with the online redo log file
- The DBA immediately queries the V$LOG view (5) and finds out the problematic log file in group 2 is the current redo log with the sequence number 482(6).
- The DBA shuts down the database(9) to restore all the datafiles(10).
- The DBA starts to recover the database using cancel-based recovery (11) and when prompted for the log to apply
- When log 482 is prompted, the DBA enters CANCEL to complete the recovery (13).
Recovery Through ControlFile - Quiz
Oracle RMAN Backup and Recovery