Skip Headers

Oracle9i Database Administrator's Guide
Release 2 (9.2)

Part Number A96521-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

8
Managing Archived Redo Logs

This chapter describes how to archive redo data. It contains the following topics:

What Is the Archived Redo Log?

Oracle enables you to save filled groups of online redo log files to one or more offline destinations, known collectively as the archived redo log, or more simply archive log. The process of turning online 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 identical filled members of an online redo log group. It includes the redo entries present in the identical member of a redo log group and also preserves the group's unique log sequence number. For example, if you are multiplexing your online redo log, and if Group 1 contains member files a_log1 and b_log1, then the archiver process (ARCn) will archive one of these identical members. Should a_log1 become corrupted, then ARCn can still archive the identical b_log1. The archived redo log contains a copy of every group created since you enabled archiving.

When running in ARCHIVELOG mode, the log writer process (LGWR) is not allowed to reuse and hence overwrite an online redo log group until it has been archived. The background process ARCn automates archiving operations when automatic archiving is enabled. Oracle starts multiple archiver processes as needed to ensure that the archiving of filled online redo logs does not fall behind.

You can use archived redo logs to:

Choosing Between NOARCHIVELOG and ARCHIVELOG Mode

This section describes the issues you must consider when choosing to run your database in NOARCHIVELOG or ARCHIVELOG mode, and contains these topics:

Running a Database in NOARCHIVELOG Mode

When you run your database in NOARCHIVELOG mode, you disable the archiving of the online redo log. The database's control file indicates that filled groups are not required to be archived. Therefore, when a filled group becomes inactive after a log switch, the group is available for reuse by LGWR.

The choice of whether to enable the archiving of filled groups of online 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. The archiving of filled online redo log files can require you to perform extra administrative operations.

NOARCHIVELOG mode protects a database only from instance failure, but not from media failure. Only the most recent changes made to the database, which are stored in the groups of the online redo log, are available for instance recovery. In other words, if a media failure occurs while in NOARCHIVELOG mode, you can only restore (not recover) the database to the point of the most recent full database backup. You cannot recover subsequent transactions.

Also, in NOARCHIVELOG mode you cannot perform online tablespace backups. Furthermore, you cannot use online tablespace backups previously taken while the database operated in ARCHIVELOG mode. You can only use whole database backups taken while the database is closed to restore a database operating in NOARCHIVELOG mode. Therefore, if you decide to operate a database in NOARCHIVELOG mode, take whole database backups at regular, frequent intervals.

Running a Database in ARCHIVELOG Mode

When you run a database in ARCHIVELOG mode, you specify the archiving of the online redo log. The database control file indicates that a group of filled online redo log files cannot be used by LGWR until the group is archived. A filled group is immediately available for archiving after a redo log switch occurs.

The archiving of filled groups has these advantages:

Decide how you plan to archive filled groups of the online redo log. You can configure an instance to archive filled online redo log files automatically, or you can archive manually. For convenience and efficiency, automatic archiving is usually best. Figure 8-1 illustrates how the archiver process (ARC0 in this illustration) writes filled online redo log files to the database's archived redo log.

If all databases in a distributed database operate in ARCHIVELOG mode, you can perform coordinated distributed database recovery. If any database in a distributed database uses NOARCHIVELOG mode, however, recovery of a global distributed database (to make all databases consistent) is limited by the last full backup of any database operating in NOARCHIVELOG mode.

Figure 8-1 Online Redo Log File Use in ARCHIVELOG Mode

Text description of admin056.gif follows
Text description of the illustration admin056.gif


Controlling Archiving

This section describes how to control the archiving mode of the database, and how to control the archiving process. The following topics are discussed:

Setting the Initial Database Archiving Mode

You set a database's initial archiving mode as part of database creation in the CREATE DATABASE statement. Usually, you can use the default of NOARCHIVELOG mode at database creation because there is no need to archive the redo information generated then. After creating the database, decide whether to change from the initial archiving mode.


