JP3002590B2 - How to manage the database - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database management method used in a system having a large-capacity database, such as a seal management system.

[0002]

2. Description of the Related Art FIGS. 5 to 7 are diagrams showing a conventional example, FIG. 5 is a system configuration diagram, FIG. 6 is a process flowchart, and FIG. 7 is a process explanatory diagram.

In the figure, 1 is a host (host computer), 2 is a disk controller (for example, a magnetic disk controller), 3 is a terminal device, 4 is a communication line, 5 is a hash key calculation processing section, and 6 is a data storage processing. Part, D1-D
Reference numeral 3 denotes a disk device (for example, a magnetic disk device).

Conventionally, for example, in a seal management system, a large-capacity database has been used. In such a database, seal stamp data and an index key for searching this data are managed in association with each other.

When a new index key is created, even if there is an unused area as a whole due to the distribution of the index key, the same data (seal stamp data) related to the index key is stored. An index key was created only in the index area in the physical volume.

In this case, if there is no free space in the same index area, the index key cannot be stored. In other words, the management is performed by being closed to the same physical volume. The details will be described below with reference to the drawings.

FIG. 5 shows an example of the configuration of the seal management system. In this system, the host (host computer)
1 and a terminal device 3 (actually, a plurality of devices) are connected via a communication line 4. A host 1 has a disk controller 2 and a disk subsystem composed of a plurality of disk devices D1 to D3. Is connected.

[0008] The seal database is constructed using the plurality of disk devices D1 to D3. Hereinafter, a process of storing data in the database will be described with reference to a process flowchart of FIG. Note that the processing numbers in FIG. 6 are shown in parentheses.

First, when a data storage request is issued from the terminal device 3, the disk controller 2 receives the data via the host 1 (S1). At this time, the disk controller 2 instructs the hash key calculation processing unit 5 to perform a hash key calculation process (S2).

The hash key calculation processing section 5 calculates a hash key value by a hash key calculation program and responds. The hash key calculation process is a process for uniformly distributing data by hash logic.

The data storage processing unit 6 determines a disk number for storing data based on the hash key calculation response (S3). Thereafter, the data storage processing unit 6 determines whether data can be stored in the determined disk (whether there is a free space in the data storage area) (S).
4). As a result, if the data can be stored (if there is a space), the data is stored (S8). However, if the data cannot be stored, it is determined whether the data can be stored in the disk next to the determined disk (S).
5) If the data can be stored, the data is stored (S8).

However, if data cannot be stored on the next disk, it is checked whether data can be stored on the next disk. In this way, the data storage area of each disk is checked until a disk that can store data is found, and if found, data is stored on that disk (S
8).

If there is no area in which data can be stored in all the disks (S6), the host 1 is replied to the effect that the data storage areas of all the disks are full (S7). The host 1 also responds to the terminal 3.

Next, when the data can be stored in the predetermined disk as described above (S8), the index key (the index key of the stored data) is stored in the same disk as the disk storing the data. ) Is determined (S9).

As a result, if an index key can be created (if there is a free space), an index key is created in the index area in the disk storing the data (S10).

However, if the index key cannot be stored, since the index key cannot be stored, the host 1 is replied to the effect that the data cannot be stored (S11). The host 1 also responds to the terminal device 3.

The above processing will be described with reference to a specific example of FIG. As a process of storing data in the database, first, data (for example, seal data) is stored in a data storage area, and then an index key is created in an index area in a disk (same disk) storing the data.

For example, as shown in FIG. 7, in the disk device D1, keys 1 to 3 (index keys) are stored in the index area 1, and data corresponding to keys 1 to 3 are stored in the data area 1. Have been.

In the disk drive D2, the key 4 is stored in the index area 2, and the key 4 is stored in the data area 2.
Corresponding data is stored. Further, the disk device D3
In the example, the key 5 is stored in the index area 3 and the data corresponding to the key 5 is stored in the data area 3.

