S kip Headers

Oracle® Database Administrator's Guide
10g Release 1 (10.1)
Part Number B10739-01		 Go to Table of Contents
Contents
Go to Docum entation Home
Home		 Go to Book List
Book List		 Go to Index
Index		 Go to Master Index
Master&nb sp;Index		 Go to Feedback page
Feedback
Go to previous page
Previous		 Go to next page
Next
 View PDF

7 Managing Archived Redo Logs

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

What Is the Archived Redo Log?

Oracle Database lets you sa ve filled groups of redo log files to one or more offline destinations, known collectively as the archived redo log, or more simply the archive 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. For example, if you are multiplexing your redo log, and if group 1 contains identical member files a_log1 and b_log1, then the archiver process (ARCn) will archive one of these member files. 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 enabl ed archiving.

When the database is running in ARCHIVELOG mode, the log writer process (LGWR) cannot reuse and hen ce overwrite a redo log group until it has been archived. The background process ARCn automates archiving operations when au tomatic archiving is enabled. The database starts multiple archiver processes as needed to ensure that the archiving of filled redo l ogs does not fall behind.

You can use archived redo logs to:

Choos ing Between NOARCHIVELOG and ARCHIVELOG Mode

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

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

Running a Database in NOARCHIVELOG Mo de

When you run y our database in NOARCHIVELOG mode, you disable the archiving of the redo log. The database control file indicates that f illed groups are not required to be archived. Therefore, when a filled group becomes inactive after a log switch, the group is availa ble for reuse by LGWR.

NOARCHIVELOG mode protects a database from instance failure but not from media failure. On ly the most recent changes made to the database, which are stored in the online redo log groups, are available for instance recovery. If a media failure occurs while the database is in NOARCHIVELOG mode, you can only restore the database to the point of the most recent full database backup. You cannot recover transactions subsequent to that backup.

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. To restore a database operating in NOARCHIVELOG mode, you can use only whole database bac kups taken while the database is closed. 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< a id="sthref952" name="sthref952">

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

The archiving of fil led groups has these advantages:

  • A database backup, together with online and archived redo log files, gu arantees that you can recover all committed transactions in the event of an operating system or disk failure.

  • If you keep an archived log, 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 continuously applying the original archived redo log s to the standby.

You can configure an instance to archive filled redo log files automatically, or you can archive manually. For convenience and efficiency, automatic arch iving is usually best. Figure 7-1 illustrates how the archiver process (ARC0 in this illustration) writes fil led redo log files to the database archived redo log.

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

Figure 7-1 Redo Log File Use in ARCHIVELOG Mode

Description of admin056.gif follows
Description of the illustration admin056.gif

Controlling Archiving

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

Setting the Initial Database Archiving Mode

< /a>You set the initial archiving mode as part of database creation in the CREATE DATABASE statement. Usually, you can us e the default of NOARCHIVELOG mode at database creation because there is no need to archive the redo information generat ed by that process. After creating the database, decide whether to change the initial archiving mode.

If you specify ARC HIVELOG mode, you must have initialization parameters set that specify the destinations for the archive log files (see "Specifying Archive Destinations").

Changing the Databa se Archiving Mode

To change the archiving mode of the database, use the ALTER DATABASE statement w ith the ARCHIVELOG or NOARCHIVELOG clause. To change the archiving mode, you must be connected to the datab ase with administrator privileges (AS SYSDBA).

The following steps switch the database 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 archiving mode. You cannot change the mode from ARCHIVELOG to NOARCHIVELOG if any datafiles n eed media recovery.

  2. Back up the database.

    Before making any major change to a database, always back up the da tabase to protect against any problems. This will be your final backup of the database in NOARCHIVELOG mode and can be u sed if something goes wrong during the change to ARCHIVELOG mode. See Oracle Database Backup and Recovery Basics for information about taking database backups.

  3. < p>Edit the initialization parameter file to include the initialization parameters that specify the destinations for the archive log f iles (see "Specifying Archive Destinations").

  4. Start a new instance and mount, but do not ope n, the database.

    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.

    ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

  6. Shut down the database.

    SHUTDOWN IMMEDIATE

  7. Back up the database.

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


    < td align="left">

    See Also:

    Oracle Real Application Clusters Administrator's Guide for more information about swit ching the archiving mode when using Real Application Clusters

    < /div>

