JPH03266045A - Data base system - Google Patents

Abstract

PURPOSE:To correctly restore a data base to its original state even if a system fault is generated at the time when an additional processor is updating the data base by providing an auxiliary journal file separately from a journal file. CONSTITUTION:In the case data base updating by an addition processor 21 for executing data base updating requested from a process 13 on a main storage 12 instead of a CPU 11 is executed, its journal is stored in an auxiliary journal file 22, and in a journal file 17, an auxiliary journal file descriptor 18 is stored in a page secured by the CPU 11. Accordingly, even if journaling by the CPU 11 is executed in the course of journaling of the processor 21, the sequence of a journal (or a descriptor) on the journal file 17 is held correctly, and the breakdown is avoided. In such a way, even if a system fault is generated in the course of data base updating of the additional processor 21, the data base is restored correctly to its original state.

Description

[Detailed Description of the Invention] [Object of the Invention] (Industrial Field of Application) The present invention relates to a database system that handles databases, and in particular, the invention relates to a database system that handles databases, and in particular, to update the database by a database processor attached to a host CPU. Regarding journaling methods.

(Prior Art) Conventionally, a database system is generally configured as shown in FIG. In FIG. 4, 41 is a CPU that forms the core of the system.

When the CPU 41 receives a request to update the database file 44 from one of the processes residing on the main memory 42 (here, the process 43) via the system bus 46, the CPU 41 updates the file 44. As a result, some of the many pages (which are data storage units) constituting the database file 44, for example, page 45i.
, 45j, and 45k are updated sequentially. This cavity, CP
U41 has pages 45i and 45j.

Journal data 481°4sj to journal file 47 the image before update to 45 (before image)
, 48 in order. This operation is called journaling. If a system failure such as a system down occurs at this point, the CPU 4L transfers the journal data 481° 48j, 48k in the journal file 47 to pages 45i, 45j, 45k of the database file 44 when restarting the system. make a copy. As a result, the logically corrupted database file 44 that was being updated at the request of the process 43
can be recovered to the correct state.

In the system shown in FIG. 4 described above, since the CPU 41 performs database update processing, a large load is placed on the CPU 41. Therefore, in order to reduce the load on the CPU 41, the fifth
As shown in the figure, C
Additional processor (database processor) 51 that updates the database file 44 in place of the PU 41
It is conceivable to provide a In order to update the database by the additional processor 51, the journaling described above must be performed in place of the CPU 41. On the other hand, since there are process groups in the system that do not use the additional processor 51, journaling by the CPU 41 is also required. Therefore, in the system shown in Figure 5,
A case may occur in which the CPU 41 and the additional processor 51 perform journaling in parallel. In this case, if a system failure occurs while the database of the additional processor 51 is being updated, the journal data will be destroyed, and recovery will not be possible. In order to prevent the journal data from being destroyed, for example, the CPU 41 may wait for the additional processor 51 to complete the database update process, but this would make high-speed processing difficult.

