Administrator > Backup and Recovery

DB2 for z/OS High Availabilty and Unplanned Outage Recovery

Note: This is the second part of a two-part exploration of DB2* for z/OS* high availability. Part one was published in the September/October issue.

 

In the first part of my exploration of DB2 for z/OS high availability, I discussed how planned system outages can be prevented through DB2 for z/OS. This article explores the role DB2 for z/OS plays in reducing unplanned system outages and supporting high availability (HA).

 

From an application perspective, DB2 offers several functions for minimizing the duration of unplanned outages. Partitioned table support has been enhanced to allow many application-related changes to be implemented non-disruptively. The application is becoming the main obstacle to 24-7 availability.

 

User-written applications don't frequently commit updates. The amount of data locked by the application can become large and include many changed rows, which limits the data that other users can process in the database. Users then experience time-outs waiting for data not yet committed. The problem is especially acute in the batch environment where there are often few or no commits, so the application can become the bottleneck causing DB2 to wait for work. This condition occurs with applications that converted from less powerful database-management systems to DB2 for z/OS. These applications begin small, with infrequent batch committing, becoming an architectural flaw not noted until processing volumes grow.

 

Application availability and performance can be achieved if the batch processes are structured to run in parallel, but little or no application committing causes a batch to run effectively in a single-thread environment. This is how the user-written application can impact both availability and performance. The application solution is to implement an architecture that provides batch application parallel processing (in effect cloning the batch processes to process multiple instances of a batch program each with different inputs). This batch architecture requires frequent application commits to enable the "clones" to execute concurrently with other application workloads.

 

The unplanned outage is generally necessitated by a component failure that can include a DASD device, a processor or system software like DB2. In part one of this article, I focused on duplexed components to minimize required planned outages. Since many of those considerations apply to the unplanned outage, I'll outline the benefits of data sharing to support duplexed components in this article, with the main focus on parallel utility processing and point-in-time recovery.

 

User implement the DB2 for z/OS on z/OS system, which can reduce the need for a planned outage and minimize the likelihood of an unplanned outage.

Next page: >>