JPH0833855B2 - Hotspot data management processing method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Outline] Regarding a hotspot data management processing method in database processing by a multiprocessor system having a bus-coupled shared memory, frequently updated database resources are described.
The database access status table in which the access status to each resource of the database is registered, and the access status registered in the database access status table for the purpose of providing a means for shortening the recovery processing time in the event of an error The hot spot data determination unit for determining hot spot data, and the hot spot buffer provided in the shared memory for storing the data determined to be hot spot data are provided. Data that stays for a long time is placed in the shared memory as hot spot data.

[Industrial applications]

The present invention relates to a hotspot data management processing method in database processing by a multiprocessor system having a shared memory connected to a bus.

The multiprocessor system is roughly classified into a tightly coupled multiprocessor system and a loosely coupled multiprocessor system. Further, there are various types such as a composite of these and an intermediate one between the tightly coupled and the loosely coupled. The system configuration has been put to practical use.

On the other hand, to implement a database management system on a single processor, there is a certain limit to the response, and it takes time to recover from a processor failure. Processing techniques are needed.

[Conventional technology]

 FIG. 9 shows an example of the prior art.

FIG. 9A shows an example of a conventional multiprocessor database processing system. Each processor module 11 is a processing device having a CPU and a local memory 24.
Are bus-coupled to enable inter-processor communication.

Access to a database resource (resource) 27 is usually managed in units of a certain data set in the database. This unit may be, for example, a file level or a record level.

In the access to the resource 27, it is necessary to perform integrity guarantee for maintaining data integrity, such as prevention of occurrence of data inconsistency due to access competition and recovery in the event of failure.

Conventionally, in the system as shown in FIG. 9 (a), regarding the data stored in the database entity storage unit 13 of the secondary storage, the resources that each processor module 11 is in charge of.
27 are determined statically in advance or dynamically according to the load situation, and each processor module 11 locally guarantees the integrity of each resource 27.

In each processor module 11, as shown in FIG. 9B, the database buffer 26 is stored in the local memory 24.
When there is a reference / update request for the database, the database access module 51 reads the requested data into the database buffer 26. The area of the database buffer 26 is managed by LRU, for example. When the data in the database buffer 26 is updated, the log management unit 52 collects the log data L1, L2, ... Of the pre-update data or the post-update data for recovery in the event of an abnormality. (Reference 1: Gray, JN [1
978]. "Notes on data base operating systems" RJ21
88, IBM, San Jose, Calif.).

By placing the resource 27 read from the database entity storage unit 13 on a shared memory (not shown) accessible by each processor module 11 and performing common processing such as exclusive control and buffer control in the entire system. That is, a system that realizes integrity guarantee as shared processing by each processor module 11 performing symmetry is also considered, but log management and the like are similar to the example shown in FIG. is there.

[Problems to be Solved by the Invention]

In the database buffer 26 shown in FIG. 9B, when LRU management is performed on the data storage area, data having a high access frequency is placed in the local memory 24 as much as possible, so Access can be expected. Such specific data that is referred / updated frequently is called hotspot data.

Hotspot data is stored in the database entity storage unit 13
Since it has a characteristic that it is difficult to be reflected in, the data in the database entity storage unit 13 will remain in the old state long before this state for a long time, so be prepared for a system failure such as a system crash. However, a lot of log data L1, L2, ... Of update logs that are retained to restore the database will be accumulated. In fact, if a system crash occurs in such a state, the recovery processing time for recovery is very long, and quick recovery cannot be performed.

However, in order to prepare for a system crash, it is necessary to frequently reflect it in the database entity storage unit 13,
This has the drawback that I / O access becomes a bottleneck and the overall system performance is degraded.

It is an object of the present invention to solve the above problems and to provide means for shortening the recovery processing time when a resource of a database that is frequently updated is abnormal by using a shared memory. I am trying.

[Means for solving the problem]

 FIG. 1 shows a configuration example of the present invention.

