ITPub博客

首页 > 数据库 > Oracle > Master Note: Overview of Redo Logs and Archiving_1503091.1

Master Note: Overview of Redo Logs and Archiving_1503091.1

Oracle 作者:rongshiyuan 时间:2014-02-13 14:55:49 0 删除 编辑

Master Note: Overview of Redo Logs and Archiving (Doc ID 1503091.1)

In this Document

Purpose
Details
  What is the Redo Log?
  Creating Redo Log Groups
  Forcing Log Switches
  Clearing a Redo Log file
  Redo Log Data Dictionary Views
  What is the Archived Redo log?
  Choosing Between NOARCHIVELOG and ARCHIVELOG Mode
  Running a Database in NOARCHIVELOG Mode
  Running a Database in ARCHIVELOG Mode
 
Performing Manual Archiving
  Adjusting the Number of Archiver Processes
  Setting Initialization Parameters for Archive Destinations
  Archive Destination Status
  Viewing Information About the Archived Redo Log
References

Applies to:

Oracle Server - Enterprise Edition - Version 10.2.0.1 and later
Information in this document applies to any platform.

Purpose

This note discusses basic information on online and archived Redo Log files and how to manage them within the Oracle Database.

If you want to read more about the same, please refer to the Oracle 11g Documentation at:
http://docs.oracle.com/cd/E11882_01/server.112/e25494/archredo.htm#ADMIN008

Details

What is the Redo Log?

Redo Logs consist of two or more pre-allocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has associated online redo logs to protect the database in case of an instance failure.
Redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database.
Redo entries record data that you can use to re-construct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.
Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.

The Oracle Database uses only one redo log file at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file. Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.
If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARCn) has archived the file. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the first available active file.

To know how Oracle Database Writes to the Redo Log, please check the documentation at:
http://docs.oracle.com/cd/E11882_01/server.112/e25494/onlineredo001.htm#i1006163


Creating Redo Log Groups

To create a new group of redo log files, use the SQL statement ALTER DATABASE with the ADD LOGFILE clause.
The following statement adds a new group of redo logs to the database:

ALTER DATABASE
ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 100M;

You can also specify the number that identifies the group using the GROUP clause, e,g,:

ALTER DATABASE
ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo')
SIZE 100M BLOCKSIZE 512;

When using the ALTER DATABASE statement, you can alternatively identify the target group by specifying all of the other members of the group in the TO clause, as shown in the following example:

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo'
TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

 

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 want to force a log switch if the currently active group must 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;

 

Clearing a Redo Log file

A redo log file might become corrupted while the database is open, and ultimately stop database activity because archiving cannot continue. In this situation the ALTER DATABASE CLEAR LOGFILE statement can be used to reinitialize the file without shutting down the database.
Example:

ALTER DATABASE CLEAR LOGFILE GROUP ;

This statement overcomes two situations where dropping redo logs is not possible:

  • If there are only two log groups
  • The corrupt redo log file belongs to the current group

If the corrupt redo log file has not been archived, use the UNARCHIVED keyword in the statement.

ALTER DATABASE CLEAR UNARCHIVED LOGFILE ;

This statement clears the corrupted redo logs and avoids archiving them. The cleared redo logs are available for use even though they were not archived.

NOTE:
If you clear a log file that is needed for recovery of a backup, then you can no longer recover from that backup.
The database writes a message in the alert log describing the backups from which you cannot recover.

 

Redo Log Data Dictionary Views

The following views provide information on redo logs

View Description
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


What is the Archived Redo log?

The Oracle Database lets you save filled groups of redo log files to one or more offline destinations, known collectively as the archived redo log. The process of turning redo log files into archived redo log files is called archiving. This process is only possible if the database is running in ARCHIVELOG mode. You can choose automatic or manual archiving.
An archived redo log file is a copy of one of the filled members of a redo log group. It includes the redo entries and the unique log sequence number of the identical member of the redo log group.

Choosing Between NOARCHIVELOG and ARCHIVELOG Mode

The choice whether or not to enable the archiving of filled groups of redo log files depends on the availability and reliability requirements of the application running on the database. If you cannot afford to lose any data in your database in the event of a disk failure, use ARCHIVELOG mode.

Running a Database in NOARCHIVELOG Mode

When you run your database in NOARCHIVELOG mode, you disable the archiving of the redo log. The database control file indicates that filled groups are not required to be archived.
NOARCHIVELOG mode protects a database from instance failure but not from media failure. Only the most recent changes made to the database, which are stored in the online redo log groups, are available for instance recovery.
In NOARCHIVELOG mode you cannot perform online tablespace backups, nor can you use online tablespace backups taken earlier while the database was in ARCHIVELOG mode.

Running a Database in ARCHIVELOG Mode

