DB2 High Availability Disaster Recovery (HADR) is an easy to use data replication feature that provides a high availability (HA) solution for both partial and complete site failures.

However, given the sheer variety of users’ requirements, there is no one ideal configuration for HADR. The decisions you make in setting up, tuning, and maintaining your HADR environment are often the result of weighing various pros and cons. For instance, you might need to balance the competing requirements of the availability of your database with protection from data loss. The good news is that this need to find a balance does not necessarily imply that one requirement needs to suffer.

This document provides a number of recommendations for setting up and maintaining your HADR environment in ways that help balance the protection HADR provides with performance and cost. The following specific areas of focus are covered:

• Setting up your system for fast failovers
• Tuning parameters to improve network performance
• Tuning parameters to minimize the impact of HADR-related logging on performance
• Choosing the right table reorganization method and load operation in an HADR environment

• Executive summary
• Introduction to HADR
• Setting up your system
• Perform an infrastructure analysis
• Requirements for setting up HADR
• Use dedicated, high performing disks or file system for the database logs
• Make the location of archived logs accessible to both the primary and standby databases
• Use a dedicated network for the HADR primary-standby connection
• Consider using multiple network adaptors
• Consider using a virtual IP address for the database server
• Consider using automatic client reroute
• Tuning parameters
• HADR-specific parameters
• Choose the appropriate HADR synchronization mode
• SYNC mode
• NEARSYNC mode
• ASYNC mode
• SUPERASYNC mode
• HADR simulator
• Tune DB2_HADR_BUF_SIZE
• Monitoring HADR standby receive buffer usage
• Tune hadr_timeout
• Tune hadr_peer_window
• Tune DB2_HADR_PEER_WAIT_LIMIT
• Tune DB2_HADR_SOSNDBUF and DB2_HADR_SORCVBUF
• Client-server communication parameters
• Tune DB2TCP_CLIENT_RCVTIMEOUT
• Database parameters
• Set logfilsiz to a moderate size
• Set logindexbuild to ON
• Set indexrec to RESTART
• Tune softmax
• Database parameters related to client reroute
• Set DB2_MAX_CLIENT_CONNRETRIES and DB2_CONNRETRIES_INTERVAL
• Database administration and maintenance
• Choosing the appropriate reorganization method
• Perform an online reorganization to maintain availability of the affected tables and indexes
• Perform an offline reorganization if the affected tables and indexes can be unavailable
• Performing load operations in an HADR environment
• Perform a nonrecoverable load only if the load operation does not need to be replicated on the standby
• Ensure that the load copy is available to the standby when it replays the load
• Set the DB2_LOAD_COPY_NO_OVERRIDE registry variable to COPY YES if there will be frequent load operations
• Best Practices
• Conclusion
• Further reading
• Contributors
• Notices
• Trademarks

" Best Practices: DB2 High Availability Disaster Recovery " (August 2011)
Recommendations for setting up and maintaining a DB2 High Availability Disaster Recovery (HADR) environment in ways that balance the protection HADR provides with performance and cost. This best practice explains optimizing for fast failovers, tuning parameters for network and logging performance, and understanding table reorganization methods and load operations in an HADR environment. (pdf; 583KB; 27 pages)

Check out all the other Best Practices papers and see how you can improve your experience with DB2 for Linux, UNIX, and Windows.