Databases Reference
In-Depth Information
3.
Attempt to issue a checkpoint.
4.
If the checkpoint is successful, the status should now be INACTIVE, and you can clear the
log group.
5.
If the log group that was cleared was unarchived, back up your database immediately.
6.
If the checkpoint is unsuccessful, then you will have to perform incomplete recovery (see
Recipe 14-5 for options).
Inspect your target database alert.log file, and verify the damage. You should see a message in the alert.log file
identifying the bad members:
ORA-00312: online log 2 thread 1: '/u01/oraredo/o12c/redo02a.rdo'
ORA-00312: online log 2 thread 1: '/u02/oraredo/o12c/redo02b.rdo'
Next, verify that the damaged log group has an ACTIVE status as follows:
$ sqlplus / as sysdba
SQL> startup mount;
Run the following query:
select group#, status, archived, thread#, sequence#
from v$log;
Here is some sample output:
GROUP# STATUS ARC THREAD# SEQUENCE#
------ ---------------- --- -------- ----------
1 CURRENT NO 1 92
2 ACTIVE YES 1 91
3 INACTIVE YES 1 90
If the status is ACTIVE, then attempt to issue an alter system checkpoint command, as shown here:
SQL> alter system checkpoint;
System altered.
If the checkpoint completes successfully, then the active log group should be marked as INACTIVE. A successful
checkpoint ensures that all modified database buffers have been written to disk, and at that point, only transactions
contained in the CURRENT online redo log will be required for crash recovery.
■
if the checkpoint is unsuccessful, you will have to perform incomplete recovery. see recipe 14-5 for a full list
of options in this scenario.
Note
If the status is INACTIVE and the log has been archived, you can use the
clear logfile
command to re-create
the log group, as shown here:
SQL> alter database clear logfile group <group#>;
