Implementing Data Guard?
What you need to know
Joseph Meeks, Server Technologies, Oracle Corporation
Planning a Disaster Recovery (DR) strategy for your Oracle database may appear daunting but the good news is that Oracle Data Guard is a straightforward application of Oracle technologies, used to maintain one or more synchronized copies of your production database. This lets you leverage existing DBA skills already in-house, and gives your DBA team complete control over your standby databases. You will simultaneously increase data protection and high availability, while reducing cost and business risk compared to using traditional DR solutions implemented in-house or outsourced to 3rd party DR service providers , . The overview provided below covers the main points you need to consider to get your Data Guard configuration up and running. For detailed information please refer to the complete Data Guard documentation .
Service Level Agreements: Determine your Recovery Point Objective (RPO). RPO is the maximum amount of data that can be lost and still satisfy Service Level Requirements (SLAs). Determine your Recovery Time Objective (RTO). RTO is the maximum amount of time that the database can be unavailable and still satisfy SLAs .
Workload: Data Guard ships redo data generated by the production database to the standby destination and applies redo data to the standby database. This makes redo volume one of the key considerations when implementing a Data Guard configuration. Determine the peak redo generation rate of the primary database; measured in Megabytes/second. Understand both the frequency and duration of these peak periods. Also determine the average redo generation. Note: if your Data Guard configuration includes a RAC primary database, the redo rate is the sum of the redo generated by all nodes
Network Requirements: The efficiency with which Data Guard can ship data to a remote DR site is dependent upon network bandwidth and latency. Determine the network bandwidth available to Data Guard for shipping redo data. Determine the round-trip network latency (RTT) between production and standby sites, measured in milliseconds. Make sure that these are adequate for Data Guard to ship redo data to the DR site at peak redo generation intervals on the production database. Data Guard best practices describe several database and OS network parameters that be tuned to enhance and optimize network transmission throughput .
Redo Apply or SQL Apply: Determine which type of Standby Database to implement. Redo Apply (physical standby database) is preferred by more conservative users where the emphasis is on scalability and/or where data types are not supported by SQL Apply (logical standby database). These preferences are rooted in the simplicity and efficiency of the media recovery mechanism used by Redo Apply. A physical standby database can also be used to offload the primary of doing online backups (RMAN can do online backups of a standby database while Redo Apply is on ), and it can be open read-only to enable reporting against a static copy of the production database.
SQL Apply (logical standby database) is preferred if the standby database must also serve as an up-to-date reporting database (read/write access is allowed while updates from the production database are being applied). By definition, SQL Apply requires more standby resources (both CPU and I/O) than Redo Apply, because it has to mine the incoming redo on the standby database, generate SQL, and apply this SQL to the standby database, and therefore is typically used for less demanding performance requirements.
Protection Mode: Determine if you will use Maximum Performance (asynchronous redo shipping, a lower level of data protection with least overhead on the production database), Maximum Availability (synchronous zero data loss protection, higher performance impact on the production database, but availability is NOT impacted should the production database be unable to communicate with the standby database), or Maximum Protection (the highest level of data protection possible that will, by definition, cause the production database to shut down if Data Guard can not confirm that redo data has been written to at least one standby location). The choice of protection mode is driven by the combination of RPO/RTO SLAs and the capacity of systems and network to ship and apply the required redo volumes.
Manual or Automatic Failover: All Data Guard configurations include role management services for the orderly transition of a standby database to the production role . Starting with Oracle Database 10 g Release 2, Data Guard configurations using Maximum Availability mode have the option of implementing unattended, automatic failover upon primary database failures .
Management Interface: Select one of three options:
Tuning SQL Apply: The SQL Apply process mines incoming redo at the standby database, converts it to SQL, and applies SQL to the standby database. The SQL Apply process requires more CPU and I/O resources than does Redo Apply. Plan accordingly by referencing SQL Apply Best Practices  and applicable MetaLink notes .
Maximum Availability Architecture: The Oracle Maximum Availability Architecture (MAA) provides a best practices blueprint for deploying the full range of Oracle HA technologies. If, in addition to Data Guard you are using RAC, RMAN, Flash Recovery Area, Flashback Database, or ASM, please refer to the MAA home page on OTN for more information .
Joseph Meeks is a Director of Product Management with Oracle's High Availability and Maximum Availability Architecture Group. He has 25 years of experience assisting customers in the design and deployment of highly available systems for mission critical applications.
More Database Downloads