The index keys and the data corresponding to the keys are allocated to the respective disk devices based on the hash logic. In this state, when the key 6 and the data corresponding to the key 6 are to be stored, it is assumed that first, the data corresponding to the key 6 can be stored in the data area 1 of the disk device D1.

At this time, there is no free area in the index area 1 in the disk device D1. Therefore, the key 6 cannot be created in the index area 1. That is, if an index key cannot be created in the index area 1 in the same disk as the data (seal stamp data), the data is not stored. This is to enable a high-speed search at the time of data search.

Therefore, in this case, the data corresponding to the key 6 cannot be stored in the disk device.

[0023]

The above-mentioned conventional apparatus has the following problems. (1) If an index key cannot be created in the index area on the same disk where the data is stored,
The data was not stored.

Therefore, at the time of designing the system, it is necessary to carefully design each disk unit so that there is no empty space in the index area before the data area. For this reason, much time and effort was required.

(2) Although there is a free space in the entire index area, no additional space can be created in the index area in the same disk where the data is stored, so that additional data cannot be created. Therefore, the disk cannot be used effectively.

An object of the present invention is to solve such a conventional problem and to make it possible to effectively use an unused portion (free space) of an index area regardless of the distribution of index keys.

[0027]

FIG. 1 is a diagram for explaining the principle of the present invention, wherein K1 to K3 are addresses of an index area,
A1 to A4 indicate addresses of the data area.

The present invention is configured as follows in order to solve the above problems. (1) In a database management method of a system in which a database spanning a plurality of physical volumes PV1 and PV2 is managed by a plurality of index areas and a plurality of data areas corresponding to the index areas, a database of a certain physical volume (for example, PV1) is used. When storing data in the data area, if an index key for the data can be created in the index area of the physical volume (PV1) storing the data, an index key is created in the index area and the index key is created. If a key cannot be created, an empty area in the index area of another physical volume (PV2) is searched, and an index key for the data is created in the empty area to manage the database.

[0029]

The operation of the present invention based on the above configuration will be described with reference to FIG. In the system for managing the database, an index area and a data area are provided for each physical volume PV1 and PV2.

For example, in the physical volume PV1, an index area 1 and a data area 1 are provided, and the physical volume PV1 is provided.
2, an index area 2 and a data area 2 are provided. When data is stored in the database, a hash key is calculated, a physical volume for storing the data is determined, and if the data can be stored, the data is stored.

However, if the data cannot be stored, the next physical volume is searched for sequentially, and the data is stored in the data area of the physical volume where data can be stored (there is a free space). Thereafter, if an index key for the data can be created in the index area in the physical volume storing the data (if there is a free space), the index key is created.

However, if an index key cannot be created, the next physical volume is searched for, and an index key for the data is created in an index area where an index key can be created.

For example, in the physical volume PV1, the keys 1 to 3 are stored in the addresses K1 to K3 of the index area 1 and there is no space, and the data A1 to A3 in the data area 1 are stored in the addresses A1 to A3. It is assumed that the data corresponding to the key 3 is stored and free (address A4).

In the physical volume PV2, the key 4 is stored in the address K1 of the index area 2;
There is a space (addresses K2 and K3), and the data corresponding to the key 4 is stored in the address A1 of the data area 2 and there is a space (addresses A2 to A4).

In this state, when data (data corresponding to the key 6) is stored in the data area 1 of the physical volume PV1 (address A4), there is no space in the index area 1 of the physical volume PV1, so that the index key of the data is used. Cannot be created.

Therefore, when the next physical volume PV2 is searched, there is a space in the index area 2, and an index key (key 6) for the data is created in this area. In this case, a physical volume number, a data storage address, and the like are created in the index key, and are used when searching for data.

In this way, it is not necessary to carefully design the index area and the data area for each physical volume, and the index area can be effectively used.

[0038]

