JP2007065978A - Computer system and database management system program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce necessary memory quantity when operating a look-ahead function on a computer where a DBMS is operating. <P>SOLUTION: This computer system includes a computer for storing a database management system program in a memory, and a storage device for storing data. The computer is provided with: a shared DB data management part for assigning a buffer on the memory, and for managing the buffer, a data processing part for acquiring the requested data; and a look-ahead part for operating the look-ahead of the data by referring to the data stored in the buffer. The shared DB data management part is characterized in that the data in the buffer is locked when the data are acquired by the data processing part. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a computer system including a computer having a database management system program, and more particularly to a method for prefetching data processed by a database management system.

  In recent years, with the increase in the amount of data handled by computer systems, a database management system (hereinafter referred to as DBMS) which is software for managing these data has become extremely important. The processing performance in the DBMS is closely related to the access performance to the data stored in the storage device, and it is not uncommon for the access performance to be a determining factor for the processing performance of the DBMS.

  As a technique for reducing the impact of access performance to storage devices and improving DBMS processing performance, this is called “read ahead” in which data to be used in the future is read in advance into a storage area such as a computer memory that can be accessed at high speed. There is a method. The problem in prefetching is how to grasp in advance the data to be used. There are the following technologies related to prefetching.

  An operating system (hereinafter referred to as “OS”) discusses a function of prefetching data into a file cache on a computer using a hint issued from a program and a control method thereof (for example, see Non-Patent Document 1). In the present technology, the program is modified by an administrator or the like so that the program issues a hint regarding a file to be accessed in the future and an access destination area. Non-Patent Document 1 describes, as an example in which the present technology is applied to a DBMS, a method in which an area indicated by a pointer corresponding to a search key value is given as a hint during a search process using a B-Tree index and prefetched. .

A prefetching technique in a storage device using a “query plan” which is an execution plan of processing in a DBMS is disclosed (see Patent Document 1). In the present technology, the pre-read function in the storage device acquires the query plan and other management information held by the DBMS. The prefetch function analyzes data managed by the DBMS based on the acquired information. As a result, the prefetch function grasps data to be accessed from now on, and prefetches them into a cache which is a storage area of the storage device that can be accessed at high speed. In the present technology, prefetching is performed independently of normal inquiry processing (hereinafter, “DBMS main processing”) performed by the DBMS, and a high prefetching effect can be expected.
Japanese Laid-Open Patent Publication No. 2003-150419 RH Patterson et al, "Informed Prefetching and Caching," In proceeding of the 15th ACM Symposium on Operationg Systems Principles, pp. 79-95, Dec. 1995.

  In the background art described so far, the following points are problems.

  In the technique described in Non-Patent Document 1, a hint is issued as part of the DBMS main process executed by the DBMS. Therefore, when the process is stopped due to an exclusive lock of data or the like, the issuing of hints is also stopped. As a result, the prefetching process is also stopped, and a high prefetching effect cannot be obtained.

  The technique disclosed in Patent Document 1 solves the problem of Non-Patent Document 1. However, in the technique disclosed in Patent Document 1, the prefetch function holds and manages data independently of the DBMS. Therefore, the same data is held twice in the computer system. Usually, DBMS uses a technique for improving performance by holding frequently used data in a storage area secured on a computer memory called a “buffer”. In general, the larger the amount of memory reserved for the buffer, the higher the performance of the DBMS. When the prefetch function and the DBMS are executed by the same computer, the same data is held twice on the computer, and accordingly, the amount of memory that can be used as a buffer is reduced, and the DBMS performance is likely to deteriorate.

  An object of the present invention is to reduce the amount of memory required when the prefetch function is performed independently of the normal inquiry processing (DBMS main processing) of the DBMS. As a result, when the prefetch function is operated on the computer on which the DBMS operates, high processing performance can be obtained by the prefetch processing even when the memory amount of the computer is small.

  The present invention relates to a computer system including a computer that stores a database management system program in a memory and a storage device that stores data, wherein the computer allocates a buffer on the memory and manages the buffer. A management unit; a data processing unit that obtains requested data; and a prefetching unit that prefetches data with reference to data stored in the buffer, wherein the shared DB data management unit includes the data When the processing unit acquires data, the data in the buffer is locked.

  According to the present invention, it is possible to reduce the amount of memory required when operating the prefetch function on a computer on which a DBMS operates. As a result, a larger amount of memory can be used as a buffer for the DBMS, so that high system performance can be obtained.

  The prefetch unit is operated on the computer on which the DBMS operates. The prefetching unit performs prefetching processing independently of the data processing unit that performs DBMS main processing. At this time, the prefetching unit is prevented from being affected by the lock on the data set by the data processing unit. The data processing unit and the prefetching unit share data, so that a high prefetching effect can be obtained while reducing the memory usage of the computer. Further, a suitable prefetching operation is realized by adjusting the prefetching unit from the outside in accordance with the operation state of the computer or the operation state of the DBMS main process.

