High Availability Technologies for Db2 LUW

Organisations are increasingly operating on a global scale. When once you could schedule your maintenance updates for Sunday night, this now affects users across the other side of the globe.

When downtime is unplanned however, these issues multiply ten-fold. These outages are a lot more visible to users and the public at large with potential ramifications to revenue, brand image and customer satisfaction.

There are a number of different solutions available which can provide high availability and disaster recovery:


DB2 features that minimise unplanned outages:


pureScale and HADR

Can be used to implement disaster recovery of pureScale clusters over long distance. Together, Db2 pureScale and HADR reduce the risks of planned and unplanned outages to help meet your SLA requirements.


Db2 pureScale

Db2’s clustering solution designed for organisations that require high and continuous availability, reliability and scalability for online transaction processing (OLTP) to meet stringent service level agreements.



HADR is a database replication feature that provides a high availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database to a target standby database in real-time. With HADR, the standby database can take over in seconds in the event of a failure on the source database.


Tivoli Systems Automation

Cluster managing software that facilitates automatic switching of users, applications, and data from one database system to another in a cluster. TSA is commonly used with HADR to automate the takeover of database operations from the primary HADR database server to the Standby database server in the event of a failure.



SQL or Q-replication can be very useful for setting up a high availability failover database that can be also be used for test or reporting purposes.


Automatic Client Reroute

Can be used with HADR to automatically redirect the clients to the standby database in the event of a failure on the source database thereby minimising application downtime.