© Copyright IBM Corp. 2005. All rights reserved. 359
Chapter 13. Achieving 24x7
In this chapter, we provide several guidelines about designing applications for continuous
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
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

Get DB2 UDB for z/OS: Design Guidelines for High Performance and Availability now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.