Note:

If a database is automatically created during Oracle installation, the initial archiving mode of the database is operating system specific.


Changing the Database Archiving Mode

To switch a database's archiving mode, use the ALTER DATABASE statement with the ARCHIVELOG or NOARCHIVELOG option. The following steps switch a database's archiving mode from NOARCHIVELOG to ARCHIVELOG:

  1. Shut down the database instance.
    SHUTDOWN
    
    

    An open database must first be closed and any associated instances shut down before you can switch the database's archiving mode. You cannot disable archiving 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 while trying to change to ARCHIVELOG mode. See Oracle9i User-Managed Backup and Recovery Guide or Oracle9i Recovery Manager User's Guide.

  3. Edit the initialization parameter file to include initialization parameters specifying whether automatic archiving is enabled (see "Enabling Automatic Archiving") and the destinations for the archive log files (see "Specifying Archive Destinations").
  4. Start a new instance and mount, but do not open, the database.
    STARTUP MOUNT
    
    

    To enable or disable archiving, the database must be mounted but not open.

  5. Switch the database's archiving mode. Then open the database for normal operations.
    ALTER DATABASE ARCHIVELOG;
    ALTER DATABASE OPEN;
    
    
  6. Shut down the database.
    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.

    See Also:

    Oracle9i Real Application Clusters Administration for more information about switching the archiving mode when using Oracle9i Real Application Clusters

Enabling Automatic Archiving

You can enable automatic archiving of the online redo log. When automatic archiving is enabled, no action is required to copy a group after it fills: Oracle automatically archives it. However, even when automatic archiving is enabled, you can still perform manual archiving as described in "Performing Manual Archiving" .

You can enable automatic archiving before or after instance startup. To enable automatic archiving after instance startup, you must be connected to Oracle with administrator privileges (AS SYSDBA), or have the ALTER SYSTEM system privilege.

Ensure that an archived redo log destination and file name format have been specified before enabling automatic archiving. This is described in "Specifying Archive Destinations".


Caution:

Oracle does not automatically archive log files unless the database is also in ARCHIVELOG mode.


Enabling Automatic Archiving at Instance Startup

To enable automatic archiving of filled groups each time an instance is started, include the initialization parameter LOG_ARCHIVE_START in the database's initialization parameter file and set it to TRUE:

LOG_ARCHIVE_START=TRUE

The new value takes effect the next time you start the database.

Enabling Automatic Archiving After Instance Startup

To enable automatic archiving of filled online redo log groups without shutting down the current instance, use the ALTER SYSTEM statement specifying the ARCHIVE LOG START clause. For example:

ALTER SYSTEM ARCHIVE LOG START;

You can optionally include the archiving destination.


Note:

If an instance is shut down and restarted after automatic archiving is enabled using the ALTER SYSTEM statement, the instance is reinitialized using the settings of the initialization parameter file. Those settings may or may not enable automatic archiving. If your intent is to always archive redo log files automatically, then you should include LOG_ARCHIVE_START = TRUE in your initialization parameters.


Controlling the Number of Archiver Processes

Oracle starts additional archiver processes (ARCn) as needed to ensure that the automatic processing of filled redo log files does not fall behind. However, to avoid any runtime overhead of invoking additional ARCn processes, you can specify the number of processes to be started at instance startup using the LOG_ARCHIVE_MAX_PROCESSES initialization parameter. Up to 10 ARCn processes can be started.

This parameter also limits the number of ARCn processes that can be started for the instance. No more than the specified number of processes can ever be started.

The LOG_ARCHIVE_MAX_PROCESSES is dynamic, and can be changed using the ALTER SYSTEM statement. The following statement increases (or decreases) the number of ARCn processes currently running:

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;

There is usually no need to change the LOG_ARCHIVE_MAX_PROCESSES initialization parameter from its default value of 2, because Oracle will adequately adjust ARCn processes according to system workload.