In FIG. 1, 10 is a shared memory, 11-1, 11-2, ... Are processor modules (PM), 12 is a bus connecting each processor module 11 and the shared memory 10, 13 is a database entity storage unit, 14 Is an I / O bus, 20 is a hotspot buffer for storing hotspot data, 22 is a hotspot management unit, 23 is a hotspot determination unit, 24 is a local memory of each processor module, and 25 is a database access status. The registered database access status table, 26 is a database buffer, and 27 is a resource which is a unit of the database.

Each of the processor modules 11-1, 11-2, ... Has a local memory 24 and is bus-coupled to the shared memory 10. Furthermore, in this system, a database entity storage unit 13 is provided in each processor module, for example.
Connected via I / O bus 14, database entity storage unit 1
The data stored in 3 can be equally accessed from each processor module. The two buses 12 and 14 may be configured as one bus. Also, I / O bus 1
Instead of 4, one that can be controlled from each processor module may be used.

In the present invention, the database access status table 25 in which the access status such as the number of times of access to each resource 27 of the database is registered is provided in the local memory 24 or the shared memory 10.

When the database is accessed, the hotspot management unit 22 registers the access status of the resource 27 in the database access status table 25.

The hotspot determination unit 23 refers to the access status registered in the database access status table 25, checks data whose access frequency is higher than a predetermined reference value or data which stays in the local memory 24 for a long time, and determines its resource 27.
Is recognized as hot spot data.

Resources recognized as hotspot data 27
Are transferred to the hotspot buffer 20 provided in the shared memory 10 and placed in the shared memory 10.

[Action]

 FIG. 2 is an explanatory view of the operation of the present invention.

In the present invention, hotspot control is performed in FIG.
This is realized by the processing shown in (c).

(A) For the access on the database buffer 26 in the local processor module, the access status such as the number of updates to the corresponding resource 27 or the stay period on the buffer is shown in the database access status table 25.
Register with.

(B) The database access status table 25 is checked each time the resource 27 is accessed or at a predetermined time cycle, and the resource 27 that has been updated frequently or the resource 27 that has been updated and remains in the database buffer 26 for a long time is hot. Recognize as spot data.

(C) Resources determined to be hotspot data 27
From the database buffer 26 to the hotspot buffer 20 in the shared memory 10. At this point, the hotspot data has become stable data that is not erased even when the processor module crashes, and hence the data access status will be managed again. Here, the database access status table 25
Information is initialized. Further, for the same reason, the log data for recovering this data is no longer necessary and may be deleted.

Since hot spot data, which is frequently accessed data, exists in the shared memory 10, for example, even if the processor module 11-1 goes down and the resource 27 in the local memory 24 is lost, the database buffer 26 It is possible to recover by the hotspot buffer 20 without performing recovery with all log data from the time of reading. Therefore, quick recovery is possible.

Further, by arranging the hotspot data in the shared memory 10, the contents of the hotspot buffer 20 can be directly updated with respect to the subsequent access. In that case, the latestness of the updated data is Guaranteed by the shared memory 10.

In exclusive control for hotspot data, concurrency can be improved by reducing the granule that is a unit of access. However, this exclusive control is well known as shown in the above-mentioned reference document 1 and the like. It can be realized by various methods by applying technology.

〔Example〕

FIG. 3 is a system configuration example according to one embodiment of the present invention, FIG. 4 is an explanatory diagram of management data used in one embodiment of the present invention,
FIG. 5 is an example of hot spot management according to one embodiment of the present invention, FIG. 6 is an example of hot spot data management form according to one embodiment of the present invention, and FIG. An example of shared / local change control, FIG. 8 shows a processing operation explanatory diagram according to an embodiment of the present invention.

The present invention is implemented, for example, on a multiprocessor system as shown in FIG. In FIG. 3, SSU is a shared memory unit (Shared Storage Unit), SCA is an I / O interface adapter (SCSI Control Adapter), DK is a disk storage device, DLP is a data link processor, and DRC is a driver / receiver for line control.・ Represents a card.