(Problems to be Solved by the Invention) As described above, in the conventional database system in which a dedicated database processor (additional processor) is added to speed up database update processing, the CPU (
A state may occur in which the host CPU (host CPU) and database processor perform journaling in parallel, but if this state occurs, the journal data will be destroyed, and if a system failure occurs while the database processor is updating the database, the database processor will not be able to update the database. There was a problem that it was impossible to restore to the original state.

This invention was made in view of the above circumstances, and its purpose is to provide a database system in which a database processor provided separately from the CPU can correctly restore the database to its original state even if a system failure occurs while updating the database. It is about providing.

[Structure of the Invention] (Means for Solving the Problems) This invention provides at least one database processor (
In a database system where an attached processor) is provided separately from the CPU (host CPU), an auxiliary journal file is provided separately from the journal file, and free pages are secured in the journal file in response to database update requests from processes. An update request means in the CPU that passes page position information and an update request to one of the database processors to request an update, and a database update process that performs a database update process in response to an update request from this update request means and is involved in the update. an update processing means within a database processor that outputs a journal to an auxiliary journal file and sets a descriptor for identifying the output journal on the auxiliary journal file in a free page on the journal file secured by the update request means; When restarting the system after a system failure occurs, the CPU sequentially inputs journaled pages from the above journal file, and if the input page is a descriptor, the journal specified by the descriptor is transferred to the above auxiliary journal file. The feature is that database recovery is performed by inputting data from

(Operation) According to the above configuration, when the database processor updates the database, the journal is stored in the auxiliary journal file instead of the journal file, and the journal file contains the journal descriptor (auxiliary journal file descriptor) is stored in a page secured by the update request means in the CPU. Therefore, even if journaling is performed by the CPU or another database processor while one database processor is journaling,
The order of journals (or descriptors) on the journal file is maintained correctly and cannot be corrupted.

(Embodiment) FIG. 1 is a block diagram of a database system according to an embodiment of the present invention. In the figure, 11 is a CPU (host CPU) that forms the core of the system, 12 is a main memory, and 13 is a process residing on the main memory 12.

Note that other processes are omitted. 14 is a database file composed of many pages;
15i, 15j, 15 are update pages on the database file 14, and 16 is a system bus. In addition to the CPU II, main memory 12, and database file 14, a journal file 17, an additional processor 21, and an auxiliary journal file 22, which will be described later, are connected to the system bus 16. ! 7 is a journal file in which journaling is performed by CPUII, 18
is an auxiliary journal file descriptor set in a page secured on the journal file 17.

This descriptor 18 has a pointer to the journal data string on the auxiliary journal file 22 created by the additional processor 21 and the number of data (number of pages). 21 is an additional processor (database processor) that executes a database update requested by a process on the main memory 12 on behalf of the CPU II; 22 is an auxiliary journal file on which journaling is performed by the additional processor 21;
231.233.23 is journal data (before image journal).

FIG. 2 is a flowchart for explaining the operation at the time of database update in the system of FIG. 1, and FIG. 3 is a flowchart for explaining the same operation at the time of database recovery.

Next, the operation of one embodiment of the present invention will be explained with reference to FIGS. 1 to 3. A process 13 residing on the main memory 12 sends a database file 14 to the CPU II.
When an update is requested (step S2 in Figure 2), the CPU
II first reserves one free page on the journal file 17 for setting an auxiliary journal file descriptor (step S2 in FIG. 2). Next, the CPU II passes the update request from the process 13 and the address of the secured free page to the additional processor 21, and issues an update request to the processor 21 (step S3 in FIG. 2). When the additional processor 21 receives an update request from the CP IJ 11, it sequentially updates, for example, pages 15i, 15j, and 15 of the database file 14 in response to the request. Now, journal data 23i as before image journal on pages 15i, 15j, 15
, 23j, 23k) as auxiliary journal file 2
2 (Step S4 in Figure i2). The additional processor 21 then transfers the auxiliary journal file descriptor 18 having the start page address and number of pages (3 pages in this case) on the auxiliary journal file 22 of the output journal to an empty page on the journal file 17 secured by the CPU 1l. settings (step S5 in FIG. 2).

As described above, in this embodiment, journaling by the additional processor 21 is performed not on the journal file 17 but on the auxiliary journal file 22, and only the information necessary to specify the journal is stored on the auxiliary journal file disk, printer. 18, it is output to the journal file 17, more specifically, to an empty page on the journal file 17 secured by CPU II.

Therefore, during the period when the additional processor 21 is performing database update processing in response to an update request from the process 13, the CPU II executes an update request from another process group on the main memory 12, and updates another database file 14.
Journal file 17
There is no risk that the journal will be destroyed by the journaling operation by the additional processor 21. That is, according to this embodiment, journaling by the CPU II and the additional processor 21 can be performed in parallel.