When you run a database in ARCHIVELOG mode, you enable the archiving of the redo log. The database control file indicates that a group of filled redo log files cannot be reused by LGWR until the group is archived. A filled group becomes available for archiving immediately after a redo log switch occurs.
The archiving of filled groups has these advantages:

  • A database backup, together with online and archived redo log files, guarantees that you can recover all committed transactions in the event of an operating system or disk failure.
  • If you keep archived logs, you can use a backup taken while the database is open and in normal system use.
  • You can keep a standby database current with its original database by continually applying the original archived redo logs to the standby.
For information on how to Turn Archiving ON and OFF in Oracle RDBMS, please refer to Note 69739.1


Performing Manual Archiving

You can configure your database for manual archiving only. To operate your database in manual archiving mode, follow the procedure below:

1.Shut down the database instance.
SQL> SHUTDOWN
An open database must first be closed and any associated instances shut down before you can switch the database archiving mode. You cannot change the mode from ARCHIVELOG to NOARCHIVELOG if any datafiles need media recovery.

2.Back up the database.
Before making any major change to a database, always back up the database to protect against any problems. This will be your final backup of the database in NOARCHIVELOG mode and can be used if something goes wrong during the change to ARCHIVELOG mode.

3.Edit the initialization parameter file to include the initialization parameters that specify the destinations for the archived redo log files.

4.Start a new instance and mount, but do not open, the database.
SQL> STARTUP MOUNT
To enable or disable archiving, the database must be mounted but not open.

5.Change the database archiving mode. Then open the database for normal operations.
SQL> ALTER DATABASE ARCHIVELOG MANUAL;
SQL> ALTER DATABASE OPEN;

6.Shut down the database.
SQL> SHUTDOWN IMMEDIATE

7.Back up the database.
Changing the database archiving mode updates the control file. After changing the database archiving mode, you must back up all of your database files and control file. Any previous backup is no longer usable because it was taken in NOARCHIVELOG mode.

When you operate your database in manual ARCHIVELOG mode, you must archive inactive groups of filled redo log files or your database operation can be temporarily suspended. To archive a filled redo log group manually, connect with administrator privileges. Ensure that the database is either mounted or open. Use the ALTER SYSTEM statement with the ARCHIVE LOG clause to manually archive filled redo log files. The following statement archives all unarchived log files:

SQL> ALTER SYSTEM ARCHIVE LOG ALL;

 

Even when automatic archiving is enabled, you can use manual archiving for such actions as rearchiving an inactive group of filled redo log members to another location

 

Adjusting the Number of Archiver Processes

The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the number of ARCn processes that the database initially starts. The default is four processes. There is usually no need specify this initialization parameter or to change its default value, because the database starts additional archiver processes (ARCn) as needed.
The following statement configures the database to start six ARCn processes upon startup:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=6;

The statement has an immediate effect on the currently running instance.

 

Setting Initialization Parameters for Archive Destinations

You can choose to archive redo logs to a single destination or to multiple destinations. Destinations can be local - within the local file system or an Oracle Automatic Storage Management (Oracle ASM) disk group - or remote (e.g. on a standby database).
To archive to only a single destination, specify that destination using the LOG_ARCHIVE_DEST initialization parameter. To archive to multiple destinations, you can choose to archive to two or more locations using the LOG_ARCHIVE_DEST_n initialization parameters, or to archive only to a primary and secondary destination using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters.

For more information, please refer to the Oracle 11g Documentation at:
http://docs.oracle.com/cd/E11882_01/server.112/e25494/archredo004.htm#i1006405

 

Archive Destination Status

Each archive destination has the following variable characteristics that determine its status:

  • Valid/Invalid: indicates whether the disk location or service name information is specified and valid.
  • Enabled/Disabled: indicates the availability state of the location and whether the database can use the destination.
  • Active/Inactive: indicates whether there was a problem accessing the destination.

 

Viewing Information About the Archived Redo Log

You can display information about the archived redo log using dynamic performance views or the ARCHIVE LOG LIST command.

Dynamic Performance View Description
V$DATABASE Shows if the database is in ARCHIVELOG or NOARCHIVELOG mode and if MANUAL (archiving mode) has been specified.
V$ARCHIVED_LOG Displays historical archived log information from the control file. If you use a recovery catalog, the RC_ARCHIVED_LOG view contains similar information.
V$ARCHIVE_DEST Describes the current instance, all archive destinations, and the current value, mode, and status of these destinations.
V$ARCHIVE_PROCESSES Displays information about the state of the various archive processes for an instance.
V$BACKUP_REDOLOG Contains information about any backups of archived logs. If you use a recovery catalog, the RC_BACKUP_REDOLOG contains similar information.
V$LOG Displays all redo log groups for the database and indicates which need to be archived.
V$LOG_HISTORY Contains log history information such as which logs have been archived and the SCN range for each archived log.

References

NOTE:69739.1 - How to Turn Archiving ON and OFF in Oracle RDBMS
NOTE:1507157.1 - Master Note: Troubleshooting Redo Logs and Archiving

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17252115/viewspace-1080860/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-11-24

  • 博文量
    798
  • 访问量
    3213552