Each processor module 11 consists of one or more CPUs.
And has a local memory 24. Local memory 24
For, I /
O can be reduced. In addition, each processor module 1
1 is capable of accessing the shared memory device SSU via the high-speed bus 12 under the control of a bus controller (not shown).

The high-speed bus 12 and the I / O bus 14 are multiplexed in order to speed up bus operations and troubleshoot. Of course, it may be a single layer.

Each processor module 11 is configured such that the processing of one processor module 11 can be performed by another processor module 11 instead. Therefore, when a processor module 11 fails, the failed device is disconnected from the system and the remaining processor modules 11 are disconnected.
Allows the service to continue.

The substance of the database is stored in a disk storage device DK such as an optical disk or a magnetic disk, and can be accessed from any processor module 11 via the I / O bus 14 and the adapter SCA.

As a system similar to such a system, Nikkei
Nikkei Electronics No.461, November 1988, published by BP
8th issue ", P110 to P115, various systems are known, but the present invention is not limited to these, and the present invention can be realized on various multiprocessor architectures in which shared memories are bus-coupled. Is possible.

In the present embodiment, it is possible to statically or dynamically use, for each resource, access control for database resources, that is, shared processing performed symmetrically by each processor module 11 and local processing performed non-symmetrically. You can do it. Details will be described later.

As the management data used for managing hotspot data and managing shared / local processing, for example, the fourth
The data as shown in the figure is prepared.

The space management table 30 shown in FIG. 4 is a table holding space management information for managing the database. In this embodiment, one processor module can have a plurality of address spaces, and a common kernel (core) in each space.
The department manages the space and the database. When space is abnormal, mutual backup is possible. The space management table 30 has a pointer to the database attribute table 31.

The database attribute table 31 has the following information for each resource.

(A) Resource name: This is a name added to each resource management unit of the database. By this name, the resource 27 of the database actually arranged can be identified. That is, the data managed by the shared buffer or the buffer in the local memory can be dealt with via the buffer management information 32.

(B) Shared / local display: This is a display with a flag or the like indicating whether the corresponding resource 27 is controlled by the shared type or the local (ubiquitous) type. According to this display, whether to allocate the resource 27 or its management information to the shared memory is determined.

(C) Access status pointer: Points to the database access status table 25.

(D) Database allocation information: In the case of a local type, it has an identifier of a processor module that guarantees its integrity.

The database access status table 25 has the following information indicating how many times each processor module has accessed that resource in order to manage the access status for each resource.

(A) PM-ID: This is an identifier of a processor module that has accessed the resource directly or indirectly by an access request.

(B) Reference count / update count: The reference or update access count for each processor module.

The control table for management data shown in FIG. 4 is arranged in the shared memory or the local memory in the processor module.

When the resource is of a local type, the database attribute table 31 and the database access status table 25 exist in the local memory of the processor module that performs the local control.

If the resource is a shared type, the database attribute table 31
Although it is on shared memory, database access status table 25
Are arranged on the shared memory and the local memory in each processor module, and the processor module updates only the access status of the processor module. On the shared memory, access status data is collected from each processor module at a certain time interval.

In recognizing hotspot data, the number of updates recorded in the database access status table 25 is used as a criterion for determination.

The access status is registered in the database access status table 25, for example, as shown in FIG.

When a data access request is issued, the database buffer management unit 50 notifies the hotspot management unit 22 of the resource name, access mode, and the like. The hotspot management unit 22 updates the access count in the database access status table 25 of the corresponding resource. From the viewpoint of log amount, in order to shorten the corresponding recovery time in the event of an abnormality, the counting of the number of updates starts from the time when the data is read into the data buffer. Or
The stay time in the data buffer may be registered.

Recognition of hotspot data according to access status
It is possible to carry out at any of the triggers shown in FIGS.

FIG. 5B shows an example of checking the hotspot data when accessing the database.

When there is an access request to the database access module 51, in the case of updating, the log management unit 52 collects log data and requests the database storage access management unit 53 for access. The database storage access management unit 53 issues an access request to the database buffer management unit 50. Database buffer management unit
In response to the notification from 50, the hot spot management unit 22 causes the hot spot determination unit 23 to check the hot spot data.

