Using Online Redo Log Files

Online Redo logfiles have the following characteristics:

·Record all changes made to data

·Provide a recovery mechanism

·Can be organized into groups

·At least two groups required

Online Redo Log File Groups

·A set of identical copies of online redo log files is called an online redo log file group.

·The LGWR background process concurrently writes the same information to all online redo log files in a group.

·The Oracle server needs a minimum of two online redo log file groups for the normal operation of a database.

Online Redo Log File Members

·Each online redo log file in a group is called a member.

·Each member in a group has identical log sequence numbers and are of the same size.

·The LSN(log sequence number) is assigned each time that the Oracle server writes to log group to uniquely identify each online redo log file.

Multiplexing Redo Log Files

To protect against a failure involving the redo log itself, Oracle Database allows a multiplexed redo log, meaning that two or more identical copies of the redo log can be automatically maintained in separate locations. For the most benefit, the selocations should be on separate disks. Even if all copies of the redo log areon the same disk, however, the redundancy can help protect against I/O errors, file corruption, and so on. When redo log files are multiplexed, LGWR concurrently writes the same redo log information to multiple identical redolog files, there by eliminating a single point of redo log failure.

Multiplexing is implemented by creating groups of redo log files. A group consists of a redolog file and its multiplexed copies. Each identical copy is said to be a member of the group. Each redo log group is defined by a number, such as group 1,group 2, and so on.

Note: Oracle recommends that you multiplex your redo log files. The loss of thelog file data can be catastrophic if recovery is required. Note that when you multiplex the redo log, the database must increase the amount of I/O that it performs. Depending on your configuration, this may impact overall database performance.

How Redo Files Work

·Online Redolog files are used in a cyclic fashion.

·When an online redo log file is full, LGWR will move tothe next log group.

  -Called a log switch

  -Checkpoint operation also occurs

  -Information written to the control file

The act of switching from one log file group to the other is called a log switch. A checkpoint is the writing of dirty (modified) blocks from the buffer cache to disk.

When will LGWR write redo?

·When a transaction commits.

·Every three seconds.

·When the Redo Log Buffer becomes one-third full.

·When there is more than a megabyte of changed records in the Redo Log Buffer.

·Before the DBWn writes modified blocks in the Database Buffer Cache to the data files.

Force Log Switches & Checkpoint

·Forcing a log switch:

SQL> ALTER SYSTEM SWITCH LOGFILE;

·Checkpoint scan be forced by:

  -Setting FAST_START_MTTR_TARGET parameter

    fast_start_mttr_target = 600

  -ALTER SYSTEM CHECKPOINT command

SQL> ALTER SYSTEM CHECKPOINT;

Adding Redo Files Groups

SQL> ALTER DATABASE ADD LOGFILE GROUP 4

(‘/u01/app/oradata/example/redo04a.rdo‘,

‘/u01/app/oradata/example/redo04b.rdo‘) SIZE 100M;

·Add a group:

SQL> alter database add logfile group 4

‘/u01/app/oradata/example/redo04a.log‘ size 60M;

·Add a member to group:

SQL> alter database add logfile member

‘/u01/app/oradata/example/redo04b.rdo‘ to group 4;

Dropping Redo Log Members

·To drop a redo log member, you must have the ALTER DATABASE system privilege. 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 there by 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 orcorrect. 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. To drop a memberof an active group, first force a log switch to occur.

·Make sure the group towhich 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.

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, ensure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file.

Drop a member:

SQL> ALTER DATABASE DROP LOGFILE MEMBER ‘/u01/app/oradata/example/redo05b.rdo‘;

Dropping Redo Files groups

·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 must drop the current group, then 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.

Drop a group:

SQL> ALTER DATABASE DROP LOGFILE GROUP 5;

Relocate & Rename redolog

You can use operating system commands to relocate redo logs, then use the ALTER DATABASE statement to make their new names (locations) known to the database. This procedure is necessary, for example, if the disk currently used for some redo log files is going to be removed, or if datafiles and several redo log files are storedon the same disk and should be separated to reduce contention.

To rename redo log members, you must have the ALTER DATABASE system privilege. Additionally, you might also need operating system privileges to copy files to the desired location and privileges to open and back up the database.

Before relocating your redo logs, or making any other structural changes to the database, completely back up the database in case you experience problems while performing the operation. As a precaution, after renaming or relocating a set of redo log files, immediately back up the database control file.

Relocate or rename online redo log files in one of the two following way:

·ALTER DATABASE RENAME FILE command.

    1.Shut down the database.

    SQL> select group#,status,type,member from v$logfile;

    SQL> shutdown immediate;

    2.Copy the online redo log files to the new location.

    $ mv /u01/app/oradata/example/redo04.log /u01/app/oradata/example/redo04a.rdo

    3.Place the database in MOUNT mode.

    SQL> startup mount;

    4.Execute the command.

    SQL> alter database rename file ‘/u01/app/oradata/example/redo04.log‘

to ‘/u01/app/oradata/example/redo04a.rdo‘;

    5.Open database for normal operation.

    SQL> alter database open;

·Add new members and drop old members.

Clear Redo Files:

·ALTER DATABASE CLEARLOGFILE command can be used to reinitialize an online redo log file.

SQL> alter database clear logfile group 4;

·Use the UNARCHIVED keyword to avoid archiving the corrupted online redo log file.

SQL> alter database clear unarchived logfile group 4;

Placing Redo Log Members on Different Disks

When setting up a multiplexed redo log, place members of a group on different physical disks. If a single disk fails, then only one member of a group becomes unavailable to LGWR and other members remain accessible to LGWR, so the instance can continue to function.

If you archive theredo log, spread redo log members across disks to eliminate contention between the LGWR and ARCn background processes. For example, if you have two groups of multiplexed redo log members (a duplexed redo log), place each member on a different disk and set your archiving destination to a fifth disk. Doing so will avoid contention between LGWR (writing to the members) and ARCn (reading the members).

Datafiles should also be placed on different disks from redo log files to reduce contention in writing data blocks and redo records.

RedoLog Data Dictionary Views

·V$LOG          Displays the redo log file information from the control file

·V$LOGFILE      Identifies redo log groups and members and member status

·V$LOG_HISTORY  Contains log history information

本文出自 “~Never” 博客，请务必保留此出处http://ospub.blog.51cto.com/6238506/1591527

管理联机重做日志