Operations on Redo Log’s Files

Steps for Renaming Redo Log Members

Shut down the database.

1.             SHUTDOWN

2. Copy the redo log files to the new location.Operating system files, such as redo log members, must be copied using the appropriate operating system commands. See your operating system specific documentation for more information about copying files.

The following example uses operating system commands (UNIX) to move the redo log members to a new location:

mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo

mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo

3. Startup the database, mount, but do not open it.

4.             CONNECT / as SYSDBA

5.             STARTUP MOUNT

6. Rename the redo log members.

Use the ALTER DATABASE statement with the RENAME FILE clause to rename the database redo log files.

ALTER DATABASE 

  RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo' 

           TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo';

7. Open the database for normal operation.

The redo log alterations take effect when the database is opened.

ALTER DATABASE OPEN; 

Dropping Log Groups

To drop a redo log group, you must have the ALTER DATABASE system privilege. Before dropping a redo log group, consider the following restrictions and precautions:

· An instance requires at least two groups of redo log files, regardless of the number of members in the groups. (A group comprises one or more members.)

· You can drop a redo log group only if it is inactive. If you need to drop the current group, first force a log switch to occur.

· Make sure a redo log group is archived (if archiving is enabled) before dropping it. To see whether this has happened, use the V$LOG view.

·                SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

·                   GROUP# ARC STATUS

·                --------- --- ----------------

·                        1 YES ACTIVE

·                        2 NO  CURRENT

·                        3 YES INACTIVE

·                        4 YES INACTIVE

Drop a redo log group with the SQL statement ALTER DATABASE with the DROP LOGFILE clause.

The following statement drops redo log group number 3:

ALTER DATABASE DROP LOGFILE GROUP 3;

When a redo log group is dropped from the database, and you are not using the Oracle-managed files feature, the operating system files are not deleted from disk. Rather, the control files of the associated database are updated to drop the members of the group from the database structure. After dropping a redo log group, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log files.

When using Oracle-managed files, the cleanup of operating systems files is done automatically for you.

Dropping Redo Log Members

To drop a redo log member, you must have the ALTER DATABASE system privilege. Consider the following restrictions and precautions before dropping individual redo log members:

· It is permissible to drop redo log files so that a multiplexed redo log becomes temporarily asymmetric. For example, if you use duplexed groups of redo log files, you can drop one member of one group, even though all other groups have two members each. However, you should rectify this situation immediately so that all groups have at least two members, and thereby eliminate the single point of failure possible for the redo log.

· An instance always requires at least two valid groups of redo log files, regardless of the number of members in the groups. (A group comprises one or more members.) If the member you want to drop is the last valid member of the group, you cannot drop the member until the other members become valid. To see a redo log file status, use the V$LOGFILE view. A redo log file becomes INVALID if the database cannot access it. It becomes STALE if the database suspects that it is not complete or correct. A stale log file becomes valid again the next time its group is made the active group.

· You can drop a redo log member only if it is not part of an active or current group. If you want to drop a member of an active group, first force a log switch to occur.

· Make sure the group to which a redo log member belongs is archived (if archiving is enabled) before dropping the member. To see whether this has happened, use the V$LOG view.

To drop specific inactive redo log members, use the ALTER DATABASE statement with the DROP LOGFILE MEMBER clause.

The following statement drops the redo log /oracle/dbs/log3c.rdo:

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

When a redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure. After dropping a redo log file, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file.

To drop a member of an active group, you must first force a log switch.

Forcing Log Switches

A log switch occurs when LGWR stops writing to one redo log group and starts writing to another. By default, a log switch occurs automatically when the current redo log file group fills.

You can force a log switch to make the currently active group inactive and available for redo log maintenance operations. For example, you want to drop the currently active group, but are not able to do so until the group is inactive. You may also wish to force a log switch if the currently active group needs to be archived at a specific time before the members of the group are completely filled. This option is useful in configurations with large redo log files that take a long time to fill.

To force a log switch, you must have the ALTER SYSTEM privilege. Use the ALTER SYSTEM statement with the SWITCH LOGFILE clause.

The following statement forces a log switch:

ALTER SYSTEM SWITCH LOGFILE;

Redo Log File Status

To see the status of the redo log file there are two dynamic views are there.
A)V$LOG
B)V$LOGFILE

A)V$LOG:
———-
V$LOG displays redo log file information from the control file.

Status:
——–
1)UNUSED – Online redo log has never been written to. This is the state of a redo log that was just added, or just after a RESETLOGS, when it is not the current redo log.

2)CURRENT – Current redo log. This implies that the redo log is active. The redo log could be open or closed.

3)ACTIVE – Log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It may or may not be archived.

4)CLEARING – Log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, the status changes to UNUSED.

5)CLEARING_CURRENT – Current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.

6)INACTIVE – Log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.

B)V$LOGFILE:
——————
V$LOGFILE view contains information about redo log files.
1)INVALID – The file is corrupted or missing.
2)STALE -This redo log file member is new and has never been used.
3)DELETED -The file is no longer being used.
4) -The redo log file is in use and is not corrupted.