FIG. 5C shows an example in which the hot spot data is determined by using as a trigger when the log data amount exceeds a certain level.

Since the amount of log data affects the recovery processing time,
Whether or not the amount of log data up to that point or the log acquisition time is long will also determine the recovery processing efficiency. Therefore, at the time of log data acquisition (for example, at the end of each transaction), the log management unit 52 checks the amount of log data, etc., and if it exceeds a certain reference value, the resource is regarded as a hot spot data candidate and is hot. Notify the spot management unit 22. With this as a trigger, the hot spot determination unit 23 determines the hot spot data.

The processing is, for example, as shown in FIG.
As shown in FIG. 5 (e), a usable threshold value is set in order to prevent the log area from overflowing in a steady state. The default value may be set at system startup. Next, at the stage of using the log area, such as when committing a transaction, the amount of log in use is calculated. Then, the size of the log amount and the threshold value are checked to determine whether to activate the hot spot determination processing or not perform the hot spot processing.

FIG. 5D is an example of checking hotspot data at predetermined time intervals.

The hot spot management unit 22 is activated by a timer or the like at a predetermined cycle, and the hot spot determination unit 23 periodically detects hot spot data based on the access status.

The processing is, for example, as shown in FIG.
First, set the hotspot determination time interval. This sets a default value at system startup, and changes the value depending on the specification from the system user and the log volume status.

Then, by time monitoring, it is determined whether or not a predetermined time has elapsed, and it is determined whether to activate the hot spot determination processing or not perform the hot spot processing.

The management method of hotspot data changes depending on the arrangement of the database buffer using the shared memory 10 or the local memory 24. Next, examples of these various management forms will be described with reference to FIG.

FIG. 6A shows an example in which the database buffer is arranged only in the shared memory.

This form is used when resources are managed by the shared type and the access frequency from each processor module PM1, PM2, etc. is high. Especially, the whole is positioned as a hotspot, and each processor module
Directly access the buffer in shared memory. Acquires log data according to the update during the transaction.

FIG. 6B shows an example in which a prototype of the resource (R1) is placed in the shared memory and a copy of the resource (R1) is placed in the local memory.

Since there is a copy of the resource in each local memory,
High-speed access is possible in each processor module. Therefore, although pages (units of data) that stay in the local memory for a long time may appear, the contents of update are written to the buffer on the shared memory and the corresponding log data is written by the periodic asynchronous transfer by hotspot management. To reduce.

In Fig. 6 (c), the shared memory does not have a database buffer, and only the local memory has resources (R
This is an example of having a copy of 1).

Performs high-speed access on local memory. Therefore, some pages will stay in the local memory for a long time. About this, instead of expelling it to secondary memory,
A shared memory is used, and hotspot data is asynchronously transferred to the shared memory.

FIG. 6D shows an example in which resources of local processing data whose access is unevenly distributed to a specific processor module are arranged only in a local memory of the specific processor module.

To efficiently reduce the amount of log data and shorten the recovery processing time, hot spot data is saved in the shared memory.

Even if the locally processed data is copied to the local memory of a plurality of processor modules,
This is the same as the form shown in FIG.

The configurations shown in FIGS. 6C and 6D are such that the shared memory is used as a backup storage device.

In the present embodiment, shared processing management and local processing management can be performed for resource management. Below, dynamic change control will be described with reference to FIG.

In the case of local processing, exclusive control and buffer control for accessing a resource are performed by a specific processor module that manages the resource. When access to a resource is unevenly distributed in a specific processor module, most access control can be speeded up by performing exclusive control and buffer control locally.

In the case of shared processing, integrity assurance is performed for the entire system. For resources that are uniformly accessed by each processor without being unevenly distributed to specific processor modules, avoiding concentration of load on specific processor modules and communication such as access requests to specific processors. It is possible to prevent an increase in cost and improve the throughput of the entire system.

Therefore, as shown in FIG. 7, when access is unevenly distributed to a specific processor module, local processing management is performed.
When the uneven distribution tendency is resolved, change control is dynamically performed so that shared processing is managed. This makes it possible to perform optimal access management according to the access status of the resource.

