JP2000035909A - Method and system for managing database - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize DB retrieval performance to have the performance that is equal to access to an unshared DB and also to easily recover and operate journals of plural CPUs without merging them at the time of recovering a DB failure by directly accessing a DB by a retrieval request source CPU at the time of retrieving only the DB and also allowing a DB management source CPU to unitarily update the DB. SOLUTION: A CPUa 1 is used as a management source of a shared DB 3. When a DB access request arrives from a user program 22 of a CPUb 2 here, a DB accessing part 21 of the CPUb 2 directly accesses and retrieves the DB and a DB accessing part 11 of the CPUa 1 accesses and updates the DB via the part 21 of the CPUb 2, a DB discrete function part 23 of the CPUb 2 and a DB discrete function part 13 of the CPUa 1. When a DB access request arrives from a user program 12 of the CPUa 1, the part 11 of the CPUa 1 accesses the DB whether it is for retrieving or updating.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION Along with the enlargement and diversification of systems, a plurality of CPU (central processing units) configuration systems for the purpose of function distribution, load distribution and risk distribution are increasing. In such a system, the present invention can be applied to a case where a data base (hereinafter referred to as a DB), which is a common resource, is shared between a plurality of CPUs.

[0002]

2. Description of the Related 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.
There is known a method of exchanging exclusion information between the lock manager and another system to centrally manage exclusion.

In this system, a journal which is recovery information at the time of a DB failure is acquired by each system.
At the time of B failure recovery, journal merge was required.

[0004]

A conventional inter-system DB
The shared system has the following problems in performance and operation.

[0005] (1) Even when only data retrieval is performed for an inter-system shared DB, it is necessary to notify the DB management source system of exclusive use in order to perform exclusive control of update processing for the DB. Compared to a case where the DB is not shared between the systems, the overhead of data search becomes large, so that it is not suitable for a large amount of data search.

(2) When data is updated from a plurality of CPUs to an inter-system shared DB, the DB update journal is acquired by the DB update request source system. Need to be done.

An object of the present invention is to provide an inter-system database sharing method which solves the above problems.

[0008]

Means for Solving the Problems To achieve the above object, as a DB sharing method between CPUs, (1) Reduction of data search overhead A process for performing only data search for a CPU shared CPU ( Transaction), exclusive control is not performed on the data to be accessed, and the data search request source C
Data is directly accessed from the PU.

As a result, for data retrieval, the CP
The same performance as access to a DB that is not shared between U can be realized.

At the time of data search, if inconsistency is detected in the control information of the search data block due to the timing of data update processing from another CPU, the data is processed by one of the following methods.

(A) The data retrieval is redirected a fixed number of times at a fixed time interval to remedy a synchronization shift due to timing.

(B) The search request is transferred to the database management source CPU, and a search in a consistent state is executed by the database management source CPU.

(2) Unification of DB failure recovery journal DB failure recovery requires DB backup information and DB update journal information after the backup was acquired. Since the DB update journal is centralized and acquired under one CPU, all DB update processing
This is performed by the B management source CPU. That is, C other than the DB management source
When updating a DB shared between CPUs from a PU, a DB update request is sent to the DB management source CPU, and the DB management source CPU updates the DB.

[0014]

According to the inter-CPU DB sharing method of the present invention, the processing (transaction) only for the DB search can be directly accessed from the DB search requesting CPU without contacting the other CPUs. Search performance equivalent to access can be realized.

Further, since the DB update is performed centrally by the DB management source CPU, even if there is an update request from a plurality of CPUs to the same DB, the update journal of the same DB is maintained by the management source CPU of the DB. It is unified and acquired, and journal merge at the time of DB failure recovery becomes unnecessary, and the burden on the DB system operation administrator concerning DB failure and the like can be greatly reduced.

[0016]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below in detail with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of the present invention.

When the CPUa1 is the management source of the shared DB3 and there is a DB access request from the user program 22 of the CPUb2, the DB access unit 21 of the CPUb2 performs direct DB access for search, and updates for From the DB access unit 21 of the CPU b2 to the CPU
The DB access unit 11 of the CPU a1 accesses the DB via the DB distribution function unit b2 and the DB distribution function unit 13 of the CPU a1.

When there is a DB access request from the user program 12 of the CPU a1, regardless of the search or update,
The DB access unit 11 of the CPU a1 performs DB access.

Whether the DB to be accessed is a DB managed by the CPUa1 or a DB managed by the CPUb2 is managed by a table shown in FIG. 6, and the management source is determined by each DB access unit.

Hereinafter, specific processing procedures for DB search and update will be described.

