JP3674598B2 - Database management method and system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
This is a database management technique when a database is shared by a plurality of database management units.
[0002]
[Prior art]
As a method of sharing a DB between systems, for example, as described in JP-A-62-204360, a DB management source is determined for exclusive control of a shared DB, and the lock manager and other systems are exclusive. There is known a method for exchanging information and performing unified management of exclusion.
[0003]
In this method, the journal, which is recovery information in the event of a DB failure, is acquired in each system, and journal merging is required when the DB failure is recovered.
[0004]
[Problems to be solved by the invention]
The conventional inter-system DB sharing method has the following problems in terms of performance and operation. (1) Even when only a data search is performed on an inter-system shared DB, in order to perform exclusive control with the update processing for the DB, it is necessary to make an exclusive use notification to the DB management source system. Compared with the case where the database is not shared, the overhead of data search becomes large, so it is not suitable for searching a large amount of data.
(2) When updating data from multiple CPUs to a shared DB between systems, the DB update journal is acquired by the DB update request source system. Yes.
An object of the present invention is to provide an inter-system database sharing method that solves the above problems.
[0005]
[Means for Solving the Problems]
In order to achieve the above object, as a DB sharing method between CPUs,
(1) Reduction of data search overhead For processing (transaction) that only performs data search for the inter-CPU shared DB, exclusive access control is not performed on the data to be accessed, and the data search request source CPU Direct data access.
[0006]
Thereby, the performance equivalent to access to DB which is not shared between CPUs can be realized for data retrieval.
[0007]
If a contradiction is detected in the control information of the search data block due to the timing of data update processing from another CPU at the time of data search, it is processed by one of the following methods. (A) Redirect data search a fixed number of times at fixed time intervals to relieve synchronization shift due to timing. (B) The search request is transferred to the database management source CPU, and the database management source CPU executes the search in a consistent state.
[0008]
(2) Centralized DB failure recovery journal For DB failure recovery, DB backup information and DB update journal information after the backup acquisition time are required. Since the DB update journal is obtained in a unified manner under one CPU, all DB update processing is performed by the DB management source CPU. That is, when updating the inter-CPU shared DB from a CPU other than the DB management source, a DB update request is sent to the DB management source CPU and the DB management source CPU updates the DB.
[Action]
In the inter-CPU DB sharing method according to the present invention, the DB search requesting CPU can directly access the DB (transaction) without contacting the other CPU, and is equivalent to accessing a non-shared DB. Search performance can be realized.
[0009]
Also, since the DB update is performed centrally by the DB management source CPU, even if there is an update request for the same DB from a plurality of CPUs, the update journal of the same DB is centralized by the management source CPU of the DB. Acquired and no journal merging is required when recovering from a DB failure, and the burden on the DB system operation manager regarding DB failure can be greatly reduced.
[0010]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a block diagram showing the configuration of the present invention.
When the CPU a1 is the management source of the shared DB 3, and there is a DB access request from the user program 22 of the CPU b2, the DB access unit 21 of the CPU b2 performs direct DB access for search, and the DB of the CPU b2 for update. The DB access unit 11 of the CPU a1 performs DB access from the access unit 21 via the DB distribution function unit 23 of the CPU b2 and the DB distribution function unit 13 of the CPU a1.
[0011]
When there is a DB access request from the user program 12 of the CPUa1, the DB access unit 11 of the CPUa1 performs DB access regardless of search and update.
[0012]
Whether the DB to be accessed is the DB managed by the CPU a1 or the DB managed by the CPU b2 is managed by the table shown in FIG. 6, and the management source is determined by each DB access unit.
[0013]
Hereinafter, specific processing procedures for DB search and update will be described.
(1) In the case of DB search (see FIG. 2)
When a search request to the shared DB 3 managed by the CPU a1 is issued from the user program 22 of the CPU b2 (201), the DB 3 is directly accessed by the DB access unit 21 of the CPU b2. However, since the access is performed without performing exclusive control with the CPUa1 side, there may be a case where the contents of the DB index part and the DB data part do not match depending on the timing of the update process on the CPUa1 side. Therefore, in order to deal with this delicate timing without exclusive control, when there is a discrepancy between the contents of the DB index part and the data part (202), the DB index and the DB data are stored a predetermined number of times at a predetermined time interval. The read is retried (203), and the process waits until the mismatch due to the timing shift is eliminated.
When the contradiction does not disappear even within the predetermined number of times, it is determined that permanent data destruction has occurred, and processing is performed as a read error (204).
(2) In the case of DB update (see FIGS. 3 to 5)
The case of updating the shared DB 3 managed by the CPU a1 from the user program 22 of the CPU b2 will be described in three stages. (A) Search Request for Update FIG. 3 shows a case where a search request for update of the shared DB 3 is issued by the CPU b2.
[0014]
The DB access unit 21 of the CPU b2 determines whether or not the requested DB is a DB managed by the own CPU using the DB location management table of FIG. 6 (301), and if it is a request to the DB managed by the CPU a1. Then, a DB access request is transmitted to the CPU a1 through the DB distributed function unit 23 (302). The CPU a1 declares the exclusive use of the DB (304) based on the DB access request transmitted from the CPU b2 and received by the DB distributed function unit 13 (304), performs DB access, and reads the DB index part and DB data part ( 305, 306). The read result is transmitted to the CPU b2 through the DB distribution function unit 13 (307).
[0015]
In the case of a DB managed by the CPU b2, DB access is performed by the access unit of the CPU b2 (308 to 310).
[0016]
(B) Update Request FIG. 4 shows a case where an update request for the shared DB 3 is issued from the CPU b2.
[0017]
As in the case of (a), when there is an update request from the user program 22 of the CPU b2 (401), the DB access unit 21 determines whether the DB is the own CPU management (402). If it is not own CPU management, a DB access request is transmitted to the DB management source CPU, in this case CPUa1, through the DB distribution function unit (403). In the CPUa1, when the DB distribution function unit 13 receives the update request (404), the DB access unit saves the DB update request until the synchronization point is reached (405), and transmits the update request processing report to the CPUb2 through the DB function distribution unit. (406). (C) Commit (COMM1T) or Rein FIG. 5 shows a case where the user program 22 of the CPUb2 issues a commit or returns and reaches the synchronization point of processing.
A case of a commit request will be described. As in the case of (a), a commit preparation request is first transmitted from the CPU b2 to the CPU a1 through the DB distribution function unit 23 (502). In the CPU a1, the DB access unit transmits a DB update request and a DB journal extraction (504, 505) and a commit preparation completion report to the CPU b2 (506). When receiving the commit preparation completion report, the DB access unit of the CPU b2 transmits a commit request (508) (two-phase commit). Upon receiving the commit request, the CPU a1 performs the actual update of the shared DB in the DB access unit (509), cancels the declaration of exclusive use of the DB (510), and sends a commit completion report to the CPU b2 (511). Since the DB update journal is acquired by the CPUal, recovery can be executed using only the journal of the CPUa1 in the recovery process when the DB fails.
[0018]
【The invention's effect】
According to the present invention, even if a DB is shared among CPUs, the DB search performance can be equivalent to that for accessing a non-shared DB.
[0019]
Further, when a DB failure is recovered, recovery operation can be easily performed without merging journals of a plurality of CPUs.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of an embodiment of the present invention.
FIG. 2 is a flowchart of processing according to an embodiment of the present invention.
FIG. 3 is a flowchart of processing according to an embodiment of the present invention.
FIG. 4 is a flowchart of processing according to an embodiment of the present invention.
FIG. 5 is a flowchart of processing according to an embodiment of the present invention.
FIG. 6 is a diagram showing a management table according to an embodiment of the present invention.
[Explanation of symbols]
1, 2 ... CPU, 3 ... shared DB, 11, 21 ... DB access unit, 12, 22 ... user program, 13, 23 ... DB distributed function unit

