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:

(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:

(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: 

{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: 

{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: 

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