Managing Redo Transport Services

To manage redo transport services, you specify configurable properties on each configuration member.

The properties you specify are as follows::

  • DGConnectIdentifier

  • StandbyAlternateLocation

  • Binding

  • Encryption (This property can be set only on a Recovery Appliance)

  • LogShipping

  • LogXptMode

  • MaxFailure

  • NetTimeout

  • RedoCompression

  • RedoRoutes

  • ReopenSecs

  • StandbyArchiveLocation

You can use these properties to specify how the broker configures redo transport services for the standby database. The actual redo transport setup, such as setting the LOG_ARCHIVE_DEST_n initialization parameter, is carried out by the broker on the primary database (except for the StandbyArchiveLocation property). If changing the property requires that you change the LOG_ARCHIVE_DEST_n initialization parameter attributes, the broker forces a log switch on each thread so that the new setting is adopted immediately by the primary database.

You should also preset these properties on the primary database in preparation for it to be switched over to a standby database.

Note:

Transport application failover (TAF) cannot be enabled on a connection for redo transport.

Setting Up For Redo Transport

Redo data is transported to a standby database using Oracle Net.

An Oracle Net service name is specified with the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization parameter and is used to transmit redo data to the standby database. The Oracle Net service name is translated into a connect descriptor that contains the information necessary for connecting to the standby database.

The SERVICE attribute can be set or changed by using the DGConnectIdentifier database property. The DGConnectIdentifier property is set when a database is first added to the configuration. Its initial value is the connect identifier that is specified in the optional CONNECT IDENTIFIER IS clause of the ADD DATABASE command.

The DGConnectIdentifier property value is also used to set up the FAL_SERVER initialization parameter. If the DGConnectIdentifier property for any database is changed, the SERVICE attribute of the corresponding LOG_ARCHIVE_DEST_n initialization parameter will also be changed. In addition, the FAL_SERVER initialization parameter will also be updated on every enabled standby database in the configuration.

Managing Redo Transport Services for Data Protection Modes

As a part of the overall configuration protection mode, you must ensure that redo transport services are also properly set up for the data protection mode that you choose.

Managing Data Protection Modes describes how the broker handles data protection modes.

You use the LogXptMode or RedoRoutes database properties to set the SYNC, ASYNC, or FASTSYNC mode for redo transport services.

The following redo transport modes are supported:

SYNC

Configures redo transport services for this standby database using the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, is required for configurations operating in either maximum protection mode or maximum availability mode. This redo transport service enables the highest grade of data protection to the primary database, but also can incur a higher performance impact.

ASYNC

Configures redo transport services for this standby database using the ASYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, enables a moderate grade of protection to the primary database, and lower performance impact.

FASTSYNC

Configures redo transport services for this standby database using the SYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode is only available in maximum availability protection mode.

Advanced Redo Transport Settings

You can use the RedoRoutes property to override the default behavior in which a primary database sends its redo to every possible redo transport destination in the configuration.

An example of redo transport topology other than the default would be one in which a physical standby or a far sync instance forwards redo received from the primary database to one or more destinations, or one in which the redo transport mode used for a given destination is dependent on which database is in the primary role.

See Also:

  • RedoRoutes for information about redo routing rules when you use the RedoRoutes property

Example 4-2 Using the RedoRoutes Property for Real-Time Cascading

Consider a configuration that has a primary database (North_Sales) and two physical standby databases (Local_Sales and Remote_Sales). The Local_Sales database is located in the same data center as the primary for high availability purposes. The Remote_Sales database is located in a remote data center for disaster recovery purposes. Instead of the primary having to ship its redo to both databases, it is possible to use the RedoRoutes property to configure real-time cascading, in which the local physical standby database forwards redo from North_Sales to the remote physical standby database, Remote_Sales. To accomplish this, the RedoRoutes property must be set as follows:

  • On the North_Sales database, the RedoRoutes property must specify that if North_Sales is in the primary role, then it should ship redo to the Local_Sales database using synchronous transport mode. This rule prevents the primary from shipping redo data directly to the Remote_Sales database.

  • On the Local_Sales database, the RedoRoutes property must specify that if North_Sales is in the primary role, then Local_Sales should forward redo it receives from North_Sales on to Remote_Sales. 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : Local_Sales SYNC)';
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';

To see the runtime RedoRoutes configuration, use the SHOW CONFIGURATION command. For example: 

DGMGRL> SHOW CONFIGURATION;
 
Configuration - Sales_Configuration
 
  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    Local_Sales  - Physical standby database
      Remote_Sales  - Physical standby database (receiving current redo)
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

Note that the ASYNC redo transport attribute was explicitly specified in the redo route rule for the Remote_Sales destination to enable real-time cascading of redo to that destination. (Real-time cascading requires a license for the Oracle Active Data Guard option.)

To disable real-time cascading of redo, do not specify the ASYNC redo transport attribute. For example: 

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales)';