(First embodiment)
In the first embodiment, the DBMS operates on one computer. The data processing unit and the prefetching unit share the buffer allocated on the memory of the computer.

  In the first embodiment, the prefetching unit is realized as one function in the DBMS.

  FIG. 1 is a block diagram of a computer system according to the first embodiment of this invention.

  The computer system includes a DB server 42, an AP server 44, and a storage device 46.

  The AP server 44 is a computer that issues a processing request to the DBMS 60 by executing an AP program.

  The DB server 42 and the AP server 44 are connected via the network 24 and can communicate with each other. The DB server 42 is connected to one or more storage devices 46 via the I / O path 34.

  The storage device 46 provides a data storage area to the DB server 42. For example, the storage device 46 stores data in a plurality of disk devices (HDDs).

  The DB server 42 is a computer that executes the DBMS 60. The DB server 42 includes a CPU 12, a memory 14, an HDD 16, a CD-ROM drive 18, a network I / F 22, and an I / O path I / F 32.

  The CPU 12, memory 14, HDD 16, CD-ROM drive 18, network I / F 22 and I / O path I / F 32 are connected by an internal bus 20.

  The CPU 12 executes various processes by executing programs on the memory 14. In addition, although the DB server 42 includes two CPUs 12 in this explanatory diagram, any number may be included.

  The memory 14 stores a DBMS 60, share management information 62, a share buffer 64, and an OS 52. The OS 52 controls the entire DB server 42. For example, the OS 52 performs program execution control, hardware control, communication between computers, management of the storage area of the HDD 16, management of the storage area of the storage device 46, and the like. Furthermore, in the present embodiment, the OS 52 measures the usage rate of the CPU 12 and provides it to other programs. The OS 52 has a thread function corresponding to the multi-thread execution model. In this embodiment, a multi-process function provided by the OS 52 or the like may be used instead of the thread function.

  The DBMS 60 is a program that performs processing related to a database (DB). Note that the DB server 42 may execute a plurality of DBMSs 60. DB data managed by the DBMS 60 is stored in the storage device 46.

  The share management information 62, which will be described in detail with reference to FIG.

  The shared buffer 64 is an area for storing data that is frequently used.

  Note that the OS 52 and the DBMS 60 are read from a portable storage medium (such as a CD-ROM) storing these using the CD-ROM drive 18 and installed in the HDD 16 or the storage device 46.

  The network I / F 22 is an interface connected to the AP server 44 via the network 24. The I / O path I / F 32 is an interface connected to the storage device 46 via the I / O path 34.

  The AP server 44 includes a CPU 82, a memory 84, an HDD 86, and a network I / F 85.

  The CPU 82, memory 84, HDD 86, and network I / F 85 are connected by an internal bus 80.

  The CPU 82 executes various processes by executing programs on the memory 84. The AP server 44 includes two CPUs 82 in this explanatory diagram, but any number of CPUs may be provided.

  The memory 84 stores the AP program 70 and the OS 89.

  The OD 89 controls the entire AP server 44.

  The AP program 70 is a program for performing business. The AP program 70 issues a processing request (query) regarding the DB to the DBMS 60.

  In the explanatory diagram, the AP program 70 operates on the AP server 44, but may operate on the DB server 42. The AP server 44 may execute a plurality of AP programs 70.

  In this explanatory diagram, one AP server 44 is shown, but a plurality of AP servers 44 may be provided. In addition, this embodiment can also be applied to a case where a plurality of AP programs 70 operate on that.

  Hereinafter, processing of the DBMS 60 according to the embodiment of this invention will be described.

  FIG. 2 is an explanatory diagram of functions of the DBMS 60 according to the first embodiment of this invention.

  The share management information 62 includes a schema 300, process management information 400, shared DB data management information 450, and prefetch process information 500.

  The schema 300 is information such as a DB definition managed by the DBMS 60, and includes table definition information, index definition information, object management information, and file management information.

  The table definition information is table definition information defined in the DB managed by the DBMS 60, which will be described later with reference to FIG. 5A. The index definition information is index definition information defined in the DB managed by the DBMS 60, which will be described later with reference to FIG. 5B. The object management information is information relating to the storage area of the object, which will be described later with reference to FIG. 5C. As will be described later with reference to FIG. 5D, the file management information is information relating to a file used when storing DB data managed by the DBMS 60 in the storage device 46.

  The process management information 400 includes query management information, transaction management information, and a query plan.

  The query management information is query management information executed by the DBMS 60, which will be described later with reference to FIG. 6A. The transaction management information, which will be described later with reference to FIG. The query plan, which will be described later with reference to FIG. 7, is information related to an execution plan for processing corresponding to the query created by the client processing unit 202.

  The shared DB data management information 450 includes shared buffer definition information, buffer block management information, buffer group management information, lock management information, and I / O wait management information.

  The shared buffer definition information is information related to the storage area of the shared buffer 64, which will be described later with reference to FIG. 8A. The buffer block management information is information for managing blocks in the shared buffer 64, which will be described later with reference to FIG. 8B. A block is a management unit of the storage area of the shared buffer 64. As will be described later with reference to FIG. 8C, the buffer group management information is information for managing each group of blocks grouped to divide the shared buffer 64. The lock management information is information for managing page lock, as will be described later with reference to FIG. 8D. The I / O waiting management information is information for managing a query waiting for I / O completion, which will be described later with reference to FIG. 8E.

  The prefetch processing information 500 includes total prefetch number management information, prefetch management information, and prefetch request management information.

  As will be described later with reference to FIG. 9A, the total prefetching number management information is information for managing the number of threads used in the prefetching process and information for managing the number of blocks holding the page read by the prefetching process. The prefetch management information, which will be described later with reference to FIG. 9B, is management information for prefetch processing executed in response to a query. As will be described later with reference to FIG. 9C, the prefetch request management information is information for managing a thread that executes a process of issuing a prefetch I / O.

  The DBMS 60 includes a client processing unit 202, an execution management unit 204, a data processing unit 206, a prefetching unit 208, and a shared DB data management unit 210.

  Also, in this explanatory diagram, an outline of an interface related to data shared by each component is described. Note that all components refer to the schema 300 as necessary.

  The client processing unit 202 acquires a query from the AP program 70. Next, a query plan (query execution plan) corresponding to the acquired query is created. Next, the created query plan is stored in the process management information 400. Next, the execution management unit 204 is requested to execute the query.

  When the query is executed, the client processing unit 202 receives the processing result from the data processing unit 206 and sends the received processing result to the AP program 70. Then, the client processing unit 202 notifies the execution management unit 204 of the end of the query, and deletes the query plan for the query from the processing management information 400.

  The execution management unit 204 receives a query execution request from the client processing unit 202. When the execution management unit 204 receives a query execution request, the execution management unit 204 sets necessary information in the prefetch processing information 500. Next, the execution management unit 204 requests the data processing unit 206 to execute processing according to the query plan. Furthermore, the execution management unit 204 requests the prefetch management unit 208 to execute prefetch processing. When the execution management unit 204 receives a notification of the completion of the query processing from the client processing unit 202 from the client processing unit 202, the execution management unit 204 deletes the prefetch processing information corresponding to the query from the prefetch processing information 500.

  Further, the execution management unit 204 monitors the execution state of the process and / or the CPU usage rate of the DB server 42. Then, the execution management unit 204 sets the execution parameter in the prefetch process information 500 according to the execution state of the process being monitored and / or the CPU usage rate of the DB server 42, thereby performing the prefetch process of the prefetch unit 208. Control.

  When the data processing unit 206 receives a processing request from the execution management unit 204, the data processing unit 206 executes the processing according to the query plan included in the processing management information 400. When the data processing unit 206 finishes the processing, the data processing unit 206 sends the processing result to the client processing unit 202.

  The data processing unit 206 acquires data necessary for executing processing by transmitting a data acquisition request to the shared DB data management unit 210. At this time, the data processing unit 206 also transmits to the shared DB data management unit 210 information on the lock to be set for the requested data.

  In addition, when the use of the acquired data is completed, the data processing unit 206 transmits a data use completion report to the shared DB data management unit 210. That is, the data processing unit 206 reports to the shared DB data management unit 210 that the data can be discarded from the shared buffer 64.

  In addition, when the processing is completed, the data processing unit 206 instructs the shared DB data management unit 210 to release the lock. Further, the data processing unit 206 refers to the prefetch processing information 500 as appropriate, and determines whether or not prefetching is necessary. If prefetching is necessary, a prefetch request is transmitted to the prefetch unit 208.

  When receiving a prefetch request from the execution management unit 204 or the data processing unit 206, the prefetch unit 208 executes prefetch processing. Note that the prefetching unit 208 executes prefetching processing using a multithreaded execution model in order to extract high I / O parallelism. Further, the prefetch unit 208 executes prefetch processing based on the prefetch processing information 500.

  The prefetch unit 208 executes the prefetch process with high independence from the process executed by the data processing unit 206 (process corresponding to the query). This is because the prefetch process does not update data. In addition, the effect of prefetching can be enhanced by increasing the I / O parallelism.

  The prefetch unit 208 acquires necessary data by transmitting a data reference request to the shared DB data management unit 210. The data reference request transmitted by the prefetch unit is different from the data acquisition request transmitted by the data processing unit 206.

  When the use of the acquired data is completed, the prefetching unit 208 transmits a data reference completion report to the shared DB data management unit 210.

  Upon receiving a data acquisition request from the data processing unit 206, the shared DB data management unit 210 sets a lock on the data in the shared buffer 64. Then, the data processor 206 is notified of the start address of the area where the request data is stored. When the request data is not stored in the shared buffer 64, the shared DB data management unit 210 reads the data into the shared buffer 64.

  Further, the shared DB data management unit 210 receives a data use completion report from the data processing unit 206. At this time, the shared DB data management unit 210 acquires information regarding whether or not the data has been updated.

  When the shared DB data management unit 210 receives a lock release instruction from the data processing unit 206, the shared DB data management unit 210 releases the set lock. Then, a lock is given to the process waiting for the lock release.

  When the shared DB data management unit 210 receives a data reference request from the prefetch unit 208, the shared DB data management unit 210 notifies the prefetch unit 208 of the start address of the area where the request data is stored. In this case, the shared DB data management unit 210 does not confirm data lock.

  In addition, the shared DB data management unit 210 receives a data reference completion report from the prefetch unit 206. Also, the shared DB data management unit 210 updates the shared DB data management information 450 as appropriate.

  Hereinafter, a data storage management method of the DBMS 60 in the present embodiment will be described.

  The DBMS 60 manages the storage area by dividing an object into units called “pages”. The object is a table or an index. In the present embodiment, it is assumed that the page size is constant for each file storing the page.

  Files are divided by page size. A page ID is added to each page. The page ID is a unique identifier of a page, and is composed of an identifier of a file in which the page is stored and a serial number in the file. In other words, the file storing the data and the storage location of the data can be uniquely specified by the page ID.

  Similarly, the pointer to the table data in the leaf page in the B-Tree format index is composed of the page ID and the data sequence number in the page.

  The data processing unit 206 and the prefetch unit 208 use data stored in the shared buffer 64. The shared DB data management unit 210 subdivides the area of the shared buffer 64 into fixed-length areas called “blocks” and manages them in units of blocks. Each block is added with a block ID which is a unique identifier of the block. The block ID is, for example, an offset from the beginning of the area of the shared buffer 64 with the block size as a unit. Thereby, the address on the memory 14 can be specified by the block ID.

  The block is divided into a plurality of groups. And the group used for every object is defined. A group ID is added to the group of blocks. The group ID is a unique identifier of the group.

  Each group manages blocks based on the LRU replacement algorithm as described below.

  FIG. 3 is an explanatory diagram of an LRU management list used for block management in the group according to the first embodiment of this invention.

  The LRU management list of this embodiment is divided into an upper LRU management list 642 and a lower LRU management list 644.

  The upper LRU management list 642 is an LRU management list used in a general LRU replacement algorithm. The upper LRU management list 642 uses an area on the MRU (Most Recently Used) end side.

  The lower LRU management list 644 uses an LRU (Least Recently Used) end area.

  When a block for storing a page requested by a data acquisition request from the data processing unit 206 or a data reference request from the prefetch unit 208 exists in the shared buffer 64, the shared DB data management unit 210 uses the block. To do. On the other hand, when the block storing the requested page does not exist in the shared buffer 64, the shared DB data management unit 210 adds the requested page to the block managed by the entry connected to the LRU end of the lower LRU management list 644. Newly memorize.

  When the shared DB data management unit 210 receives a data acquisition request from the data processing unit 206, the shared DB data management unit 210 reconnects the management information of the block storing the requested page to the MRU end of the upper LRU management list 642.

  On the other hand, when the shared DB data management unit 210 receives a data reference request from the prefetch unit 208, the shared DB data management unit 210 performs the following processing. First, the shared DB data management unit 210 determines whether the management information of the block storing the request page exists in the upper LRU management list 642 or the lower LRU management list 644. Note that the shared DB data management unit 210 determines that the management information of the block storing the requested page exists in the lower LRU management list 644 when the management information of the block storing the request page does not exist in either the upper LRU management list 642 or the lower LRU management list 644. .

  When the management information exists in the upper LRU management list 642, the shared DB data management unit 210 does not change the LRU management list. On the other hand, when the management information exists in the lower LRU management list 644, the shared DB data management unit 210 reconnects the management information of the block storing the request page to the MRU end of the lower LRU management list 644.

  As a result, the shared DB data management unit 210 prevents the data referenced by the prefetch unit 208 from being excessively stored in the shared buffer 64.

  Next, an outline of the query plan and the prefetch process will be described.

  FIG. 4 is an explanatory diagram of a query plan in the DBMS 60 according to the first embodiment of this invention.

  The client processing unit 202 receives the query 622 from the AP program 70. Then, a query plan 624 having a tree structure is created from the received query 622.

  The query plan 624 includes nodes 626A to 626I and branches. Nodes 626A-626I indicate processing steps in the query plan 624. The branches indicate processing step and data dependency relationships.

  In each of the nodes 626A to 626I, index reference, table data access by index, table data scan, filter processing, join operation, sort, aggregation operation, set operation, and the like are executed. The filtering process is a process for narrowing the acquired table data by a condition.

  The data processing unit 206 interprets the query plan according to a rule given in advance, and executes processing steps corresponding to the nodes 626A to 626I. In the present embodiment, the data processing unit 206 executes each processing step for each data unit. The data unit is determined by the content of the processing step to be executed. Further, the data processing unit 206 may alternately perform a plurality of processing steps if necessary.

  In the present embodiment, the B-Tree index reference process (node 622A and node 626D) and the table data access process (nodes 626B and 626E) using the index subsequent to that process are prefetched.

  At this time, the prefetching unit 208 uses the search key value of the index based on the search condition included in the query plan, the data value specified by the prefetching request from the data processing unit 206 and / or the data value grasped by the past prefetching process. To figure out. If the search key value of the index can be grasped, the index data and the table data corresponding to the grasped search key value are prefetched.

  FIG. 5A is a configuration diagram of the table definition information 310 included in the schema 300 according to the first embodiment of this invention.

  The table definition information 310 includes an object ID 312 and a table definition 314.

  The object ID 312 is a unique identifier of a table defined in the DB managed by the DBMS 60. The table definition 314 is definition information of the table.

  FIG. 5B is a configuration diagram of the index definition information 320 included in the schema 300 according to the first embodiment of this invention.

  The object management information 330 includes an object ID 322 and an index definition 324.

  The object ID 322 is a unique identifier of an index defined in the DB managed by the DBMS 60. The index definition 324 is definition information of the index.

  FIG. 5C is a configuration diagram of the object management information 330 included in the schema 300 according to the first embodiment of this invention.

  The object management information 330 includes an object ID 332, a group ID 334, a corresponding page ID 338, and an index root page ID 342.

  The object ID 332 is a unique identifier of the object. The group ID 334 is a unique identifier of the group to which the block storing the object belongs. The corresponding page ID 338 is a unique identifier of a page storing the object.

  The index root page 342 is a unique identifier of a page that stores the root data of the object. The index route page 342 stores a value only when the object is a B-Tree format index.

  FIG. 5D is a configuration diagram of the file management information 350 included in the schema 300 according to the first embodiment of this invention.

  The file management information 350 includes a file ID 352, a page size 354, a page number 356, and a file path 358.

  The file ID 352 is an identifier that uniquely identifies the file by the DBMS 60. The page size 354 is the size of a page stored in the file. The page number 356 is the number of pages stored in the file. The file path 358 is an identifier for uniquely identifying the file by the OS 52.

  FIG. 6A is a configuration diagram of the query management information 410 included in the processing management information 400 according to the first embodiment of this invention.

  The query management information 410 includes a query ID 412, a transaction ID 414, a processing priority 416, a processing status 418, a target resource 422, and a query plan 424.

  The query ID 412 is a unique identifier of the query. In this explanatory diagram, the query ID 412 is composed of a client ID and a serial number added to the query by the AP program. The client ID is an identifier that uniquely identifies the AP program 70 by the DBMS 60.

  The transaction ID 414 is an identifier of a transaction to which the query belongs. The processing priority 416 indicates the priority of processing when executing the query.

  The processing status 418 indicates the current execution state of the query.

  When “waiting for lock setting” is stored in the processing status 418, a value is stored in the target resource 422. The target resource 422 indicates a resource that is a target of waiting for lock setting.

  The query plan 424 indicates a query plan corresponding to the query.

  FIG. 6B is a configuration diagram of the transaction management information 430 included in the processing management information 400 according to the first embodiment of this invention.

  The transaction management information 430 includes a client ID 432 and a transaction ID 434.

  The client ID 432 is a unique identifier of the AP program 70. The transaction ID 434 is a unique identifier of a transaction based on a query from the AP program 70. Note that a value is stored in the transaction ID 434 only when a transaction is in progress. Therefore, if no transaction is in progress, no value is stored in the transaction ID 434.

  FIG. 7 is a configuration diagram of the query plan 600 included in the processing management information 400 according to the first embodiment of this invention.

  The query plan 600 includes a process start step ID 602, a process end step ID 604, a step ID 606, a parent step ID 608, a child step ID 612, a process type 614, and process details 616.

  The process start step ID 602 is a unique identifier of the process step executed first in the query plan. The process end step ID 604 is a unique identifier of the process step executed last in the query plan.

  Step ID 606 is a unique identifier of the processing step.

  The parent step ID 608 is an identifier of the parent step of the processing step. The parent step is a processing step that uses the processing result of the processing step (child step). The child step ID 612 is an identifier of the child step of the processing step.

  The process type 614 indicates the content of the process executed in the process step.

  The processing details 616 indicate details of processing executed in the processing step. When “index reference” is stored in the process type 614, the process details 616 stores the object ID of the index to be referenced and the index reference condition. When “table data access by index” is stored in the process type 614, the object ID of the access destination table is stored in the process details 616. When “nested loop join” is stored in the process type 614, the process details 616 stores a join condition.

  FIG. 8A is a configuration diagram of the shared buffer definition information 451 included in the shared DB data management information 450 according to the first embodiment of this invention.

  The shared buffer definition information 451 includes buffer area information 452 and a buffer block size 454.

  The buffer area information 452 is information regarding the storage area of the shared buffer 64 on the memory 14. The buffer area information 452 includes the start address of the shared buffer 64 and the size of the shared buffer 64. The buffer block size 454 is the size of the block in the shared buffer 64.

  FIG. 8B is a configuration diagram of the buffer block management information 460 included in the shared DB data management information 450 according to the first embodiment of this invention.

  The buffer block management information 460 includes a block ID 462, a page ID 463, a state 464, link information 466, a usage count 468, and a prefetching correspondence query ID 469.

  The block ID 462 is a unique identifier of the block. The page ID 463 is a unique identifier of the page currently stored in the block.

  A state 464 is a state of data stored in the block. For example, when the data stored in the block matches the data stored in the storage device 46, “Clean” is stored in the state 464. If the data stored in the block does not match the data stored in the storage device 46, “Dirty” is stored in the state 464. When data is being read from the storage device 46 to the block, “Reading” is stored in the state 464. If no valid data is stored in the block, “Invalid” is stored in the state 464.

  The link information 466 includes a management list and a pointer. The management list is a unique identifier of the management list to which the block belongs. The pointer indicates the position of the block in the management list. For example, the pointer is a unique identifier of a block located immediately before and after the block in the management list.

  The usage number 468 is the number of processes using the page stored in the block.

  The prefetch correspondence query ID 469 is a unique identifier of a query corresponding to the prefetch processing regarding the data stored in the block. Note that the pre-read query ID 469 stores a value only when the data stored in the block is read by the pre-read process.

  FIG. 8C is a configuration diagram of the buffer group management information 470 included in the shared DB data management information 450 according to the first embodiment of this invention.

  The buffer group management information 470 includes a group ID 472, upper LRU management list information 474, and lower LRU management list information 476.

  The group ID 472 is a unique identifier of the group to which the block belongs.

  The upper LRU management list information 474 is information for managing the upper LRU management list 642 corresponding to the group. The upper LRU management list information 474 includes the number of blocks, a head block ID, and a terminal block ID. The number of blocks is the number of blocks belonging to the upper LRU management list 642 corresponding to the group. The head block ID is a unique identifier of a block located at the head of the upper LRU management management list 642 among the blocks belonging to the group. The terminal block ID is a unique identifier of a block located at the terminal of the upper LRU management management list 642 among the blocks belonging to the group.

  The lower LRU management list information 476 is information for managing the lower LRU management list 644 corresponding to the group. The lower LRU management list information 476 includes the number of blocks, a head block ID, and a terminal block ID. The number of blocks is the number of blocks belonging to the lower LRU management list 644 corresponding to the group. The head block ID is a unique identifier of a block located at the head of the lower LRU management management list 644 among the blocks belonging to the group. The terminal block ID is a unique identifier of a block located at the terminal of the lower LRU management management list 644 among the blocks belonging to the group.

  FIG. 8D is a configuration diagram of the lock management information 480 included in the shared DB data management information 450 according to the first embodiment of this invention.

  The lock management information 480 includes a page ID 482, a lock type 484, a lock acquisition transaction ID 486, and a lock wait list 488.

  The page ID 482 is a unique identifier of a page to be locked. The lock type 484 is a type of lock set for the page. Specifically, the lock type 484 stores “shared” indicating a shared lock, “exclusive” indicating an exclusive lock, and the like.

  The lock acquisition transaction ID 486 is a unique identifier of a transaction that acquires a lock for the page.

  The lock waiting list 488 stores a query ID and a lock type. The query ID is a unique identifier of a query waiting for lock release. The lock type is a lock type set by the query. When the query does not set a lock, “no lock” is stored as the lock type. When a plurality of queries are waiting for lock release, the lock wait list 488 stores the same number of query IDs and lock types as the number of queries waiting for lock release.

  In this embodiment, locks are managed in units of pages, but may be managed in other granularities.

  FIG. 8E is a configuration diagram of I / O wait management information 490 included in the shared DB data management information 450 according to the first embodiment of this invention.

  The I / O wait management information 490 includes a block ID 492 and an I / O wait list 494.

  The block ID 492 is a unique identifier of the block in the I / O.

  The I / O waiting list 494 is an identifier of a process waiting for completion of I / O of the block. Specifically, the I / O waiting list 494 stores a query ID or an identifier for prefetch processing. When there are a plurality of processes waiting for I / O completion of the block, the same number of identifiers as the number of processes waiting for completion are stored in the I / O wait list 494.

  FIG. 9A is a configuration diagram of the total prefetch number management information 501 included in the prefetch processing information 500 according to the first embodiment of this invention.

  The total prefetch number management information 501 includes a total prefetch thread number 502 and a total prefetch block number 504.

  The total prefetch thread number 502 is information for managing the total number of threads used in the prefetch process. The total prefetch thread number 502 includes a maximum value and an assigned value. The maximum value is the upper limit of the total number of threads that can be used in the prefetch process. The number of allocations is the total number of threads currently allocated to the prefetch process.

  The total prefetch block number 504 is information for managing the number of blocks that hold the page read by the prefetch process. The total number of read blocks 504 includes a maximum value and an assigned value. The maximum value is the upper limit of the number of blocks that hold a page read by the prefetch process. The assigned value is the total number of blocks currently assigned to the prefetch process.

  FIG. 9B is a configuration diagram of prefetch management information 510 included in the prefetch processing information 500 according to the first embodiment of this invention.

  The prefetch management information 510 includes a query ID 512, a prefetch thread number 514, a prefetch block number 516, an execution confirmation value 518, I / O issue interval management information 522, a data processing prefetch request creation setting 526, and a page number statistic 528.

  The query ID 512 is a unique identifier of a query that is a target of the prefetch process.

  The prefetch thread number 514 includes the maximum thread number and the current use thread number. The maximum number of threads is the total number of threads assigned to the prefetch process corresponding to the query. The number of currently used threads is the total number of threads currently used in the prefetch process corresponding to the query.

  The number of prefetch blocks 516 includes the maximum number of blocks and the number of prefetched blocks. The maximum number of blocks is the total number of blocks allocated to the prefetch process corresponding to the query. The number of prefetched blocks is the total number of blocks that hold pages actually prefetched in the prefetch processing corresponding to the query.

  The execution confirmation value 518 is a value used for execution control of the prefetch process corresponding to the query. The execution confirmation value 518 will be described later.

  The I / O issuance interval management information 522 is management information used in control for setting the I / O issuance interval for prefetch processing in processing with low priority to a certain value or more. The I / O issue interval management information 522 includes a set lower limit value and a time stamp. The set lower limit value is a lower limit value of the set I / O issue interval. The time stamp is the time when the latest I / O is issued by the prefetch process corresponding to the query.

  The data processing prefetch request setting 526 is information relating to a prefetch request created while the data processing unit 206 is processing the query. The data processing prefetch request setting 526 includes creation necessity information, a step ID, and a reference condition.

  The creation necessity information indicates whether the data processing unit 206 creates a prefetch request. Specifically, when the data processing unit 206 creates a prefetch request, “Yes” is stored in the creation necessity information. When the data processing unit 206 does not create a prefetch request, “No” is stored in the creation necessity information. In addition, when the data processing unit 206 is currently interrupting creation of the prefetch request, “Stop” is stored in the creation necessity information.

  The step ID is a unique identifier of a processing step in which the data processing unit 206 creates a prefetch request. Only when the creation necessity information is “Yes” or “Stop”, values are stored in the step ID and the reference condition.

  The page number statistic 528 is a statistic value for determining the effect of prefetching corresponding to the query. The page number statistic 528 includes the number of processing uses and the number of prefetch hits. The number of processing uses is the total number of data acquisition requests issued in response to the query. The number of hits is the number of times the data requested by the data acquisition request issued corresponding to the query hits the prefetched data.

  FIG. 9C is a configuration diagram of the prefetch request management information 540 included in the prefetch processing information 500 according to the first embodiment of this invention.

  The prefetch request management information 540 includes a query ID 541, a step ID 543, an execution confirmation value 545, a page ID 549, an in-page offset 542, a reference condition 544, a list pointer 548, and waiting list management information 552.

  The prefetch request management information 540 is a unique identifier of a query corresponding to a thread that executes processing for issuing prefetch I / O. The step ID 543 is a unique identifier of the processing step corresponding to the query.

  The execution confirmation value 545 is a value used for execution control of the prefetch process corresponding to the query.

  The page ID 549 is a page unique identifier. When table data is stored in the page, a value is stored in the in-page data ID 549. The in-page data ID 549 is a unique identifier of data to be prefetched in the page.

  The reference condition 544 stores a known index search condition in the prefetch process further executed from the prefetch process and the table data acquired as a result.

  The list pointer 548 stores a pointer to an entry located immediately before and after the entry.

  The waiting list management information 552 stores pointers to the first entry and the last entry that are in a process execution waiting state.

  When a new entry is added to the prefetch request management information 540, the entry is connected to the end of the waiting list.

  Hereinafter, the processing of the present embodiment will be described.

  FIG. 10 is a flow chart for query processing of the DBMS 60 according to the first embodiment of this invention.

  When the DBMS 60 receives a query from the AP program 70, the DBMS 60 starts query processing (1101).

  When receiving the query, the client processing unit 202 grasps the client ID of the AP program 70 that is the transmission source of the query. Further, the client processing unit 202 acquires the processing priority of the query from the AP program 70 simultaneously with the reception of the query. If the processing priority cannot be acquired, the client processing unit 202 treats the processing priority as a preset processing priority. The processing priority may be given as a hint during the query.

  Next, the client processing unit 202 creates a query plan 600 based on the received query (1102). Also, by referring to the transaction management information 430, it is confirmed whether or not a transaction ID 434 corresponding to the acquired client ID is set.

  If the transaction ID 434 is not set, a new transaction ID is set.

  Next, the client processing unit 202 creates a new entry in the query management information 410. At this time, the grasped client ID and the serial number added to the received query are set as the query ID. Next, the query ID is stored in the query ID 412 of the new entry. Next, an entry in which the grasped client ID matches the client ID 434 of the transaction management information 430 is selected from the transaction management information 430. Next, the transaction ID 434 is extracted from the selected entry. Next, the extracted transaction ID 434 is stored in the transaction ID 414 of the new entry.

  Next, the processing priority acquired from the AP program 70 is stored in the processing priority 416 of the new entry. Next, “being executed” is stored in the process execution status 418 of the new entry. Next, an invalid value is stored in the target resource 422 of the new entry.

  Next, the client processing unit 202 transmits a query processing execution request to the execution management unit 204. The query process execution request includes the query ID stored in the new entry.

  When receiving the query processing execution request, the execution management unit 204 performs prefetch management information setting processing (1103). Details of the prefetch management information setting process will be described with reference to FIG.

  The execution management unit 204 determines whether or not the prefetch process management loop process is in a sleep state when a new entry is added to the prefetch request management information 540 in the prefetch management information setting process. If it is in the sleep state, a prefetch processing management loop process is caused. Details of the prefetch processing management loop processing will be described with reference to FIG.

  Next, the execution management unit 204 notifies the data processing unit 206 of the query ID included in the received query processing execution request, and requests execution of the query corresponding to the query ID.

  When requested to execute the query, the data processing unit 206 executes data processing (1104). Details of the data processing will be described with reference to FIG.

  When the data processing unit 206 completes the data processing, it checks the state of the transaction. Specifically, it is confirmed whether or not commit and rollback have been executed.

  When the commit and rollback are executed, the data processing unit 206 determines that the transaction is completed and executes the following processing.

  First, the data processing unit 206 grasps the transaction ID 414 by referring to the query management information 410. Next, the data processing unit 206 transmits a lock release request acquired by the transaction corresponding to the grasped transaction ID 414 to the shared DB data management unit 210. Note that the lock release request includes the transaction ID 414 recognized by the data processing unit 206.

  When the shared DB data management unit 210 receives the lock release request, it releases the lock (1105). Specifically, all entries (target entries) in which the transaction ID included in the lock release request matches the lock acquisition transaction ID 486 of the lock management information 480 are grasped from the lock management information 480.

  Next, the first value is extracted from the lock wait list 488 of each target entry. Next, a query corresponding to the query ID included in the extracted value is set as a query for acquiring a lock next. Based on the extracted value, the lock type 484 and the lock acquisition transaction ID 486 of the target entry are set.

  Thereafter, the next query for acquiring the lock is resumed. At this time, an entry corresponding to the resumed query is selected from the query management information 410. Next, “executing” is stored in the processing status 418 of the selected entry. Next, an invalid value is stored in the selected target resource 422.

  If no value is stored in the lock waiting list 488 of the target entry, the entry is deleted from the lock management information 480.

  The data processing unit 206 sends the query ID and processing result of the query to be processed to the client processing unit 202.

  Then, the client processing unit 202 transmits the received processing result to the AP program 70 (1106).

  Next, the client processing unit 202 deletes, from the query management information 410, an entry in which the query ID of the query that has been processed matches the query ID 412 of the query management information 410.

  When the transaction is completed due to the completion of the query processing, an entry in which the client ID of the AP program 70 matches the client ID 432 of the transaction management information 430 is selected from the transaction management information 430. Next, an invalid value is stored in the transaction ID 434 of the selected entry.

  Next, the client processing unit 202 transmits a query completion report to the execution management unit 204. The query completion report includes the query ID of the query that has been processed.

  Then, the execution management unit 204 deletes an entry in which the query ID included in the received end report and the query ID 512 of the prefetch management information 510 match from the prefetch management information 510 (1107).

  Then, the query process ends (1108).

  FIG. 11 is a flowchart of the prefetch management information setting process of the execution management unit 204 according to the first embodiment of this invention.

  The prefetch management information setting process is executed in step 1103 of the query process (FIG. 10).

  When receiving the query process execution request, the execution management unit 204 starts a prefetch management information setting process (2101). The query process execution request includes the query ID stored in the new entry.

  First, prefetch management information is initialized (2102). An entry in which the query ID included in the received query processing execution request matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, the processing priority 416 of the designated query is grasped by extracting the processing priority 416 from the selected entry.

  Next, a new entry is added to the prefetch management information 510. Next, the query ID included in the received query processing execution request is stored in the query ID 512 of the new entry.

  Next, a specified value determined from the extracted processing priority 416 is stored in the maximum number of threads of the prefetch thread number 514. Next, an initial value is stored in the number of currently used threads of the number of prefetch threads 514.

  Next, a specified value determined from the extracted processing priority 416 is stored in the maximum number of blocks of the number of prefetch blocks 516. Next, the initial value is stored in the number of currently used blocks of the number 516 of prefetch blocks.

  Next, the random value is stored in the execution confirmation value 518 of the new entry. Next, the specified value determined from the extracted processing priority 416 is stored in the set lower limit value of the I / O issue interval management information 522. In addition, an invalid value is stored in the time stamp of the I / O issue interval management information 522.

  Next, the initial value is stored in the page number statistics 528.

  Then, in response to the new allocation, the allocation value of the total prefetch thread number 502 and the allocation value of the total prefetch block number 504 are updated. At this time, if the updated allocation value exceeds the maximum value, correction processing is executed (2103).

  Specifically, the processing priority 416 of the query management information 410 is referred to, and the query ID 412 of a query having a processing priority 416 lower than the processing target query is grasped. Next, an entry in which the grasped query ID 412 matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, a predetermined value is subtracted from the maximum value of the prefetch thread number 514 and the maximum value of the prefetch block number 516 of the selected entry.

  Next, the allocation value of the total prefetch thread number 502 and the allocation value of the total prefetch block number 504 are updated. Then, this correction process is repeated until the updated assigned value falls below the maximum value.

  Next, the query plan is grasped by referring to the query management information 410. Next, a processing step for performing an index reference process is selected from the query plan processing steps. Next, from the selected processing step, a processing step whose index reference condition values are all known is grasped (2104). If even one such processing step is grasped, the process proceeds to step 2105. On the other hand, if none can be grasped, the process proceeds to step 2107 as it is.

  Next, using the grasped process steps as starting points, the process steps that can be continuously read ahead are grasped and grouped (2105).

  Here, the processing steps that can be prefetched continuously are processing steps that can be executed based on the table, index data, or setting values in the query plan acquired after the processing step grasped here. In the processing step, an index reference process, a table data access process, a filter process, or a nested loop join operation process is executed.

  Next, in order to start the prefetch process, an entry is secured in the prefetch request management information 540 for each group. Then, a value is set in the secured entry (2106).

  Specifically, the query ID included in the received query processing execution request is stored in the query ID 541 of the secured entry. Next, the step ID of the processing step executed first in the group is stored in the step ID 543 of the secured entry. Next, the value stored in the execution confirmation value 518 of the prefetch management information 510 in step 2102 is stored in the execution confirmation value 545 of the secured entry.

  Next, information regarding the reference condition value of the index reference process executed in the group is stored in the reference condition 544 of the secured entry. When the reference condition value is known, the known value is stored in the reference condition 544, and when the reference condition value is unknown, information regarding which attribute of which table the value is acquired from is referred to as the reference condition. Stored in 544.

  Next, a processing step for executing an index reference process that does not belong to the group set in step 2105 is grasped (2107). In step 2104, if no processing steps with known index reference condition values are known, all the processing steps do not belong to the group.

  Then, it is determined whether or not there is a processing step for executing an index reference process that does not belong to the group. If the processing step exists, the process proceeds to step 2108. On the other hand, if the processing step does not exist, the process proceeds to step 2121.

  Next, “Yes” is stored in the necessity of creation of the data processing creation request creation setting 526 of the prefetch management information 510 (2108).

  Next, as in step 2105, the process steps that can be prefetched continuously from the grasped process steps are grasped and grouped (2109). Note that the processing steps that already belong to the group created in step 2105 are treated as processing steps that cannot be prefetched here.

  Next, for each group, the processing step to be executed first is specified. Next, the step ID of the identified processing step is stored in the step ID of the data processing prefetch request creation setting 526 of the prefetch management information 510.

  Next, similarly to step 2106, information related to the reference condition value of the index reference process executed in the group is stored in the reference condition of the data processing prefetch request creation setting 526 of the prefetch management information 510 (2110). If the reference condition value is known, the known value is stored in the reference condition of the data processing prefetch request creation setting 526. If the reference condition value is unknown, the value is acquired from which attribute of which table. Is stored in the reference condition of the data processing prefetch request creation setting 526. Then, the prefetch management information setting process ends (2111).

  On the other hand, if it is determined that there is no processing step for executing the index reference processing that does not belong to the group, “No” is stored in the necessity of creation of the data processing creation request creation setting 526 of the prefetch management information 510 (2121). Then, the execution management unit 204 ends the prefetch management information setting process (2111).

  FIG. 12 is a flowchart of data processing of the data processing unit 206 according to the first embodiment of this invention.

  The data processing is executed in step 1104 of the query processing (FIG. 10).

  First, when receiving a query execution request, the data processing unit 206 starts data processing (2401). The query execution request includes the query ID of the query that requests execution.

  Next, an entry in which the query ID included in the received execution request matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, by extracting the query plan 424 from the selected entry, the query plan 600 corresponding to the query to be executed is grasped (2402).

  Next, the process start step ID 602 is extracted from the grasped query plan 600. Thereby, the processing step to be processed first is confirmed (2403). In the first process, the head portion of the data handled in the processing step is processed.

  Next, data to be processed in the confirmed processing step is acquired. When the table or index data is directly used in the processing step, a data acquisition request is transmitted to the shared DB data management unit 210. The data acquisition request includes a page ID, a lock type, a query ID, and a transaction ID. The page ID is a unique identifier of a page having data for which acquisition is requested. The lock type is a type of lock set for the page. The query ID is a unique identifier of a query that requires data for which acquisition is requested. The transaction ID is a unique identifier of the transaction to which the query belongs.

  When the shared DB data management unit 210 receives the data acquisition request, the shared DB data management unit 210 executes data acquisition request processing (2404). Details of the data acquisition request processing will be described with reference to FIG.

  The data processing unit 206 acquires data from the shared DB data management unit 210. Next, a processing step is executed on the acquired data (2405).

  Then, the data use completion report is transmitted to the shared DB data management unit 210. The data use completion report includes a page ID and update information. The page ID is an identifier of a page having the table or index data acquired in step 2404. The update information indicates whether or not the page corresponding to the page ID has been updated.

  When the shared DB data management unit 210 receives the data use completion report, the shared DB data management unit 210 executes data use completion processing (2406).

  Specifically, an entry in which the page ID included in the received data use completion report matches the page ID 463 of the buffer block management information 460 is selected from the buffer block management information 460. Next, the usage number 468 of the selected entry is decreased. Next, when the page is updated, “Dirty” is stored in the state 464 of the selected entry (2406).

  The data processing unit 206 confirms the next processing step to be executed (2407). Specifically, the processing step to be executed next is determined based on the interpretation of the query plan according to the rule given in advance and the processing result of step 2405.

  If there is no processing step to be executed next, it is determined that all the processing steps have been completed, and the data processing is terminated (2409).

  On the other hand, when the same processing step is executed for subsequent data, the process returns to step 2404.

  When different processing steps are executed for subsequent data, a prefetch request setting process is executed (2408). Details of the prefetch request setting process will be described with reference to FIG. Then, the process returns to step 2404.

  FIG. 13 is a flowchart of the prefetch request setting process of the data processing unit 206 according to the first embodiment of this invention.

  The prefetch request setting process is executed in step 2408 of the data process (FIG. 12).

  First, the data processing unit 206 is given a query ID of a query being executed and a step ID of a processing step to be executed next in the query plan 600, and starts a prefetch request setting process (2201).

  Then, it is determined whether or not an entry in which the given query ID matches the query ID 512 of the prefetch management information 510 exists in the prefetch management information 510.

  If the entry exists in the prefetch management information 510, the data processing prefetch request creation setting 526 is extracted from the entry. Next, it is determined whether “Yes” is stored in the necessity of creation of the extracted data processing prefetch request creation setting 526. If “Yes” is stored, it is determined whether or not the step ID given at the start of the process is stored in the step ID of the extracted data processing prefetch request creation setting 526. Thus, it is determined whether or not setting of a prefetch request is necessary (2202).

  If “Yes” is not stored in the necessity of creation of the extracted data processing prefetch request creation setting 526, or if the step ID given at the start of processing is not stored in the data processing prefetch request creation setting 526, prefetching is performed. It is determined that the request setting is unnecessary, and the prefetch request setting process is terminated as it is (2207).

  When the step ID given at the start of processing is stored in the data processing prefetch request creation setting 526, it is determined that the prefetch request needs to be set.

  Therefore, a new entry is added to the prefetch request management information 540. Next, the query ID given at the start of processing is stored in the query ID 541 of the new entry. Next, the step ID given at the start of processing is stored in the step ID 543 of the new entry.

  Next, an entry in which the query ID given at the start of processing matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, an execution confirmation value 518 is extracted from the selected entry. Next, the extracted execution confirmation value 518 is stored in the execution confirmation value 545 of the prefetch request 540 (2203).

  Next, an entry in which the query ID given at the start of processing matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, the reference condition of the data processing prefetch request creation setting 526 is extracted from the selected entry. Next, the reference condition 544 of the new entry is stored as the extracted reference condition. In the stored reference condition 544, regarding the part whose value is unknown, the value is set for the part in which the value of the attribute of the corresponding table becomes known in the processing so far. Thereby, the reference condition 544 is set (2204).

  Next, an entry in which the query ID given at the start of processing matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, the query plan 600 is specified by extracting the query plan 424 from the selected entry. Next, an entry in which the step ID given at the start of the process and the step ID 606 of the identified query plan 600 match is selected from the query plan 600.

  Next, the object ID of the index referred to by the index reference process is extracted from the process details 616 of the selected entry. Next, an entry in which the extracted object ID matches the object ID 332 of the object management information 330 is selected from the object management information 330. Next, the index route page ID 342 is extracted from the selected entry. The extracted index root page ID 342 is stored in the page ID 549 of the new entry (2205). When the index root page ID 342 includes a plurality of page IDs, the number of new entries corresponding to the page ID is created in the prefetch request management information 540.

  Next, when the prefetch process management loop process (FIG. 15) is in the sleep state, the prefetch process management loop process is generated (2206).

  Then, the data processing unit 206 ends the prefetch request setting process (2207).

  FIG. 14 is a flow chart for data acquisition request processing of the shared DB data management module 210 according to the first embodiment of this invention.

  When the shared DB data management unit 210 receives a data acquisition request from the data processing unit 206 in step 2404 of the data processing (FIG. 14), the shared DB data management unit 210 starts this processing (1201). The data acquisition request includes a page ID, a lock type, a query ID, and a transaction ID. The page ID is a unique identifier of the page having the required data. The lock type is a lock type to be set for the page. Note that when the lock setting is unnecessary, the data acquisition request does not include the lock type. The query ID is a unique identifier of a query that requires data. The transaction ID is a unique identifier of the transaction to which the query belongs.

  The shared DB data management unit 210 sets the lock of the lock type included in the data acquisition request to the page corresponding to the page ID included in the received data acquisition request (1202). If the lock type is not included in the data acquisition request, this step is not executed.

  Specifically, an entry in which the page ID included in the received data acquisition request matches the page ID 482 of the lock management information 480 is selected from the lock management information 480. Next, the selected entry is grasped as a target entry.

  When the target entry cannot be grasped, no lock is set for the page. Therefore, a new entry is created in the lock management information 480. Next, the page ID included in the data acquisition request is stored in the page ID 482 of the new entry. Next, the lock type included in the data acquisition request is stored in the lock type 484 of the new entry. Next, the transaction ID included in the data acquisition request is stored in the lock acquisition transaction ID 486 of the new entry. Next, the initial value is stored in the lock wait list 488.

  On the other hand, when the target entry can be grasped, it is determined by referring to the lock type 484 and the lock acquisition transaction ID 486 of the target entry whether or not the processing related to the query can be continued.

  If it can continue, processing continues. At this time, if necessary, the lock type 484 is updated and a value is added to the lock acquisition transaction ID 486.

  On the other hand, if it is impossible to continue, the page ID and the lock type included in the data acquisition request are stored at the end of the lock waiting list 488 of the target entry. Then, the query is suspended until the lock is acquired.

  During query interruption, “waiting for lock setting” is stored in the processing status 418 of the query management information 410. Further, the page ID of the page from which the lock is acquired is stored in the target resource 422 of the query management information 410.

  Next, the shared DB data management unit 210 selects, from the buffer block management information 460, an entry in which the page ID included in the received data acquisition request matches the page ID 463 of the buffer block management information 460. Then, the selected entry is grasped as the target block entry. Next, it is determined whether or not the target block entry exists.

  If there is no target block entry, the process proceeds to step 1211.

  On the other hand, if the target block entry exists, it is determined whether or not the status 464 of the target block entry is “Reading” (1203).

  If the state 464 of the target block entry is not “Reading”, the process proceeds to step 1205 as it is. On the other hand, if the state 464 of the target block entry is “Reading”, the process proceeds to step 1204.

  First, an entry in which the block ID 462 of the target block entry matches the block ID 492 of the I / O waiting management information 490 is selected from the I / O waiting management information 490. Next, the query ID included in the received data acquisition request is stored in the selected entry I / O waiting list 494. Then, the query is suspended until the I / O processing is completed (1204).

  Next, the prefetch correspondence query ID 469 is grasped from the target block entry. Next, it is determined whether or not a value is stored in the grasped prefetch query ID 469.

  If a value is stored in the prefetch query ID 469, the data in the target block has been prefetched, so the following processing is performed.

  First, an entry in which the grasped prefetch correspondence query ID 469 matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. If there is an entry to be selected, the number of prefetch blocks 516 of the selected entry is reduced (1205).

  Next, an invalid value is stored in the prefetch correspondence query ID 469 of the corresponding block entry. Further, when the prefetch process management loop process (FIG. 15) is in the sleep state, the prefetch process management loop process is caused.

  Next, the management information of the target block entry is updated (1206). Specifically, by extracting the management list of the link information 466 from the target block entry, the management list to which the block belongs is grasped. Next, it is determined whether the grasped management list is an upper LRU management list or a lower LRU management list.

  If the grasped management list is the upper LRU management list, the target block entry is inserted at the MRU end of the upper LRU management list.

  On the other hand, if the grasped management list is the lower LRU management list, the entry existing at the LRU end (end) of the insertion destination upper LRU management list is inserted together with the insertion of the target block entry similar to the above, and the MRU of the management list Reconnect to the edge. This process is realized by referring to and updating the buffer block management information 460 and the buffer group management information 470. Next, the usage number 468 of the target block entry is increased.

  Next, the page number statistics 528 of the prefetch management information 510 is updated (1207). Specifically, an entry in which the query ID included in the received data acquisition request matches the query ID 512 of the management information 510 is selected from the prefetch management information 510. Next, the processing usage number of the page number statistics 528 of the selected entry is increased. If it is determined in step 1205 that the data is “prefetched”, the number of prefetch hits in the page number statistics 528 of the selected entry is increased.

  Next, based on the block ID 462, the buffer area information 452, and the buffer block size 454 of the target block entry, the head address of the block holding the target data is calculated. Then, the calculated head address is transmitted to the data processing unit 206. Then, the data acquisition request processing is terminated (1208).

  On the other hand, if it is determined in step 1203 that the target block entry does not exist, an entry including the page ID included in the received data acquisition request in the corresponding page ID 338 of the object management information 330 is selected from the object management information 330. Next, the group ID 334 is extracted from the selected entry.

  Next, an entry in which the extracted group ID 334 matches the group ID 472 of the buffer group management information 470 is selected from the buffer group management information 470. Next, the lower LRU management list information 476 is extracted from the selected entry. Next, by referring to the extracted lower LRU management list information 476, the block managed by the entry existing at the LRU end of the lower LRU management list is grasped. Next, the grasped block is set as a replacement target block (replacement block) (1211). Then, the target data is held in the replacement block.

  Next, an entry in which the block ID of the replacement block matches the block ID 462 of the buffer block management information 460 is selected from the buffer block management information 460. Next, the selected entry is set as a target block entry.

  Next, it is determined whether or not the usage number 468 of the target block entry is “0”. When the usage number 468 of the target block entry is not “0”, the process waits until the usage number 468 becomes “0”. Then, the target block entry is removed from the lower LRU management list.

  Next, it is determined whether or not the state 464 of the target block entry is “Dirty”. If the state 464 of the target block entry is “Dirty”, the data stored in the replacement block is written to the file (1212). Note that the storage location on the file is written in a storage location that can be grasped from the page ID and the file management information 350.

  When the file writing process is started, a new entry is added to the I / O waiting management information 490. Next, the block ID 462 of the target block entry is stored in the block ID 492 of the new entry. Next, the query ID included in the received data acquisition request is added to the I / O waiting list 494 of the new entry. When the file writing process is completed, the new entry added to the I / O waiting management information 490 is deleted.

  Next, the shared DB data management unit 210 executes the same processing as in step 1205 and step 1206.

  Next, the page ID included in the received data acquisition request is stored in the page ID 463 of the target block entry. Next, an invalid value is stored in the prefetch correspondence query ID 469 of the target block entry.

  Next, “Reading” is stored in the state 464 of the target block entry.

  Next, a new entry is added to the I / O waiting management information 490. Next, the block ID 462 of the target block entry is stored in the block ID 492 of the new entry. Next, the query ID included in the received data acquisition request is added to the I / O waiting list 494 of the new entry.

  Then, the page data corresponding to the page ID included in the received data acquisition request is read from the file (1215). The storage location on the file is read from the storage location that can be grasped from the page ID and the file management information 350.

  When the reading is completed, the corresponding entry of the I / O waiting management information 490 is referred to. If a value other than the query ID included in the data acquisition request is stored in the I / O waiting list 494 of the referenced entry, a query processing resumption is instructed.

  Then, the corresponding entry is deleted from the I / O waiting management information 490. Then, the process proceeds to Step 1207.

  FIG. 15 is a flowchart of the prefetch processing management loop process of the prefetch unit 208 according to the first embodiment of this invention.

  In the initialization process or the like when the DBMS 60 is activated, the prefetch unit 208 starts this process (1401). Further, the prefetch unit 208 executes this processing independently even while the DBMS 60 is being executed.

  The prefetch unit 208 interrupts (sleeps) the processing for a certain period of time. The certain time is, for example, about 10 milliseconds. When an event occurs, a prefetch processing management loop process is triggered. The occurrence of an event is, for example, when a new entry is added to the prefetch request management information 540, when the prefetch real processing thread is terminated, or when prefetched data is used.

  Next, by referring to the waiting list management information 552 of the prefetch request management information 540, the entry located at the head in the wait list of the prefetch request management information 540 is grasped. The grasped entry is set as a processing target entry (1403).

  Next, it is determined whether or not the processing target entry has been set (1404). If the process target entry cannot be set, the process returns to step 1402.

  On the other hand, when the processing target entry can be set, the entry positioned next to the processing target entry is grasped (1405).

  Next, the query ID 541 is extracted from the processing target entry. Next, an entry in which the extracted query ID 541 matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, the selected entry is grasped as a process management entry.

  It is determined whether the execution confirmation value 545 of the processing target entry matches the execution confirmation value 518 in the process management entry (1406). If the execution confirmation values do not match, the process proceeds to step 1421.

  On the other hand, when the execution confirmation values match, the number of prefetch threads 514 in the process management entry is referred to. Then, it is determined whether or not the currently used thread number of the referenced prefetch thread number 514 is less than the maximum thread number of the prefetch thread number 514 (1407). If the number of currently used threads is equal to or greater than the maximum number of threads, the process proceeds directly to step 1411.

  On the other hand, if the number of currently used threads is less than the maximum number of threads, the number of prefetch blocks 516 in the process management entry is referred to. Then, it is determined whether or not the number of prefetched blocks of the referenced prefetch block number 516 is less than the maximum number of prefetched block numbers 516 (1408). If the number of pre-read blocks is equal to or greater than the maximum number of blocks, the process proceeds directly to step 1411.

  On the other hand, if the number of prefetched blocks is less than the maximum number of blocks, the current use of the prefetch thread number 514 of the process management entry is increased. Then, the prefetch real processing thread is activated by designating the processing target entry (1409). Details of the prefetch actual processing thread will be described with reference to FIG. Further, the prefetch unit 208 can simultaneously execute a plurality of prefetch real processing threads.

  Next, the processing target entry is removed from the waiting list management information 552 of the prefetch request management information 540 (1410).

  Next, the entry grasped in step 1405 is set as a processing target entry (1411). Then, the process returns to step 1404.

  On the other hand, if the execution confirmation values do not match in step 1406, the processing target entry is removed from the waiting list management information 552 of the prefetch request management information 540. Next, the processing target entry is deleted from the prefetch request management information 540 (1421). Then, the process proceeds to Step 1411.

  FIG. 16 is a flowchart of the prefetching real processing thread of the prefetching unit 208 according to the first embodiment of this invention.

  The prefetch actual processing thread is executed in step 1409 of the prefetch processing management loop processing (FIG. 15).

  When the prefetching unit 208 starts the prefetching process management loop process (2301), a process entry (an entry of the prefetching request management information 540) including information related to the prefetching process to be executed is designated.

  First, the prefetch unit 208 transmits a data reference request including the page ID 549 of the process entry to the shared DB data management unit 210.

  When the shared DB data management unit 210 receives the data reference request, the shared DB data management unit 210 executes a data reference request process (2302). Details of the data reference request processing will be described later with reference to FIG.

  The prefetch unit 208 waits for completion of the data reference request processing of the shared DB data management unit 210. Then, an entry in which the query ID 541 of the process entry matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, the selected entry is grasped as a management entry.

  Next, it is determined whether or not the execution confirmation value 545 of the processing entry matches the execution confirmation value 518 of the management entry (2303). If the execution confirmation values do not match, the process proceeds to step 2321.

  On the other hand, if the execution confirmation values match, it is determined whether or not the data stored in the designated page is an index. If the data is not an index, the process proceeds to step 2311.

  On the other hand, if the data is an index, the query ID 541 and the step ID 543 are extracted from the processing entry. Next, an entry in which the extracted query ID 541 matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, the reference condition of the index is grasped by referring to the query plan 424 of the selected entry (2305).

  Next, it is determined whether or not the grasped reference condition has a pointer to the table data. As a result, it is determined whether or not the designated page is an index leaf page (2306).

  If the designated page is not an index leaf page, the process advances to step 2308.

  On the other hand, if the designated page is an index leaf page, a prefetch request to the table page corresponding to the reference condition is created (2307). Specifically, the specified page is analyzed. Thus, the pointer to the table data corresponding to the index reference condition grasped in step 2305 is grasped.

  Next, a new entry is added to the prefetch request management information 540 in order to acquire a page storing the data. Next, the query ID 512 of the process entry is stored in the query ID 541 of the new entry. Next, the execution confirmation value 518 of the process entry is stored in the execution confirmation value 545 of the new entry. Next, the value grasped from the pointer to the table data acquired by the analysis is stored in the page ID 549 and the in-page data ID 542 of the new entry.

  Next, the step ID of the data processing prefetch request creation processing 526 is extracted from the processing entry. Next, by referring to the query plan, the step ID of the processing step corresponding to the table data acquisition processing executed corresponding to the processing step of the extracted step ID is specified. Next, the identified step ID is stored in the step ID 543 of the new entry.

  Next, the reference request 544 is extracted from the processing entry. Next, the step ID 543 is extracted from the process entry. Next, a value obtained by removing the search condition in the processing step corresponding to the extracted step ID 543 from the extracted reference condition 544 is obtained. The obtained value is stored in the new entry reference request 544.

  When there are a plurality of corresponding data, a new entry corresponding to each data is added to the prefetch request management information 540.

  Next, the completion of reference to the data designated by the data reference request is reported to the shared DB data management unit 210.

  Next, the process entry is deleted from the prefetch management information 510 (2321). Then, the prefetch actual processing thread is terminated (2322).

  On the other hand, if the designated page is not an index leaf page in step 2306, a prefetch request for a lower index page corresponding to the reference condition is created (2308). Specifically, the specified page is analyzed.

  Next, a pointer to a page corresponding to the reference condition grasped in step 2305 and holding index data existing on the leaf side is grasped. Next, a new entry is added to the prefetch request management information 540 in order to acquire a page holding the index data.

  Next, the query ID 512 of the process entry is stored in the query ID 541 of the new entry. Next, the step ID of the data processing prefetch request creation setting 526 of the processing entry is stored in the step ID 543 of the new entry. Next, the execution confirmation value 518 of the process entry is stored in the execution confirmation value 545 of the new entry. Next, the reference condition of the data processing prefetch request creation setting 526 of the processing entry is stored in the reference condition 544 of the new entry.

  Next, the page ID of the page holding the index data grasped by the analysis is set to the page ID 549 of the new entry. If there are a plurality of pages holding corresponding index data, new entries corresponding to the pages are added to the prefetch request management information 540. . Then, the process proceeds to Step 2321.

  On the other hand, if the data stored in the designated page in step 2304 is not an index, it is determined whether or not a value is stored in the reference condition 544 of the process entry.

  If no value is stored in the reference condition, the process proceeds to step 2321 as it is.

  On the other hand, if a value is stored in the reference condition, the data corresponding to the in-page data ID 542 of the processing entry is grasped by analyzing the page acquired in step 2302.

  Next, a corresponding value to be set in the reference condition 544 of the process entry is obtained based on the grasped data. Then, the obtained corresponding value is stored in the reference condition 544 of the process entry (2312).

  Next, the search condition in the index reference process executed next to the process corresponding to the process entry reference condition 544 is grasped. Then, it is determined whether the grasped search conditions are met.

  If the search conditions are not met, the process proceeds to step 2321 as it is.

  On the other hand, if the index step 2314 is prepared, a new entry is added to the prefetch request management information 540 in order to acquire the data of the index root page in the next index reference process (2314).

  Next, the query ID 512 of the process entry is stored in the query ID 541 of the new entry. Next, the execution confirmation value 518 of the process entry is stored in the execution confirmation value 545 of the new entry. Next, the reference condition of the data processing prefetch request creation setting 526 of the processing entry is stored in the reference condition 544 of the new entry.

  Next, an entry in which the query ID 512 of the process entry matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, the query plan 424 is extracted from the selected entry. Next, by referring to the extracted query plan 424 and the step ID of the processing entry data processing prefetch request creation setting 526, the object ID of the index to be referred to in the next index reference processing and the step ID corresponding to the processing step are obtained. To grasp.

  Next, the grasped step ID is stored in the step ID 543 of the new entry. Next, an entry in which the grasped object ID matches the object ID 330 of the object management information 330 is selected from the object management information 330. Next, the index route page ID 342 is extracted from the selected entry. Next, the extracted index route page ID 342 is stored in the page ID 549 of the new entry. Then, the process proceeds to Step 2321.

  FIG. 17 is a flowchart of the data reference request processing of the shared DB data management unit 210 according to the first embodiment of this invention.

  The data reference request processing is executed in step 2302 of the prefetch actual processing thread (FIG. 16).

  When the shared DB data management unit 210 receives a data reference request from the prefetch unit 208, the shared DB data management unit 210 starts a data reference request process (1301). The data reference request includes the page ID of the page having the required data and the query ID of the query corresponding to the prefetch process that requires the data.

  The shared DB data management unit 210 selects, from the buffer block management information 460, an entry in which the page ID included in the received data reference request matches the page ID 462 of the buffer block management information 460. Next, the selected entry is grasped as a target block entry. Next, it is determined whether or not the target block entry to be grasped exists.

  If there is no target block entry, the process proceeds to step 1211.

  On the other hand, if the target block entry exists, it is determined whether or not the status 464 of the target block entry is “Reading” (1303).

  If the state 464 of the target block entry is not “Reading”, the process proceeds to step 1305 as it is. On the other hand, if the state 464 of the target block entry is “Reading”, the process proceeds to step 1304.

  First, an entry in which the block ID 462 of the target block entry matches the block ID 492 of the I / O waiting management information 490 is selected from the I / O waiting management information 490. Next, the query ID included in the received data reference request is stored in the selected entry I / O waiting list 494. Then, the query is suspended until the I / O processing is completed (1304).

  Next, the management list to which the target block entry belongs is grasped by extracting the management list of the link information 466 of the target block entry. Then, it is determined whether the target block belongs to the upper LRU management list or the lower LRU management list (1305).

  When the target block belongs to the upper LRU management list, the usage number 468 of the target block entry is increased (1322). Then, the data reference request processing is terminated (1309).

  On the other hand, if the target block belongs to the lower LRU management list, step 1205 is executed. Note that step 1205 is the same as the processing described in the data acquisition request processing (FIG. 14), and a description thereof will be omitted.

  Next, the management list of the link information 466 is extracted from the target block entry, thereby grasping the lower LRU management list to which the target block entry currently belongs. Next, the target block entry is reconnected to the MRU end of the grasped lower LRU management list. This process is executed by referring to and updating the buffer block management information 460 and the buffer group management information 470. Next, the usage number 468 of the corresponding block entry is increased (1307).

  Next, an entry in which the query ID included in the received data reference request matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, the number of prefetched blocks in the number of prefetched blocks 516 of the selected entry is increased. Next, the query ID included in the received data reference request is stored in the prefetch correspondence query ID 469 of the target block entry (1308).

  Next, based on the block ID 462, buffer area information 452, and buffer block size 454 of the target block entry, the head address of the block holding the target data is obtained. Then, the obtained start address is transmitted to the prefetch unit 208. Then, the data reference request processing is terminated (1309).

  On the other hand, if it is determined in step 1303 that the target block entry does not exist, step 1211, step 1212, step 1205 and step 1314 are executed. Steps 1211, 1212 and 1205 are the same as the processing described in the data acquisition request processing (FIG. 14), and thus description thereof is omitted.

  Next, the buffer block management information is updated (1314). Specifically, the page ID included in the received data reference request is stored in the page ID 463 of the target block entry. Next, an invalid value is stored in the prefetch correspondence query ID 469 of the target block entry.

  Next, the I / O issue interval is adjusted (1315). Specifically, an entry in which the query ID included in the received data reference request matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, the time stamp of the I / O issue interval management information 522 of the selected entry is extracted. Next, when the extracted time stamp is valid, the difference between the extracted time stamp and the current time is obtained. Next, it is determined whether or not the obtained difference is smaller than a set lower limit value of the I / O issue interval management information 522 of the selected entry.

  If the difference is smaller than the set lower limit value, the process is suspended until the difference becomes equal to or greater than the set lower limit value. When the difference becomes equal to or greater than the set lower limit value, the current time is stored in the time stamp of the I / O issue interval management information 522 of the selected entry.

  Next, as in step 1215, data is read (1316). Note that step 1215 is the same as the processing described in the data acquisition request processing (FIG. 14), and a description thereof will be omitted. Then, the process proceeds to Step 1308.

  FIG. 18 is a flowchart of the execution management unit loop process of the execution management unit 204 according to the first embodiment of this invention.

  In an initialization process or the like when the DBMS 60 is activated, the execution management unit 204 starts this process (1501). Further, even during execution of the DBMS 60, the execution management unit 204 executes this process independently.

  First, the execution management unit 204 grasps the CPU usage rate of the DB server 42 (1502). Specifically, the CPU usage rate is obtained by the CPU usage rate measured by the OS 52.

  Next, it is determined whether or not a state where the grasped CPU usage rate is equal to or higher than the overload threshold continues for a certain time (1503). The overload threshold is given in advance by a user or the like.

  If the state where the CPU utilization rate is equal to or higher than the overload threshold continues for a certain period of time, the process proceeds to step 1521.

  On the other hand, if the state where the CPU utilization is equal to or higher than the overload threshold has not continued for a certain period of time, it is determined whether or not the state where the grasped CPU utilization is equal to or less than the low load threshold continues for a certain period of time (1504). The low load threshold is given in advance by a user or the like.

  If the state where the CPU usage rate is equal to or lower than the low load threshold has not continued for a certain period of time, the process proceeds directly to step 1507.

  On the other hand, if the state where the CPU usage rate is equal to or lower than the low load threshold continues for a certain period of time, the prefetching process that is currently suspended is resumed (1506).

  Specifically, an entry having “Stop” as the creation necessity information in the data processing prefetch request creation setting 526 of the prefetch management information 510 is selected. Next, the creation necessity information of the data processing prefetch request creation setting 526 of the selected entry is changed to “Yes”. Note that the processing target may be controlled based on the processing priority 416 of the query management information 410.

  Next, an entry in which a number of query IDs equal to or greater than the threshold is stored in the lock waiting list 488 of the lock management information 480 is selected. Then, the selected entry is grasped as an entry corresponding to the excessive waiting number page. Here, an excessively waiting page is a page in which there are many queries waiting for the release of a lock.

  Then, it is determined whether or not there is an excessive number of waiting pages (1507).

  If there is no excessive waiting page, the process proceeds to step 1509 as it is.

  On the other hand, if there is an excessive waiting number page, the prefetch data amount of the query is increased corresponding to the waiting large number page (1508). The lock acquisition transaction ID 486 of the entry corresponding to the excessive waiting number page is extracted. Next, an entry in which the extracted transaction ID 486 matches the transaction ID 414 of the query management information 410 is selected from the query management information 410. Next, it is determined whether or not “wait for lock setting” is stored in the processing status 418 of the selected entry.

  When “waiting for lock setting” is not stored in the processing status 418, the query ID 412 of the selected entry is grasped.

  On the other hand, when “waiting for lock setting” is stored in the processing status 418, the target resource 422 is extracted from the selected entry. Next, an entry in which the extracted target resource 422 matches the page ID 482 of the lock management information 480 is selected from the lock management information 480. Next, the lock acquisition transaction ID 486 is extracted from the selected entry. Next, an entry in which the extracted lock acquisition transaction ID 486 matches the transaction ID 414 of the query management information 410 is selected again from the query management information 410. Next, it is determined whether or not “wait for lock setting” is stored in the processing status 418 of the selected entry.

  This process is repeated until “waiting for lock setting” is not stored in the process status 418. When “waiting for lock setting” is not stored in the processing status 418, the query ID 412 of the entry is grasped.

  Next, an entry in which the grasped query ID 412 matches the query ID 512 of the prefetch management information 510 is selected from the prefetch management information 510. Next, the maximum number of prefetch blocks 516 of the selected entry is increased by a certain percentage.

  Next, the allocation value of the total prefetch block number 504 in the total prefetch number management information 501 is updated in accordance with the increase in the maximum block number. If the assigned value of the total prefetch block number 504 exceeds the maximum value of the total prefetch block number 504, this step is not executed.

  Next, a ratio between the assigned value in the total prefetch block number 504 and the maximum value of the total prefetch block number 504 is obtained. Next, it is determined whether or not the obtained ratio is equal to or less than a threshold value.

  If the ratio is less than or equal to the threshold, the maximum number of blocks of the number of prefetch blocks 516 in the prefetch management information 510 is reviewed (1509).

  Specifically, the query ID 512 is extracted from each entry of the prefetch management information 510. Next, an entry in which the extracted query ID matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, the processing priority 416 is extracted from the selected entry. Next, the number of allocation blocks defined by the extracted processing priority 416 (specified allocation block count) is grasped.

  Next, when the allocated block number of the prefetch block number 516 of the prefetch management information 510 is smaller than the specified allocation block number, the allocated block number of the prefetch block number 516 is changed to the specified allocation block number.

  Next, as in step 1508, the assigned value of the total number of prefetched blocks 504 is updated.

  If the assigned value of the total prefetch block number 504 exceeds the maximum value of the total prefetch block number 504, this step is not executed.

  Then, it sleeps for a certain time (1510) and returns to step 1502.

  On the other hand, if the state where the CPU usage rate is equal to or higher than the overload threshold value continues for a certain period of time in step 1503, the prefetch processing of the processing with low processing priority is stopped (1521).

  Specifically, the query ID 512 is extracted from each entry in the prefetch management information 510. Next, an entry in which the extracted query ID 512 matches the query ID 412 of the query management information 410 is selected from the query management information 410. Next, the processing priority 416 is extracted from the selected entry.

  Next, it is determined whether or not the extracted processing priority 416 is equal to or lower than a predetermined priority. Note that the priority set in advance may be changed according to the CPU usage rate.

  If the extracted processing priority 416 is equal to or lower than a predetermined priority, the following processing is performed.

  A new random value is stored in the execution confirmation value 518 of the selected entry. Next, it is confirmed whether “Yes” is stored in the creation necessity information of the data processing prefetch request creation setting 528. When “Yes” is stored in the creation necessity information, the creation necessity information is changed to “Stop”. This confirmation process is performed for all selected entries, and the process proceeds to step 1507.

  As described above, in the present embodiment, a process for controlling the prefetching process from the outside according to the operating state of the computer or the like is provided. Thereby, the influence on the DBMS main process by the prefetch process can be reduced, so that the prefetch operation can be optimized.

