Highly reliable online system - Patent Review 5596706

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

The present invention relates to a highly reliable online system for a computer system having a database.

Conventionally, the following methods have been taken for improving the reliability of online systems. FIG. 38 is a diagram for explaining such methods.

A computer center 11 is provided with duplicate external storage units 13, 14 for storing database records 15, 16 and updating the same in an on-line fashion. The databse records 15, 16 are updated, when necessary, simultaneously from a central processing unit 12 (1). Thus, even if one of the external storage units 13 or 14 is unusable due to a failure, a duplicate storage of the identical database in different external storage units permits utilizing the database records stored in the other external storage unit.

Also, a backup of a database (DB) is stored in an external storage unit 17 which is not connected to the online system (2), and the storage unit 17 is preserved in the same computer center 11 to which the online system is connected or in another warehouse or a computer center 18 so as to allow the database to be recovered in case the external storage units 13, 14, or even with the external storage unit 17 included, are simultaneously unusable.

This type of art is disclosed, for example, in Japanese Patent Laid-open JP-A-61-196347 (1986) and so on.

The above-mentioned prior art implies the following problems in the online system which requires a high reliability, as will be hereblow explained with reference to FIG. 39:

(1) If the computer center 11 suffers from a disaster (A), terminals 24a, 24b, 24c, 24d become all inoperable. The recovery of the database is also impossible due to such a disaster.

(2) If a wide area 21 including the computer center 11 (an area including a plurality of adjacent prefectures, cities, towns or villages) suffers from a disaster (B), not only the terminals 24a, 24b included in the computer center 11 but also the terminals 24c, 24d included in a wide area 25, which was not hit by the disaster, becomes unusable for online operations. The recovery of the database is not possible due to this type of disaster.

(3) If a disaster occurs in a transmission line 26b connecting a computer 23 and the terminals 24c, 24d for operating the computer between the wide area 21 including the computer center 11 and another wide area 25 (C), the terminals 24a, 24b included in the wide area 21 can be used for online operations, whereas the terminals 24c, 24d in the wide area 25 cannot be used.

(4) When the computer center needs a construction work on a large scale for maintaining the reliability of hardware, attending to the operating performance or the like, it is necessary to temporarily interrupt the online service.

SUMMARY OF THE INVENTION

It is an object of the present invention to construct an on-line system which is capable of solving the above-mentioned problems.

The above object can be achieved by a highly reliable online system comprising an original computer center for updating records relative to an original database on the basis of transactions inputted from terminals and delivering information on the update performed for this database and a backup computer center for updating records relative to a backup database on the basis of this received update information. More specifically, the object can be achieved by a system which operates in the following manner (see FIG. 1).

(1) A backup computer center 32b is provided, as a computer center in addition to the original computer center 32a, wherein each of the centers are provided with computers 33a, 33b, and databases 34a, 34b, respectively. Normally, terminals in the original computer center 38a, 38b, 38c, 38d are connected to the computer 33a in the original computer center 32a through an original transmission path 36a to utilize the original database 34a. When contents of the original database 34a is updated, update information is reflected to the backup database 34b through a database transmission path 35, whereby contents of the backup database 34b follows the contents of the original database 34a in real time or with a delay of a predetermined time period (this is referred to as "quasi-real time").

When the original computer center suffers from a disaster, the transmission path for connecting the terminals to the computer is changed over from the original transmission path 36a to a backup transmission path 36b by way of switches 37a, 37b (1, 2), to thereby permit the utilization of the backup database 34b from the terminals. It should be noted that the damaged original database 34a can be recovered on the basis of the backup database 34b.

(2) A wide area 31a including the original computer center is spaced apart from a wide area 31b including the backup computer center by such a distance as to prevent both wide areas from being damaged by a single cause such as an earthquake.

When a disaster occurs in the wide area 31a including the original computer center, the transmission path which connects the computer with the terminals 38b, 38d is changed over by the switch 37b (2) to thereby permit utilizing the database in areas outside the disaster-stricken area.

(3) The database transmission path 35, the original transmission path 36a and the backup transmission path 36b all include portions which interconnect wide areas (these portions are referred to as "an inter-area main line group"). If a disaster causes a stoppage of all the inter-area main line group 39, the transmission path for connecting the terminals 38b, 38d to the computer is changed over to the backup transmission path by means of the switch 37b (2) to thereby permit utilizing the database with terminals in the wide areas where the respective computers are located.

(4) If the original computer center needs a large scale construction work, the terminal connection is changed intentionally in a manner similar to the foregoing (1) to allow the construction of the original computer center without interrupting the online service thereof.

It is another object of the present invention to provide an online system which is capable of synchronizing contents of an original database (a main database) with those of a backup database (a sub-database) when an original computer center (a main online system) is changed over to a backup computer center (a sub-computer center).

The above object is achieved by providing the terminal side with functions for transmitting a transaction sequence number and transaction data to the main online system as well as storing the same, wherein the main online system is adapted to transmit update information thereof and transaction sequence numbers for the respective terminals to the sub-online system. When the main on-line system is changed over to the sub-online system, the terminal receives the transaction sequence numbers from the sub-online system, compares the same with transaction sequence numbers possessed by itself and retransmits a number of transactions, the number being equal to the difference between the received transaction sequence number and the transaction sequence number stored in the terminal.

It is a further object of the present invention to provide an online system which is capable of facilitating the recovery of the main database or the sub-database which suffers from a disaster.

The above object is achieved by recovering the damaged original database on the basis of the backup database and recovering the damaged backup database on the basis of the original data base.

It is a yet further object of the present invention to provide an online system which is capable of facilitating the integration of the main database and the sub-database after updating the both respectively with different contents in parallel.

The above object is achieved by providing each database record with a main database update sequence number and a sub-database update sequence number, transmitting database update information and the above-mentioned database update sequence numbers from the sub-database side to the main database side and matching both database update sequence numbers, to thereby discriminate records which have been parallelly updated in both the main database and sub-database and records which have been individually updated only in the sub-database, wherein the individually updated records are reflected to the main database by transmitting database update information relative thereto, and parallelly updated records are reprocessed by inputted transaction data while observing the order of updating the records, to thereby integrate both databases.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a systematic structural diagram showing the concept of a highly reliable online system;

FIG. 2 is a block diagram showing an embodiment of a highly reliable online system;

FIG. 3 is a block diagram showing a modification in structure which is made when the computer center suffers from a disaster;

FIG. 4 is a block diagram showing a modification in structure which is made when a disaster occurs in a transmission path connecting wide areas;

FIG. 5 is a diagram used for explaining a method of changing over cables of a multiplex transmission apparatus;

FIG. 6 is a diagram used for explaining how a path change performed in a packet exchanger;

FIG. 7 is a functional block diagram showing a processing method for reflecting main master database (DB) update information to a sub-master database (DB);

FIG. 8 is a flowchart showing a procedure of a sub-master-DB reflecting program;

FIG. 9 is a diagram showing specific examples of the order of updating the sub-master-DB;

FIG. 10 is a diagram showing an example of a multiplex transmission of database update information and a parallel update performed based on the update information on the sub-system side;

FIG. 11 is a diagram showing an exmaple of a format of transmission data which is transmitted from the main online system to the sub-online system;

FIG. 12 is a diagram used for explaining a flow of database records and transmission records and a scope of physical addresses processed by programs in respective stages;

FIG. 13 is a diagram used for expalining an exmaple wherein the main online system and the sub-online system individually arrange databases in different lay-out;

FIG. 14 is a diagram used for explaining an example wherein the main online system and the sub-online system individually organize different databases;

FIG. 15 is a diagram used for explaining the system size of the original computer center and the backup computer center;

FIG. 16 is a diagram showing a condition in which a discrepancy is produced in contents between the main database and sub-database;

FIG. 17 is a diagram showing a condition in which the main and sub-databases are out of synchronism;

FIG. 18 is a systematic structural diagram showing the concept of another embodiment of the present invention;

FIG. 19 is a structural diagram showing the other embodiment in detail;

FIG. 20 is a flowchart showing a processing flow on the terminal side;

FIG. 21 is a diagram showing a data format of synchronization acknowledge information;

FIG. 22 is a conceptional block diagram showing a system having a backup database;

FIG. 23 is a conceptional block diagram showing a recovery method which is utilized when the original database is impeded by a failure;

FIG. 24 is a conceptional block diagram showing a recovery method which is utilized when the backup database is impeded by a failure;

FIG. 25 is a systematic structural diagram showing a further embodiment of the present invention;

FIG. 26 is a diagram showing data formats for a database record and database update information in the embodiments;

FIG. 27 is a diagram showing a recovery procedure, executed in the embodiments, when the main master database suffers from a disaster;

FIG. 28 is a diagram showing a recovery procedure, executed in the embodiments, when the sub-master database suffers from a disaster;

FIG. 29 is a graph used for comparing time periods required to recover the database between the prior art and the present invention;

FIG. 30 is a flowchart showing a procedure of reflecting database update information to the database;

FIGS. 31(a) to 31(f) are diagrams showing database record formats;

FIG. 32 is a diagram showing a format of database update information with additional information;

FIG. 33 is a state transition diagram of the database records showing a case where the sub-database records have been solely updated;

FIG. 34 is a state transition diagram of the database records showing a case where a record in the main database is updated prior to an update of a record in the sub-database;

FIG. 35 is a state transition diagram of the database records showing a case where a record in the main database is updated after a record in the sub-database has been updated;

FIG. 36 is a block diagram showing an embodiment for practicing the present invention in a bank online system;

FIG. 37 is a block diagram showing an embodiment for implementing the present invention in a distributed system;

FIG. 38 is a block diagram showing a prior art system; and

FIG. 39 is a block diagram showing problems implied in the prior art system .

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the present invention will hereinafter be explained with reference to the accompanying drawings.

(1) System Structure

FIG. 2 shows an outline of a system according to the present invention and a normal connecting configuration thereof. A terminal 38a in an original computer center 32a (also referred to as "the main online system") is connected to two special paths 49f, 49h, wherein a half of transaction data inputted from the terminal 38a is delivered to a central processing unit 43a through the special path 49f (1), a packet exchanger 47a and a communication control unit 45c (5). In a similar manner, the remaining half of the transaction data passes through the special path 49h (2), a packet exchanger 47c, a multiplex transmission unit 45e, a high speed cable 49d, a multiplex transmission unit 46c and the communication control unit 45c (3, 4, 5). A similar processing is performed with respect to a terminal 38c. On the other hand, a half of transaction data inputted from a terminal 38b in a backup computer center 32b (a sub-online system) passes through a special path 49g, a packet exchanger 47b, a multiplex transmission unit 46d, a high speed cable 49b, the multiplex transmission unit 46c, while the remaining half of the data passes through a special path 49i, the packet exchanger 47d, a multiplex transmission unit 46f, a high speed cable 49d, a multiplex transmission unit 46e, a high speed cable 49d, the multiplex transmission unit 46c and the communication control unit 45c in a similar manner. With the terminal 38d, a similar data transmission is performed. The central processing unit 43a processes transaction data, which leads to updating a main master-DB 44a corresponding to an original database 34a (10). Updated data in the main master-DB 44a is transmitted from the central processing unit 43a to a central processing unit 43b in the backup computer center 32b through the communication control unit 45a, the multiplex transmission unit 46a, the high speed cable 49a, the multiplex transmission unit 46b and the communication control unit 45b. Such a database update processing performed by the central processing unit 43b causes updating a sub-master-DB 44b corresponding to a backup database 34b which thereby follows the main master-DB 44a. Incidentally, the database transmission path 35 in FIG. 1 is developed as the high speed cables 49a, 49b in FIG. 2. Therefore, the high speed cables 49a, 49b, 49c constitute the inter-area main line group 35. Further, the special paths 49f and the high speed cable 49d is developed in FIG. 2 in place of the original transmission path 36a in FIG. 1.

FIG. 3 shows a connection configuration of two wide areas modified after a disaster has been occurred in the original computer center 32a.

Transaction data from the terminal 38a is delivered to the central processing unit 43b disposed in the sub-online system through the packet exchanger 47c and the multiplex transmission unit 46e both disposed in a relay center 42c (1), the high speed cable 49c (2), the multiplex transmission unit 46f, the high speed cable 49e, the multiplex transmission unit 46d and the communication control unit 45d (3, 4, 5). A transaction data processing performed by the sub-online system causes the sub-master-DB 44b to be updated (6). Transaction data from the terminal 38b is also processed by the sub-online system in a similar manner, which leads to updating the sub-master-DB 44b.

If the original computer center 32a suffers from a disaster, connection cable definitions in the multiplex transmission units 46e, 46f, 46d are modified. FIG. 5 shows a method of modifying the connection cable definition in the multiplex transmission unit 46e, wherein reference numerals 71, 72, 73 designate addresses of cables to be connected, respectively. In the multiplex transmission unit 46e, a table entitled "Corresponding Table in Unit" indicating addresses corresponding to cables to be relayed is set as shown on the left side in FIG. 5. Reference numerals 73a, 73b indicate the same address 73 only to distinguish one from another on the table. This table is modified as shown in a table on the right side of FIG. 5 on the instructions from the backup computer center 32b. Stated another way, the table on the left side is replaced by the table on the right side which is reloaded from a floppy disk drive connected to the multiplex transmission unit 46e. Tables in the multiplex transmission units 46f, 46d may be also modified in a similar manner.

FIG. 6 shows a method of changing a cable connection in the packet exchanger 47b, wherein reference numerals 81, 82, 83 designate addresses of cables to be connected in the packet exchanger 47b. The packet exchanger 47b has a table entitled "Table Definition" as shown on the left side of the second row in FIG. 6. This table is not modified even when the cable connection is changed. However, instead of modifying the table, a header of a message transmitted from the terminal 38b is modified from "1" indicative of normality to "2" indicative of abnormality, whereby the packet exchanger 47b identifies the modified header and modifies the cable connection by referring to the table. The modification in the header is instructed from the backup computer center 32b to the terminal 38b when an abnormality occurs.

A cable change-over operation and a data flow when the wide area 31a including the original computer center suffers from a disaster are similar to those as shown in FIG. 3. However, the terminal 38a and the relay center 42c do not exist.

Next, FIG. 4 shows a cable change-over operation and a flow of transaction data when the high speed digital cable which connects the main online system and the sub-online system suffers from a disaster.

The main online system does not need a modification in the cable connection, so that transaction data from the terminal 38a reaches the main online system in a manner similar to FIG. 2 to update the main master-DB 44a (1, 5). On the other hand, in the sub-online system, there are a modification of the cable connection definition in the multiplex transmission units 46d, 46f and a modification of the cable connection in the packet exchanger 47b due to a change in the header of the message which is transmitted between the central processing unit 43b and the terminal 38b. These modifications on the sub-online system side are similar to those in the case shown in FIG. 3.

If either of the centers requires a construction, the configuration shown in FIG. 2 is intentionally changed over to that shown in FIG. 3 to permit such a construction. A construction in the sub-online system is also possible in a similar manner.

Next, a processing for reflecting main master-DB update information in a normal operation to the sub-master-DB will be explained in detail with reference to FIG. 7.

Assume, for example, that the main online system is performing a bank accounting application. A transaction message inputted from a terminal 38 is analyzed by an application program 94a provided in the main online system 32a (1), and the main master-DB 44a is updated (2). In this event, DB (database) update information 95a is generated for updating the main master-DB. For reflecting the update information 95a of the main master-DB 44a to the sub-master-DB 44b, the DB update information 95a is queued in a transmission queue by means of a transmission processing program 98a (3) and read again for transmission to the sub-online system 32b (4).

The sub-online system 32b receives the DB update information 95a by means of a reception program 98b and writes the same in a reception queue 97b (5). Then, the information 95a is again read from the reception queue 97b by means of a read-out program 98c, and a DB reflection processing program 94b is started to which the DB update information is delivered (6).

The DB reflection processing program 94b reflects the DB update information to the sub-online system in accordance with the DB update information without accompanying any operation performed by the operator (7).

The main master-DB 44a and the sub-master-DB 44b have update sequence numbers 99a, 99b respectively for each record to record historical data on update processing (the record is a unit of information composed of a set of items). The update sequence number begins with "1" and is incremented by one every time the record is updated. In the example shown in FIG. 7, a record in the main master-DB 44a is shown to be updated from AAAA to BBBB, and the corresponding record in the sub-master-DB 44b is immediately before being updated from AAAA to BBBB.

If a counterpart center is inoperable due to a construction or the like, transmission (4) from the transmission queue 97a shown in FIG. 7 is impossible, whereby an overflow is caused in the transmission queue 97a. To cope with this overflow, a system mode storing area 92 is provided in a main storage, and also the DB update information 95a is outputted to an external recording medium as a journal 91 (8). The system mode storing area 92 includes a bit indicative of "normal 92a" and another bit indicative of "one system 92b". The normal 92a bit is set when the main online system and the sub-online system are both operable while the one system 92b bit is set when either of them is inoperable. In addition to the update sequence number 99a and the DB update information 95a, the above-mentioned system mode is written into the journal 91 in correspondence to respective DB update information 95.

The DB update information 95a is stored in the transmission queue 97a as well as usually outputted as the journal 91 (8). When both systems are operable, the system mode in which the normal 92a bit is set is written into the journal 91. If a counterpart system is inoperable due to a construction or the like, the normal 92a bit is reset while the one system 92b bit is set, so that the transmission processing program 98a does not write the DB update information 95a into the transmission queue 97a. At this time, the system mode in which the one system bit is set is written into the journal 91. When the counterpart center resumes its operation, for example, by the termination of a construction, the journal 91 is read, and the DB update information 95a having the system mode set at one system, included in the journal 91, is solely transmitted to the counterpart center through the transmission queue 97a (9, 4).

Also, if the storage unit for storing the transmission queue 97a suffers from a disaster, the DB update information 95a cannot be transmitted from the main online system to the sub-online system. Also on this occasion, when the storage unit is recovered from the disaster, the DB update information 95a, which has not been transmitted to the counterpart center due to the disaster, is solely extracted from the journal 91 and transmitted to the counterpart center through the transmission queue 97a (9, 4). To facilitate such a recovery from a disaster, the journal 91 includes information necessary to treat the respective DB update information 95a, however, a detailed explanation thereof will be omitted.

FIG. 8 is a flowchart showing the procedure of the DB reflection processing program 94b in detail. After the reception processing program 98b has received data (step 101), the DB reflection processing program 94b determines whether or not the received data is a database update record (step 102). If the data is a database update record, the concerned record is read from the sub-master-DB 44b (step 103), and then a database update sequence number (N, 99a) included in the received record is compared with a value produced by incrementing by one a database update sequence number (M, 99b) included in the concerned record in the sub-master-DB (step 104). If N=M+1 is satisfied as a result of the comparison, the concerned record in the sub-master-DB is updated by the received record (step 105). If N>M+1 stands, the received record is temporarily preserved in an accumulating area (step 106). If a record which satisfies N=M+1 has already been preserved in the accumulating area or if the answer to step 107 is YES, the concerned record in the sub-master DB is updated by this record (step 108). This processing is repeated in this manner until records having sequential sequence numbers preserved in the accumulating area are exhausted. If N<M+1 stands at step 104, it means that the update record has been twice received, so that the received information is deleted (step 109). When information announcing that transmission of update records has been terminated is received from the main-online system or if the answer to step 102 is NO, concerned records in the sub-master-DB are updated until records having sequential sequence numbers and satisfying N=M+1, which have been previously preserved in the accumulating area, are exhausted (steps 110, 111).

FIG. 9 shows an example of updating a record in accordance with the processing flow shown in FIG. 8. In 1, a received record having a skipped sequence number has been received and therefore is preserved in the accumulating area. In 2, a record having a sequential sequence number has been received so that the corresponding record in the sub-master-DB 44b is updated by the received record. In 3, a received record is temporarily preserved in the accumulating area, however, since the received record has a sequence number which is sequential to a sequence number possessed by the record previously stored in the accumulating area, the newly received record is reflected to the sub-master-DB 44b, subsequent to the previously stored record. As described above, the update order in record units can be ensured by means of the sub-online system.

Since the update order in record units is ensured by the sub-online system as described above, it is possible to transmit DB update information on the main online system side to the sub-system side in a multiplex manner. More specifically, a multiplex transmission of DB update information can be performed by physically providing a plurality of cables and logically setting a plurality of logical channels to these cables.

FIG. 10 shows an example of a multiplex transmission of the DB update information and a parallel update performed on records in the sub-online system with update information.

FIG. 11 shows an example of a format of data transmitted from the main online system to the sub-online system. In the drawing, a destination address 121 is an address in the sub-online system from a view-point of the main online system, and an inter-system transmission processing sequence number 122 is added to provide the order to each cable since transmission processing is multiplexed by the cables or the like. An update information management unit 123 manages respective update information particularly when a plurality of update information 124a, 124b, 124c are transmitted in a block form. The respective update information is composed of an update sequence number 99a and update data 95a.

FIG. 12 shows a flow of database records and transmitted records in the original computer center 32a and the backup computer center 32b and a scope of physical addresses processed by programs in respective layers. Reference numerals 94a, 94b designate application programs, 145a, 145b the scope of online control programs, and 146a, 146b the scope of operating system (OS). Also, reference numeral 141 designates an absolute address in a disk in which a concerned record is stored, 147 designates logical management information for identifying the database record, 143 an absolute address of the cable 49 assigned for data transmission, and 144 a relative address of the cable 49. The OS 146 needs to be aware of the absolute address 141 in the disk in which the database records are stored, the relative address 142 of the same and the absolute address 143 and the relative address 144 of the cable 49. However, the online control program 145 only needs to be aware of the relative address 142 in the disk and the relative address 144 of the cable 49. The application program 94 need not be aware of any of these addresses. For this reason, DB update records delivered from the application program 94 through the cable 49 to the application program 94b does not have these physical addresses. A conclusion obtained from the above-mentioned consideration lies in that the main master-DB 44a and the sub-master-DB 44b can be laid out as databases (group) respectively independent of each other.

FIG. 13 shows an example where the main master-DB 44a and the sub-master-DB 44b are independently assigned in physical recording media. Reference numeral 151 designates a recording medium having a small capacity and 152 a recording medium having a large capacity. Reference characters A, B, C, D designate databases constituting a database group. First, the databases A, B, C, D are stored in media 151-1, 151-2, 151-3 and 151-4, respectively. Next, the capacities of the databases A, C are enlarged so that a medium 151-5 is added to the main master-DB 44a and a database storing lay-out is modified as shown in FIG. 13. The sub-master-DB 44b, on the other hand, introduces large capacity media 152-1, 152-2 to modify the database storing lay-out. This example shows that the system has a highly extensible database.

FIG. 14 shows an example where dispersed vacant areas are produced as a result of deletion and/or additon of records performed to the databases stored in the media 151-1 and 151-3. Hatched portions indicate record regions in use while blank portions indicate vacant record regions. In the example shown in FIG. 14, the database in the main master-DB 44a is rearranged to remove the vacant areas, however, the sub-master-DB 44b remains unchanged. This example shows a system having a high working efficiency of the database.

Finally, reference is made to the fact that the backup computer center 32b according to the present embodiment is a smaller online system than the original computer center 32a and accordingly can be built at a low cost.

FIG. 15 is a diagram used for schematically explaining the above-mentioned advantage. FIG. 15(1) shows that the backup computer center is supplied with the same transaction as that inputted to the original computer center and the same application processing as that performed by the original computer center is carried out in the backup computer center, wherein the system size of the backup computer center is the same as that of the original computer center. In FIG. 15(2), the backup computer center does not perform a variety of determinations based on inputted transaction information or transmission of processing results to the terminal. Instead, a special program for performing database update processing and reception processing of DB update