Claims (13)

In the database management method in which the first management unit that manages the first data and the second management unit that manages the second data share the first data and the second data.
When referring to the second data from the first management unit, the first management unit refers to the second data and updates the second data from the first management unit. Sends an update request for updating the second data from the first management unit to the second management unit, and the second management unit updates the second data. Method.     2. The database management method according to claim 1, wherein when referring to the second data from the second management unit, the second management unit refers to the second data, and the second management unit. In the database management method, the second management unit updates the second data when the second data is updated.     2. The database management method according to claim 1, wherein when referring to the first data from the first management unit, the first management unit refers to the first data, and the first management unit. When the first data is updated from the above, the first management unit updates the first data.     4. The database management method according to claim 3, wherein the first management unit generates an update journal for the first data, and the second management unit generates an update journal for the second data. A database management method characterized by the above.     5. The database management method according to claim 4, wherein an update journal generated by said first management unit is detected when a failure of said first data is detected, and said second when a failure of said second data is detected. A database management method characterized in that recovery processing is performed with reference to an update journal generated by a management unit.     In the database management method for sharing the data area between the first processor and the second processor that manages the data area, the first processor that has received the data reference request refers to the data area, and The first processor that has received the update request transfers the data update request to the second processor, and the second processor that has received the update request updates the data in the data area. A database management method characterized by the above.     In the database management system in which the first management means for managing the first data and the second management means for managing the second data share the first data and the second data, the first management means The management means includes a first data update means for updating the first data according to the input update request, and a first data update request means for sending the second data update request to the second management means. And first data reference means for referring to the first data and the second data according to the input reference request, wherein the second management means stores the second data according to the input update request. A second data update means for updating, a second data update request means for sending an update request for the first data to the first management means, the first data and the second data according to the inputted reference request See data for Database management system is characterized in that a second data reference means.     In the database management system in which a first management unit that manages first data and a second management unit that manages second data share the first data and the second data, the first management unit When referring to the second data from the management unit, the first management unit refers to the second data, and when updating the second data from the first management unit, A database management system, wherein an update request for updating the second data is sent from a first management unit to a second management unit, and the second management unit updates the second data.     9. The database management system according to claim 8, wherein when the second management unit refers to the second data from the second management unit, the second management unit refers to the second data. When the second data is updated, the database management system updates the second data.     9. The database management system according to claim 8, wherein when the first management unit refers to the first data, the first management unit refers to the first data and receives the first data from the first management unit. When updating, the database management system updates the first data.     11. The database management system according to claim 10, wherein the first management unit generates an update journal of the first data, and the second management unit generates an update journal of the second data. A database management system characterized by comprising:     12. The database management system according to claim 11, wherein an update journal generated by the first management unit is detected when a failure of the first data is detected, and the second journal is detected when a failure of the second data is detected. A database management system comprising means for performing recovery processing with reference to an update journal generated by a management unit of the database.     In the database management apparatus that shares the data area between the first processor and the second processor that manages the data area, the first processor that has received the data reference request refers to the data area, The first processor that has received the update request transfers the data update request to the second processor, and the second processor that has received the update request updates the data in the data area. A database management device characterized by the above.

Images