JP4628830B2 - System for ensuring the integrity of data stored in DBMS - Google Patents

Description

  The present invention relates to a technique for ensuring data consistency among a plurality of tables stored in a DBMS in a system using a DBMS (Database Management System).

  In recent years, software source code has been released as open source free of charge through the Internet or the like so that anyone can use it freely. And if you use open source software, you can build application systems at low cost, so companies are gradually starting to use it.

  Some DBMS (Database Management System) has been released as open source. Some open source DBMSs do not have advanced features such as two-phase commitment. When such a DBMS is used, even when two-phase commitment is to be performed in order to ensure data consistency, it is not performed. In this case, data inconsistency occurs, and inconvenience occurs in an application system that uses this data.

  Therefore, an object of the present invention is to provide a technique for ensuring data consistency even when a DBMS having no two-phase commitment function is used.

  When a system connected to a DBMS (Database Management System) according to an embodiment of the present invention and ensuring the integrity of data stored in the DBMS receives a request from a request request source, identification information is included in the request. The update requesting unit for requesting the DBMS to update the data based on the request, and the update unit requesting the DBMS to perform a plurality of update processing based on the request. Update information acquisition means for acquiring update information about the contents of each update process associated with the identification information given to the DBMS, and based on the processing results of all update processes requested by the update means to the DBMS Request success / failure determination means for determining success / failure of the request; and request success / failure determination The determination result by the means and the update information acquired by the update information acquisition means are stored in association with the identification information given to the request, and the determination result by the request success / failure determination means is stored in the request request source. And outputting means.

  In a preferred embodiment, the update information is classified according to an update process requested by the update unit. When each update process is normally completed, update information related to the update process may be generated by the DBMS.

  In a preferred embodiment, the request success / failure determination unit determines that the request is successful when all the update processes requested by the update unit are normally completed, and one or more of the update processes requested by the update unit are normal. If it is not completed, it may be determined that the request is unsuccessful.

  In a preferred embodiment, the storage unit stores a determination result of a request to which certain identification information is given as unsuccessful request, and the one related to the identification information acquired by the update information acquisition unit. When the update information of a part is stored, a consistency determination unit that determines that inconsistency occurs between a plurality of tables stored in the DBMS may be further provided.

  A system for performing transaction processing using a DBMS that does not support two-phase commitment according to an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram showing a configuration of a transaction processing system 10 and its monitoring device 20 according to the present embodiment. The transaction processing system 10 includes an interface server 1 that performs data input / output with the outside, a business processing server 3 that performs predetermined business processing, and a DBMS 5. For example, the monitoring device 20 is connected to the interface server 1.

  In the present embodiment, when the DBMS 5 has an inventory master and the business processing server 3 performs product ordering, inventory management, etc., processing when the interface server 1 accepts a transaction requesting product ordering is performed. Let's take an example.

  Each of the interface server 1, the business processing server 3, the DBMS 5, and the monitoring device 20 is configured by, for example, a general-purpose computer system, and individual components or functions in the servers 1, 3, 5, and 20 described below Is realized, for example, by executing a computer program.

  The interface server 1 accepts a request from the request requesting device as a transaction, and returns a request success / failure indicating whether or not the request has been normally completed to the request requesting source. Further, the interface server 1 includes, as internal functions, a request ID assigning unit 11 that assigns an ID that is identification information to a request included in a received transaction, and a transaction journal 13 that records a transaction processing history.

  The request ID assigning unit 11 assigns a request ID unique within the transaction processing system 10 to a request relating to each transaction and sends the request to the business processing server 3.

  The transaction journal 13 stores information such as processing results for each request related to each transaction. For example, a reply to the request returned from the business processing server 3 is stored in the transaction journal 13.

  FIG. 2 shows an example of the data structure of the transaction journal 13. The transaction journal 13 includes, as data items, a request ID 21, a request success / failure 22, table update information 23 for the inventory master table, and table update information 24 for the transaction table. The request success / failure 22 and the table update information 23 and 24 will be described later.

  Referring to FIG. 1 again, the DBMS 5 stores various tables 51 and 53 each storing data, and table update information 55. The table update information 55 stores the update contents and the like when each table is updated (overwritten and inserted). The table update information 55 is for each table.

  The data structure of the table update information 55 is shown in FIG. The table update information 55 includes a table name 41, an overwrite / insertion type 42, an update main key 43, pre-update information 44, post-update information 45, and a request ID 46 as data items. In the table update information 55, when the update process of each table is completed, a record related to the update process is added. Therefore, even when the DBMS 5 receives a data update request from the business processing server 3, if the update does not end normally, a record related to the update process is not generated. As a result, the success or failure of each update process can be determined by referring to the table update information 55 using the request ID 46 as a key.

  In the example of FIG. 1, the DBMS 5 has an inventory master table 51 and a transaction table 53. The table update information 55 stores update information 551 of the inventory master table and update information 552 of the transaction table.

  The business processing server 3 includes a transaction control unit 31 that performs transaction control and a business processing unit 33 having a plurality of individual processes 331 and 332. Here, the individual processes include an inventory process 331 and an order process 332.

  The transaction control unit 31 receives the transaction notified from the interface server 1 and selects and executes the individual processing corresponding to the request included in the transaction from the business processing unit 33. Then, the transaction control unit 31 determines whether or not the processing for the request has been normally completed (request success / failure) according to the result of the individual processing of the business processing unit 33. Further, the table update information 55 is acquired from the DBMS 5 using the request ID as a key, and is returned to the interface server 1 as a reply to the transaction along with the success or failure of the request.

  Each individual process of the business processing unit 33 executes a predetermined business process. Further, each individual process requests the DBMS 5 to perform processing when referring to or updating each table in the DBMS 5. When requesting processing to the DBMS 5, the request ID is also notified.

  For example, when a transaction for a product order request is notified from the interface server 1, the transaction control unit 31 sequentially calls the inventory process 331 and the order process 332 to execute the respective processes. Here, as the inventory processing 331, inventory allocation, updating of the inventory master table 51, and the like are performed. The update of the inventory master table 51 requests the DBMS 5 for processing. As the order processing 332, for example, an order ID for product ordering is numbered, and the DBMS 5 is requested to store the order information in the transaction table 53.

  Next, transaction processing for ordering products will be described with reference to the flowchart of FIG.

  First, when the interface server 1 receives a transaction including a product order request, the request ID assigning unit 11 assigns a request ID to the transaction (S11). The transaction with the request ID is notified to the business processing server 3.

  In the business processing server 3, when the transaction control unit 31 receives a transaction, the individual processing 331 and 332 of the business processing unit 33 are sequentially executed according to the transaction (S12). In each individual process executed here, when updating the table in the DBMS 5, the DBMS 5 is requested to update the table (S13). The request ID given to the accepted transaction is attached to the update request for this table.

  In the present embodiment, the transaction control unit 31 first causes the inventory processing 331 to be executed for a product ordering transaction. In the inventory process 331, after executing the inventory allocation process, an update request for the inventory master table 51 is output to the DBMS 5.

  When the DBMS 5 receives a table update request, the table is updated accordingly (S14). Then, when the update of this table is successful, the DBMS 5 stores the table update information 55 (see FIG. 3) based on the update of this table (S15).

  In this embodiment, the DBMS 5 updates the inventory master table 51 and stores information related to the update in the table update information 551 of the inventory master.

  When the process in the DBMS 5 is completed, the transaction control unit 31 is notified of a processing result indicating whether or not the individual process has been normally completed, thereby ending the individual process (S16). The transaction control unit 31 determines whether there are other individual processes to be performed, and causes all the individual job processes to be executed according to the above steps S12 to S16 (S17).

  In the present embodiment, when the above-described inventory processing 331 ends, the transaction control unit 31 causes the order processing 332 to be executed subsequently thereto. That is, for the order process 332, the processes after step S12 are executed again. In the order process 332, the order ID is numbered and an update request for the transaction table 53 is output to the DBMS 5. The DBMS 5 updates the transaction table 53 and stores information related to the update in the table update information 552 of the transaction table. Then, these processing results are notified to the transaction control unit 31, and the processing is terminated.

  When all the individual processes are completed (S17: Yes), the transaction control unit 31 determines the success or failure of the request (S18). In other words, the transaction is successful if all of the individual processes processed based on this transaction are completed normally, and the transaction is unsuccessful (error) if any one of the individual processes is not completed normally. is there. The success / failure determination of the individual processing is performed based on the processing result notified from the DBMS 5. Further, the transaction control unit 31 acquires the table update information 55 from the DBMS 5, and returns a reply including the acquired table update information 55, the request success / failure, and the request ID to the interface server 1.

  In the present embodiment, the transaction control unit 31 sets the success / failure of the request when both the inventory processing 331 and the order processing 332 are normally completed, and requests either when both or both are not normally completed. The success or failure is defined as “error”. Further, the transaction control unit 31 acquires table update information 551 and 552 of the inventory master and transaction table, and returns a reply to the interface server 1.

  The interface server 1 stores the reply from the business processing server 3 in the transaction journal 13 (see FIG. 2), outputs the request success / failure as the transaction processing result, and ends the processing (S19).

  As a result, for each transaction (request ID 21), the transaction journal 13 includes a request success / failure 22 indicating whether or not all the processing of the request relating to the transaction has been successful, and table update information indicating individual processing contents for each table. 23 and 24 are stored. Therefore, by referring to the transaction journal 13, it can be confirmed whether or not data inconsistency has occurred. For example, the monitoring device 20 may acquire the storage contents of the transaction journal 13 and output it to a display device or the like so that the system administrator can confirm it. Consistency of the output contents and individual countermeasures can be confirmed by a transaction consistency check table described below.

  FIG. 5 shows a transaction consistency check table 100. This check table 100 indicates a response method to be taken by the system administrator depending on whether or not the table update information (stock master) 23 and the table update information (transaction) 24 have been registered for the request success / failure 22. Show. Here, the table update information 23 and 24 is generated only when the table update is normally completed. Therefore, when the table update information 23 and 24 is not registered, the table update is not normally completed. Means.

  For example, when the request success / failure 22 of item number 3 is “error” and the table update information 23 and 24 are both “unregistered”, and when the request success / failure 22 of item number 4 is “success”, the table update information 23 and 24 When both are “registered”, the data is consistent, and no special correspondence to the database is required.

  On the other hand, if the request success / failure 22 of item number 2 is “error” and the table update information 23 is “registered”, but the table update information 24 is “unregistered”, data inconsistency has occurred. Yes. In other words, in this case, after the stock master table 51 is updated normally, the transaction table 53 has failed to be updated, and therefore there is a mismatch. In this case, the system administrator searches the table update information 55 by the request ID and manually performs rollback.

  In the case of a DBMS that supports two-phase commitment, in the above case, the update process of the inventory master table 51 is rolled back to maintain consistency. However, in the DBMS that does not support the two-phase commitment as in this embodiment, the inventory master table 51 is not rolled back, and this needs to be detected.

  In addition, the system administrator may detect inconsistency and perform rollback manually as described above, but in addition to that, the monitoring device 20 automatically performs inconsistency determination, and the result is system management. The system administrator may be notified, or the system administrator may be notified of the result by automatically performing the rollback. Whether automatic or manual, inconsistency detection and rollback execution need not be synchronized with transaction processing.

  In the case of item numbers 1 to 5-7, it is considered that a system failure or a DBMS failure has occurred, and appropriate measures are required respectively.

  The above-described embodiments of the present invention are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to those embodiments. Those skilled in the art can implement the present invention in various other modes without departing from the gist of the present invention.

  For example, in the above-described embodiment, the case where data consistency between a plurality of tables in the same DBMS is secured has been described. However, consistency between different DBMSs can be secured in the same manner.

