Administrator > DB 2

DB2 for z/OS Features Contribute to High Availability

September | October 2005 | by Lee Siegmund

Note: This is the first part of a two-part exploration of DB2* for z/OS* high availability. Part two will run in the November/December issue.

DB2 for z/OS has built a reputation as a world-class database server, and high availability (HA) has been key to that reputation. From the early days of it's history to the modern era, DB2 has consistently provided customers with features that can be implemented to provide nearly 24-7 availability. The biggest deterrent to 24-7 availability has traditionally been customer-written applications, something that will be explored further in this article.

HA is focused on minimizing the duration of both planned and unplanned outages. With that in mind, lets explore some DB2 for z/OS product features that enable users to minimize the duration of planned and unplanned outages. Within the framework of addressing both planned and unplanned outages, I'll focus on two important questions:

What functions of DB2 facilitate minimizing the duration of planned and unplanned outages?

For today and into the future, what are the DB2 users primary inhibitors to 24-7 availability?

What is HA?

A brief review of DB2 history is helpful when trying to understand availability issues. The current release of DB2 is Version 8, which is actually the 12th release of DB2 (Version 1 and Version 2 each had three releases). When DB2 was announced and first made available in the early 1980s, HA was on the users radar screen, but the state of technology was less advanced than today. DB2's availability features were impressive by standards of the early 1980s; without bringing down DB2, the user could:

1. Define a DB2 table

2. Populate the table using the Load utility

3. Establish security and authorization procedures

4. Backup the table with the Copy utility

5. Recover the table with the Recover utility

The user could perform tasks like these while DB2 continued to make application and system functions available to users. As significant as availability functions were, there were also limitations that could impact not only applications but also the DB2 system. Some of those limitations included:

1. Load and Reorganization utilities blocking application access to the data

2. Single points of failure: DB2, the OS and DASD could fail, making the system unavailable

3. Performance issues relative to availability; it could take awhile to recover an index or reorganize a table

4. Users required point-in-time recovery when their applications erroneously updated data, and early point-in-time recovery support was crude at best

DB2 got off to a good start, but it required improvements that have been integrated into DB2 over the years, while providing functional enhancements. The substance of DB2 availability enhancements can be introduced at a high level with two concepts: duplexing prior single points of failure and parallel processing. I'll fully explore and develop these concepts to explain how DB2 for z/OS can provide near 24-7 availability and outline why the current major obstacle to that availability is the user-application program. Simply stated, a major exposure to HA is a users application contaminating the data through erroneous program logic or a flawed operational procedure.