DB2 on LUW – A Highly Available Database

How much does your business suffer if you cannot get to your data within a certain time? Loss of data access can significantly impact your business resulting in losses in revenue, customer confidence, market share, and more. Database High Availability is about making sure the database system remains operational during both during planned and unplanned outages, such as maintenance operations, or hardware or network failures. High Availability is not a single feature in DB2 on LUW. There are a number of high availability features in DB2 that allow you to cater for the amount of downtime and budget that is acceptable for your business applications. DB2 provides database clustering as well as high availability and disaster recovery capabilities designed to maximize data availability during both planned and unplanned events:

DB2 features that minimise planned outages

Every database requires routine maintenance tasks, regular tuning, schedule backups that need to be executed, indexes that need to be maintained, and more. DB2 will allow these tasks to take place whilst maintaining the high availability of the database system using several inbuilt features:

• Online, fast, scalable and granular database backup operations
• Online, fast, scalable and granular data movement operations
• Online Utilities
  • Online table and index reorganization
  • Online Index creation
  • Online Statistics collection
  • Online Index creation
  • Online Table Move
  • Online Rebalance
  • Dynamic Configuration parameters
  • Automatic Space Management
  • Automatic Log Management

DB2 features that minimise unplanned outages

A database server can fail as a result of several unplanned factors. These include:

• Hardware failure
• Software failure
• Network failure
• Human intervention
• Adverse environmental conditions

As with planned outages, there are several high availability features that are natively available in DB2 that help you minimize unplanned outages:

• HADR (High Availability and Disaster Recovery) feature of DB2.  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 (logged) changes from a source database, called the primary, to one or more target databases, called the standbys in real-time. With HADR, the standby database can take over in seconds. Further, you can redirect the clients that were using the original primary database to the standby database (new primary database) by using automatic client reroute feature. HADR allows you to perform rolling upgrades such as operating system fixes or database fixpaks with minimal interruptions, thereby reducing downtime.
• IBM Tivoli System Automation (TSA) – a 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.
• pureScale – DB2’s clustering solution designed for organizations that require high availability, reliability and scalability for online transaction processing (OLTP) to meet stringent service level agreements. HADR can also help 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.
• pureScale + HADR – Can be used to implement disaster recovery of pureScale cluster over long distance.  Together, DB2 pureScale and HADR reduce the risks of planned and unplanned outages to help meet your SLA requirements.
• Replication – This option allows organisations to replicate all or a subset of the data from a source database to one or more target database. Both source and primary databases are active. The big advantage in using replication is the ability to do reporting, ad hoc queries, and backups, and more from the target database without impacting your source database.  There are two types of replication supported in DB2, SQL and Q-replication.  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.

Find out more about Database Availability for DB2 LUW

• Share