(1) 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 (20).
1) In the DB access unit 21 of the CPU b2, the DB 3
To access directly. However, since the access is performed without performing the exclusive control with the CPUa1, the contents of the index part of the DB and the data part of the DB may appear to be inconsistent depending on the timing with the update processing of the CPUa1. In order to cope with this delicate timing without exclusive control, when there is a mismatch between the contents of the DB index part and the data part (202), the DB index and the DB data of the DB index and the DB data are determined at predetermined time intervals. Retry reading (203), and wait until there is no mismatch due to timing deviation.

If the contradiction does not disappear within the predetermined number of times,
It is determined that permanent data destruction has occurred, and is processed as a read error (204).

(2) DB Update (See FIGS. 3 to 5) A case where the user DB 22 of the CPUb2 updates the shared DB3 managed by the CPUa1 will be described in three stages.

(A) Search Request for Update FIG. 3 shows a case where a search request for updating the shared DB 3 is issued by the CPU b2.

The DB access unit 21 of the CPU b2 uses the DB location management table shown in FIG.
It is determined whether or not B is a DB managed by its own CPU (301).
If the request is for a DB managed by Ua1, a DB access request is transmitted to CPUa1 through DB distribution function unit 23 (302). The CPUa1 declares exclusive use of the DB based on the (303) DB access request transmitted from the CPUb2 and received by the DB distribution function unit 13 (30).
4) Perform DB access, DB index part, D
The B data portion is read (305, 306). The read result is transmitted to the CPUb2 by carrying the DB distribution function unit 13 (307).

In the case of the DB managed by the CPU b2, the CP
DB access is performed by the access unit of Ub2 (308 to
310).

(B) Update request FIG. 4 shows a case where an update request to the shared DB 3 is issued from the CPU b2.

As in the case (a), when there is an update request from the user program 22 of the CPU b2 (401), the DB
The access unit 21 determines whether the DB is managed by its own CPU (402). If not the own CPU management, the DB management source CPU through the DB distribution function unit, in this case, the CPU
An access request is transmitted (403). In CPUa1,
When the DB distribution function unit 13 receives the update request (40
4), the DB access unit saves the DB update request until the synchronization point is reached (405), and transmits an update request processing report to the CPUb2 through the DB function distribution unit (406).

(C) Commit (COMMlT) or Resuming FIG. 5 shows a case where the user program 22 of the CPU b2 issues a commit or returns and reaches a processing synchronization point.

The case of a commit request will be described. As in the case of (a), first, a commit preparation request is transmitted from the CPU b2 to the CPU a1 via the DB distribution function unit 23 (502). In the CPU a1, the DB access unit transmits a DB update request and a DB journal fetch (504, 505) commit preparation completion report to the CPU b2 (50).
6). Upon receiving the commit preparation completion report, the DB access unit of the CPU b2 transmits a commit request (50
8) (2 phase commit). Upon receiving the commit request, the CPUa1 updates the shared DB in the DB access unit (509), and releases the declaration of exclusive use of the DB (51).
0), a commit completion report is sent to CPUb2 (51).
1). At this time, the journal of the DB update is acquired by the CPUal. Therefore, in the recovery processing when the DB has failed, the recovery can be executed using only the journal of the CPUa1.

[0032]

According to the present invention, even if a DB is shared between CPUs, the DB search performance can be realized at the same level as the access to a non-shared DB.

Further, at the time of DB failure recovery, 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 a process according to an embodiment of the present invention.

FIG. 3 is a flowchart of a process according to an embodiment of the present invention.

FIG. 4 is a flowchart of a process according to an embodiment of the present invention.

FIG. 5 is a flowchart of a process 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.

[Description of Signs] 1, 2 CPU, 3 shared DB, 11, 21 DB access unit, 12, 22 user program, 13, 23 DB distributed function unit

────────────────────────────────────────────────── ───

[Procedure amendment]

[Submission date] August 6, 1999 (1999.8.6)

[Procedure amendment 1]

[Document name to be amended] Statement

[Correction target item name] Name of invention

[Correction method] Change

[Correction contents]

Patent application title: Database management method and system

[Procedure amendment 2]

[Document name to be amended] Statement

[Correction target item name] Claims

[Correction method] Change

[Correction contents]

[Claims]

Claims (2)

[Claims] In a processing system in which a database is shared and accessed between a plurality of systems, at the time of data search, direct data access is performed without exclusive control from a system of a data search request source, and at the time of data update, the data is stored. A database sharing method between systems, wherein a data update request is transferred to a system that manages a database to be updated, and the data is updated with exclusive control. 2. The inter-system database sharing method according to claim 1, wherein, when inconsistency is detected in the control information of the search data block during the data search, a retry is performed.