Disabling Automatic Archiving

You can disable automatic archiving of the online redo log groups at any time. After having disabled automatic archiving, you must manually archive groups of online redo log files in a timely fashion. If you run a database in ARCHIVELOG mode and disable automatic archiving, and if all groups of online redo log files are filled but not archived, then LGWR cannot reuse any inactive groups of online redo log groups. Therefore, database operation is temporarily suspended until you perform the necessary archiving.

You can disable automatic archiving at or after instance startup. To disable automatic archiving after instance startup, you must be connected with administrator privileges or have the ALTER SYSTEM privilege.

Disabling Automatic Archiving at Instance Startup

To disable the automatic archiving of filled online redo log groups at database startup, set the LOG_ARCHIVE_START initialization parameter to FALSE:

LOG_ARCHIVE_START=FALSE

Disabling Automatic Archiving after Instance Startup

To disable the automatic archiving of filled online redo log groups without shutting down the current instance, use the SQL statement ALTER SYSTEM with the ARCHIVE LOG STOP parameter. The following statement stops archiving:

ALTER SYSTEM ARCHIVE LOG STOP;

If ARCn is archiving a redo log group when you attempt to disable automatic archiving, ARCn finishes archiving the current group, but does not begin archiving the next filled online redo log group.

The instance does not have to be shut down to disable automatic archiving. If an instance is shut down and restarted after automatic archiving is disabled, however, the instance is reinitialized using the settings of the initialization parameter file, which may or may not enable automatic archiving.

Performing Manual Archiving

If you operate your database in ARCHIVELOG mode, but do not have automatic archiving enabled, then you must archive inactive groups of filled online redo log files or your database operation can be temporarily suspended.

You can also use manual archiving, even when automatic archiving is enabled, for such action as rearchiving an inactive group of filled online redo log members to another location. In this case, however, it is possible that the instance can reuse the redo log group before you have finished manually archiving, and thereby overwrite the files. If this happens, Oracle will write an error message to the alert file.

To archive a filled online redo log group manually, connect with administrator privileges. Use the ALTER SYSTEM statement with the ARCHIVE LOG clause to manually archive filled online redo log files. The following statement archives all unarchived log files:

ALTER SYSTEM ARCHIVE LOG ALL;

Specifying the Archive Destination

When archiving redo logs, determine the destination to which you will archive and familiarize yourself with the various destination states. Develop a practice of using dynamic performance (V$) views, listed in "Viewing Information About the Archived Redo Log", to access archive information.

The following topics are contained in this section

Specifying Archive Destinations

You must decide whether to make a single destination for the logs or multiplex them. When you multiplex them, you archive the logs to more than one location. You specify your choice by setting initialization parameters according to one of the following methods.

Method Initialization Parameter Host Example

1

LOG_ARCHIVE_DEST_n

where:

n is an integer from 1 to 10

Local or remote

LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arc'

LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1'

2

LOG_ARCHIVE_DEST and

LOG_ARCHIVE_DUPLEX_DEST

Local only

LOG_ARCHIVE_DEST = '/disk1/arc'

LOG_ARCHIVE_DUPLEX_DEST = '/disk2/arc'

See Also:
  • Oracle9i Database Reference for additional information about the initialization parameters used to control the archiving of redo logs
  • Oracle9i Data Guard Concepts and Administration for information about using the LOG_ARCHIVE_DEST_n initialization parameter for specifying a standby destination. There are additional keywords that can be specified with this initialization parameter and that are not discussed in this book.

Method 1: Using the LOG_ARCHIVE_DEST_n Parameter

The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 10) to specify from one to ten different destinations for archival. Each numerically-suffixed parameter uniquely identifies an individual destination.

You specify the location for LOG_ARCHIVE_DEST_n using these keywords:

Keyword Indicates Example

LOCATION

A local file system location.

LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arc'

SERVICE

Remote archival through Oracle Net service name.

LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1'

If you use the LOCATION keyword, specify a valid path name for your operating system. If you specify SERVICE, Oracle translates the net service name through the tnsnames.ora file to a connect descriptor. The descriptor contains the information necessary for connecting to the remote database. The service name must have an associated database SID, so that Oracle correctly updates the log history of the control file for the standby database.

Perform the following steps to set the destination for archived redo logs using the LOG_ARCHIVE_DEST_n initialization parameter:

  1. Use SQL*Plus to shut down the database.
    SHUTDOWN 
    
    
  2. Edit the LOG_ARCHIVE_DEST_n parameter to specify from one to ten archiving locations. The LOCATION keyword specifies an operating system specific path name. For example, enter:
    LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive'
    LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive'
    LOG_ARCHIVE_DEST_3 = 'LOCATION = /disk3/archive'
    
    

    If you are archiving to a standby database, use the SERVICE keyword to specify a valid net service name from the tnsnames.ora file. For example, enter:

    LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'
    
    
  3. Edit the LOG_ARCHIVE_FORMAT initialization parameter, using %s to include the log sequence number as part of the file name and %t to include the thread number. Use capital letters (%S and %T) to pad the file name to the left with zeroes. For example, enter:
    LOG_ARCHIVE_FORMAT = arch%s.arc
    
    

    These settings will generate archived logs as follows for log sequence numbers 100, 101, and 102:

    /disk1/archive/arch100.arc, /disk1/archive/arch101.arc,
    /disk1/archive/arch102.arc
    
    /disk2/archive/arch100.arc, /disk2/archive/arch101.arc,
    /disk2/archive/arch102.arc
    
    /disk3/archive/arch100.arc, /disk3/archive/arch101.arc,
    /disk3/archive/arch102.arc
    
    

Method 2: Using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST

The second method, which allows you to specify a maximum of two locations, is to use the LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DEST to specify an optional secondary archive destination. Whenever Oracle archives a redo log, it archives it to every destination specified by either set of parameters.

Perform the following steps to use method 2:

  1. Use SQL*Plus to shut down the database.
    SHUTDOWN
    
    
  2. Specify destinations for the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameter (you can also specify LOG_ARCHIVE_DUPLEX_DEST dynamically using the ALTER SYSTEM statement). For example, enter:
    LOG_ARCHIVE_DEST = '/disk1/archive'
    LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'
    
    
  3. Edit the LOG_ARCHIVE_FORMAT parameter, using %s to include the log sequence number as part of the file name and %t to include the thread number. Use capital letters (%S and %T) to pad the file name to the left with zeroes. For example, enter:
    LOG_ARCHIVE_FORMAT = arch_%t_%s.arc
    
    

    For example, the above settings generates archived logs as follows for log sequence numbers 100 and 101 in thread 1:

    /disk1/archive/arch_1_100.arc, /disk1/archive/arch_1_101.arc
    /disk2/archive/arch_1_100.arc, /disk2/archive/arch_1_101.arc
    
    See Also:

    The following books contain more information about archiving and standby databases:

Understanding Archive Destination Status

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

Several combinations of these characteristics are possible. To obtain the current status and other information about each destination for an instance, query the V$ARCHIVE_DEST view.

The characteristics determining a locations status that appear in the view are shown in Table 8-1. Note that for a destination to be used, its characteristics must be valid, enabled, and active.

Table 8-1 Destination Status 
Characteristics
STATUS Valid Enabled Active Meaning

VALID

True

True

True

The user has properly initialized the destination, which is available for archiving.

INACTIVE

False

n/a

n/a

The user has not provided or has deleted the destination information.

ERROR

True

True

False

An error occurred creating or writing to the destination file; refer to error data.

FULL

True

True

False

Destination is full (no disk space).

DEFERRED

True

False

True

