Oracle9i Data Guard:
Primary Site and Network Configuration Best Practices
With Oracle Data Guard and Real Application Clusters, Oracle is addressing the requirements of business continuity for disaster recovery. Because Data Guard transmits primary database changes to a standby database connected over a network, the performance and degree of protection of the databases in the Data Guard configuration are dependent on how the databases and the network are configured. This white paper determines the configuration best practices for Data Guard to optimize system performance while maximizing data protection, using Data Guard Redo Apply.
Oracle’s High Availability Systems team executed a series of tests over a local area network (LAN) and simulated metropolitan area (MAN) and wide area networks (WAN). The series of tests used different application profile workloads to determine Data Guard configuration best practices. The team determined that Data Guard’s zero data loss synchronous log transport (i.e. the Maximum Protection and Maximum Availability modes) is recommended for a configuration in which the standby database is located up to hundreds of miles away from the production database, providing maximum protection and availability advantages with very little impact on the production database. Data Guard’s asynchronous log transport (i.e. the Maximum Performance mode) is recommended for a configuration in which the network distance is up to thousands of miles, providing continual maximum performance, while minimizing the risks of transaction loss in the event of a disaster.
Based on the test results the following are realistic scenarios:
1. Building a Data Guard environment between Tokyo and Kyoto (229 miles / 366 kilometers, ~ 7ms RTT) using synchronous mode will provide zero data loss with minimal performance impact (less than 3% in tests). The performance impact is dependent on the application commit frequency. Our tests showed a higher commit frequency incurred more impact to the primary (2-3% more in our 400 user tests).
2. Building a Data Guard environment between San Francisco and New York (2582 miles / 4157 kilometers, ~ 78ms RTT) using asynchronous mode will have almost no performance impact (1% in tests) and minimal application impact in the event of a disaster. On average, the transaction loss potential was 0.6-1.3 seconds and the worst-case loss was 6-13 seconds worth of transactions in our tests.
Note that this is not a benchmark of the Oracle9i Data Guard redo apply database feature. These tests did not attempt to determine the maximum rate at which redo can be transferred and applied.
NETWORK CONFIGURATION Best Practices
These best practices were derived after extensive testing on Oracle9i databases as part of the studies within the Maximum Availability Architecture (MAA) best practices and recommendations. For more information about MAA, refer to http://otn.oracle.com/deploy/availability/htdocs/maa.htm. Descriptions of the test environment, test cases, and test results used to identify these best practices are included in subsequent sections of this paper.
The following experiments are documented:
· Performance of the different transport services in a LAN and WAN network environment
· Impact of different network round trip times (RTT) on primary database throughput
The Data Guard transport service options were tested in a LAN and an emulated MAN / WAN network environment using high transaction rates of 180 and 360 transactions per second (TPS) and redo rates ranging from 0.7 to 1.6 MB/sec for OLTP tests and 4.5 MB/sec for our batch runs.
Local Area Network
Data Guard is often used in a local area network (LAN) to protect against data loss due to human error or data failure. LAN testing was done on an internal private network with a network RTT of approximately 0.2 milliseconds (ms). When using Data Guard Redo Apply in a LAN the following is recommended:
· Use Maximum Protection or Maximum Availability modes for zero data loss; the performance impact was less than 3% in all synchronous tests. With a single remote archive destination, use the NOPARALLEL option (“lgwr sync=noparallelâ€).
· For very good performance and a minimal risk of transaction loss in the event of a disaster, use Maximum Performance mode, with LGWR ASYNC and a 10 MB async buffer (ASYNC=20480). LGWR ASYNC performance degraded no more than 1% as compared to using the ARCH transport. LGWR ASYNC also bounds the risk of potential transaction loss much better than the ARCH transport. The 10 MB async buffer outperformed smaller buffer sizes and reduced the chance of network timeout errors in a high latency / low bandwidth network.
Metropolitan and Wide Area Network
Data Guard is used across a metropolitan area networks (MAN) or WANs to get complete disaster recovery protection. Typically a MAN covers a large metropolitan area and has network Round-Trip-Times (RTT) from 2-10 ms. For the MAN/WAN tests, different network RTT’s were simulated during testing to measure the impact of the RTT on the primary database performance. The tests were conducted for the following RTT’s: 2 ms (MAN), 10 ms, 50 ms, and 100 ms (WAN) Additionally, tests using Secure Shell (SSH) port forwarding with compression were also done for different RTT’s. Best practices recommendations are:
· Use Maximum Protection and Maximum Availability modes over a MAN for zero data loss. . For these modes, the network RTT overhead over a WAN can impact response time and throughput of the primary database. The performance impact was less than 6% with a 10 ms network RTT and a high transaction rate.
· For very good performance and a minimal risk of transaction loss in the event of a disaster, use Maximum Performance mode, with LGWR ASYNC and a 10 MB async buffer (ASYNC=20480) LGWR ASYNC performance degraded no more than 2% as compared to remote archiving. The 10 MB async buffer outperformed smaller buffer sizes and reduced the chance of network timeout errors in a high latency / low bandwidth network.
· For optimal primary database performance throughput, use remote archiving (i.e. the ARCH process as the log transport). This configuration is best used when network bandwidth is limited and when your applications can risk some transaction loss in the event of a disaster.
· Set SDU=32K for the Oracle Net connections between the primary and standby. Setting the Oracle network services session data unit (SDU) to its maximum setting of 32K resulted in a 5% throughput improvement over the default setting of 2K for LGWR ASYNC transport services and a 10% improvement for the LGWR SYNC transport service.
For complete details on the testing environment and testing results see http://otn.oracle.com/deploy/availability/pdf/MAA_DG_NetBestPrac.pdf.
Conclusion
The various test results demonstrate that Data Guard is a highly efficient and flexible disaster recovery solution that can maximize protection without sacrificing performance. This paper has highlighted that:
· The Maximum Performance protection mode performs well in all environments
· The Maximum Protection and Maximum Availability protection modes perform well in LAN and MAN environments
· The network bandwidth and latency between the production and standby sites have an impact on production database throughput
· Maintaining optimal performance with the required database protection requires testing and continual monitoring of the database, system and network, and response time
Optimally, tuned database server systems are paramount in meeting application service level agreement (SLA) requirements consistently. When using Data Guard it is also recommended that the network RTT be a component of an SLA. This implies that you also have a well-understood SLA with your network provider and that you ask your network provider the right questions. Setting a network RTT guarantee as part of a SLA and monitoring RTT data, long term is useful for trend analysis and correlation against other performance metrics. Ideally the Data Guard primary/secondary network connection should be dedicated or at a minimum given a higher priority within an IP classification and prioritization scheme to reduce variance in the network RTT.
A performance assessment will detail and document your end-to-end performance and allow for the establishment of baseline performance numbers as part of your SLA(s). Following the best practices in this paper will assist with implementing a properly tuned Data Guard configuration that minimizes any impact to the primary database and gives superior protection to your business from disasters, site failures, data failures, and human
| 相关的 产品
|
||