JP2008146118A - Method for update and recovery of database in computer system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method for quickly recovering data to a desired point of time in the event of a failure and for easily correcting data in the event that illegal data has been mixed in. <P>SOLUTION: A computer system not only achieves data recovery in the event of a failure by outputting a history of updates upon a data update, but also outputs the content of an update request from a business process as an update history, so that, particularly in a database that mainly performs update processes by adding or subtracting numerical values, such as an inventory database, data can be corrected more easily in the event of mixing of illegal data than if data patches are implemented directly on the database. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a method for updating and recovering a database in a computer system, and in particular, for a database mainly performing update processing by addition and subtraction of numerical values such as an inventory database, data correction and data correction when illegal data are mixed are facilitated. It relates to database update and recovery methods.

  In recent years, in computer systems, a technique for acquiring an update history in preparation for a database failure and preparing for data recovery in the event of a failure has been put into practical use.

  For example, as described in Japanese Patent Laid-Open No. 01-166232, at the time of database update, pre-update information and update date and time are accumulated as update history information, thereby realizing data recovery at a desired time.

Japanese Patent Laid-Open No. 01-166232

  In the conventional technique, when it is determined that illegal data is mixed, it is necessary to return data to a point before the illegal data mixing or to investigate the influence thereof and to execute data patch individually. Especially for databases such as the inventory database, where update processing is mainly performed by adding and subtracting numerical values, it is necessary to calculate a correct numerical value (for example, the current inventory quantity) from incorrect data and perform data batching. If illegal data is output, the operation becomes complicated.

  It is an object of the present invention to provide a method for performing quick data recovery to a desired time when a failure occurs and easily correcting data when illegal data is mixed.

  In order to achieve the above object, the present invention accepts an update request from each business process and updates the database, periodically saves data in the corresponding database, saves data in the event of a failure, A data recovery process for performing data recovery is provided.

  In the data update process, when there is an update request from each business process, the corresponding database is updated based on the update contents, and at the same time, an update history is output. At this time, the content to be output to the update history is not the record itself before or after the update of the corresponding database (for example, the current inventory quantity), but the update request content (for example, the inventory increment / decrement quantity) received from each business process. Output and store the update date and time.