(Second Embodiment)
In the second embodiment of the present invention, a plurality of DB servers 42 exist in the computer system. The DBMSs 60 operating on the respective DB servers 42 cooperate to operate as one parallel DBMS.

  FIG. 19 is a block diagram of a computer system according to the second embodiment of this invention.

  The computer system according to the second embodiment includes a plurality of DB servers. The other configuration of the computer system of the second embodiment is the same as that of the computer system (FIG. 1) of the first embodiment. Therefore, the same number is attached | subjected to the same structure and description is abbreviate | omitted.

  The AP program 70 issues a query to the DBMS 60 operating on the predetermined DB server 42. The AP program 70 may operate on any DB server 42.

  The DBMSs 60 operating on different DB servers 42 are “Shared Noting” type parallel DBMSs that manage different data. Therefore, the configuration of the file management information 350 of the schema 300 is different.

  FIG. 20 is a configuration diagram of the file management information 350 included in the schema 300 according to the second embodiment of this invention.

  The file management information 350 includes a file ID 352, a page size 354, a page number 356, a file path 358, and a server ID 362.

  The file ID 352, the page size 354, the page number 356, and the file path 358 are the same as the configuration of the file management information (FIG. 5D) of the first embodiment. Therefore, the description is omitted.

  The server ID 362 is an identifier of the DB server 42 on which the DBMS 60 that manages data stored in the file is operating.

  The DBMSs 60 operating on the respective DB servers 42 can communicate with each other via the network 24. Therefore, the plurality of DBMSs 60 each hold a copy of the same query plan 600. Then, the processing corresponding to one query is shared and processed. The plurality of DBMSs 60 hold the same schema 300 and the same process management information 400. On the other hand, each DBMS 60 manages the shared buffer 64 independently.

  First, the AP program 70 transmits a query to one DBMS 60. The DBMS 60 that has received the query performs communication processing with the AP program 70 and query plan creation processing. All DBMSs share and execute processes other than the communication process with the AP program 70 and the query plan creation process.

  In the present embodiment, a DBMS 60 that manages data is determined for each file. The page ID includes an identifier related to the file. Therefore, the DB server 42 on which the DBMS 60 to be processed operates can be grasped based on the page ID.

  Based on the page ID of the page including the data to be used and the file management information 350, the data processing unit 206 and the prefetching unit 208 grasp the DB server 42 on which the DBMS 60 that executes processing related to the page is operating. Then, it requests the grasped DB server 42 to execute the process.

  For example, when a new entry is added to the prefetch request management information 540, it is necessary to store a value in the page ID 549 of the new entry to be added. At this time, the DB server 42 grasped based on the page ID is requested to add a new entry of the prefetch request management information 540.