Embodiments of the present invention will be described below with reference to the drawings. (Explanation of First Embodiment) FIGS. 2 to 4 are views showing a first embodiment of the present invention, FIG. 2 is a system configuration diagram, FIG. 3 is a process flowchart, and FIG. 4 is a process explanatory diagram. .

In the figures, the same reference numerals as those in FIGS. 1 and 5 denote the same parts. Reference numeral 7 denotes a control unit, and 3-1 to 3-m denote terminal devices. This embodiment is an example applied to a large-capacity database such as a seal management system, and the configuration of the system is shown in FIG.

This system includes a plurality of terminal devices 3-1.
-M, a host (host computer) 1 connected to the terminal device via a communication line 4, and a disk subsystem (for example, a magnetic disk subsystem) connected to the host 1.

The disk subsystem includes a disk controller (for example, a magnetic disk controller),
A plurality of disk devices (for example, magnetic disk devices) D1
To D3.

The plurality of disk devices D1 to D1
A database is configured using D3, and a process of storing data in the database and a process of retrieving data are performed by the disk controller 2 based on an instruction from the host 1.

In this example, a control unit 7, a hash key calculation unit 5, a data storage processing unit 6 and the like are provided in the disk controller 2, and data is stored in each of the disk devices D1 to D3.

Hereinafter, the process of storing data in the database in the above system will be described with reference to the processing flowchart of FIG. Each processing number in FIG. 3 is shown in parentheses.

A data storage request from each of the terminal devices 3-1 to 3-m is sent to the host 1 via the communication line 4, and then sent to the disk controller 2. When the control unit 7 in the disk controller 2 receives the data storage request (S21), the hash key calculation processing unit 5
The hash key calculation process is instructed for the received data.

The hash key calculation processing section 5 executes a hash key calculation process based on the instruction (S2).
2). After that, when the hash key calculation process ends,
A response signal is sent from the hash key calculation processing unit 5 to the control unit 7.

Upon receiving the response signal, the control section 7 issues a data storage instruction to the data storage processing section 6. The data storage processing unit 6 receives the value of the hash key calculated by the hash key calculation processing unit 5, and determines the number of the disk device that stores the data (S23).

Thereafter, the data storage processing section 6 determines whether or not data can be stored in the determined disk device (whether or not there is a free space in the data area in the disk device of the determined number) (S24).

As a result, if the data can be stored (there is a space), the data is stored in the data area (S2).
8). However, if the data cannot be stored (S2
4) It is determined whether data can be stored in the next disk (whether there is a free space) (S25). As a result, if the data can be stored, the data is stored in the data area.

If data cannot be stored, it is determined whether data can be stored in the next disk. In this way, if data can be stored in the data area of any disk device, the data is stored in that disk device.

However, if the data cannot be stored in the data areas of all the disks (S26), a response is sent to the host 1 via the control unit 7 that the data storage areas of all the disk devices are full (S27). ). Then host 1
Responds to the corresponding terminal device.

When data can be stored in the data area in any of the disk devices as described above (S2
8) Next, it is determined whether an index key can be created (whether there is a free space) in the same disk device as the disk device storing the data (S29).

As a result, if it can be created, the index key is stored in the index area (S30). However, if an index key cannot be created (S2
9) It is determined whether an index key can be created in the index area of the next disk device (whether there is a free space) (S31).

If the index key can be created, the index key is stored in the index area (S30). If the index key cannot be created, it is determined whether the index key can be created in the next disk device. I do.

In this manner, the search is sequentially performed until a disk device capable of creating an index key is found.
If an index area of any of the disk devices can be created, an index key is created in that index area (S30).

However, if an index key cannot be created even after searching all the disk devices (S3
2) A response is sent to the host 1 via the control unit 7 to the effect that the index areas of all the disk devices are unipolar (S3).
2). Thereafter, the host 1 also responds to the terminal device.

Next, the example of FIG. 4 will be described. In FIG. 4, keys 1 to 3 are stored in the index area 1 of the disk device D1, and the key 1 is stored in the data area 1.
It is assumed that correspondence data to key 3 correspondence data are stored.

