U.S. patent application number 13/731561 was filed with the patent office on 2014-01-16 for database management method, database management system, and processing program therefor.
This patent application is currently assigned to Hitachi, Ltd.. The applicant listed for this patent is Hitachi, Ltd.. Invention is credited to YUKI SUGIMOTO.
Application Number | 20140019430 13/731561 |
Document ID | / |
Family ID | 43589178 |
Filed Date | 2014-01-16 |
United States Patent
Application |
20140019430 |
Kind Code |
A1 |
SUGIMOTO; YUKI |
January 16, 2014 |
DATABASE MANAGEMENT METHOD, DATABASE MANAGEMENT SYSTEM, AND
PROCESSING PROGRAM THEREFOR
Abstract
A method of increasing a processing performance by setting a
suitable upper limit of a resources count for each processing
request according to an arrangement of hardware such as a storage
device or to contents of the processing request. A processing
request acceptor accepts the processing request as a data query. An
auxiliary storage device forms a storage area where a database is
stored. A data operation executor analyzes the accepted processing
request and executed the data operations on the basis of the
analyzed result. A resource manager manages the respective data
operations allocated to generated processes or threads. A buffer
manager caches data of the data operations upon execution of the
data operations from the auxiliary storage device to a memory, and
determines whether or not the data as the target of the data
operations are present in the cache.
Inventors: |
SUGIMOTO; YUKI; (Sagamihara,
JP) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Hitachi, Ltd.; |
|
|
US |
|
|
Assignee: |
Hitachi, Ltd.
Tokyo
JP
|
Family ID: |
43589178 |
Appl. No.: |
13/731561 |
Filed: |
December 31, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12703661 |
Feb 10, 2010 |
8346744 |
|
|
13731561 |
|
|
|
|
Current U.S.
Class: |
707/705 |
Current CPC
Class: |
G06F 16/24561 20190101;
G06F 2209/5018 20130101; G06F 9/5033 20130101; G06F 16/211
20190101; G06F 16/24552 20190101 |
Class at
Publication: |
707/705 |
International
Class: |
G06F 17/30 20060101
G06F017/30; G06F 9/50 20060101 G06F009/50 |
Foreign Application Data
Date |
Code |
Application Number |
Aug 12, 2009 |
JP |
2009-186956 |
Claims
1. A database management method in a database management system
comprising auxiliary storage devices having a storage area for
storing a database therein, the method comprising the steps of:
holding, by a storage unit, schema definition information including
information about a table structure of the database and storage
arrangement information including a mapping with a storage area for
storing data in the database, and holding an upper limit of a
threads count by correlating with the storage devices; accepting,
by a processing request acceptor, a processing request as a data
query; analyzing, by a data operation executor, the accepted
processing request, referring the schema definition information and
the storage arrangement information, obtaining a data in the
database accessed in accordance with the processing request by
accessing the plurality of storage devices which store the data in
the database, and executing data operations for a plurality of
obtained data on the basis of the analyzed result; managing, by a
resource manager, the respective data operations allocated to
generated threads for each processing request; and obtaining, by an
each-processing-request each-request resources-count determiner,
the upper limit of the threads count correlated with the respective
storage devices accessed in accordance with the processing request,
calculating the obtained upper limit of the threads count, and
determining an upper limit of the threads count for the each
processing request.
2. A database management method according to claim 1, wherein the
each-processing-request resources count determiner refers to the
threads count used by the processing request for each operation of
the accepted processing request from performance statistical
information about the database management system acquired upon
execution of past processing requests, and calculates an upper
limit value of the threads count to be used.
3. A database management method according to claim 1, wherein the
each-processing-request resources count determiner determines an
upper limit value of the threads count used for the each processing
request when an execution on the basis of the threads count
calculated from an I/O performance of the storage device accessed
in accordance with the processing request when an execution.
4. A database management system comprising auxiliary storage
devices having a storage area for storing a database therein, the
system comprising: a storage unit which holds schema definition
information including information about a table structure of the
database and storage arrangement information including mapping with
a storage area for storing data in the database, and holds an upper
limit of a threads count by correlating with the storage devices; a
processing request acceptor configured to accept a processing
request as a data query; a data operation executor configured to
analyze the accepted processing request, refer the schema
definition information and the storage arrangement information,
obtain a data in the database accessed in accordance with the
processing request by accessing the plurality of storage devices
which store the data in the database, and execute data operations
for a plurality of obtained data on the basis of the analyzed
result; a resource manager configured to manage the respective data
operations allocated to generated threads for each processing
request; and an each-processing-request each-request
resources-count determiner configured to obtain the upper limit of
the threads count correlated with the respective storage devices
accessed in accordance with the processing request, calculate the
obtained upper limit of the threads count, and determine an upper
limit of the threads count for the each processing request.
5. A database management system according to claim 1, wherein the
each-processing-request resources count determiner is configured to
refer to the threads count used by the processing request for each
operation of the accepted processing request from performance
statistical information about the database management system
acquired upon execution of past processing requests, and calculate
an upper limit value of the threads count to be used.
6. A database management system according to claim 1, wherein the
each-processing-request resources count determiner is configured to
determine an upper limit value of the threads count used for the
each processing request when an execution on the basis of the
threads count calculated from an I/O performance of the storage
device accessed in accordance with the processing request when an
execution.
7. A non-transitory computer readable storage medium storing a
database management program in a database management system
comprising auxiliary storage devices having a storage area for
storing a database therein, the database management program
executes the steps of: holding, by a storage unit, schema
definition information including information about a table
structure of the database and storage arrangement information
including mapping with a storage area for storing data in the
database, and holding an upper limit of a threads count by
correlating with the storage devices; accepting, by a processing
request acceptor, a processing request as a data query; analyzing,
by a data operation executor, the accepted processing request,
referring the schema definition information and the storage
arrangement information, obtaining a data in the database accessed
in accordance with the processing request by accessing the
plurality of storage devices which store the data in the database,
and executing data operations for a plurality of obtained data on
the basis of the analyzed result; managing, by a resource manager,
the respective data operations allocated to generated threads for
each processing request; and obtaining, by an
each-processing-request each-request resources-count determiner,
the upper limit of the threads count correlated with the respective
storage devices accessed in accordance with the processing request,
calculating the obtained upper limit of the threads count, and
determining an upper limit of the threads count for the each
processing request.
8. A non-transitory computer readable storage medium storing a
database management program according to claim 1, wherein the
each-processing-request resources count determiner refers to the
threads count used by the processing request for each operation of
the accepted processing request from performance statistical
information about the database management system acquired upon
execution of past processing requests, and calculates an upper
limit value of the threads count to be used.
9. A non-transitory computer readable storage medium storing a
database management program according to claim 1, wherein the
each-processing-request resources count determiner determines an
upper limit value of the threads count used for the each processing
request when an execution on the basis of the threads count
calculated from an I/O performance of the storage device accessed
in accordance with the processing request when an execution.
Description
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS
[0001] Japan Priority Application 2009-186956, filed Aug. 12, 2009
including the specification, drawings, claims and abstract, is
incorporated herein by reference in its entirety. This application
is a Continuation of U.S. application Ser. No. 12/703,661, filed
Feb. 10, 2010, incorporated herein by reference in its
entirety.
BACKGROUND OF THE INVENTION
[0002] The present invention relates to a database management
technique which can be applied widely to a database management
system (DBMS).
[0003] Such a technique as disclosed in JP-A-2007-249468 has been
so far employed for a database management system to dynamically
allocate CPU resources and execute a database processing
request.
[0004] As the need for large-scale analysis is increasing in these
years, such a technique as disclosed in JP-A-2007-34414 is
employed, wherein high-speed processing is required by parallel
processing which utilizes many resources including processes and
threads within a database management system.
[0005] Further, even with respect to data operations such as index
creation, data insertion and data update in the database management
system, such a technique as to increase the processing speed by
parallelly processing a single processing request from a user or an
application program has also become popular.
SUMMARY OF THE INVENTION
[0006] Such processing requires use of many resources including
processes and threads. However, there exists such a state that
allocation of even an increased number of resources results in the
fact that a performance cannot be increased depending upon, for
example, the input/output performance of a storage device. In the
case of, for example, processes or threads, even allocation of an
increased number of resources in such a state involves an increased
cost necessary for switching such processes or threads and so on,
and in some cases, even increase of the resources count beyond a
predetermined value reversely deteriorates the performance.
[0007] Such a system as an operating system has generally an upper
value for the number of resources usable for the entire system.
There occurs, in some cases, such a situation that, when a
plurality of processing requests are executed and one of the
executed processing requests executed firstly uses resources up to
its upper limit, a necessary number of resources cannot be
allocated to the next processing request, thus resulting in a low
performance.
[0008] In the database management system, on the other hand, when
each access is made to each of threads prepared for accesses to
already stored data for example, the access can be made with a less
number of threads. In other words, in order to processing a request
with use of an optimum number of processes or threads, it becomes
important to determine an upper limit value for the number of
processes or threads.
[0009] An object of the present invention is to increase a
processing performance by setting a suitable upper limit for the
number of resources for each of processing requests depending upon
the arrangement of hardware such as a storage device or the
contents of each processing request.
[0010] In accordance with an aspect of the present invention, the
above object is attained by providing a database management system
which includes a processing request acceptor which accepts a
processing request as a data query; an auxiliary storage device in
which storage areas for storing data stored in a database are
arranged; a data operation executor which analyzes the accepted
processing request and operates a plurality of pieces of data on
the basis of the analyzed result; a resource manager which manages
each of the data operations allocated to generated processes or
threads; and a buffer manager which caches data as a target of the
data operation from the auxiliary storage device into a memory upon
execution of the data operations and determines whether or not the
data as the target of the data operations is present in a cache.
When the data operation executor executes the data operations, the
buffer manager determines whether or not the data is present in the
cache. The resource manager determines the usable state of the
processes or threads in the data operations when the data is not
present in the cache. When some of the processes or threads are
free or usable, the resource manager sends an access request of
caching data as the target of the executed data operations in the
memory to the auxiliary storage device in order to execute the data
operations through the processes or threads. When all the processes
or threads are already used, the resource manager executes the data
operations after some of the processes or threads are released or
free. In the presence of the data in the cache, the resource
manager executes the data operations.
[0011] In the present invention, since an upper limit for the
number of resources allocated to a single processing request is set
in the database management system, the resources can be efficiently
used.
[0012] Other objects, features and advantages of the invention will
become apparent from the following description of the embodiments
of the invention taken in conjunction with the accompanying
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG. 1 shows a conceptual view for explaining an
each-request resources-count determiner for determining the number
of resources for each processing request in the present
invention;
[0014] FIG. 2 shows a schematic configuration of a computer system
in an embodiment of the present invention;
[0015] FIG. 3 is a flow chart for explaining details of the
each-request resources-count determiner;
[0016] FIG. 4 schematically shows a table for explaining schema
definition information;
[0017] FIG. 5 schematically shows a table for explaining storage
arrangement information;
[0018] FIG. 6 schematically shows a diagram for explaining the
storage arrangement information when the hierarchy of a storage
device is made complex;
[0019] FIG. 7 schematically shows a table for explaining mapping
information about schema and storage:
[0020] FIG. 8 shows a flow chart for explaining details of the
each-request resources-count determiner when an I/O performance is
used as the storage arrangement information;
[0021] FIG. 9 schematically shows a table for explaining an example
of the storage arrangement information when the I/O performance is
treated as the storage arrangement information;
[0022] FIG. 10 is a flow chart for explaining the operation when
resources are allocated to each operation target table in linking
operation;
[0023] FIG. 11 is a flow chart for explaining the operation of the
data operation executor for executing operations involved by
input/output (I/O) to/from a disk;
[0024] FIG. 12 schematically shows a table for explaining a
relationship between a reference resources count and a disk
device;
[0025] FIG. 13 schematically shows a table for explaining
performance statistical information;
[0026] FIG. 14 is a diagram for explaining the effects of the
resources count allocation in the linking operation;
[0027] FIG. 15 is a flowchart for explaining the resources count
allocation when a linking sequence in the linking operation is
considered; and
[0028] FIG. 16 schematically shows a linking order coefficient
management table.
DESCRIPTION OF THE EMBODIMENTS
Embodiment 1
[0029] A first embodiment of the present invention will be
explained with reference to the accompanying drawings.
[0030] FIG. 2 shows, as an example, a schematic configuration of a
computer system in an embodiment of the present invention.
[0031] A computer system 201 includes a CPU 202 and a main storage
device 203. The computer system is connected to a storage subsystem
205 via a storage area network 204. The computer system is also
connected to many client hosts 206 each having a database access
processor 207 via a network 208.
[0032] Database storage areas 210 for storing data to be managed by
a database management system 101 are provided in areas of a
plurality of disk devices 209 within the storage subsystem 205. The
storage subsystem 205 also has a controller 214 for managing
storage arrangement information 212 including a correlation between
data storage areas 215 and the disk devices 209.
[0033] The storage subsystem 205 may be formed as a disk device
built in the computer system 201.
[0034] A management server 211 is a server for managing a storage
area network environment and contains storage management software
213 which manages the storage arrangement information 212.
[0035] The storage management software 213 may be built in the
storage subsystem 205.
[0036] The database management system 101 is provided in the main
storage device 203.
[0037] The database management system 101 has a processing request
acceptor 216 as a already known means for accepting a processing
request including data search from the client host 206, a data
operation executor 218 as an already known means for causing the
database management system 101 to execute the data operations
provided in the database storage area 210, schema definition
information 219 such as information about database table structure,
a resource manager 221 for causing the database management system
101 to hold processes or threads and allocating the processing
operation, an each-request resources-count determiner 217 for
determining the number of resources for each processing request,
mapping information 220 of schema and storage arrangement
indicating a table definition etc. and the disk device having the
data management area which is storing the table definition etc.,
and a reference resources count 222 as a threads count which can
get the best I/O performance per one disk device.
[0038] The reference resources count 222 can be derived from
experimental values or the like for the same hardware arrangement.
In the present embodiment, a reference-resources-count/disk-device
table 223 showing a relationship between disk device ID 1201 such
as a model number indicating the type of the disk device 209 and
the reference-resources count 222 is stored.
[0039] The processing operations of the aforementioned respective
processors are executed under control of the CPU 202. In this
connection, the respective processors may be called also as
corresponding processing means. The respective processors can be
implemented by hardware (for example, a circuit), a computer
program, an object or by combining these (for example, by executing
part of the processing under control of the computer program and by
executing part of the processing under control of the hardware
circuit). Each computer program can be read from a storage resource
(such as a memory) provided in a computer machine. The computer
program may be installed in the storage resource via a recording
medium such as CD-ROM or DVD (Digital Versatile Disk), or may be
downloaded via a communication network such as the Internet or an
LAN.
[0040] FIG. 12 schematically shows a table for explaining the
reference-resources-count/disk-device table 223. A correlation
between the disk device ID 1201 such as a model number indicating
the type of the disk device and the reference-resources count 222
is stored in the table.
[0041] The reference-resources-count/disk-device table 223 may be
used so that the database management system 101 acquires
performance statistical information 224 upon data operation
execution and determines the reference-resources count 222
corresponding to the associated disk device 209 from the
performance statistical information about the disk device 209.
[0042] Since such performance statistical information can be
acquired generally by the database management system 101 or by the
operating system, the system, for example, can measure the number
of inputs/outputs per one second (TOPS), detect an IOPS when
operated with one resource and the state that the IOPS cannot be
increased any longer even if the resources count is increased, and
employ the resources count when the IOPS reaches its upper limit as
the reference-resources count
[0043] FIG. 13 schematically shows a table for explaining the
performance statistical information 224.
[0044] In the present embodiment, the performance statistical
information 224 includes a storage area ID 403, a maximum IOPS 1301
so far generated, and a number 1302 of resources having accessed to
the area upon acquisition of the maximum IOPS.
[0045] Although the resources count is treated as a threads count
in the present embodiment, similar processing can be carried out
even for the number of the other resources such as a processes
count.
[0046] The database management system 101 generally has a buffer
management function 226 of caching disk data in the memory and
managing whether or not the data is present in a DB buffer 227 for
the purpose of increasing a data operation performance.
[0047] FIG. 1 shows a schematic diagram for explaining the
each-request resources-count determiner for determining a resources
count for each processing request in the present invention. The
database management system 101 has a processing request executor
105 for accepting and executing a processing request from the
client host 206.
[0048] Though such a processing request is usually issued from a
business application or the like, such a request may also be issued
by a user from the client host computer 206 as a terminal or the
like to the database management system 101 to process the
processing request.
[0049] In the processing request executor 105, the processing
request is accepted by the processing request acceptor 216 for
accepting the processing request, and the processing request is
parsed, optimized and converted to an execution logic as a group of
data operation instructions including data updating in a table or
data reading therefrom. The data operation executor 218 reads such
execution logic and executes the data operation.
[0050] The each-request resources-count determiner determines a
search target table from the analyzed result on the basis of the
schema definition information 219 (step 102).
[0051] On the basis of the storage arrangement information 212 and
the mapping information 220 of a scheme and storage arrangement,
the each-request resources-count determiner acquires a storage
arrangement in the operation target table indicating which disk
devices 209 data in tables located in (step 103).
[0052] On the basis of the acquired storage arrangement, the
each-request resources-count determiner determines a maximum
threads count suitable for each processing request corresponding to
the storage arrangement (step 104).
[0053] FIG. 3 is a flow chart for explaining details of the
each-request resources-count determiner 217, and corresponds to
details of the each-request resources-count determiner in FIG.
1.
[0054] The each-request resources-count determiner 217 reads the
schema definition information 219 (step 301), and prepares a list
of operation target tables included in the processing request
analysis result (step 302).
[0055] The each-request resources-count determiner then reads
storage arrangement information from the storage management
software 213 or from the controller 214 of the storage subsystem
205 (step 303).
[0056] The storage arrangement information 212 indicates the number
of physical disk devices in which the area being used is formed,
and can be acquired from the controller 214 of the storage
subsystem 205 or from the storage management software 213 for
management of the storage subsystem 205.
[0057] Further, the each-request resources-count determiner reads
the mapping information 220 of a scheme and storage arrangement
possessed by the database management system 101 (step 304), and
combines the mapping information 220 of a scheme and storage
arrangement and the storage arrangement information obtained in the
step 303 to obtain the storage arrangement information 212 about
the operation target table being stored (step 305).
[0058] The each-request resources-count determiner now reads a
reference resources count as a threads count per one disk device
(step 306), multiplies the storage arrangement information 212
obtained in the step 305, that is, the number of the arranged disk
devices 209 by the reference resources count 222, and determines a
suitable threads count for each processing request (step 307).
[0059] In this connection, a disk device rotational speed, an
input/output throughput performance or a response performance in
place of the disk devices count may also be used as the storage
arrangement information 212 to obtain similar processing
operation.
[0060] FIG. 4 schematically shows a table for explaining the schema
definition information 219.
[0061] The schema definition information 219 includes a table name
402 for an operation target, a table ID 401 for identifying a table
in the processing interior, and a storage area ID 403 as an ID of a
storage area in which the table is actually stored.
[0062] In this connection, the table name or the storage area name
may be also used as an ID.
[0063] Even an index prepared for the purpose of high-speed search
similarly has information about an index name 405, an index ID 404,
an ID 403 of an area where the index name and the index ID 404 are
stored, and an ID 401 of the table in which the index is
defined.
[0064] In the present embodiment, the schema definition information
is stored in the memory. However, the schema definition information
may be stored in another location, for example, in the disk device,
so long as the information can be read out upon execution of the
each-request resources-count determiner.
[0065] FIG. 11 is a flow chart for explaining the data operation
executor 218 for executing the operation involved by input/output
to/from the disk device.
[0066] The data operation executor 218 first reads the execution
logic (step 1101), and determines whether or not the execution
logic can be parallelly processed as previously defined (step
1107).
[0067] When the execution logic can be parallelly processed, the
operation target is not cached in the buffer, and the data
operation executor confirms whether or not the operation target is
present only in the disk (step 1701).
[0068] When the operation target is not cached in the buffer, the
data operation executor confirms whether or not the threads count
now being used fails to reach its upper limit (step 1102). When the
threads count now being used reaches its upper limit, the data
operation executor waits for a released thread (step 1103). When
the threads count being used fails to reach its upper limit, the
data operation executor allocates the data operation to a thread
(step 1104) and executes the data operation (step 1106).
[0069] When the execution logic can be parallelly processed and
when the operation target is cached in the buffer, the data
operation executor simply executes the data operation (step
1105).
[0070] And the above steps are repeated until the execution logic
is completed (step 1105).
[0071] When the data operation executor reads the cached data using
the DB buffer 227, even allocation of many threads fails to obtain
a great effect.
[0072] To avoid this, it is considered to determine whether or not
the data operation target is cached upon execution of the
processing request, to read the data as it is when the data is
cached in the DB buffer 227, and to allocate the data to thread and
execute it when the data is not cached.
[0073] When the data operation executor 218 executes the
aforementioned processing operations, resource allocation
considering the cached state of the data can be attained.
[0074] FIG. 5 schematically shows a table for explaining the
storage arrangement information 212.
[0075] The storage arrangement information 212 includes a logical
device ID 502 that the database server can recognize the logical
device and a disk devices count 501 indicating the number of disk
devices used for the area.
[0076] With respect to the disk devices count, the disk devices
count can have a relationship of a plurality of correlations
overlapped when the hierarchy becomes complex by virtualizing the
storage devices or the like, and when the area has a plurality of
spanned areas, the disk devices count can be approximated to an
average of the plurality of areas.
[0077] FIG. 6 schematically shows a diagram for explaining the
storage arrangement information 212 when the hierarchy of storage
devices becomes complex.
[0078] In this example, a plurality of disk devices 209 are
combined into a RAID group 601, and each of such RAID groups 601 is
divided into logical devices 602, some of the divided logical
devices 602 are extracted from the plurality of RAID groups 601 and
combined into a single logical device 603.
[0079] In such a case, an average disk devices count as all the
RAID groups is assumed to be the disk devices count 501
corresponding to the database storage area 210.
[0080] The respective disk devices counts may be weighted on the
basis of a ratio among disk capacities being used, and the disk
devices count 501 corresponding to the database storage area 210
may be determined.
[0081] FIG. 7 schematically shows a table for explaining the
mapping information 220 of a scheme and storage arrangement.
[0082] The mapping information 220 of a scheme and storage
arrangement includes a storage area ID 403 indicating an area where
data is stored and a logical device ID 502 corresponding to the
storage area.
[0083] In this case, one storage area may have a plurality of
logical devices or a plurality of storage areas may have a single
logical device.
[0084] As examples other than the above example, various
arrangements using the functions of the storage subsystem and
operating system are considered. Even in such cases, the disk
devices count 501 corresponding to the database storage area 210
can be determined in the same manner as in the aforementioned
case.
[0085] In this case, the storage arrangement information 212 may be
treated as the storage arrangement information 212 simply with the
I/O performance of the storage area as in the case of the disk
devices count.
[0086] FIG. 8 is a flow chart for explaining details of the
each-request resources-count determiner 217 for each processing
request similarly to FIG. 3, and shows an example when the I/O
performance is used as the storage arrangement information.
[0087] In this flow chart, the operations of steps 301 to 305 are
similar to the contents already explained in FIG. 3.
[0088] The each-request resources-count determiner reads a threads
count per unit I/O performance as the reference resources count in
place of reading the reference resources count as a threads count
per one storage in the step 306 of FIG. 3 (step 801).
[0089] The each-request resources-count determiner, in place of the
step 307 of FIG. 3, derives an optimum threads count for each
processing request by multiplying the threads count per unit I/O
performance by the I/O performance of the storage area (step
802).
[0090] FIG. 9 schematically shows a table for explaining an example
of the storage arrangement information when the I/O performance is
treated as the storage arrangement information 212.
[0091] In this case, the storage arrangement information 212
includes the logical device ID 502 which can be recognized by the
database server, and also an I/O performance 901 indicating how
many inputs/outputs the area can produce.
[0092] When the data arrangement is biased, the system cannot
possibly exhibit a theoretical performance. In the present
invention, however, when searching objects are evenly distributed,
the system can exhibit especially a high effect. When a scale of
stored data is sufficiently large, the data are expected to be
evenly distributed.
Embodiment 2
[0093] A second embodiment corresponds to an example when the
system waits for a linkage process of processing data of a
plurality of tables in association with each other, and the
schematic configuration of its computer system is similar to that
of FIG. 2.
[0094] When the system waits for such a linkage process, in order
to operate the plurality of tables simultaneously, it is required
to allocate a suitable resources count to each of the operation
target tables.
[0095] FIG. 10 is a flow chart for explaining the operations of a
linkage process of allocating a resources count to each of
operation target tables.
[0096] In the flow chart, the operations of steps 301 to 307 are
similar to the contents already explained in FIG. 3.
[0097] In this flow chart, the operation of determining a suitable
resources count for each processing request by multiplying the disk
device arrangement count of the step 307 by the reference resources
count is repeated by a number of times corresponding to the number
of the operation target tables (step 1001).
[0098] The obtained resources count for each table is stored as a
resources count upper limit for each operation target table (step
1002).
[0099] At this time, the data operation executor, which is similar
to that in FIG. 11, checks whether or not a threads count currently
being used reaches its upper limit in a step 1102 for each table.
When the current threads count exceeds its upper limit allocated to
one table, the data operation executor executes a step (step 1103)
to wait for thread release.
[0100] FIG. 14 is a schematic diagram for explaining the effect of
resources count allocation in the linkage process. In this case,
the storage area 210 having 4 disk devices 209 and the storage area
210 having two disk devices 209 are provided. A table 1401 having
data stored therein is provided in each of the storage areas.
[0101] When the system executes the linkage process to match data
in two tables under such a condition, merely a sum of resources
count upper limits of all the tables can be treated as an entire
resources count upper limit. As explained in the above embodiment,
however, when resources count upper limits are set for respective
tables A and B in search thereof, search of the table A is executed
using resources corresponding to 4 disk devices, and search of the
table B is executed using two disk devices. In accordance with the
present embodiment in this way, even when an access to a plurality
of storage areas is made for a single database processing request,
a suitable resources count allocation can be attained for each
area.
[0102] In general, when a system has a linkage process, data to be
linked later in linkage order tend to be read more than data to be
linked earlier in linkage order. Thus a method of setting a
resources count requirement of allocating a larger number of
resources to the data to be linked later in linkage order than the
data to be linked earlier may be employed.
[0103] FIG. 15 is a flow chart for explaining the resources count
allocation when consideration is paid to a linkage order in a
linkage process.
[0104] In the flow chart, the operations of steps 301 to 307, 1001,
and 1002 are similar to the contents already explained in FIG.
10.
[0105] In a step 1501 after the step 307 of determining a suitable
resources count for each processing request by multiplying the
number of arranged disk devices by the reference resources count,
the resources count is modified by multiplying it by a linkage
order coefficient 1602 associated with a linkage order 1601.
[0106] The linkage order coefficient, which is previously kept in
the system as a constant value, has a value smaller than 1. Whether
or not data is processed earlier or later in linkage order is
determined and easily discriminated by the processing request
acceptor.
[0107] FIG. 16 is a schematic diagram for explaining a linkage
order coefficient management table 225.
[0108] The linkage order coefficient management table 225 shows a
relationship between the linkage order 1601 and the linkage order
coefficient 1602. The linkage order coefficient 1602 is set at 1 in
the last linkage and at a value smaller than 1 in the order earlier
therethan. The earlier the linkage order is the smaller the linkage
order coefficient is.
[0109] Since the linkage order coefficient depends on the number of
pieces of data to be accessed in the table, the coefficient cannot
determined before execution of the access request. As an example,
the linkage order coefficient is considered merely based on the
linkage order to be previously set at 0.9 for linkage one previous
to the last linkage, 0.8 for linkage two previous to the last
linkage, and 0.1 for linkages smaller than 0.1.
[0110] As has been explained above, when data are stored in a
plurality of storage devices and many resources are used, the
system can efficiently use such resources, which leads to its
high-speed operation as a whole.
[0111] The embodiments of the present invention have been explained
above. However, these embodiments are exemplified merely for the
purpose of explaining the present invention, and the scope of the
invention is not limited only to the illustrated embodiments. The
present invention can be embodied in various ways without departing
from the gist of the invention.
[0112] It should be further understood by those skilled in the art
that although the foregoing description has been made on
embodiments of the invention, the invention is not limited thereto
and various changes and modifications may be made without departing
from the spirit of the invention and the scope of the appended
claims.
* * * * *