The user manually and temporarily disabled the destination.

DISABLED

True

False

False

The user manually and temporarily disabled the destination following an error; refer to error data.

BAD PARAM

n/a

n/a

n/a

A parameter error occurred; refer to error data. Usually this state is only seen when the LOG_ARCHIVE_START initialization parameter is not set.

The LOG_ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10) initialization parameter allows you to control the availability state of the specified destination (n). The destination state can have three values: ENABLE,DEFER, or ALTERNATE. The value ENABLE indicates that Oracle can use the destination, whereas DEFER indicates that the location is temporarily disabled. The third value, ALTERNATE, means that the destination is an alternate. It's availability state is DEFER, unless there is a failure of its parent destination, in which case its state becomes ENABLE.

Specifying the Mode of Log Transmission

There are two modes of transmitting archived logs to their destination: normal archiving transmission and standby transmission mode. Normal transmission involves transmitting files to a local disk. Standby transmission involves transmitting files through a network to either a local or remote standby database.

Normal Transmission Mode

In normal transmission mode, the archiving destination is another disk drive of the database server. In this configuration archiving does not contend with other files required by the instance and can complete more quickly. Specify the destination with either the LOG_ARCHIVE_DEST_n or LOG_ARCHIVE_DEST parameters.

Ideally, you should permanently move archived redo log files and corresponding database backups from the local disk to inexpensive offline storage media such as tape. Because a primary value of archived logs is database recovery, you want to ensure that these logs are safe should disaster strike your primary database.

Standby Transmission Mode

In standby transmission mode, the archiving destination is either a local or remote standby database.


Caution:

You can maintain a standby database on a local disk, but Oracle strongly encourages you to maximize disaster protection by maintaining your standby database at a remote site.


If you are operating your standby database in managed recovery mode, you can keep your standby database in sync with your source database by automatically applying transmitted archive logs.

To transmit files successfully to a standby database, either ARCn or a server process must do the following:

Each ARCn process has a corresponding RFS for each standby destination. For example, if three ARCn processes are archiving to two standby databases, then Oracle establishes six RFS connections.

You can transmit archived logs through a network to a remote location by using Oracle Net. Indicate a remote archival by specifying a Oracle Net service name as an attribute of the destination. Oracle then translates the service name, through the tnsnames.ora file to a connect descriptor. The descriptor contains the information necessary for connecting to the remote database. The service name must have an associated database SID, so that Oracle correctly updates the log history of the control file for the standby database.

The RFS process, which runs on the destination node, acts as a network server to the ARCn client. Essentially, ARCn pushes information to RFS, which transmits it to the standby database.

The RFS process, which is required when archiving to a remote destination, is responsible for the following tasks:

Archived redo logs are integral to maintaining a standby database, which is an exact replica of a database. You can operate your database in standby archiving mode, which automatically updates a standby database with archived redo logs from the original database.

See Also:

Managing Archive Destination Failure

Sometimes archive destinations can fail, causing problems when you operate in automatic archiving mode. To minimize the problems associated with destination failure, Oracle provides you with options. Discussions of these options are contained in the following sections:

Specifying the Minimum Number of Successful Destinations

The optional initialization parameter LOG_ARCHIVE_MIN_SUCCEED_DEST=n (where n is an integer from 1 to 10, or 1 to 2 if you choose to use duplexing) determines the minimum number of destinations to which Oracle must successfully archive a redo log group before it can reuse online log files. The default value is 1.

Specifying Mandatory and Optional Destinations

Using the LOG_ARCHIVE_DEST_n parameter, you can specify whether a destination has the attributes OPTIONAL (default) or MANDATORY. The LOG_ARCHIVE_MIN_SUCCEED_DEST=n parameter uses all MANDATORY destinations plus some number of OPTIONAL non-standby destinations to determine whether LGWR can overwrite the online log.

When determining how to set your parameters, note the following:

