Data Guard Transport Considerations on Oracle Database Machine (Exadata)

(Doc ID 960510.1)

Last updated on SEPTEMBER 01, 2017

Applies to:

Oracle Database - Enterprise Edition - Version 11.1.0.7 and later
Oracle Exadata Hardware - Version 11.1.0.7 and later
Information in this document applies to any platform.

Goal

In a typical Data Guard configuration, the primary database uses the same network to transmit redo to the standby database as client connections use to connect to the primary database. For example, both client connections and Data Guard redo transport traffic use the eth1 Ethernet interface. In configurations that place high demand on the network, combining both types of traffic on the same network can impact performance. Also, business availability requirements may mandate that Data Guard traffic be on a separate network from client connections.

Move Data Guard network traffic to a separate network interface
This approach to eliminate contention between the different types of network traffic is to move Data Guard redo transport to a separate network. For example, client connections continue to use the eth1 Ethernet interface, but Data Guard redo transport instead uses the eth3 Ethernet interface to access a dedicated disaster recovery network.  It is not recommended to use Infiniband for Data Guard transport as it becomes a single point of failure.

The remainder of this document explains how to direct Data Guard network traffic through a different network than what is used for client connections to the database. 

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms