© 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