Assessing and Tuning Network Performance for Data Guard and RMAN
(Doc ID 2064368.1)
Last updated on JUNE 28, 2023
Applies to:
Oracle Cloud Infrastructure - Database Service - Version N/A and laterOracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.
Goal
The goal of this note is to provide steps to evaluate network bandwidth and experiments that will help tune operating system, Oracle Net or RMAN parallelism to improve overall network throughput for Oracle database operations that need to transfer data across the network. The most typical database operations that will benefit from this tuning is 1) RMAN database backup/restore or database migration operations across the network, 2) Data Guard instantiation across network, and 3) Data Guard or GoldenGate redo or data transport across the network.
- Scenario 1 - Understand the existing network and evaluate tuning options prior to database migration, Data Guard deployment or RMAN operations for a large database.
It is critical that you have sufficient network bandwidth to support peak redo rates (steady state and when resolving gaps) along with any other network activity that shares the same network. Please note that your point-to-point network bandwidth will be throttled by the network segment, switch, router, and interface with the lowest network bandwidth. Some networks also implement Quality of Service rules to prioritize certain data as well as placing restrictions on a single flow throughput to prevent a single process from consuming the network. Using oratcptest as described below can help you determine potential network throughput using the shared network.
- Scenario 2- Experiencing a transport lag with the ASYNC transport.
With enough network bandwidth, ASYNC transport can maintain pace with very high workloads, up to approximately 400MB/sec per Real Application Cluster instance. In cases where resources are constrained, the ASYNC transport can fall behind, resulting in a growing transport lag on the standby. A transport lag is the amount of data, measured in time that the standby has not received from the primary. Determine transport lag on the standby database by querying the V$DATAGUARD_STATS view using a query like the following.
Solution
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
Goal Solution Installation and Usage of oratcptest Supporting Utilities Gathering Information about the Interface with ethtool Gather Socket Information Using the ‘ss’ Command Using the Linux ‘sar’ Command to Monitor Interface Throughput Determining Optimal Socket Buffer Size Socket Buffer Size Selective Acknowledgements Changing the Maximum Socket Buffer Size and Testing Single Process Throughput (Scenarios 1, 2, 3 and 4) Multiple Process Aggregate Throughput (Scenario 3 - RMAN Operations) Testing Multiple Process Throughput Throughput with SYNC (Scenario 4 – SYNC Transport) Assessing Network Performance for Data Guard Synchronous Redo Transport Setting Oracle Net SDU for SYNC Transport Setting SDU for Oracle RAC Setting SDU for Non-Oracle RAC Use oratcptest to Assess SYNC Transport Performance Determine Redo Write Size Run tests with oratcptest Implement FASTSYNC Increase Socket Buffer Size Command Options oractcptest help output: My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.