Recreating inactive redo logs in Oracle 12c involves identifying the inactive log files, dropping them, and recreating them. Here's a step-by-step guide:
Identify Inactive Redo Log Files:
Connect to the Oracle database using SQL*Plus or any other Oracle client tool.
Execute the following query to identify inactive redo log files:
SELECT GROUP_ID, MEMBER, STATUS
Look for log files with a status of 'INACTIVE'.
Drop Inactive Redo Log Files:
For each inactive redo log file, execute the following query to drop it:
ALTER SYSTEM DROP REDO LOGFILE group <group_id>;
Replace `<group_id>`with the actual group ID of the inactive log file.
Recreate Redo Log Files:
Once all inactive log files are dropped, you can recreate them using the ALTER DATABASE DROP command.
Execute the following query to recreate the redo log files:
ALTER DATABASE ADD LOGFILE group <group_id> ('<logfile_path1>','<logfile_path2>') SIZE <logfile_size>;
Replace `<group_id>` with the actual group ID of the log file to be recreated.
Replace `<logfile_path1>` and `` with the paths to the new redo log files.
Replace `<logfile_size>` with the desired size of the redo log files (in bytes).
Switch Logfile Group (Optional):
If you want to switch to the newly created redo log group, execute the following query:
ALTER SYSTEM SWITCH LOGFILE group <group_id>;
Replace `<group_id>` with the actual group ID of the newly created redo log group.
To ensure that all changes are committed to disk, execute the following query:
ALTER SYSTEM CHECKPOINT GLOBAL;
ALTER DATABASE CLEAR LOGFILE
The ALTER DATABASE CLEAR LOGFILE command drops and recreates the corrupt online redo file, but you can also perform this process manually. It's a helpful procedure to know if the ALTER DATABASE CLEAR LOGFILE command fails and reusing the currently configured log file name to recreate the log file becomes impossible. You may also preview all the steps.
Steps to recreate an Inactive Online Redo Log
To recreate an inactive online redo log manually, do the following:
When one of the multiplexed members of any group is corrupted or accidently dropped, the LGWR process ignores it and writes the information to the only available member. The following scenario gives a demonstration to easily understand the main concept:
b.group#, a.status, b.status, b.member
v$log a, v$logfile b
Add one member to each redo log group. Query all redo log members and their status:
GROUP# STATUS MEMBER
---- ------------ --------------------------------
1 CURRENT /u01/oracle/product/10.2.0/db_1/ora
2 INACTIVE /u01/oracle/product/10.2.0/db_1/ora
3 ACTIVE /u01/oracle/product/10.2.0/db_1/ora
The following series of images demonstrates how to perform an inactive redo log recovery.
Recreating an online redo log file
Since the database cannot be opened before the damaged online redo log is recreated, the DBA starts the database in the mount mode.
The DBA queries the data dictionary view V$LOGFILE to find the location to create the damaged redo log file(3).
Since there are more than two online redo logs, the DBA drops the corrupted online redo log (5)
The command lines and their results for the whole process are displayed below.
SQL> STARTUP OPEN PFILE='C:\ORANT\DATABASE\INITORCL.ORA'
ORACLE instance started.
Total System Global Area 11710464 bytes
Fixed Size 49152 bytes
Variable Size 11177984 bytes
Database Buffers 409600 bytes
Redo Buffers 73728 bytes
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: 'C:\ORANT\DATABASE\LOG2ORCL.ORA'
SQL> SELECT * FROM V$LOGFILE;
GROUP# STATUS MEMBER
------ ------- ----------------------------------------------
2 STALE C:\ORANT\DATABASE\LOG3ORCL.ORA
3 STALE C:\ORANT\DATABASE\LOG2ORCL.ORA
4 rows selected.
SQL> ALTER DATABASE DROP LOGFILE GROUP 3;
SQL> ALTER DATABASE ADD LOGFILE GROUP 3 'C:\ORANT\DATABASE\LOG2ORCL.ORA' SIZE 150k;
SQL> ALTER DATABASE OPEN;
The next lesson demonstrates how to obtain recovery status information through the data dictionary views.