Data Guard Transport Considerations on Oracle Database Machine (Exadata)
(Doc ID 960510.1)
Last updated on AUGUST 04, 2018
Applies to:Oracle Database - Enterprise Edition - Version 188.8.131.52 and later
Oracle Exadata Hardware - Version 184.108.40.206 and later
Information in this document applies to any platform.
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|Configuration for 11.2|
|Configuration for 11.1|
|Sending Redo to Specific Standby Instances|