1 is a diagram showing a transaction processing system 10 and its monitoring device 20 according to an embodiment of the present invention. 3 is a diagram illustrating an example of a data structure of a transaction journal 13. FIG. It is a figure which shows an example of the data structure of table update information. It is a flowchart which shows a process sequence. It is a figure which shows an example of a transaction consistency check table.

Explanation of symbols

1 interface server 3 business processing server 5 DBMS
DESCRIPTION OF SYMBOLS 10 Transaction processing system 11 Request ID provision part 13 Transaction journal 20 Monitoring apparatus 31 Transaction control part 33 Business processing part 51 Inventory master table 53 Transaction table 55 Table update information

Claims (4)

A system connected to a DBMS (Database Management System) for ensuring the integrity of data stored in the DBMS,
Upon receiving a request from a request request source, means for giving identification information to the request;
Update means for requesting the DBMS to update data based on the request, including identification information given to the request;
When the update unit requests the DBMS to perform a plurality of update processes based on the request, update information related to the contents of each update process associated with the identification information given to the request is acquired from the DBMS Acquisition means;
Based on the notification of the processing results from the DBMS for the plurality of update processes requested by the DBMS by the update unit, when all the update processes requested by the update unit have been normally completed, the request is determined to be successful, A request success / failure determination means for determining that the request is unsuccessful when at least one of the update processes requested by the update means is not normally terminated ;
Storage means for storing the determination result by the request success / failure determination means and the update information acquired by the update information acquisition means in association with the identification information given to the request;
Means for outputting the determination result by the request success / failure determination means to the request request source;
Consistency determining means for determining whether or not inconsistency occurs between a plurality of tables stored in the DBMS based on the storage content of the storage means;
When the determination result of a request to which certain identification information is given is a request unsuccessful and when some of the update information related to the identification information is stored, it is determined as inconsistent
The consistency determination means for determining that there is no inconsistency when the update information related to the identification information is not stored even if the determination result of the request to which certain identification information is given is a request unsuccessful; ,
And a means for notifying that the inconsistency is detected when it is determined by the consistency determining means that the inconsistency has occurred . The update information acquired by the update information acquisition means is classified by the update process requested by the update means,
The system according to claim 1, wherein when each update process ends normally, update information related to the update process is generated by the DBMS. A system using a DBMS (Database Management System) is a method for ensuring data consistency among a plurality of tables stored in the DBMS,
When receiving a request from the request request source, giving identification information to the request;
Requesting the DBMS to perform a plurality of update processes based on the request;
Obtaining update information about the contents of each update process associated with the identification information given to the request from the DBMS;
Based on the notification of the processing results from the DBMS for all the requested update processes, when all the requested update processes are normally completed, it is determined that the request is successful, and any one or more of the requested update processes. A step that determines that the request is unsuccessful when is not successful ,
Storing the determination result of success or failure of the request and the acquired update information in a storage unit in association with the identification information given to the request;
Outputting a determination result of success or failure of the request to the request request source;
When the determination result of a request to which certain identification information is given is stored in the storage means as a request unsuccessful and a part of the update information related to the identification information is stored, the DBMS Even if it is determined that there is a mismatch between the plurality of tables stored in the table, and the determination result of the request to which certain identification information is assigned is a request unsuccessful, the update information related to the identification information is stored. Determining that it is not inconsistent when not done,
And a step of notifying that the inconsistency is detected when it is determined by the determination that an inconsistency has occurred . A computer program for ensuring the integrity of data stored in a DBMS (Database Management System),
When executed on a computer,
When receiving a request from the request request source, giving identification information to the request;
Requesting the DBMS to perform a plurality of update processes based on the request;
Obtaining update information about the contents of each update process associated with the identification information given to the request from the DBMS;
Based on the notification of the processing results from the DBMS for all the requested update processes, when all the requested update processes are normally completed, it is determined that the request is successful, and any one or more of the requested update processes. A step that determines that the request is unsuccessful when is not successful ,
Storing the determination result of success or failure of the request and the acquired update information in a storage unit in association with the identification information given to the request;
Outputting a determination result of success or failure of the request to the request request source;
When the determination result of a request to which certain identification information is given is stored in the storage means as a request unsuccessful and a part of the update information related to the identification information is stored, the DBMS Even if it is determined that there is a mismatch between the plurality of tables stored in the table, and the determination result of the request to which certain identification information is assigned is a request unsuccessful, the update information related to the identification information is stored. Determining that it is not inconsistent when not done,
And a step of notifying that the inconsistency is detected when it is determined by the determination that an inconsistency has occurred .

Images