DB2 UDB for z/OS: Design Guidelines for High Performance and Availability

© Copyright IBM Corp. 2005. All rights reserved. 359

Chapter 13. Achieving 24x7

In this chapter, we provide several guidelines about designing applications for continuous

availability.

Building a system that provides users with 24x7 availability is not an easy task. The cost of

providing the availability can be significant and is not linear, because every percentage point

that brings you closer to the goal of 100% 24x7 availability has an increased cost.

The first activity for your organization is to set a realistic goal for the availability of your system

providing a realistic return on investment. A risk assessment must analyze the criticality of

each process and the impact of unavailability of that process on your business. You can set

different availability goals, depending on your industry and even the criticality of your business

processes. Some processes allow for a downtime of one day, where other processes can be

unavailable only for hours, minutes, or even seconds.

The user perception of non-availability covers a broad range of issues including hardware

availability, system software defects, application software defects, database maintenance,

application design practices, procedures for application life cycle management, and recovery

procedures. If you want to achieve the maximum availability goal, you need to evaluate,

manage, and reduce the impact of all of these potential points of failure.

Hardware and system software are constantly improving and providing new and better

mechanisms and features which help you build the infrastructure delivering the availability.

The data sharing architecture enables you to dramatically improve the availability of your

system components, where dual and remote copy contribute to the overall availability of the

I/O subsystem and disaster recovery.

Application software defects can be very disruptive because they can cause data

inconsistencies. Deploying server side constraints such as RI or table check constraints can

protect you against some of these issues, but they do not cover the full scope of application

defects. Setting up proper testing procedures helps to reduce the probability of moving

erroneous programs into production. Once the damage is done, it is important to limit its

impact, so you need verification procedures and utilities that enable you to back out the

changes and restore both the data and the programs to a consistent state.

The impact of database maintenance depends on the database design and the nature of your

applications. The frequency of reorganization is a good example to illustrate that concept. In

13

360 DB2 UDB for z/OS: Application Design for High Performance and Availability

an R/O environment, the frequency is close to zero, but in a highly volatile environment, the

frequency could be as high as daily. Database design and insert patterns can heavily affect

the frequency of database maintenance. The business itself can influence insert patterns by

deciding to turn on a feature or take in new streams of transactions.

DB2 provides features, such as partition independence and online REORG and LOAD with

inline image copy, that limit the scope or even eliminate the unavailability.

Some application design techniques sacrifice availability in order to reduce the elapsed

processing time. If you unload a table in a sequential file, the table should be made

unavailable for updates until the file is reloaded in the table. Failing to do so causes the

changes, which are applied to the table after the unload, to be lost. Achieving the continuous

availability goal could mean that some of the design techniques are no longer applicable.

This chapter contains the following topics:

򐂰 Maintaining the schema

򐂰 Managing application programs

򐂰 Designing for application parallelism

򐂰 Managing application data