High Availability is a key requirement for important database applications. IBM DB2 9.5 provides many features to meet this requirement. If you are not familiar with DB2 on the distributed platform, or have been using it for a while, you may find this set of processing availability features confusing. When to use which feature and what target do you want to accomplish when to use it?
Before getting started, let's first define the meaning of the term HA. HA indicates that data is provided when dependent applications require data. The purpose is to eliminate or avoid downtime as much as possible. One term related to HA is Disaster Recovery, DR). The difference between DR and HA is that it focuses on protecting data and preventing data loss due to catastrophic faults. This article only focuses on HA.
Terms and Client/Server database architecture
Terms and Client/Server database architecture
First, we will discuss some terms and concepts, which are important for understanding high availability.
A database solution consists of three parts of software:
· User applications
· Client software
· Database Engine
In addition to software, to get an effective solution, you must have other resources:
· Server hardware
· Network Connection
· Disk storage
· Operating System
All these aspects must be taken into account when designing an HA solution. An HA solution may not be created only when the database engine is highly available. The design of an HA solution is not entirely a technical problem. It must also consider other factors, such as the cost, skill requirements, and management requirements of the solution.
Database applications are based on clients/servers. Whether an application can produce consistent results depends on the integrity of the database software. Although this is obvious, it is important to select 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 activities. Write a transaction to change at least one database. Read transactions require a consistent view of data-that is, when two read transactions are committed at the same time, if they select the same data range, a consistent result set should be generated. Write transactions require committed database changes to be persistent, even when a fault occurs. What HA solutions are available or most suitable. Generally, the design of the HA solution is driven by two factors: normal running time uptime) requirements and transaction consistency. If the business requires higher availability and read consistency is not very important, asynchronous selection may be a more economical method. On the other hand, if transaction consistency is a key requirement, You need to select a more synchronous solution. If both transaction consistency and availability are required, the optional range will be further reduced.
- Features of the next IBM DB2 database version
- DB2 transaction log usage
- Make the DB2 database in the business system architecture more reliable