The management pattern of various hotspot data shown in FIG. 6 is selected depending on whether shared processing management or local processing management is performed.

The processing operation will be described below with reference to FIG. ~ In the following description is shown in FIG.
Corresponding to.

The shared / local management unit 60 refers to the database access status table 25, checks whether the access to the resource is unevenly distributed to a specific processor module, and determines the shared type / local type for the resource. When changing sharing / local, the sharing / local display of the database attribute table 31 is changed.

The database buffer management unit 50 determines the placement of the database buffer depending on whether the resource is a shared type or a local (unevenly distributed) type. Whether or not to have a copy in local memory is determined when the corresponding page is accessed. Basically, you have a copy.

For access to the database, the access status is registered in the database access status table 25 via the hot spot management unit 22 or directly.

The hot spot determination unit 23 refers to the database access status table 25 and determines whether the data is hot spot data. The result is registered again as the access status.

The database buffer management unit 50 requests the hotspot management unit 22 to manage the hotspot data according to the database access status table 25.

In implementing the present invention, when managing hotspot data, it is not necessary to adopt all of the forms shown in FIG. 6 described above, and for example, it may be applied only to the local type. .

〔The invention's effect〕

As described above, according to the present invention, by utilizing the characteristics of the multiprocessor architecture and utilizing the shared memory for the database resources that are frequently updated, the log data amount can be reduced and an error occurs. It is possible to shorten the recovery processing time.

[Brief description of drawings]

FIG. 1 is a configuration example of the present invention, FIG. 2 is an explanatory diagram of the operation of the present invention, FIG. 3 is a system configuration example according to an embodiment of the present invention, and FIG. 4 is for management used in an embodiment of the present invention. FIG. 5 is an explanatory diagram of data, FIG. 5 is an example of hot spot management according to one embodiment of the present invention, FIG. 6 is an example of hot spot data management form according to one embodiment of the present invention, and FIG. An example of shared / local change control in one embodiment, FIG. 8 is an explanatory view of processing operation according to one embodiment of the present invention, and FIG. 9 shows an example of a conventional technique. In the figure, 10 is a shared memory, 11-1, 11-2, ... Are processor modules, 12 is a bus, 13 is a database entity storage unit, and 14 is I / O.
A bus, 20 is a hotspot buffer, 22 is a hotspot management unit, 23 is a hotspot determination unit, 24 is a local memory, 25 is a database access status table, 26 is a database buffer, and 27 is a resource.

Front page continued (72) Inventor Masaaki Mitani 1015 Kamiodanaka, Nakahara-ku, Kawasaki, Kanagawa, Fujitsu Limited (72) Inventor Tomohiro Hayashi 1015, Uedota, Nakahara-ku, Kawasaki, Kanagawa Prefecture, Fujitsu Limited (72) Inventor Hiroshi Sekine 1015 Kamiodanaka, Nakahara-ku, Kawasaki City, Kanagawa Prefecture, Fujitsu Limited (56) References JP 60-189041 (JP, A) "Lecture Note on Computer Science" Vol. 368 (1989) P. 251-268

Claims (1)

[Claims] 1. In a database processing by a multiprocessor system comprising a plurality of processor modules (11-i) each having a local memory (24) and a shared memory (10) bus-coupled to each of these processor modules. This is a hotspot data management processing method. The database access status table (25) in which the access status of each resource of the database is registered and the access status of the above access status table is updated when the resource of the database is accessed. A hot spot management unit (22), a hot spot data judging unit (23) for judging hot spot data according to the access status registered in the database access status table, and data judged as hot spot data are stored. Provided in the above shared memory The hotspot buffer (20) and the data determined by the hotspot data determination unit determine whether the data that has been referred to or updated a certain number of times or more within a predetermined time or the data that stays in the local memory for a certain time or more is hotspotted. A hotspot data management processing method characterized by comprising processing means for arranging as data in a hotspot buffer on the shared memory.