Example 4-3 Using the RedoRoutes Property for Remote Alternate Destinations

The RedoRoutes property can also be used to set up a remote alternate destination so that a terminal member can still receive redo data even if the member from which it was receiving the redo data fails. Using the previous example, it would be possible to have the primary database, North_Sales, send redo data directly to Remote_Sales if the Local_Sales standby database failed. It is also possible, using the PRIORITY attribute, to set it up so that once the Local_Sales failure has been resolved it can resume shipping redo to Remote_Sales. 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : ( Local_Sales ASYNC PRIORITY=1, Remote_Sales ASYNC PRIORITY=2 ))';
Property "RedoRoutes" updated

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';
Property "RedoRoutes" updated

DGMGRL> SHOW CONFIGURATION;

Configuration - Sales_Configuration

  Protection Mode: MaxPerformance
  Members:
  North_Sales    - Primary database
    Local_Sales  - Physical standby database
      Remote_Sales - Physical standby database
Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

To see the full RedoRoutes configuration, use the SHOW CONFIGURATION VERBOSE command. For example: 

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - Sales_Configuration

  Protection Mode: MaxPerformance
  Members:
    North_Sales - Primary database
      Local_Sales - Physical standby database
        Remote_Sales - Physical standby database
      Remote_Sales - Physical standby database (alternate of Local_Sales)

  Properties:
    FastStartFailoverThreshold      = '180'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '300'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    ConfigurationWideServiceName    = 'c0_CFG'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Turning Redo Transport Services On and Off

You turn redo transport services on and off by setting the state of the primary database.

Setting the primary database state to TRANSPORT-ON starts redo transport services at the primary database, and setting the primary database state to TRANSPORT-OFF stops redo transport services at the primary database.

Note:

Oracle does not recommend turning off redo transport services to all standby databases. This increases the risk of data loss if the primary database fails.

Turn redo transport services on and off to an individual standby database using the LogShipping database property on the standby database. The LogShipping property accepts values ON and OFF. If you set the LogShipping property to OFF for a standby database, redo transport services to this standby database are turned off, while redo transport services to other databases are not affected. You can set LogShipping to ON to turn back on redo transport services to the standby database.

The relationship between setting the primary database state and setting the LogShipping property is as follows:

  • If the primary database state is set to TRANSPORT-OFF, redo transport services to all the standby databases are stopped regardless of the LogShipping property values of the individual standby databases.

  • If the primary database state is set to TRANSPORT-ON, redo transport services to each standby database are determined by the LogShipping property of that database.

Example 4-4 and Example 4-5 show how to turn off redo transport services in two different scenarios.

Example 4-4 Turn Off Redo Transport Services to All Standby Databases

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
Succeeded.
DGMGRL> SHOW DATABASE 'North_Sales';

Database - North_Sales

  Role:                PRIMARY
  Intended State:      TRANSPORT-OFF
  Redo Rate:           (unknown)

  Instance(s):
    NorthSales

Database Status:
SUCCESS

Example 4-5 Turn Off Redo Transport Services to a Specific Standby Database

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated

DGMGRL> SHOW DATABASE 'South_Sales' 'LogShipping';
  LogShipping = 'OFF'

Specifying Locations for Archived Redo Log Files

You can use broker configurable properties to set up locations to store both archived standby redo log files and archived online redo log files.

For online redo log files, use the ArchiveLocation and AlternateLocation properties on a primary, logical, or snapshot standby database.

For standby redo log files, use the StandbyArchiveLocation and StandbyAlternateLocation properties on a standby database. If the StandbyArchiveLocation is not set, ArchiveLocation or AlternateLocation specify the archiving location for both of online and standby redo log files. If StandbyArchiveLocation is set, ArchiveLocation and AlternateLocation specify the archiving location for online redo log files.

The StandbyArchiveLocation property specifies a location to store archived redo log files. The broker uses the location to store only archived redo log files received from the primary database. For archived redo log files generated locally when the database is either the primary database, a logical standby database, or a snapshot standby database, you need to specify the ArchiveLocation property. The broker allows the value of the StandbyArchiveLocation and ArchiveLocation properties to be the same as the location you set up for locally generated logs, in which case the broker sets up the VALID_FOR attribute of the destination appropriately so that it can be used for both the archived redo log files received from the primary database and archived redo log files generated locally. When a location is used for both online and standby redo log files, you must configure the ArchiveLocation property to the shared location and leave the StandbyArchiveLocation property empty.

You can also set up an alternate location to store archived redo log files by using the StandbyAlternateLocation and AlternateLocation properties. The alternate locations specified by these properties are where the archived redo log files are stored if the original archive location (specified by StandbyArchiveLocation or Archivelocation) fails. The broker sets up the alternate location properly using the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

Note:

You can use the database recovery area to store archived redo log files on the standby. In such a case, the value of the StandbyArchiveLocation or ArchiveLocation properties can be set to USE_DB_RECOVERY_FILE_DEST.