Next, a description will be given of database recovery processing when restarting the system after a system failure occurs. In this case, the CPU II first sequentially inputs the journaled pages from the journal file 17 (step 811 in FIG.
8) (step S12 in FIG. 3).
゜513). If it is not the auxiliary journal file descriptor (18), the CPU 11 assumes that the data on that page is journal data, and overwrites the corresponding page in the database file 14 with the data on that page (step 514 in FIG. 3). The CPU II repeats the above processing until the journal end is reached or an auxiliary journal file descriptor (18) appears.

Overwriting of journal data (database restoration) to the database file 14 is repeated as described above.
Eventually, the page where the auxiliary journal file descriptor 18 is set will be transferred from the journal file 17 to the CP
It is assumed that the information has been input to the UII. c p u ti is
When the auxiliary journal file descriptor 18 is input, the start page address is extracted from the descriptor 18 (step 515 in FIG. 3), and the corresponding page data, that is, journal data (here, journal data 231) is input from the auxiliary journal file 22. <
Figure 13 step 516). Then, the CPU 11 overwrites the input journal data (23i) on the corresponding page of the database file 14 (step 517 in FIG. 3).
). Next, cptytt inputs the input descriptor 18
(Step 518 in Figure 3)
, if the number of pages has not been reached, the process returns to step S16 and data for the next page (here journal data 23j) is input from the auxiliary journal file 22. This input page data is overwritten on the corresponding page of the database file 14. Similarly, when the database file 14 is overwritten with journal data on the auxiliary journal file 22 for the number of pages described in the auxiliary journal file descriptor 18, the CP
The UII executes step Sll again and inputs the next page from the journal file 17.

If this page is neither journal data nor auxiliary journal file descriptor, the CPU II assumes that the journal end has been reached and terminates the database recovery process.

In the above embodiment, recovery from a logical failure has been described, but by journaling the after-image journal in the same manner as the before-image journal described above, the present invention can also be applied to recovery from a physical (media) failure. Further, in the above embodiment, a case was explained in which one additional processor (database processor) 21 was added in order to speed up database processing, but the present invention further speeds up database processing. Therefore, it is also applicable to a system with a plurality of additional processors that perform database update processing in parallel. In this system, since the CPU II does not necessarily need to perform database update processing, the load on the CPU II can be further reduced while speeding up the database update processing.

[Effects of the Invention] As detailed above, according to the present invention, a database processor (additional processor) provided separately from a CPU (host CPU) in order to speed up database update processing performs journaling associated with database updates. If this is done, the journal file can be prevented from being destroyed, and as a result, even if a system failure occurs while the database processor is updating the database, the database can be correctly restored to its original state.

[Brief explanation of drawings]

FIG. 1 is a block configuration diagram of a database system according to an embodiment of the present invention, and FIG. 2 is a flowchart for explaining the operation at the time of database update in the embodiment.
FIG. 3 is a flowchart for explaining the operation during database recovery in the same embodiment, and FIGS.
The figure is a block diagram of a conventional database system. 11...CPU, 12...Main memory, 13...Process, 14...Database file, 1B...System bus, 17...Journal file, 1B...
- Auxiliary journal file descriptor, 21...
Additional processor (database processor), 22...
・Auxiliary journal file, 23i, 23j, 21
k...Journal data.

Claims (1)

[Claims] In order to speed up database update processing, in a database system that includes at least one database processor that performs database update processing separately from the CPU that forms the core of the system, if a system failure occurs during database update, A journal file for recovery in the event of an error, an auxiliary journal file for storing journals related to database updates by the database processor, and free pages of the journal files are secured in response to database update requests from processes. Then, the page information and the update request are sent to one of the database processors.
an update request means in the CPU that sends an update request to the CPU, and performs database update processing in response to the update request from this update request means, outputs the journal related to the update to the auxiliary journal file, and outputs the journal related to the update to the auxiliary journal file. update processing means within the database processor for setting a descriptor for identifying the output journal on the auxiliary journal file in a free page on the journal file secured by the update request means; When the system is restarted after a system failure occurs, it sequentially inputs the journaled pages from the above journal file, and if the input page has the above descriptor, inputs the journal specified by the same descriptor from the above auxiliary journal file. A database system characterized by performing database recovery.