You can also establish which destinations are mandatory or optional by using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters. Note the following rules:

Sample Scenarios: Specifying the Number of Successful Destinations

You can see the relationship between the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_MIN_SUCCEED_DEST parameters most easily through sample scenarios.

Scenario 1

In this scenario, you archive to three local destinations, each of which you declare as OPTIONAL. Table 8-2 illustrates the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n in this case.

Table 8-2 LOG_ARCHIVE_MIN_SECCEED_DEST Values for Scenario 1
Value Meaning

1

Oracle can reuse log files only if at least one of the OPTIONAL destinations succeeds.

2

Oracle can reuse log files only if at least two of the OPTIONAL destinations succeed.

3

Oracle can reuse log files only if all of the OPTIONAL destinations succeed.

4 or greater

ERROR: The value is greater than the number of destinations.

This scenario shows that even though you do not explicitly set any of your destinations to MANDATORY using the LOG_ARCHIVE_DEST_n parameter, Oracle must successfully archive to one or more of these locations when LOG_ARCHIVE_MIN_SUCCEED_DEST is set to 1, 2, or 3.

Scenario 2

In this scenario, consider a case in which:

Table 8-3 shows the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n.

Table 8-3 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 2
Value Meaning

1

Oracle ignores the value and uses the number of MANDATORY destinations (in this example, 2).

2

Oracle can reuse log files even if no OPTIONAL destination succeeds.

3

Oracle can reuse logs only if at least one OPTIONAL destination succeeds.

4

Oracle can reuse logs only if both OPTIONAL destinations succeed.

5 or greater

ERROR: The value is greater than the number of destinations.

This case shows that Oracle must archive to the destinations you specify as MANDATORY, regardless of whether you set LOG_ARCHIVE_MIN_SUCCEED_DEST to archive to a smaller number of destinations.

Re-Archiving to a Failed Destination

Use the REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter to specify whether and when ARCn attempts to rearchive to a failed destination following an error. REOPEN applies to all errors, not just OPEN errors.

REOPEN=n sets the minimum number of seconds before ARCn should try to reopen a failed destination. The default value for n is 300 seconds. A value of 0 is the same as turning off the REOPEN option. In other words, ARCn will not attempt to archive after a failure. If you do not specify the REOPEN keyword, ARCn will never reopen a destination following an error.

You cannot use REOPEN to specify a limit on the number of attempts to reconnect and transfer archived logs. The REOPEN attempt either succeeds or fails, in which case the REOPEN information is reset.

If you specify REOPEN for an OPTIONAL destination, Oracle can overwrite online logs if there is an error. If you specify REOPEN for a MANDATORY destination, Oracle stalls the production database when it cannot successfully archive. In this situation, consider the following options:

When using the REOPEN keyword, note the following:

Tuning Archive Performance by Specifying Multiple ARCn Processes

For most databases, ARCn has no effect on overall system performance. On some large database sites, however, archiving can have an impact on system performance. On one hand, if ARCn works very quickly, overall system performance can be reduced while ARCn runs, since CPU cycles are being consumed in archiving. On the other hand, if ARCn runs extremely slowly, it has little detrimental effect on system performance, but it takes longer to archive redo log files, and can create a bottleneck if all redo log groups are unavailable because they are waiting to be archived.

You can specify up to ten ARCn processes for each database instance. Enable the multiple processing feature at startup or at runtime by setting the initialization parameter LOG_ARCHIVE_MAX_PROCESSES=n (where n is any integer from 1 to 10). By default, the parameter is set to 2.

Because LGWR automatically increases the number of ARCn processes should the current number be insufficient to handle the current workload, the parameter is intended to allow you to specify the initial number of ARCn processes or to increase or decrease the current number. Assuming the initial number of ARCn processes was set to 4, the following statement will decrease the number of processes to 2.

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=2;