If you are not using a database recovery area, then on a logical standby database Oracle recommends that the ArchiveLocation property be different from the value of the StandbyArchiveLocation property.

Example 4-6 Using the Same Archiving Location for Standby Redo Log Files and Online Redo Log Files

The following example uses the same archiving location for online redo log files and standby redo log files.

ArchiveLocation='/archfs/arch'

Example 4-7 Specifying an Alternate Location for Archived Standby and Online Redo Log Files

The following example uses the same archiving location for online redo log files and standby redo log files. Configuring the AlternateLocation property ensures that a shared, alternate, location is available to store standby redo log files if the location specified by the ArchiveLocation property is unavailable. 

ArchiveLocation='/archfs/arch'
AlternateLocation='/archfs/alt'

Example 4-8 Specifying Separate Archiving Locations for Online and Standby Redo Log Files

This example configures separate archiving locations for standby redo log files and online redo log files. Also, alternate archiving locations are configured for the online and standby redo log files by using the AlternateLocation and StandbyAlternateLocation properties respectively 

ArchiveLocation='/archfs/arch/online'
AlternateLocation='/archfs/alt/online'
StandbyArchiveLocation='/archfs/arch/standby'
StandbyAlternateLocation='/archfs/alt/standby'

Other Redo Transport Settings

You can use database properties to tune the performance of redo transport services and to set up redo transport services failure policies.

The properties used are: Binding, MaxFailure, NetTimeout, RedoCompression, and ReopenSecs . These properties correspond to attributes on the LOG_ARCHIVE_DEST_n initialization parameter.

See Also:

Oracle Data Guard Broker Properties for complete information about these database properties

Redo Transport Services in an Oracle RAC Database Environment

If the primary database is an Oracle RAC database, the broker ensures that redo transport services are set up identically on each of the primary database instances.

Each instance has the same remote destinations, and for each remote destination, all instances are set up the same in terms of redo transport service, performance related settings, local archival of the online redo logs, and so on. If an instance has different settings, the broker raises a health check warning on that particular instance

Settings relative to redo transport services are saved in the broker configuration file as properties. When you update a redo transport-related property on a standby database, the corresponding change is also made automatically by the broker to the LOG_ARCHIVE_DEST_n initialization parameter on all of the primary database instances. If a new instance comes up on the primary database, the broker sets up redo transport services for the new instance using the redo transport-related properties of all the configuration members currently being managed by the broker. After the new instance is opened for activity, all archived redo log files generated on this instance begin to transmit to members of the configuration.

See also:

Oracle Data Guard Concepts and Administration for additional information about the LOG_ARCHIVE_DEST_n initialization parameter

Transport Lag

Transport lag is a measure of the degree to which the transport of redo to a standby database or far sync instance lags behind the generation of redo on the primary database.

If there are one or more redo gaps on a standby database or far sync instance, then the transport lag is calculated as if no redo has been received after the beginning of the earliest redo gap.

Both Cloud Control and the DGMGRL client display the redo transport lag for each managed standby or far sync instance. Cloud Control displays the transport lag on the Oracle Data Guard home page. The DGMGRL client displays the transport lag in the SHOW DATABASE output. There is no transport lag displayed for a primary database. Here is an example of the transport lag for a physical standby database: 

DGMGRL> SHOW DATABASE 'South_Sales';

Database - South_Sales

  Role:                PHYSICAL STANDBY
  Intended State:      APPLY-ON
  Transport Lag:       0 seconds (computed 1 second ago)
  Apply Lag:           0 seconds (computed 1 second ago)
  Average Apply Rate:  13.00 KByte/s
  Real Time Query:     OFF
  Instance(s):
    SouthSales

Database Status:
SUCCESS

Starting with Oracle Database Release 19c, the SHOW CONFIGURATION LAG command displays a summary of the broker configuration and the transport lag of all standby databases. 

DGMGRL> SHOW CONFIGURATION LAG;

Configuration - config

  Protection Mode: MaxPerformance
  Members:
  North_Sales - Primary database
    Warning: ORA-16801: Redo transport-related property is inconsistent with member setting.

    South_Sales - Physical standby database 
                  Transport Lag:       0 seconds (computed 1 second ago)
                  Apply Lag:           0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 11 seconds ago)
The transport lag can help you identify any problems that may exist with the redo transport services.

You can set the TransportLagThreshold database configurable property to generate a health check warning when the transport of redo data to a standby database or far sync instance lags behind the generation of redo data on the primary database.

The following command sets the TransportLagThreshold property to 15 seconds: 

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportLagThreshold'=15;
Property TransportLagThreshold updated

Additionally, you can set the TransportDisconnectedThreshold database configurable property to generate a health check warning if a standby or far sync instance finds that it has not had any redo transport-related communication with the primary database. The property has a default value of 30 seconds.

The following command sets the TransportDisconnectedThreshold property to 15 seconds: 

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportDisconnectedThreshold'=15;
Property TransportDisconnectedThreshold updated