In the data saving process, all records of the corresponding database are periodically saved.
In the data recovery process, when a failure occurs, the data saved in the data saving process is first recovered, and the difference between the time when the data is saved and the time when the recovery is desired is recovered from the update history. When incorrect data is mixed, the user can correct the update history before the data recovery process, thereby enabling recovery of the incorrect data simultaneously with the data recovery. At this time, since the update history conforms to the update request contents from the business process and is output in a form that is easy for the user to understand, it is easier to correct the data than to apply the data patch directly to the database. It becomes possible.

  As described above, according to the present invention, in a computer system, not only data recovery in the event of a failure is realized by outputting an update history at the time of data update, but also update request contents from business processing are updated. By outputting as a history, especially for databases that mainly perform update processing by adding and subtracting numerical values such as an inventory database, it is possible to correct data more easily than when data patching is performed directly on the database when incorrect data is mixed become.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 shows an embodiment in which the present invention is applied to update and recover a database. In FIG. 1, each business process 111 to 113, a data update process 120 that accepts a data update request from a business process, a data saving unit 130 that periodically saves data, and data recovery when a failure occurs or illegal data is mixed A data recovery process 140 to be performed operates on the CPU 100. In FIG. 1, there are three business processes 111 to 113, but these numbers naturally vary depending on the computer system. 150 is an update history file output by the data update process 120, 160 is a database to be updated and recovered, and 170 is a save database to which the target database is periodically saved by the data save process 140. Here, the target database 160 is assumed to be a database that mainly performs update processing by addition and subtraction of numerical values, such as an inventory database, and the data includes items, current quantities, and other information.

  First, the data update process will be described with reference to FIG. It is assumed that an update request 202 for increasing the inventory quantity of item B by 20 is passed from a certain business process 201 to the data update process 203. The data of the update request 202 delivered at this time is composed of an item, an added / subtracted quantity, and other information. In the data update process 203, update processing (increase the quantity by 20) is performed on the record of the corresponding item B in the target database based on the received update request 202, and a record obtained by adding the update date and time to the update request content 202 is updated history file Output to 204. That is, the update history data is composed of update date / time, item, adjustable quantity, and other information. By repeating the above process every time an update request is received from the business process, the update history is accumulated together with the target data update.

  Next, the data saving process will be described with reference to FIG. In the data saving process 302, a process of copying all the data in the target database 301 at a certain point to the saving database is periodically performed. Therefore, the data in the evacuation database 303 is composed of items, current quantities, and other information just like the target database 301.

  Finally, data recovery processing will be described. In the data recovery process, first the data saved by the data save process is recovered, and then the difference between the time when the data was saved and the time when the data is desired to be recovered is recovered from the update history output by the data update process. To do. There are two situations in which data recovery processing should be performed: a case where it is desired to recover data when a failure occurs and a case where it is desired to correct illegal data mixed in the past.

  In the case where it is desired to recover data when a failure occurs, this is a process of performing data recovery using the accumulated update history and saved data as they are, and there is no mixing of illegal data. Data recovery processing in this case will be described according to the flowchart of FIG. 4 and the example of FIG. First, the data recovery process 501 requests the user to input the specified recovery date. The specified recovery date / time is the time at which data in the target database 505 is to be recovered, and the user inputs the desired specified recovery date / time (step 401). Reference numeral 502 denotes an example of the screen at this time, and the user inputs the specified recovery date and time according to the instructions on the screen. Next, the data recovery process 501 recovers the data 503 saved by the data saving process to the target database 505 (step 402). At this time, the target database 505 is restored to the state at the time when the data saving process was last executed (save date and time). Next, the save date and time and the recovery specified date and time are compared, and the subsequent processing is branched depending on the result (step 403). If the specified recovery date / time is newer than the save date / time, the user specifies the target database 505 by processing records in the update history file 504 in the range from the save date / time to the specified recovery date / time (step 404). Can be recovered to the state of the specified recovery date and time. FIG. 5 shows this case. If the three updates from the update date / time T1 to T3 are the difference between the save date / time and the specified recovery date / time, the target database 505 is brought into the recovery specified date / time state by processing these three items. Can be recovered. On the other hand, if the specified recovery date is older than the save date, the target database 505 can be recovered to the recovery specified date and time by performing the same processing as step 404 in the order of time (step 405).

  When it is desired to correct invalid data mixed in the past, the target database can be recovered to a correct state by recovering the update history after the user corrects it. Normally, when incorrect data is mixed, a method of directly patching the database can be considered, but in the case of a database mainly performing update processing by adding and subtracting numerical values such as an inventory database, correct data (for example, The current batch quantity etc.) must be calculated and a data batch must be performed. Therefore, when a plurality of invalid data are output at one time, the work becomes complicated. In the present invention, since the update history conforms to the update request contents from the business process and is output in a form that is easy for the user to understand, the data can be corrected more easily than when the data patch is directly applied to the database. Is possible. Further, even when a failure occurs and a state in which illegal data is mixed, the target database can be restored to a correct state by this method. In this way, the data recovery process when illegal data is mixed will be described according to the flowchart of FIG. 6 and the example of FIG. First, the data recovery process 701 copies the update history file 702, and creates an uncorrected update history file 703 in a state before correction by the user (step 601). Next, the update history file 702 is opened in a form that can be corrected by the user, and the user is requested to correct it (step 602). On the screen, the user appropriately corrects the correction or deletion of the illegal data record (step 603). 704 is an example of the screen at this time, which is a case where the place where the addition / subtraction quantity of the record of the update date / time T2 should originally be 20 is updated as 50, and the user corrects it to 20 according to the instruction on the screen. As a result, a modified update history file 705 is created. Next, the data recovery process 701 detects the difference by comparing the update history file 703 before correction created in step 601 and the update history file 705 after correction created in step 603, and among the records in which the difference is detected, The update date of the record with the oldest update date is acquired as the correction start date (step 604). The data recovery process 701 prompts the user to input the specified recovery date and time, and the user inputs the desired recovery specified date and time. (Step 605). A screen example at this time is shown in 706. Next, the data recovery processing 701 recovers the data 707 saved by the data saving processing to the target database 708 (step 606). Next, the save date / time and the specified recovery date / time, and the save date / time and the correction start date / time are compared, and the subsequent processing is branched depending on the result (steps 607 and 608). When the recovery specified date and the correction start date and time are newer than the save date and time, records in the post-correction update history file whose update date ranges from the save date and time to the recovery specified date are processed in order (step 609). FIG. 7 shows this case. If three cases from the update date / time T1 to T3 are the difference between the save date / time and the specified recovery date / time, the update history by the user can be corrected by processing these three cases ( The target database 708 can be recovered to the state of the specified recovery date and time by reflecting the record at the update time T2. Conversely, if the specified recovery date or modification start date and time is older than the save date and time, the correction by the user may not be reflected even if the update history from the save date and time to the specified recovery date is processed in order. Therefore, once the records in the post-correction update history file whose update date is in the range from the save date to the correction start date and time are processed retroactively (step 610), the records in the range from the correction start date to the specified recovery date and time are processed. Are processed in order (step 611), the target database 708 can be recovered to the state of the specified recovery date and time by reflecting the correction of the update history by the user.

  Although the embodiment of the present invention has been described above, the present invention is particularly effective for a database that mainly performs update processing by addition and subtraction of numerical values such as an inventory database, but also for a database having other characteristics. Applicable.

1 is a system configuration block diagram illustrating an embodiment of the present invention. An example of data update processing. An example of data saving processing. The flowchart in case there is no illegal data mixing of a data recovery process. An example of data recovery processing when there is no illegal data mixing. The flowchart in case there exists illegal data of a data recovery process. An example of data recovery processing when there is illegal data mixing.

Explanation of symbols

  100 ... CPU, 111, 112, 113, 201 ... Business processing, 120, 203 ... Data update processing, 130,302 ... Data save processing, 140,501,701 ... Data recovery processing, 150,204,504,702 ... Update History file, 160, 205, 301, 505, 708 ... Update, database to be recovered, 170, 303, 503, 707 ... Saved database, 502, 706 ... Screen example when inputting recovery specified time, 703 ... Update history file before correction 704: Example of screen when update history is corrected, 705: Update history file after correction.

Claims (1)

Has a data update process that processes update requests from each business process, a data save process that periodically saves the data in the database, and a data recovery process that recovers when a failure occurs or illegal data is mixed,
At all times, the data update process receives a request for each business process and updates the database. At the same time, the update request contents from each business process are output as an update history, and the data save process saves the data in the corresponding database at an arbitrary timing. By doing so,
Database update and recovery, characterized in that the database is restored to the data at the time the user wants in the event of a failure, and the data is corrected at the same time as the data recovery by the user correcting the update history when unauthorized data is mixed the method of.

Images