Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-11-09
2002-02-12
Homere, Jean R. (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000
Reexamination Certificate
active
06347322
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates in general to replicated database systems, and, more particularly, to a system and method for improving the reliability of replicated database systems.
Many industry applications, such as airline reservation systems, banking applications and telecommunications, require reliable database transaction processing. A transaction is a sequence of actions or operations that must be performed in its entirety or not at all. Any degradation in reliability has a negative impact on the customer (e.g., the individual making an airline reservation) as well as the service provider (e.g., the airline). For example, if airline transactions are not reliably processed, customers may experience flight overbooking and, as a result, may choose to fly a different airline.
Historically, systems requiring highly reliable transaction processing have been built using highly fault tolerant computing hardware. Typically these systems are guaranteed to function up to 99.9999% of the time which equates to only 30 minutes of downtime/failure time per year. Such a highly fault tolerant computing system is also service reliable as it is nearly always available. Service reliability is a primary objective in designing such computing hardware.
Fault tolerant systems are very expensive and tend to lag behind the “technology innovation curve” by several years. For example, a fault tolerant system may only support on the order of megabytes of memory while a non-fault tolerant system may support on the order of gigabytes of memory. The fault tolerant system providers must transform commercially available hardware into reliability hardened hardware for fault tolerant systems which typically takes two to three years. This transformation process typically entails providing hardware component redundancy and sophisticated hardware failure detection. The underlying objective is to provide a system that rarely fails and is thus nearly always available.
In recent years non-fault tolerant computing systems have become very inexpensive and provide orders of magnitude greater performance in both memory capacities and processor speeds. While the performance of the computing systems have increased, the cost of such computing systems have decreased significantly such that a number of replicated non-fault tolerant computing systems is inexpensive compared to the corresponding fault tolerant computing system. Service reliability may be achieved utilizing less expensive but less reliable computing systems. Instead of utilizing expensive fault tolerant systems, service reliability can be achieved by utilizing redundant non-fault tolerant systems. The idea is to provide an appropriate number of fully replicated systems so that individual system failures do not negatively affect service reliability. Since these systems provide orders of magnitude more performance and capacity, the end result is higher performance and lower cost computing networks with service reliability that is as good as, and often better than, existing networks utilizing fault tolerant systems.
However, there are a number of factors that must be addressed so that a transaction is reliably processed in the midst of system failures. Transaction processing is typically divided into two distinct categories: executing the intent of the transaction and updating/reading the database; and, maintaining the transaction state data required to execute the transaction. There are well understood methods of reliably performing the first category of transaction processing and assuring that data already in a database is stored reliably, e.g., two-phase-commit protocols, redundant array of independent disks (RAID) and shared disk systems.
Transaction state data (TSD) is transient data associated with a single transaction. It is data that is maintained for the life of a transaction to assure that all the parts/messages of the transaction are executed correctly. There is a difference between the data corresponding to the records in a database, e.g., customer specific data, and TSD. Each record in a database includes data unique to that record while TSD is created by the computing system to assure that multiple messages for a particular transaction are correlated appropriately. TSD is also created to store intermediate data needed for subsequent message processing for the transaction.
Referring now to
FIG. 1
, a typical replicated database system
10
is illustrated. The replicated database system
10
comprises a querying system
20
and a logical database
30
. The querying system
20
is the system from which all transactions originate. The querying system
20
is configured to generate transactions accessing records in the logical database
30
in response to requests by one of a number of database users
60
accessing the database system
10
. For example, the querying system
20
could be part of an airline reservation system with users accessing and entering reservation data via terminals or a telecommunications switch that is sending transactions to a calling card database for card and personal identification number (PIN) validation. It is the system that requires reliable transaction processing and data storage.
The logical database
30
is the system to which the querying system
20
sends transaction messages for reliable processing and data storage. It is referred to as a logical database because it is actually comprised of multiple physical databases. In the illustrated system, the logical database
30
comprises two physical databases, an active database
40
and a standby database
50
. The logical database
30
also comprises a reliable transaction distributor
70
which receives transaction messages from the querying system
20
and transmits them to one of the databases
40
,
50
. The reliable transaction distributor
70
also receives response messages from one of the databases
40
,
50
and transmits them to the querying system
20
. It will be appreciated by those skilled in the art that the reliable transaction distributor
70
may be located within the querying system
20
. It will be further appreciated by those skilled in the art that the querying system
20
and the logical database
30
may each comprise a reliable transaction distributor. It will be even further appreciated by those skilled in the art that the reliable transaction distributor
70
is viewed logically as one system but could be comprised of a plurality of physical systems.
The exact number of physical databases within the logical database
30
is completely transparent to the querying system
20
. The reliable transaction distributor
70
is the only component that needs to keep track of the number of physical databases. The databases
40
,
50
are fully replicated with each database comprising an identical set of records. The active database
40
is the database that receives transaction messages from the reliable transaction distributor
70
during normal operations, i.e., absent any failures in the active database
40
. The backup database
50
is available for use whenever the active database
40
is experiencing problems.
A typical transaction is described below. Message
1
of the transaction is sent from the querying system
20
to the logical database
30
for processing (step 1). The reliable transaction database
70
receives message
1
and transmits it to the active database
40
for processing (step 2). The active database
40
retrieves data from an appropriate record in the database and creates internal TSD for subsequent message processing of the transaction. The active database
40
then creates and sends a response message based on the data retrieved from the database and message
1
to the reliable transaction distributor
70
(step 3) for transmission to the querying system
20
(step 4). The querying system
20
then monitors the transaction and transmits a termination message to the logical database
30
(step 5) at the conclusion of the transaction from the view of the querying system
20
. The reliable transa
Bogantz Robert L.
Green Gary Michael
Hester Sidney Dean
Homere Jean R.
Lucent Technologies - Inc.
Stevens & Showalter LLP
Wassum Luke S
LandOfFree
Transaction state data replication by transaction forwarding... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transaction state data replication by transaction forwarding..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transaction state data replication by transaction forwarding... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2949579