The key 4 is stored in the index area 2 of the disk drive D2, the data corresponding to the key 4 is stored in the data area 2, the key 5 is stored in the index area 3 of the disk drive D3, and the data area is stored. 3 to key 5
It is assumed that corresponding data has been stored.

In this state, when data (data corresponding to the key 6) is stored in the data area 1 of the disk device D1, an attempt is made to create an index key for the data in the index area 1, but there is no free space. Cannot be created.

Therefore, the next disk drive D2 is searched, and an index key (key 6) for the data is created in a free area in the index area 2. In this case, for each index key, information on the disk device number or symbol (D1, D2, D3, etc.) and the storage address (A1, A2, A3, A4, etc.) of the key corresponding data is created together. Use it when searching for data.

In this way, even if the disk device storing the data does not have an empty area where an index key can be created, the index key can be created in an empty area of another disk device. Available.

(Other Embodiments) Although the embodiments have been described above, the present invention can be implemented as follows. (1) The database is not limited to the disk device, and another device (for example, a magnetic tape device) may be used.

(2) The present invention is not limited to the system shown in FIG. 2, but can be applied to other systems. For example, the present invention is also applied to a system in which a seal management system having a database is installed at each of a plurality of branches (for example, branches of a bank) and the systems of the branches can be connected to each other via an ISDN network. It is possible.

(3) The present invention is applicable not only to the seal management system but also to other databases. That is, the database
Any system can be applied as long as the system manages the index area and the corresponding data area.

[0065]

As described above, according to the present invention,
The following effects are obtained. (1) If there is no free space in the index area in the same disk device as the disk device storing the data, an index key can be created in the index area of another disk device.

For this reason, when designing the system, it is not necessary to carefully design the index area. (2) The index area does not need to be carefully designed for each disk device, but may be designed with the total size of the disk.

Therefore, the system design becomes easy, and the index area can be effectively used. (3) The data and the index key are stored in different disk devices only when the data can be stored and the index key cannot be stored in the same disk device.

Therefore, in a normal case, the data and the index key are stored in the same disk device.
Practically, the search speed is hardly reduced.

[Brief description of the drawings]

FIG. 1 is a principle diagram of the present invention.

FIG. 2 is a system configuration diagram in an embodiment of the present invention.

FIG. 3 is a processing flowchart of the embodiment.

FIG. 4 is an explanatory diagram of a process according to the embodiment.

FIG. 5 is a system configuration diagram of a conventional example.

FIG. 6 is a processing flowchart of a conventional example.

FIG. 7 is an explanatory diagram of processing in a conventional example.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Host (host computer) 2 Disk controller 3-1-3-m Terminal device 4 Communication line 5 Hash key calculation processing part 6 Data storage processing part 7 Control part D1-D3 Disk device

──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Takehiko Nakasone 1-1-1, Tonya-machi, Maebashi-shi, Gunma NF2 Building Inside Gunma Fujitsu Co., Ltd. (72) Kunio Miyazaki 1-1-1, Tonya-cho, Maebashi-shi, Gunma Prefecture NF2 Building Gunma Fujitsu Co., Ltd. (56) References JP-A-63-217417 (JP, A) JP-A-2-16649 (JP, A) JP-A-2-299037 (JP, A) (58) Field surveyed (Int. Cl. ⁷ , DB name) G06F 12/00

Claims (1)

(57) [Claims] 1. A plurality of physical volumes (PV1, PV2)
In a method of managing a database of a system that manages a database spanning a plurality of index areas and a plurality of corresponding data areas, when data is stored in a data area of a certain physical volume (for example, PV1), If an index key for the data can be created in the index area of the physical volume (PV1) storing the data, an index key is created in the index area. If the index key cannot be created, another index key is created. A database management method comprising: searching for an empty area in an index area of a physical volume (PV2); creating an index key of the data in the empty area; and managing the database.