Note that there are processes that should be executed by a single DB server 42, such as a totaling process. Regarding these processes, the server ID of the DB server 42 that executes the process is stored in the process details 616 of the query plan 600. As a result, the processing to be executed by one DB server 42 can be appropriately performed (third embodiment).
In the third embodiment of the present invention, as in the second embodiment, a plurality of DB servers 42 exist in the computer system. The DBMSs 60 operating on the respective DB servers 42 cooperate to operate as one parallel DBMS.

  However, in the third embodiment, unlike the second embodiment, the DBMS 60 operating on a different DB server 42 is a “Shared Disk” type parallel DBMS capable of processing the same data.

  The configuration of the computer system according to the third embodiment is the same as the configuration of the computer system according to the second embodiment (FIG. 19), and a description thereof will be omitted.

  In the third embodiment, the DBMS 60 operating on different DB servers 42 can process the same data. Therefore, the DB server 42 that holds a page including the latest data changes according to time.

  Therefore, the DBMS 60 manages data using the shared DB data management information 450 including the latest page possession server information 650.

  FIG. 21 is a configuration diagram of the latest page possession server information 650 included in the shared DB data management information 450 according to the third embodiment of this invention.

  The latest page possession server information 650 includes a page ID 651 and a server ID 652.

  The page ID 651 is a unique identifier of a page to be managed. The server ID 652 is a unique identifier of the DB server 42 that holds the latest data of the page.

  The latest page possession server information 650 is updated every time the DB server 42 that possesses the latest page changes.

  The DBMS 60 determines which data should be processed by which DBMS 60 when creating a query plan. Then, the determined content is stored in the process sharing information 660 included in the process management information 400.

  FIG. 22 is a configuration diagram of the process sharing information 660 included in the process management information 400 according to the third embodiment of this invention.

  The process sharing management information 660 includes a step ID 661, a division condition 662, and a server ID 663.

  The step ID 661 is a unique identifier of the processing step. Note that when the next processing step is executed based on the result of a certain processing step, there is no entry corresponding to the next processing step.

  The division condition 662 indicates a process division method in the processing step. Regarding the operation to be executed on one DB server 42, “all data” is stored in the division condition 662.

  The server ID 663 is a unique identifier of the DB server 42 on which the processing step is executed.

  When the data processing unit 206 expands data to the next processing step, or when the prefetching unit 208 assigns a new entry related to the next processing step to the prefetching request management information 540, the processing sharing information 660 of the query plan 600 is assigned. Based on this, the DB server 42 that performs processing is grasped. Then, the grasped DB server 42 is requested to execute the processing.

  In the present embodiment, the AP program 70 transmits a query to one DBMS 60. The DBMS 60 that has received the query performs communication processing with the AP program 70 and query plan creation processing. All DBMSs share and execute processes other than the communication process with the AP program 70 and the query plan creation process.

  In step 1215 of the data acquisition request processing (FIG. 14), the shared DB data management unit 210 refers to the latest page holding server information 650 so that the other DB server 42 holds the latest data of the requested page. It is determined whether or not.

  When the other DB server 42 holds, it requests the shared DB data management unit 210 of the DBMS 60 operating on the other DB server 42 to transfer the page.

  Then, the shared DB data management unit 210 that has received the transfer request refers to the lock management information 480 to determine whether or not a lock is set on the page requested to be transferred.

  If the lock is not set, the page is transmitted to the shared DB data management unit 210 of the request destination. On the other hand, if a lock is set, a query ID corresponding to the process is added to the lock management information 480 lock wait list 488.

  When the lock can be acquired, the requested page and the lock wait list 488 corresponding to the page are transmitted to the requested shared DB data management unit 210.

  Next, the entry corresponding to the block holding the page is deleted from the buffer block management information 460.

  The shared DB data management unit 210 that has requested the transfer of the page receives the page. At this time, when the lock wait list is received together with the page, the received lock wait list is stored in the lock wait list 488 of the lock management information 480. Thereafter, the DB data management unit 210 performs the same processing as in the first embodiment.

  The shared DB data management unit 210 refers to the latest page holding server information 650 in step 1316 of the data reference request processing (FIG. 17), so that the other DB server 42 holds the latest data of the requested page. It is determined whether or not.

  When the other DB server 42 holds, it requests the shared DB data management unit 210 of the DBMS 60 operating on the other DB server 42 to transfer the page.

  Then, the shared DB data management unit 210 that has received the transfer request immediately transmits the requested page data and the lock state of the page to the requesting shared DB data management unit 210.

  The requesting shared DB data management unit 210 determines whether a lock is set on the received page.

  When the lock is not set, management is performed in the same manner as the page read from the storage device 46.

  On the other hand, when the lock is set, the page is held separately from the page read from the storage device 46. When the data reference completion report is received from the prefetch unit 208, the data is immediately discarded. That is, when the lock is not set, the DB server 42 that holds the latest page changes. On the other hand, when the lock is set, the DB server 42 that holds the latest page does not change.

  According to the present invention, the prefetch unit can be effectively operated on a computer on which a DBMS operates even under a condition where the computer has a small amount of memory. Therefore, it is possible to shorten the processing time of inquiry processing by the DBMS. In particular, the processing time of search processing using an index in the B-Tree format can be greatly shortened. Since the present invention uses a configuration used in a general computer system, it can be applied to a wide range of computer systems. By applying it to a computer system, it is possible to obtain a performance improvement effect by prefetching data.

1 is a block diagram of a computer system according to a first embodiment of this invention. It is explanatory drawing of the function of DBMS of the 1st Embodiment of this invention. It is explanatory drawing of the LRU management list utilized for the block management in the group of the 1st Embodiment of this invention. It is explanatory drawing of the query plan in DBMS of the 1st Embodiment of this invention. It is a block diagram of the table definition information contained in the schema of the 1st Embodiment of this invention. It is a block diagram of the index definition information contained in the schema of the 1st Embodiment of this invention. It is a block diagram of the object management information contained in the schema of the 1st Embodiment of this invention. It is a block diagram of the file management information contained in the schema of the 1st Embodiment of this invention. It is a block diagram of the query management information contained in the process management information of the 1st Embodiment of this invention. It is a block diagram of the transaction management information contained in the process management information of the 1st Embodiment of this invention. It is a block diagram of the query plan contained in the process management information of the 1st Embodiment of this invention. FIG. 3 is a configuration diagram of shared buffer definition information included in shared DB data management information according to the first embodiment of this invention. FIG. 3 is a configuration diagram of buffer block management information included in shared DB data management information according to the first embodiment of this invention. It is a block diagram of the buffer group management information included in the shared DB data management information according to the first embodiment of this invention. It is a block diagram of the lock management information included in the shared DB data management information according to the first embodiment of this invention. It is a block diagram of the I / O waiting management information included in the shared DB data management information according to the first embodiment of this invention. It is a block diagram of the total prefetch number management information contained in the prefetch process information of the 1st Embodiment of this invention. It is a block diagram of the prefetch management information contained in the prefetch process information of the 1st Embodiment of this invention. It is a block diagram of the prefetch request management information contained in the prefetch process information of the 1st Embodiment of this invention. It is a flowchart of DBMS query processing according to the first embodiment of this invention. It is a flowchart of the prefetch management information setting process of the execution management part of the 1st Embodiment of this invention. It is a flowchart of the data processing of the data processing part of the 1st Embodiment of this invention. It is a flowchart of the prefetch request | requirement setting process of the data processing part of the 1st Embodiment of this invention. It is a flowchart of the data acquisition request processing of the shared DB data management unit according to the first embodiment of this invention. It is a flowchart of the prefetch process management loop process of the prefetch part of the 1st Embodiment of this invention. It is a flowchart of the prefetch real process thread of the prefetch part of the 1st Embodiment of this invention. It is a flowchart of the process at the time of a data reference request | requirement of the shared DB data management part of the 1st Embodiment of this invention. It is a flowchart of the execution management part loop process of the execution management part of the 1st Embodiment of this invention. It is a block diagram of a computer system according to a second embodiment of this invention. It is a block diagram of the file management information contained in the schema of the 2nd Embodiment of this invention. It is a block diagram of the newest page possession server information contained in the shared DB data management information of the 3rd Embodiment of this invention. It is a block diagram of the process share information contained in the process management information of the 3rd Embodiment of this invention.

