New to IBM PureData System for Transactions: DB2 10.5 and HADR
August 14, 2013 3 Comments
Kelly Schlamb, DB2 pureScale and PureData Systems Specialist, IBM
In a comment on my previous blog post, somebody recently asked about when the PureData System for Transactions was going to be updated to include DB2 10.5, the latest and greatest version of DB2 that was released on June 14th, 2013. At the time, I hinted that it would be coming soon but I couldn’t share any details. The curtain can now been lifted.
PureData System for Transactions Fix pack 3 was made available for download on July 31st (and any new deployments of the system will automatically have this level as well). This fix pack adds DB2 10.5 to the software stack of the system. So, when you go to deploy a cluster you can now choose to deploy either DB2 10.1 or 10.5, depending on your needs.
As with every major release of DB2, this new version is jam-packed with countless features and enhancements. There’s a lot of great information out there about 10.5 if you’re interested in reading more, including some entries from fellow blogger, Bill Cole and the What’s New section in the Information Center.
While many things will be of general interest to people – such as performance enhancements, new SQL capabilities, and further Oracle compatibility updates – I did want to specifically call out something that will be of great interest to those interested in the DB2 pureScale feature and PureData System for Transactions (which has pureScale built into it). This is the addition of HADR support. HADR is DB2’s High Availability / Disaster Recovery feature. With HADR, changes to a primary database are replicated via transaction log shipping to one or more standbys, allowing for both local high availability and longer distance disaster recovery. There are many reasons why DB2 users have embraced HADR, but the one I hear all the time is that it’s built right into DB2 which makes it very easy to setup and maintain.
In the case of a pureScale environment, you’re already getting the highest levels of availability. For instance, with pureScale in the PureData System for Transactions box, a compute node failure wouldn’t result in the database going offline. In this case, other compute nodes associated with the cluster would still be available to process database transactions. So, with HA already being accounted for, the value in using HADR in this type of environment is for setting up a disaster recovery system. Now, you do have other options for disaster recovery of PureData System for Transactions, such as using QReplication, and there is functionality within QRep that might make it a more suitable choice for a particular database (such as only having a need to replicate a partial set of the data in the database). But with HADR you have another option and those that use it and love it today for their traditional DB2 environments, can now use it here as well. For example, you can have a PureData System for Transactions at your primary site and another one at your disaster recovery site. HADR is enabled at the database level and for one or more databases on the primary system, you can create a standby version at the other site. If there is ever a need to failover to that standby site, it’s a relatively simple process to perform the takeover of the databases on the standby.
Rather than getting into the specifics about how this works, how to configure the environment, etc. I’m going to take the easy route and point you to this comprehensive document on this topic.
Just learning about the product? Check out the PureData for Transactions page .