When decreasing the number of ARCn processes, it is not determinate exactly which process will be stopped. Also, you are not allowed to alter the value of the parameter to 0, so at least one ARCn process is always active. Query the V$ARCHIVE_PROCESSES view to see information about the state of each archive process. Processes that have stopped show as being in the IDLE state.

Creating multiple processes is especially useful when you:

Multiple ARCn processing prevents the bottleneck that occurs when LGWR switches through the multiple online redo logs faster than a single ARCn process can write inactive logs to multiple destinations. Each ARCn process works on only one inactive log at a time, but must archive to each specified destination.

For example, if you maintain five online redo log files, then you may decide to start the instance using three ARCn processes. As LGWR actively writes to one of the log files, the ARCn processes can simultaneously archive up to three of the inactive log files to various destinations. As Figure 8-2 illustrates, each instance of ARCn assumes responsibility for a single log file and archives it to all of the defined destinations.

Figure 8-2 Using Multiple ARCn Processes

Text description of admin055.gif follows
Text description of the illustration admin055.gif


See Also:

Oracle9i Database Performance Tuning Guide and Reference for more information about tuning the archiving process

Controlling Trace Output Generated by the Archivelog Process

As discussed in "Trace Files and the Alert File", background processes always write to a trace file when appropriate. In the case of the archivelog process, it is possible to control the output that is generated.

The LOG_ARCHIVE_TRACE initialization parameter can be set to specify a trace level. The following values can be specified:

Trace Level Meaning

0

Disable archivelog tracing - default setting.

1

Track archival of redo log file.

2

Track archival status for each archivelog destination.

4

Track archival operational phase.

8

Track archivelog destination activity.

16

Track detailed archivelog destination activity.

32

Track archivelog destination parameter modifications.

64

Track ARCn process state activity

128

Track FAL (fetch archived log) server releated activities

256

Supported in a future release

512

Tracks asynchronous LGWR activity

1024

RFS physical client tracking

2048

ARCn/RFS heartbeat tracking

You can combine tracing levels by specifying a value equal to the sum of the individual levels that you would like to trace. For example, setting LOG_ARCHIVE_TRACE=12, will generate trace level 8 and 4 output. You can set different values for the primary and any standby database.

The default value for the LOG_ARCHIVE_TRACE parameter is 0, and at this level, error conditions still generate the appropriate alert and trace entries.

You can change the value of this parameter dynamically using the ALTER SYSTEM statement. For example:

ALTER SYSTEM SET LOG_ARCHIVE_TRACE=12;

Changes initiated in this manner will take effect at the start of the next archiving operation.

See Also:

Oracle9i Data Guard Concepts and Administration for information about using this parameter with a standby database

Viewing Information About the Archived Redo Log

You can display information about the archived redo logs using the following:

Dynamic Performance Views

There are several dynamic performance views that contain useful information about archived redo logs.

Dynamic Performance View Description

V$DATABASE

Identifies whether the database is in ARCHIVELOG or NOARCHIVELOG mode.

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 online 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.

For example, the following query displays which online redo log group requires archiving:

SELECT GROUP#, ARCHIVED
   FROM SYS.V$LOG;

GROUP#     ARC
--------   ---
       1   YES
       2   NO

To see the current archiving mode, query the V$DATABASE view:

SELECT LOG_MODE FROM SYS.V$DATABASE;

LOG_MODE
------------
NOARCHIVELOG
See Also:

Oracle9i Database Reference for detailed descriptions of data dictionary views

The ARCHIVE LOG LIST Command

The SQL*Plus command ARCHIVE LOG LIST can be used to show archiving information for the connected instance. For example:

SQL> ARCHIVE LOG LIST

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            D:\ORANT\oradata\IDDB2\archive
Oldest online log sequence     11160
Next log sequence to archive   11163
Current log sequence           11163

This display tells you all the necessary information regarding the archived redo log settings for the current instance:


Go to previous page Go to next page
Oracle
Copyright © 2001, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback