Managing Archive Destination Failure - Oracle 10g

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

• Specifying the Minimum Number of Successful Destinations
• Rearchiving to a Failed Destination

Specifying the Minimum Number of Successful Destinations

The optional initialization parameter LOG _ARCHIVE _MIN _SUCCEED _DEST=n determines the minimum number of destinations to which the database must successfully archive a redo log group before it can reuse online log files. The default value is 1. Valid values for n are 1 to 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 destination 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 MANDATORY 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.
• When you specify a value for LOG _ARCHIVE _MIN _SUCCEED _DEST=n, Oracle Database will treat at least one 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_SUCCEED_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 establish 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 mandatory.
• Any destination declared by LOG _ARCHIVE _DUPLEX _DEST is optional if LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 and mandatory if LOG _ARCHIVE _MIN _SUCCEED _DEST = 2.

Specifying the Number of Successful Destinations: Scenarios

You can see the relationship between the LOG _ARCHIVE _DEST _n and LOG _ARCHIVE _MIN _SUCCEED _DEST parameters most easily through sample scenarios.

Scenario for Archiving to Optional Local Destinations

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

LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 1

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 successfully 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 shows the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n.

LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 2

This case shows that the database 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.

Rearchiving to a Failed Destination

Use the REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter to specify whether and when ARCn should attempt 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 attribute; 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 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 database can overwrite online logs if there is an error. If you specify REOPEN for a MANDATORY destination, the database 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 the destination, specifying the destination as optional, or changing the service.
• Drop the destination.

When using the REOPEN keyword, note the following:

• ARCn reopens a destination only when starting an archive operation from the beginning of the log file, never during a current operation. 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 interval is less than the current time. If it is, ARCn retries the log copy.
• The REOPEN clause successfully affects the ACTIVE=TRUE destination state. The VALID and ENABLED states are not changed.