Performing Manual Archiving

To operate your database in manual archiving mode, follow the procedure shown in "Changing the Database Archiving Mode ". However, when you specify the new mode in step 5, u se the following statement:

ALTER DATABASE ARCHIVELOG MANUAL;

When you operate your databas e 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 mounted but not open. Use the ALTER SYSTEM statement with the ARCHIVE LOG clause to manually archive fil led redo log files. The following statement archives all unarchived log files:

ALTER SYSTEM ARCHIVE LOG
 ALL;

When you use manual archiving mode, you cannot specify any standby databases in the archiving destinations.

Even when automatic archiving is enabled, you can use manual archiving for such actions as rearchiving an inactive group of filled re do log members to another location. In this case, it is possible for the instance to reuse the redo log group before you have finishe d manually archiving, and thereby overwrite the files. If this happens, the database writes an error message to the alert file.

Adjusting the Number of Archiver Processes

The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the number of ARCn processes that the database initially invokes. The default is two processes. There is usually no need specify this initialization parameter or to change its default value, because the database st arts additional archiver processes (ARCn) as needed to ensure that the automatic processing of filled redo log files does no t fall behind.

However, to avoid any runtime overhead of invoking additional ARCn processes, you can set the LO G_ARCHIVE_MAX_PROCESSES initialization parameter to specify up to ten ARCn processes to be started at instance startu p. The LOG_ARCHIVE_MAX_PROCESSES parameter is dynamic, and can be changed using the ALTER SYSTEM statement. The database must be mounted but not open. The following statement increases (or decreases) the number of ARCn processes cu rrently running:

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;

Specifying the Archive Destination

Before you can archive redo logs, you must determine the destination to which you will archive and familiarize yourself wi th the various destination states. The dynamic performance (V$) views, listed in "Viewing Information About the A rchived Redo Log", provide all needed archive information.

The following topics are contained in this section:

Specifying Arch ive Destinations

You can choose whether to archive redo logs to a single destination or multiplex them. If you want to archive only to a single destination, you specify that destination in the LOG_ARCHIVE_DEST initialization parameter. If you want to multiplex the archived lo gs, you can choose whether to archive to up to ten locations (using the LOG_ARCHIVE_DEST_n parameters) or to archive onl y to a primary and secondary destination (using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST). The followin g table summarizes the multiplexing alternatives, which are further described in the sections that follow.

Method Initialization Parameter Host Example
1 L OG_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 = 'SERVI CE=standby1'

2 LOG_ARCHIVE_DEST and

LOG_ARCHIVE_DUPLEX_DEST

 Local only LOG_ARCHIVE_DEST = '/disk1/arc'

< code>LOG_ARCHIVE_DUPLEX_DEST = '/disk2/arc'



See Also:

  • Oracle Database Reference for additional in formation about the initialization parameters used to control the archiving of redo logs

  • Oracle Data Guard Concepts and Administration for information about using the LOG_ARCHIVE_DEST_n initialization parameter for specifying a sta ndby destination. There are additional keywords that can be specified with this initialization parameter that are not discussed in th is book.


Method 1: Using the LOG_ARCHIVE_DEST_n Parameter

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 the keywo rds explained in the following table:

Keyword Indicates Example
LOCATION A local file system lo cation. LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arc'
SERVICE Remote archival through Oracle Net service name. LOG_ARCHIVE_DEST_2 = 'SERV ICE=standby1'

If you use the LOCATION keyword, specify a valid path name for your operating system. If you specify SERVICE, the database translates the net service name through the tnsnames.ora file to a connect descriptor. The descripto r contains the information necessary for connecting to the remote database. The service name must have an associated database SID, so that the database 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 paramet er:

  1. Use SQL*Plus to shut down the database.

    SHUTDOWN

  2. Set the LOG_ARCHIVE_DEST_n initialization 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 = 'L
