Best Practices for Automatic Failover Using Oracle Data Guard 10g Release 2

作者: Maclean Liu , post on November 26th, 2010 , English Version
【本站文章除注明转载外,均为本站原创编译】
转载请注明:文章转载自: Oracle Clinic – Maclean Liu的个人技术博客 [http://www.oracledatabase12g.com/]
本文标题: Best Practices for Automatic Failover Using Oracle Data Guard 10g Release 2
本文永久地址: http://www.oracledatabase12g.com/archives/best-practices-for-automatic-failover-using-oracle-data-guard-10g-release-2.html

Agenda

  • Fast-Start Failover Overview
  • Fast-Start Failover, Details & Best Practices
    • Failover Processing Flow
    • Failover Events and Monitoring
    • Best Practices
    • Test Results
  • Automatic Client Failover
  • Questions?

Failover Requirements

  • Faster is better
    • Downtime is bad
    • If manual intervention is required, the time it takes to notify administrative staff can be lengthy
  • Reliability is a must-have
    • Correct procedure for failover must be followed to minimize data loss (recovery point objective)
  • Simplicity is preferred
    • Determining if failure condition warrants a failover adds time & complexity to the failover process
    • Manually rebuilding the old primary following failover consumes time and resources and is error prone

Fast-Start Failover Requirements

  • Primary and Target Standby are managed by the Data Guard Broker
  • Primary database must be in Maximum Availability mode – synchronous redo shipping
  • Primary and target standby must have Flashback Database enabled
  • Observer host must have DGMGRL utility installed and must have Oracle Net connectivity to both the primary and target standby

When is a Fast-Start Failover Triggered?

  • Network Related Conditions:
    • Failover occurs only if links between primary and observer as well as primary and target standby are down
      • Requires a connection between Observer and standby to enable the Observer to confirm that the configuration is in a synchronized state
  • By ensuring that at least two fast-start failover partners are present, conditions such as split-brain scenarios are avoided

Reinstatement after a Fast-Start Failover

  • Any attempt to start old primary will stop at the mount state thus preventing split brain
  • Once Observer sees the old primary is at the mount state, reinstatement is begun
  • The old primary is automatically reinstated as the new standby using flashback database
  • New standby is automatically resynchronized with new primary by Data Guard
  • Once resynchronized, a switchover can occur if desired – returning all systems to their original roles


© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.

相关文章 | Related posts:

  1. Extending Automatic Storage Management to Manage ALL Data Oracle Database 11g Release 2
  2. Make Money with Active Data Guard
  3. Script to Collect Data Guard Diagnostic Information
  4. Oracle Database 11gr1/10gr2 Automatic Storage Management Overview and Technical Best Practices
  5. Best Practices for Loading in an Oracle Data Warehouse
  6. Scripts for Oracle Streams Performance Tuning Best Practice: Oracle 10g Release 10.2
  7. Migrating to RAC using Data Guard
  8. CLOBs and NCLOBs character set storage in Oracle Release 8i, 9i, 10g and 11g
  9. Automatic Checkpoint Tuning
  10. How to Make Use of Oracle's Data Compression with Materialized Views.

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>