Explanation of symbols

12 CPU
14 Memory 16 HDD
18 CD-ROM drive 20 Internal bus 22 Network I / F
24 Network 32 I / O path I / F
34 I / O path 42 DB server 44 AP server 46 Storage device 52 OS
60 DBMS
62 Shared management information 64 Shared buffer 70 AP program 80 Internal bus 82 CPU
84 Memory 86 HDD
85 Network I / F
202 Client processing unit 204 Execution management unit 206 Data processing unit 208 Prefetch unit 210 Shared DB data management unit

Claims (13)

In a computer system including a computer that stores a database management system program in a memory and a storage device that stores data,
The calculator is
Allocate a buffer on the memory,
A shared DB data management unit that manages the buffer; a data processing unit that acquires requested data; and a prefetch unit that prefetches data with reference to data stored in the buffer;
The shared DB data management unit locks data in the buffer when the data processing unit acquires data.   The computer system according to claim 1, wherein the shared DB data management unit enables the prefetching unit to refer to all data in the buffer when the prefetching unit prefetches.   The computer system according to claim 1, comprising a plurality of the computers. The computer has an execution management unit that controls the prefetching unit,
The execution management unit sets an execution parameter in the prefetch unit,
The computer system according to claim 1, wherein the prefetching unit prefetches based on the set execution parameter. The execution management unit
Obtain the CPU usage rate of the computer,
The computer system according to claim 4, wherein an execution parameter corresponding to the acquired usage rate of the CPU is set in the prefetching unit. The execution management unit
Get the lock status of the data in the buffer;
The computer system according to claim 4, wherein execution parameters corresponding to the acquired lock state are set in the prefetch unit.   The computer system according to claim 1, wherein the prefetch unit prefetches a plurality of data in parallel. A database management system program for managing data stored in a storage device by being executed by a computer,
A process of allocating a buffer on the memory of the computer;
A process for managing the buffer;
A process of prefetching data with reference to the data stored in the buffer;
And a process of acquiring the requested data while locking the data in the buffer when the data is requested.   The database management system program according to claim 8, further comprising a process for making it possible to refer to all data in the buffer during the prefetching process. Furthermore, a process for setting execution parameters,
The database management system program according to claim 8, further comprising: prefetching data based on the set execution parameter. Further, a process for acquiring the utilization rate of the CPU of the computer;
The database management system program according to claim 10, further comprising a process of setting an execution parameter in accordance with the acquired CPU usage rate. A process of acquiring a lock state of the data in the buffer;
The database management system program according to claim 10, further comprising: setting an execution parameter according to the acquired lock state.   The database management system program according to claim 8, further comprising a process of prefetching a plurality of data in parallel.

Images