OCATION = /disk3/archive'

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

    LOG_ARCHIVE_DEST_4 =
 'SERVICE = standby1'

  3. Optionally, set the LOG_ARCHIVE_FORMAT initialization parameter, using %t to include the thread number as part of the file name, %s to include the log sequence number, and %r to include the resetlogs ID (a timestamp value represented in ub4). Use capital letters (%T, %S, and %R) to pad the file name to the left with zeroes.


    Note:

    If the COMPATIBLE initialization paramet er is set to 10.0 or higher, the database requires the specification of resetlogs ID (%r) when you include the LOG _ARCHIVE_FORMAT parameter. The default for this parameter is operating system dependent. For example, this is the default form at for UNIX:

    LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf

    The incarnation of a database changes when you open it with the RESETLOGS option. Specifying %r causes the database to capture the resetlogs ID in the archive log file nam e, enabling you to more easily perform recovery from a backup of a previous database incarnation. See Oracle Database Backup and Recovery Advanced User's Guide for more in formation about this method of recovery.


    The followin g example shows a setting of LOG_ARCHIVE_FORMAT:

    LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc

<
/pre>


    This setting will generate archived logs as follows for thread 1; log sequence numbers 100, 101, and 102; resetlogs ID 5092
10197. The identical resetlogs ID indicates that the files are all from the same database incarnation:
    

    /disk1/archive/arch_1_100_509210197.arc, 
/disk1/archive/arch_1_101_509210197.arc, 
/disk1/archive/arch_1_102_509210197.arc

/disk2/a
rchive/arch_1_100_509210197.arc, 
/disk2/archive/arch_1_101_509210197.arc, 
/disk2/archive/arch_1_102_509210197.arc

/disk3/archive/a
rch_1_100_509210197.arc, 
/disk3/archive/arch_1_101_509210197.arc, 
/disk3/archive/arch_1_102_509210197.arc
< !-- class="sect3" -->

Method 2: Using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST

To specify a maximum of two locations, use the LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DEST to spe cify an optional secondary archive destination. All locations must be local. Whenever the database archives a redo log, it archives i t to every destination specified by either set of parameters.

Perform the following steps the use method 2:

  1. Use SQL*Plus to shut down the database.

    SHUTDOWN

  2. Specify destin ations for the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameter (you can also specify LOG_ARCHI VE_DUPLEX_DEST dynamically using the ALTER SYSTEM statement). For example, enter:

    L
OG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'

  3. Set the LOG_ARCHIVE_FORMAT< /code> initialization parameter as described in step 3 for method 1.

< h3>Understanding Archive Destination Status

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

  • Valid/Invalid: indicates whether the disk location or service n ame information is specified and valid

  • Enabled/Disabled: indicates the availability sta te of the location and whether the database can use the destination

  • Active/Inactive: in dicates whether there was a problem accessing the destination

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

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

Table 7-1 Destination Status


T he LOG_ARCHIVE_DEST_STATE_n< /code> (where n is an integer from 1 to 10) initialization parameter lets you control the availability state of the spe cified destination (n).

  • ENABLE indicates that the database can use the destination .

  • DEFER indicates that the location is temporarily disabled.

  • < code>ALTERNATE indicates that the destination is an alternate.

The availability state of the destination is < code>DEFER, unless there is a failure of its parent destination, in which case its state becomes ENABLE.

Specifying the Mode of Log Transmission

The two modes of transmitting archived logs to their destination are normal archiving t ransmission 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.

It is good practice to move archived redo log files and corresponding database backups from the local disk to permanent inexpensive offline storage media such as tape. A primary value of archived logs is database recovery, so you want to e nsure 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.


STATUS Characteristics Meaning
Valid Enabled Active
VALID True True True The user has properly initialized the destination, which is available for archiving.
INACTIVE Fal se 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 Fals e Destination is full (no disk space).
DEFERRED True False True The user manually and temporarily disabled the des tination.
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.

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


If you are o perating your standby database in managed recovery mode, you can keep your standby database synchronized with your s ource database by automatically applying transmitted archive logs.

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

  • Recognize a remote location

  • Transmit the archived logs in conjunction with a remote file server (RFS) process that resides on the re mote server

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

You transmit archived logs through a network to a remote location by using Oracle Net Services. Indicate a remo te archival by specifying a Oracle Net service name as an attribute of the destination. Oracle Database then translates the service n ame, through the tnsnames.ora file, to a connect descriptor. The descriptor contains the information necessary for conne cting to the remote database. The service name must have an associated database SID, so that the database correctly updates the log h istory of the control file for the standby database.

The RFS process, which runs on the destination node, acts as a network se rver 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:

  • Consuming network I/O from the ARCn process

  • Creating file names on the standby database by using the STANDBY_ARCHIVE_DEST parameter

  • Populating the log files at the remot e site

  • Updating the standby database control file (which Recovery Manager can then use for recovery)

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


See Also:


Managing Archive Destination Failure

Sometimes archive destinations can fail, causing problems when you operate in automatic ar chiving mode. Oracle Database provides procedures to help you minimize the problems associated with destination failure. These proced ures are discussed in the sections that follow:

Specifying the Minimum Number of Successful Destinations

The optional initialization parameter LO G_ARCHIVE_MIN_SUCCEED_DEST=n determines the minimum number of destinations to which the database must su ccessfully archive a redo log group before it can reuse online log files. The default value is 1. Valid values for n are 1 t o 2 if you are using duplexing, or 1 to 10 if you are multiplexing.

Specifying Mandatory and Optional Destinations

The LOG_ARCHIVE_DEST_n parameter lets you specify whether a desti nation is OPTIONAL (the default) or MANDATORY. The LOG_ARCHIVE_MIN_SUCCEED_DEST=n parameter uses all MANDATORY destinations plus some number of nonstandby OPTIONAL destinations to determine whether LGWR can overwrite the online log. The following rules apply:

  • Omitting the MAND ATORY attribute for a destination is the same as specifying OPTIONAL.

  • You must have at least one local destination, which you can declare OPTIONAL or MANDATORY.

  • W hen you specify a value for LOG_ARCHIVE_MIN_SUCCEED_DEST=n, Oracle Database will treat at least on e local destination as MANDATORY, because the minimum value for LOG_ARCHIVE_MIN_SUCCEED_DEST is 1.

  • If any MANDATORY destination fails, including a MANDATORY standby destination, Oracle Database ignores the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter.

  • The LOG_ARCHIVE_MIN_SUCC EED_DEST value cannot be greater than the number of destinations, nor can it be greater than the number of MANDATORY destinations plus the number of OPTIONAL local destinations.

  • If you DEFER a MANDATORY destination, and the database overwrites the online log without transferring the archived log to the standby site, then you must transfer the log to the standby manually.

If you are duplexing the archived logs, you can estab lish which destinations are mandatory or optional by using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters. The following rules apply:

  • Any destination declared by LOG_ARCHIVE_DEST is man datory.

  • Any destination declared by LOG_ARCHIVE_DUPLEX_DEST is optional if LOG_ARCHIV E_MIN_SUCCEED_DEST = 1 and mandatory if LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.

Speci fying the Number of Successful Destinations: Scenarios

You can see the relati onship between the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_MIN_SUCCEED_DEST parameters mos t easily through sample scenarios.

Scenario for Archiving to Optional Local Destinations

In this scenario, you archive to t hree local destinations, each of which you declare as OPTIONAL. Table 7-2 illustrates the possib le values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n in this case.

Tabl e 7-2 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 1

< td align="left" headers="r5c1-t13 r1c2-t13">ERROR: The value is greater than the number of destinations.
Value Meaning
1 The database can reuse log files only if at least one of the OPTIONAL destinations succeeds.
2 The database can reuse log files only if at least two o f the OPTIONAL destinations succeed.
3 The database can reuse log files only if all of the OPTIONAL destinations succeed.
4 or greater

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

Scenario for Archiving to Both Mandatory and Optional Destinations

Consider a case in which:

    You specify two MANDATORY destinations.

  • You specify two OPTIONAL destinations.

  • No destination is a standby database.

Table 7-3< /a> shows the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n.

< a id="sthref1031" name="sthref1031">

Table 7-3 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 2

Value Meaning
1 The database ignores the value and uses the number of MANDATORY destinations (in this example , 2).
2 The database can reuse log files even if no OPTIONAL destination succeeds.
3 The database can re use logs only if at least one OPTIONAL destination succeeds.
4 The database can reuse logs only if both OP TIONAL destinations succeed.
5 or g reater ERROR: The value is greater than the number of destinations.

This case shows that the database must archive to the destinat ions you specify as MANDATORY, regardless of whether you set LOG_ARCHIVE_MIN_SUCCEED_DEST to archive to a s maller number of destinations.

Rearchiving to a Failed Destination

Use the REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter to specify wh ether and when ARCn should attempt to rearchive to a failed destination following an error. REOPEN applies to a ll errors, not just OPEN errors.

