DB2 9.5 High Availability Solution

High availability is a key requirement for important database applications. IBM DB2 9.5 offers many features to meet this requirement. If you are not familiar with the DB2 on a distributed platform, or have been using it for a while, you may find this set of features confusing to deal with usability. When to use which feature, what goals do you want to accomplish when using features?

Before we begin, we'll define the meaning of the term high availability (HA). HA refers to the requirement to provide data when a dependent application requires data. The aim is to eliminate or avoid downtime as much as possible. One term associated with HA is disaster recovery (disaster RECOVERY,DR), and DR differs from ha in that it focuses on protecting data and preventing data loss due to catastrophic failures. This article focuses only on HA.

Terminology and client/server database schemas

Terminology and client/server database schemas

We first discuss terms and concepts that are important to understanding high availability.

A database solution consists of three pieces of software:

• User Applications

• Client Software

• Database Engine

In addition to software, to obtain an effective solution, you must have some other resources:

• Server hardware

• Network connection

• Disk storage

• Operating System

All these aspects must be considered when designing an HA solution. Simply making the database engine highly available does not necessarily create an HA solution. The design of the HA solution is not entirely a technical issue, it must also take into account other factors, such as the cost of the solution, skill requirements, and management requirements.

The database application is based on client/server. Whether the application produces consistent results depends on the integrity of the database software. While this is obvious, it is important to choose and design a solution.

SQL transactions can be divided into two types: Read and write. A read transaction is a selection statement that does not require inserting, updating, or deleting an activity. Write a transaction to change at least one database. Read transactions require a consistent view of the data-that is, when two read transactions are committed simultaneously, if they choose the same data range, a consistent result set should be produced. Writing a transaction requires that the submitted database changes be persisted, even when a failure occurs. The business requirements affect what HA solutions are available or most appropriate. In general, the design of the HA solution is driven by two factors, normal uptime (uptime) requirements, and transactional consistency. If the business requires higher availability, and read consistency is not important, it may be more economical to choose Asynchrony. On the other hand, if transactional consistency is a critical requirement, then you need to choose a more synchronized solution. If transactional consistency and availability are required, the range of choices will be narrowed further.