1,Log Archive Destinations to a Group

Use the GROUP attribute of the LOG_ARCHIVE_DEST_n initialization parameter to assign log archive destinations to groups.

If log archive destination groups are used, then as long as at least one destination within the group remains available, at least one destination remains enabled and active. Log archive destinations that are not assigned to a group behave the same as log archive destinations did prior to Oracle Database 12c Release 2 (12.2.0.1).

There can be up to 30 log archive destinations in a group. Log archive destination groups are referenced by their group number, which is assigned when the group is created. Groups are numbered from 1 through 8. A log archive destination group contains a set of remote (SERVICE=…) destinations. (Local archival (LOCATION=…) destinations are not supported in log archive destination groups and must use the ALTERNATE attribute for alternate local archiving locations. See ALTERNATE.

One log archive destination in the group is always active and the others are available for use in the event of a failure of the active log archive destination. When a failed destination again becomes available it becomes eligible if the currently active destination fails, but it does not become active immediately, unless all other group members are also unavailable. For example, the following declaration can be used to specify three far sync instances as members of the same group and having the same priority (Priority within a group is described in the next section). These are example parameter definitions and do not contain all the necessary attributes. Do not use them verbatim. In this example only the first destination is active with the second destination available to take over if destination 1 becomes unavailable.

LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1'

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_DEST_3='SERVICE=chicagoFS1 SYNC  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1'

LOG_ARCHIVE_DEST_STATE_3=ALTERNATE

2, Assigning Priorities to Log Archive Destinations in a Group

LOG_ARCHIVE_DEST_2=’SERVICE=chicagoFS SYNC  

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_DEST_3=’SERVICE=chicagoFS1 SYNC  

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’

LOG_ARCHIVE_DEST_STATE_3=ALTERNATE

LOG_ARCHIVE_DEST_4=’SERVICE=chicagoFS2 ASYNC  

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=2’

LOG_ARCHIVE_DEST_STATE_4=ALTERNATE

This declaration results in the following behavior:

• The primary ships redo to the first of two preferred far sync instances, chicagoFS
  
• If chicagoFS become unavailable, then the primary ships to chicagoFS1.
  
• If chicagoFS becomes available again, no fail back occurs. It becomes the alternate to chicagoFS1 because the priority is the same.
  
• If both chicagoFS and chicagoFS1 become unavailable, then the primary ships to chicagoFS2 (in this case via the ASYNC redo transmission mode).
  
• If either chicagoFS or chicagoFS1 become available while the primary is shipping to chicagoFS2, then the primary fails back to that available preferred log archive destination.
  

3, RedoRoutes配置

Redo Routing Rules

The RedoRoutes property is set to a character string that contains one or more redo routing rules.

Each rule is contained within a set of parentheses, as follows:

Copy

(redo_routing_rule_1) [(redo_routing_rule_n)]

A redo routing rule contains a redo source field and a redo destination field separated by a colon:

Copy

(redo source : redo destination)

The redo source field must contain the keyword LOCAL or ANY, or a comma-separated list of DB_UNIQUE_NAME values, as follows:

Copy

{LOCAL | ANY | db_unique_name_1,[,db_unique_name_n]}

• The LOCAL keyword is an alias for the local database name. This keyword cannot be used at a far sync instance.
  
• The ANY keyword is an alias for any database in the configuration.
  
• A database cannot be specified as a redo source in more than one redo routing rule defined at a given database, either explicitly or implicitly through use of the LOCAL keyword.
  

The redo destination field must contain the keyword ALL or a comma-separated list of redo destination groups, each of which consists of destination databases with optional priority attributes and optional redo transport mode attributes:

Copy

{ALL [xpt_mode] | redo_dest_group_1 [, redo_dest_group_n]}

• The ALL keyword is an alias for all possible destinations in the configuration.
  
• The redo_dest_group_n is:
• Copy
• { db_unique_name_1 [xpt_mode] | ( db_unique_name_1 [xpt_mode] [PRIORITY=n] [,db_unique_name_n [xpt_mode] [PRIORITY=n]] ) }
• The optional xpt_mode specifies the redo transport mode to be used to send redo to the associated destination. It can have one of three values: ASYNC, SYNC, or FASTSYNC. If the redo transport attribute is not specified, then the transport mode used will be the one specified by the LogXptMode property for the redo destination.
  The optional [PRIORITY=n] can have n =1 ~ 8. The default value for far sync members is 1 and the default value for non-far sync members is 8. It is important to understand how different group and priority settings affect redo transport under various conditions. The following examples describe some sample situations.

Example 1: Different Priorities Within a Group

Assume there are three members in a broker configuration:

• PRI (primary database)
• SB1 (standby database)
• FS1 (far sync instance)

The primary database PRI generates the redo log for use by the standby database SB1. Because there is a far sync instance, FS1, there are two possible redo delivery paths to the standby database:

• (path 1) PRI —> FS1 —> SB1
• (path 2) PRI —> SB1

Assume (path 1) is more desirable than (path 2). This can be expressed with the RedoRoutes property as follows:

• PRI —RedoRoutes = (local : ( FS1 PRIORITY=1, SB1 PRIORITY=2 ) )
• FS1 —RedoRoutes = ( PRI : SB1 )

As specified in the PRI RedoRoutes property, the primary (PRI) has two destinations : one for FS1 with PRIORITY=1 and one for SB1 with PRIORITY=2. Smaller priority numbers mean higher priority, so primary PRI tries to ship the redo log to FS1 first.

If FS1 is available, then the primary ships to FS1 which has PRIORITY=1. If FS1 is unavailable, then the primary ships to SB1 which has PRIORITY=2. When FS1 becomes active again, the primary will ship to it again because priority 1 is higher than priority 2.

Example 2: The Same Priorities Within a Group

Suppose you add one more far sync instance, FS2, to the configuration set up in Example 1, and then update the RedoRoutes property as follows:

• PRI — RedoRoutes = (local : ( FS1 PRIORITY=1, FS2 PRIORITY=1 ) )
• FS1 — RedoRoutes = ( PRI : SB1 )
• FS2 — RedoRoutes = ( PRI : SB1 )

The primary PRI now has two destinations, FS1 and FS2, with the same priority. The primary must choose either FS1 or FS2. Assume the primary chooses FS1.

If FS1 is available, then the primary ships to FS1. If FS1 is unavailable, then the primary ships to FS2. Even after FS1 becomes active again, the primary continues shipping to FS2 because FS1 and FS2 have the same priority. If FS2 fails, then the primary ships to FS1.

Example 3: Multiple Groups

Assume that you add one more standby, SB2, to the configuration, and then update the RedoRoutes property as follows so that the primary has two destination groups:

• PRI — RedoRoutes = (local : ( FS1 PRIORITY=1, SB1 PRIORITY=2 ), ( FS2 PRIORITY=1, SB2 PRIORITY=2 ) )
• FS1 — RedoRoutes = ( PRI : SB1 )
• FS2 — RedoRoutes = ( PRI : SB2 )

The general rule is that there is one active redo path for each group. (See Example 4 for a scenario in which there are multiple active redo paths.) The primary establishes one redo delivery path for the first group ( FS1 PRIORITY=1, SB1 PRIORITY=2 ), and establishes another redo delivery path for the second group ( FS2 PRIORITY=1, SB2 PRIORITY=2 ).

• If both FS1 and FS2 are available, then the primary ships to FS1 and FS2.
  
• If FS1 is unavailable and FS2 is available, then the primary ships to SB1 and FS2.
  
• If FS1 is available and FS2 is unavailable, then the primary ships to FS1 and SB2.
  
• If both FS1 and FS2 are unavailable, then the primary ships to SB1 and SB2.
  

Example 4: The PRIORITY Attribute is Set to 8

Setting PRIORITY=8 has special meaning. If a primary ships redo to a destination with PRIORITY=8, then it must ship to every PRIORITY=8 destination. Suppose you update the RedoRoutes property as follows so that the primary has one group containing three destinations:

• PRI — RedoRoutes = (local : ( FS1 PRIORITY=1, SB1 PRIORITY=8, SB2 PRIORITY=8 ) )
• FS1 — RedoRoutes = ( PRI : SB1, SB2 )

These settings result in the following behavior:

• If FS1 is available, then the primary ships to FS1.
  
• If FS1 is unavailable, then the primary ships to both SB1 and SB2 because they both have PRIORITY=8
  
• If FS1 becomes active again, then the primary ships to FS1.
  

Usage Notes for Advanced Redo Transport Settings

The following usage notes apply regarding advanced redo transport settings:

• The RedoRoutes property has a default value of NULL, which is treated as (LOCAL : ALL) at a primary database.
  
• A redo routing rule is active if its redo source field specifies the current primary database. If a rule is active, primary database redo is sent by the database at which the rule is defined to each destination specified in the redo destination field of that rule.
  
• The ASYNC redo transport attribute must be explicitly specified for a cascaded destination to enable real-time cascading to that destination.
  
• The RedoRoutes property cannot be configured such that when a physical standby database is converted to a snapshot standby, the snapshot standby would send redo data to another member.
  
• The RedoRoutes property can be set for a logical standby database only if the redo source field is set to LOCAL.