REOPEN=n sets the minimum number of seconds b efore ARCn should try to reopen a failed destination. The default value for n is 300 seconds. A value of 0 is the s ame as turning off the REOPEN attribute; ARCn will not attempt to archive after a failure. If you do not specif y the REOPEN keyword, ARCn will never reopen a destination following an error.

You cannot use REOP EN to specify the number of attempts ARCn should make to reconnect and transfer archived logs. The REOPEN attempt either succeeds or fails.

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

  • Archive manually to the failed destination.

  • Change the destination by deferring th e destination, specifying the destination as optional, or changing the service.

  • Drop the destination.

When using the REOPEN keyword, note the following:

  • ARCn reopens a d estination only when starting an archive operation from the beginning of the log file, never during a current opera tion. ARCn always retries the log copy from the beginning.

  • If you specified REOPEN , either with a specified time the default, ARCn checks to see whether the time of the recorded error plus the REOPEN< /code> interval is less than the current time. If it is, ARCn retries the log copy.

  • The R EOPEN clause successfully affects the ACTIVE=TRUE destination state. The VALID and ENABLED states are not changed.

Co ntrolling Trace Output Generated by the Archivelog Process

Background processes always write to a trace file when appropriate. ( See the discussion of this topic in "Monitoring the Database Using Trace Files and the Alert File" .) In the case of the archivelog process, you can control the output that is generated to the trace file. You do this by setting the LOG_ARCHIVE_TRACE initialization param eter to specify a trace level. The following values can be specified:

256
Trace Level Meaning
0 Disable arch ivelog tracing. This is the default.
1 Track archival of redo log file.
2 Track archival status for each archivelog d estination.
4 Track archival operational phase.
8 Track archivelog destination activity.
16 Track detailed ar chivelog destination activity.
32 Track archivelog destination parameter modifications.
64 Track ARCn proces s state activity.
128 Track FAL (fetch archived log) server related activities.
Supported in a future release .
512 Tracks asynchronous LGWR activity.
1024 RFS physical client tracking.
2048 ARCn/RFS hear tbeat tracking.
4096 Track real-time apply

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 a nd any standby database.

The default value for the LOG_ARCHIVE_TRACE parameter is 0. At this level, the archivelo g process generates appropriate alert and trace entries for error conditions.

You can change the value of this parameter dynam ically using the ALTER SYSTEM statement. The database must be mounted but not open. 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:

Oracle 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 th e archived redo logs using the following sources:

Dynamic Per formance Views

Several dynamic performance views contain useful information about archived redo logs, as summarized in the following table.

Dynamic Performance View Description
V$DATABASE Identifies whether t he database is in ARCHIVELOG or NOARCHIVELOG mode and whether MANUAL (archiving mode) has been specified.
V$ARCHIVED_LOG Displays historical archived log information from the control file. If you use a reco very catalog, the RC_ARCHIVED_LOG view contains similar information.
V$ARCHIVE_DEST Describes the c urrent 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 cont ains similar information.
V$LOG Displays all redo log groups for the database and indicates which need to be arc hived.
V$LOG_HISTORY Contains log history information such as which logs have been archived and the SCN range fo r each archived log.

For example, the following query di splays which 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 t he V$DATABASE view:

SELECT LOG_MODE FROM SYS.V$DATABASE;

LOG_MODE
------------
NOARCHIVEL
OG

See Also:

Oracle Database Reference for detailed descriptions of dy namic performance views

The ARCHIVE LOG LIST Command

The SQL*Plus command ARCHIVE LOG LIST displays ar chiving information for the connected instance. For example:

SQL> ARCHIVE LOG LIST

Database log mod
e              Archive Mode
Automatic archival             Enabled
Archive destination            D:\oracle\oradata\IDDB2\archive
Old
est 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:

  • The database is currently operating in ARCHIVELOG mode.

  • Automatic archiving is enabled.< /p>

  • The archived redo log destination is D:\oracle\oradata\IDDB2\archive .

  • The oldest filled redo log group has a sequence number of 11160.

  • The next filled redo log group to archive h as a sequence number of 11163.

  • The current redo log file has a sequence number of 11163.


    See Also:

    SQL*Plus User's Guide and Reference for more information on the ARCHIVE L OG LIST command

< tr>
Go to previous page
Previous		 Go to next page
Next
 Oracle
Copyright © 2001, 2003 Oracle Corporation
All Rights Reserved.< /td>
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Feedback