WO2011061869A1 - データベース管理方法、データベース管理システム及びデータベース管理プログラム - Google Patents

データベース管理方法、データベース管理システム及びデータベース管理プログラム Download PDF

Info

Publication number
WO2011061869A1
WO2011061869A1 PCT/JP2010/001527 JP2010001527W WO2011061869A1 WO 2011061869 A1 WO2011061869 A1 WO 2011061869A1 JP 2010001527 W JP2010001527 W JP 2010001527W WO 2011061869 A1 WO2011061869 A1 WO 2011061869A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
data
database management
management device
storage location
Prior art date
Application number
PCT/JP2010/001527
Other languages
English (en)
French (fr)
Inventor
熊谷昌大
原憲宏
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US13/389,548 priority Critical patent/US9002796B2/en
Publication of WO2011061869A1 publication Critical patent/WO2011061869A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/184—Distributed file systems implemented as replicated file system
    • G06F16/1844—Management specifically adapted to replicated file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the present invention relates to a database management method, a database management system, and a database management program, and is particularly suitable for application to data linkage between an in-memory database and a disk type database.
  • an in-memory database (hereinafter referred to as “in-memory DB”) is a method in which data is resident in, for example, a volatile memory to provide a high-speed response to an access request. Output is not performed or restricted.
  • the in-memory DB backs up data to a disk-type database (hereinafter referred to as “disk-type DB”) that holds data in an external storage device because data is lost from the memory when the system is stopped. Like to do.
  • Non-Patent Document 4 uses a unique index defined in the tables of two databases to be linked, and records corresponding to each record in the database data are stored in the other database. A technique for uniquely identifying data is disclosed.
  • the unique index used in the data linkage technology described above may not exist in the user's database design. In this case, there are problems such as an increase in time and effort of a user adding a unique index to the database, an increase in usage of the external storage device by storing the unique index, and an increase in processing overhead associated with the update of the unique index.
  • Patent Document 1 discloses a technique that eliminates the need to define a unique index by creating a mapping table of physical storage position information between different databases.
  • Non-Patent Document 3 is a Japanese translation of Non-Patent Document 2
  • the information on the free area is held in the database, so the record is added to This is because the information on the free area is referred to in order to determine the physical storage location information.
  • Patent Document 1 in preparation for re-execution at the time of data linkage failure due to a failure of an external storage device at the data linkage destination, information used at the time of data linkage such as SQL executed at the data linkage destination, It cannot be deleted until data linkage is completed.
  • the in-memory DB is used in a system that processes a large amount of data at a high speed as described above, it is often required to continuously add records. Therefore, if data linkage is delayed, information used during data linkage cannot be deleted and accumulated, and as a result of compressing the capacity of the external storage device, new information cannot be output and records can be added to the in-memory DB. Disappear.
  • the present invention has been made in consideration of the above points, and performs data linkage at a high speed during data linkage when a record is added to the in-memory DB, and continuously accepts addition of records to the in-memory DB.
  • a database management method, a database management system, and a database management program are proposed.
  • one aspect of the present invention provides a first database management device having a main memory in which a first database is arranged, and a second database management device having a secondary storage in which a second database is arranged.
  • a database management method for a system that is connected via a network and reflects data stored in the first and second database management devices to each other, the first database management device adding to the first database A first list that holds storage location information indicating a write destination of data in the second database, and when the first database management device adds arbitrary data to the first database, the data A first step of appending the storage location information from the first list to the first database; A second step of transmitting the data to which the storage location information is added to the second database management device, and requesting the second database management device to add the data; and the second database management In response to a request for addition of the data from the second database management device, a device adds the data to the storage location of the second database indicated by the storage location information added to the data.
  • a database management method comprising the
  • a first database management device having a main memory for arranging a first database and a second database management device having a secondary storage for arranging a second database are connected via a network.
  • a database management method of a system that is connected and reflects data stored in the first and second database management devices to each other, wherein the first database management device includes the second of data to be added to the first database.
  • the data is added to the storage location of the second database.
  • the first database is connected to a second database management apparatus having a secondary storage for arranging the second database, and has a main memory for arranging the first database.
  • a second database management apparatus having a secondary storage for arranging the second database, and has a main memory for arranging the first database.
  • the present invention it is possible to provide a database management method, a database management system, and a database management program that can continuously accept record additions to the first database.
  • reference numeral 1 denotes a database management system according to this embodiment as a whole.
  • the database management system 1 includes an in-memory DB management device 2 (corresponding to “first database management device”), a disk-type DB management device 3 (corresponding to “second database management device”), and a terminal device 4. Are connected via the network 5.
  • a disk-type DB management device 3 is connected to the external storage device 6.
  • the in-memory DB management device 2 is a disk type DB 63 (corresponding to the second database) when there is a request for access from the terminal device 4 to the in-memory database 236 or when the data in the in-memory database 236 is changed. )).
  • the in-memory DB management device 2 includes a CPU 21, an interface 22, and a memory 23.
  • the CPU 21 is a processor that controls the operation of the entire in-memory DB management device 2, and executes necessary processes based on various control programs stored in the memory 23.
  • the interface 22 is connected to the network 5 and performs protocol control during communication between the disk-type DB management device 3 or the terminal device 4 and the in-memory DB management device 2.
  • the memory 23 is composed of a semiconductor memory, a hard disk, and the like, and is used for holding a control program such as an OS (Operating System) and also used as a work memory for the CPU 21.
  • the memory 23 includes a DB access request unit 231, a DB access processing unit 232, a location information management unit 233, a reserved list 235 (corresponding to “first list”), and an in-memory DB 236 (“first database”). ").) Is stored.
  • the DB access request analysis unit 231 analyzes a request from the terminal device 4 or the disk-type DB management device 3, and requests the DB access processing unit 232 to access the in-memory DB 236 according to the analyzed request.
  • the DB access processing unit 232 accesses the in-memory DB 236 in response to a request from the DB access request analysis unit 231.
  • the position information management unit 233 acquires physical storage position information indicating the write destination in the disk type DB 63 of the record to be added to the in-memory DB 236 from the reserved list 235. To do.
  • a physical storage location for example, a physical address of an HDD
  • logical storage location information for example, an HDD or the like is used.
  • the logical address of the logical volume to be stored may be used as data storage location information.
  • the data linkage request unit 234 reflects the update, addition, and deletion in the disk type DB 63 (“corresponds to the second database”). Requests to the DB management device 3.
  • the reserved list 235 stores physical storage position information indicating the reflection destination in the disk type DB 63 of the record to be added to the in-memory DB 236. More specifically, as shown in FIG. 2, the reserved list 235 includes a reserved physical storage location information column 2351 indicating a reflection destination in the disk type DB 63 of a record to be added to the in-memory DB 236 in a table format, and its state.
  • the status field 2352 indicating (in use or unused), a reserved physical storage position information number field 2353, and a used physical storage position information number field 2354 are configured.
  • the reserved list 235 is created based on a reservation instruction list 61 described later.
  • the in-memory DB 236 is a database formed in the semiconductor memory, and includes a table 2361 and an index 2362 as shown in FIGS.
  • the table 2361 includes data and information on physical storage positions of data in the disk type DB 63 corresponding to the data.
  • the index 2362 is used to search the data of the table 2361, and here, information on the physical storage position of the data in the disk type DB 63 is used.
  • the disk-type DB management device 3 manages the entire disk-type DB 63 such as an inquiry to the disk-type DB 63 stored in the external storage device 6 and resource management.
  • the disk-type DB management device 3 includes a CPU 31, an interface 32, a memory 33, and an external storage device input / output interface 34.
  • the CPU 31 is a processor that controls the operation of the entire disk-type DB management device 3, and executes necessary processing based on various control programs stored in the memory 33.
  • the interface 32 is connected to the network 5 and performs protocol control during communication between the in-memory DB management device 2 or the terminal device 4 and the disk-type DB management device 3.
  • the memory 33 is composed of a semiconductor memory, a hard disk, and the like, and is used for holding a control program such as an OS (Operating System) and also used as a work memory for the CPU 31.
  • the memory 33 stores a DB access request unit 331, a DB access processing unit 332, a location information management unit 333, a data linkage request unit 334, a reservation instruction list buffer 335, and a DB buffer 336.
  • the DB access request analysis unit 331 analyzes a request from the terminal device 4 or the in-memory DB management device 2, and requests the DB access processing unit 332 to access the disk type DB 63.
  • the DB access processing unit 332 accesses the disk type DB 63 via the DB buffer 336 in response to a request from the DB access request analysis unit 331.
  • the location information management unit 333 refers to the reservation instruction list 61 via the reservation instruction list buffer 335 and sets the reservation instruction list 61 (“second list”). Corresponding physical storage location information that is not registered.
  • the data linkage request unit 334 requests the in-memory DB management device 2 to reflect the update in the in-memory DB 236.
  • the disk type DB management device 3 is connected to the external storage device 6 via the input / output interface 250.
  • the external storage device 6 stores a reservation instruction list 61, a position information reservation parameter file 62, and a disk type DB 63.
  • the reservation instruction list 61 includes a physical storage position information column 611 indicating a reflection destination in the disk type DB 63 of a record reserved by the user and added to the in-memory DB 236, and a reservation unit indicating a unit of the size.
  • the disk-type DB management device 3 refers to the reservation instruction list 61 via the reservation instruction list buffer 335.
  • the reservation unit is a unit in which a user reserves a physical storage position, and is any one of a file, an extent, a page, and a record.
  • the file is a unit for storing the data of the database in the external storage device 6 as one chunk, and is composed of one or more extents.
  • An extent is a unit for allocating an area in a file and is composed of one or more pages.
  • a page is an input / output unit of an external storage device, and is composed of one or more records.
  • the location information reservation parameter file 62 is a file created in advance for the user to reserve physical storage location information.
  • the reservation instruction list 61 is created by reading a plurality of position information reservation parameter files 62.
  • the position information reservation parameter file 62 reserved physical storage position information is registered for each table.
  • the reservation unit may be specified in a unit in which a plurality of records such as a file, an extent, and a page are collected. For example, in the example shown in FIG. 4, in the location information reservation parameter file 62 named “Table 1”, “# 3-1”, “# 3-2”, and “# 3-3” are reserved in record units. Then, “# 5” and “# 6” are reserved in page units, “EXT3” is reserved in extent units, and “FILE2” is reserved in file units.
  • the disk type DB 63 is formed in the hard disk device and includes a table 631 as shown in FIGS.
  • the table 631 holds each data in each storage position indicated by the physical storage position 632.
  • the present invention provides, for example, a case where the memory 23 of the in-memory DB management device 2 is positioned as the main memory.
  • Various storage devices can be applied as long as they function as a storage area as a storage memory.
  • an optical disk, a non-volatile semiconductor device for example, SSD (Solid state disk) or the like may be used.
  • the “disk” includes these rotating magnetic disks (HDD and the like), optical disks, and nonvolatile semiconductor devices.
  • the in-memory DB 236 When the in-memory DB 236 receives a request for adding a record (“CCC” in the example of FIG. 5), the in-memory DB 236 stores the reserved information acquired by referring to the record “CCC”, the index 2362, and the reserved list 235 in the table 2361. Physical storage location information “# 3-1” is added.
  • the in-memory DB 236 adds the physical storage location information “# 3-1” to the record “CCC” and transmits it to the disk type DB 63, and makes a record addition request to the disk type DB 63.
  • the disk-type DB 63 receives the record addition request and adds the record “CCC” to the position indicated by the physical storage position information “# 3-1” in the table 112.
  • the database management system 1 when the database management system 1 adds a record to the in-memory DB 236, the database management system 1 refers to the reserved list 235 and determines the physical storage location information 632 of the disk type DB 63 that is the data linkage destination. As a result, even if the table 631 of the disk type DB 63 is not referred to, the in-memory DB management device 236 that is the data linkage source can determine the linkage destination, and the data linkage performance can be improved.
  • the disk-type DB 63 receives a request for adding a record (“DDD” in the example of FIG. 6), the record “DDD” is added to the table 631.
  • the physical storage locations registered in the reservation instruction list 61 (“# 3-1”, “# 3-2” in the example of FIG. 6) "And” # 3-3 ") do not store records.
  • the disk-type DB 63 adds the physical storage position information 113 (“# 4-1” in the example of FIG. 6) indicating the position where the record “DDD” is stored to the record “DDD” and transmits it to the in-memory DB 236.
  • the in-memory DB 236 is requested to add the record “DDD”.
  • the in-memory DB 236 receives the request for adding the record “DDD”, and adds the record “DDD” and the physical storage location information “# 4-1” to the free area of the table 2361.
  • the in-memory DB 236 adds the physical storage location information “# 4-1” to the index 2362.
  • the database management system 1 sets the physical storage location information 632 of the disk type DB 63 to which the record is added in the table 2361 of the in-memory DB 236. Since the record added to the in-memory DB 236 does not use the reserved physical storage position information, it is not necessary to change the reserved list 235.
  • the DB access request analysis unit 231 of the in-memory DB management device 2 analyzes the update request SQL for the in-memory DB 236 from the terminal device 4.
  • the SQL type is determined (SP101), and it is determined whether the SQL type is addition, update, or deletion (SP102).
  • step SP102 when the SQL type is added, the DB access processing unit 232 determines a record addition destination (SP103).
  • the location information management unit 233 refers to the reserved list 235 and acquires one reserved physical storage location information from the head of the reserved list 104 (SP104), and the DB access processing unit 232 acquires the table 2361.
  • the reserved physical storage position information and the record are added (SP105), and the process proceeds to step SP114.
  • step SP102 when the SQL type is update, the DB access processing unit 232 selects a record to be updated (SP106), and determines whether or not there is a record to be selected (SP107). If a negative result is obtained in step SP107 (SP107: NO), the process is terminated.
  • SP107: YES When a positive result is obtained in step SP107 (SP107: YES), the location information management unit 233 refers to the index 2362 to acquire physical storage location information (SP108), and the DB access processing unit 232 uses the table 2361.
  • the record at is updated (SP109), and the process proceeds to step SP114.
  • step SP102 when the SQL type is deletion, the DB access processing unit 262 selects a record to be deleted (SP110), and determines whether or not there is a record to be selected (SP111). If a negative result is obtained in step SP111 (SP111: NO), the process is terminated. If a positive result is obtained in step SP111 (SP111: YES), the location information management unit 263 refers to the index 2362 to acquire physical storage location information (SP112), and the DB access processing unit 262 displays the table 2361. Is deleted (SP113), and the process proceeds to step SP114.
  • the data linkage request unit 234 After adding, updating, or deleting records in steps SP105, SP109, and SP113, the data linkage request unit 234 generates data linkage SQL for data linkage to the disk type DB 111 (SP114). However, the data linkage SQL includes a record to which the acquired physical storage position information is added. Then, the data linkage request unit 234 transmits the data linkage SQL to the disk-type DB management device 3 and requests the execution thereof (SP115).
  • step SP116 determines whether or not the processing has been completed for all records described in the SQL (SP116). If a positive result is obtained in step SP116 (SP116: YES), the process is terminated. If a negative result is obtained in step SP116 (SP116: NO), the processing is repeated from step SP102.
  • the DB access request analysis unit 331 of the disk type DB management device 3 receives the data linkage SQL transmitted by the in-memory DB management device 2 in step SP115 (SP201), the DB access request analysis unit 331 performs the processing for the disk type DB 63.
  • the data linkage SQL is analyzed to determine the SQL type (SP202), and it is determined whether the SQL type is addition, update, or deletion (SP203).
  • step SP203 when the type of the data linkage SQL is added, the DB access processing unit 332 determines the addition destination of the record included in the data linkage SQL from the physical storage location information included in the data linkage SQL (SP204). Then, the DB access processing unit 332 adds a record to the addition destination determined in step SP204 in the table 631 (SP205), and proceeds to step SP212.
  • step SP203 when the SQL type is update, the DB access processing unit 332 selects a record to be updated (SP206), and determines whether or not a record to be selected exists (SP207). If a negative result is obtained in step SP207 (SP207: NO), the process ends. When an affirmative result is obtained in step SP207 (SP207: YES), the DB access processing unit 332 updates the record stored in the storage location indicated by the physical storage location information included in the data linkage SQL in the table 631 (SP208). ), The process proceeds to step SP212.
  • step SP203 when the SQL type is deletion, the DB access processing unit 332 selects a record to be deleted (SP209), and determines whether or not a record to be selected exists (SP210). If a negative result is obtained in step SP210, the process ends (SP210: NO). When an affirmative result is obtained in step SP210 (SP210: YES), the DB access processing unit 332 deletes the record stored in the storage location indicated by the physical storage location information included in the data linkage SQL in the table 631 (SP211). ), The process proceeds to step SP212.
  • the disk-type DB management device 3 determines whether or not the processing has been completed for all records described in SQL (SP212). If an affirmative result is obtained in step SP212 (SP212: YES), the process is terminated. If a negative result is obtained in step SP212 (SP212: NO), the processing is repeated from step SP203. In this way, the update of the in-memory DB 236 is linked to the disk type DB 63.
  • disk type DB 63 update processing when an update request is made from the terminal device 4 to the disk type DB 63 will be described with reference to FIG.
  • the DB access request analysis unit 331 of the disk-type DB management device 3 analyzes the received update request SQL, The SQL type is determined (SP301), and it is determined whether the SQL type is addition, update, or deletion (SP302).
  • step SP302 when the SQL type is added, the DB access processing unit 332 determines the addition destination of the record (SP303).
  • the position information management unit 263 refers to the reservation instruction list 61 to determine whether or not the addition destination matches the physical storage position information with the reservation instruction (SP304). If a positive result is obtained in step SP304 (SP304: YES), the process returns to step SP303. When a negative result is obtained in step SP304 (SP304: NO), a record is added to the addition destination determined in step SP303 (SP305), and the process proceeds to step SP314.
  • step SP302 when the SQL type is update, the DB access processing unit 332 selects a record to be updated (SP306), and determines whether there is a record to be selected (SP307). If a negative result is obtained in step SP307 (SP307: NO), the process ends. If a positive result is obtained in step SP307 (SP307: YES), the location information management unit 333 acquires physical storage location information (SP308), and the DB access processing unit 332 updates the record (SP309). .
  • step SP302 when the SQL type is deletion, the DB access processing unit 332 selects a record to be deleted (SP310), and determines whether there is a record to be selected (SP311). If a negative result is obtained in step SP311 (SP311: NO), the process ends.
  • step SP311 when a positive result is obtained (SP311: YES), the location information management unit 333 acquires physical storage location information (SP312), and the DB access processing unit 332 deletes the record (SP313). .
  • the data linkage request unit 334 In steps SP305, SP309, and SP313, after adding, updating, or deleting a record, the data linkage request unit 334 generates a data linkage SQL for data linkage to the in-memory DB 236 (SP314).
  • the data linkage SQL includes a record to which the physical storage information of the addition destination or the acquired physical storage information is added. Then, the data linkage request unit 334 transmits the data linkage SQL to the in-memory DB management device 2 and requests the execution thereof (SP315).
  • the disk-type DB management device 3 determines whether or not the processing has been completed for all the records described in SQL (SP316). If a positive result is obtained in step SP316 (SP316: YES), the process is terminated. If a negative result is obtained in step SP316 (SP316: NO), the processing is repeated from step SP302.
  • the DB access request analysis unit 231 of the in-memory DB management device 2 receives the data linkage SQL transmitted by the disk-type DB management device 3 in step SP315 (SP401), the DB access request analysis unit 231 performs the process for the in-memory DB 236.
  • the data linkage SQL is analyzed to determine the SQL type (SP402), and it is determined whether the SQL type is addition, update, or deletion (SP403).
  • step SP403 when the type of the data linkage SQL is added, the DB access processing unit 232 determines the addition destination of the record included in the data linkage SQL from the physical storage location information included in the data linkage SQL (SP404). Then, the DB access processing unit 232 adds a record to the addition destination determined in step SP404 in the table 2361 (SP405), and proceeds to step SP412.
  • step SP403 if the SQL type is update, the DB access processing unit 232 selects a record to be updated (SP406), and determines whether there is a record to be selected (SP407). If a negative result is obtained in step SP407 (SP407: NO), the process ends. If an affirmative result is obtained in step SP407 (SP407: YES), the DB access processing unit 232 updates the record stored in the storage location indicated by the physical storage location information included in the data linkage SQL in the table 2361 (SP408). ), And proceeds to step SP412.
  • step SP403 if the SQL type is deletion, the DB access processing unit 232 selects a record to be deleted (SP409), and determines whether or not there is a record to be selected (SP410). If a negative result is obtained in step SP410 (SP410: NO), the process is terminated. When an affirmative result is obtained in step SP410 (SP410: YES), the DB access processing unit 232 deletes the record stored in the storage position indicated by the physical storage position information included in the data linkage SQL in the table 2361 (SP411). ), The process proceeds to step SP412.
  • step SP412 After adding, updating, or deleting records in steps SP405, SP408, and SP411, the in-memory DB management device 2 determines whether or not processing has been completed for all records described in SQL (SP412). In step SP412, when a positive result is obtained (SP412: YES), the process is terminated. If a negative result is obtained in step SP412 (SP412: NO), the processing is repeated from step SP403. In this way, the update of the disk type DB 63 is linked to the in-memory DB 236.
  • the in-memory DB management device 2 creates the in-memory DB 236, the in-memory DB management device 2 notifies the disk-type management device 3 that the in-memory DB 236 has been created.
  • the DB access processing unit 332 exports the data of the disk type DB 63 via the DB buffer 336 (SP501).
  • the location information management unit 333 exports the reserved physical storage location information of the reservation instruction list 61 via the reservation instruction list buffer 335 (SP502), and the data linkage request unit 334 outputs the in-memory DB management device 2 Then, a request for reading the exported data is made (SP503).
  • the disk type DB device 3 determines whether or not all data of the disk type DB 63 and all reserved physical storage position information of the reservation instruction list 61 have been read (SP504). If a positive result is obtained in step SP504, the process ends. If a negative result is obtained in step SP504, the process returns to step SP501.
  • the disk-type DB device 3 exports all the data in the disk-type DB 63 and all the reserved physical storage position information in the reservation instruction list 61, and makes a read request for the exported data to the in-memory DB 236.
  • the DB access processing unit 262 displays the table in the in-memory DB 236.
  • the data of the disk type DB 63 is imported to 2361 (SP602).
  • the location information management unit 263 creates an index 2362 (SP603), creates a reserved list 235 based on the read reserved physical storage location information (SP604), and ends the processing.
  • the location information management unit 333 of the disk type DB management device 3 reads the location information reservation parameter file 62 created by the user (SP701), and registers the contents of the parameter file in the reservation instruction list 61 (SP702).
  • the disk-type DB management device 3 determines whether or not all the location information reservation parameter files 62 have been read (SP703). If an affirmative result (SP703: YES) is obtained in step SP703, the process ends. If a negative result is obtained in step SP703 (SP703: NO), the process returns to step SP701.
  • the user can create a plurality of location information reservation parameter files 62 and can create a reservation instruction list 61 from the plurality of location information reservation parameter files 62.
  • the location information management unit 233 of the in-memory DB management device 2 acquires the reserved physical storage location information from the reserved list 235, the top information among the unused location information in the reserved list 235. Is changed to in use (SP801).
  • the location information management unit 233 subtracts “1” from the number of used physical storage location information 2354 in the reserved list 104 (SP802).
  • the location information management unit 233 determines whether the usage rate, which is the ratio of the number of physical storage location information in use to the number of reserved physical storage location information, is 80% or more (SP803).
  • step SP803 When a negative result is obtained in step SP803 (that is, when the usage rate is 80% or more (SP803: YES)), it is determined that replenishment is not necessary, and the process is terminated at that point.
  • step SP803 if a positive result is obtained (that is, if the usage rate is less than 80% (SP803: NO)), the location information management unit 233 supplements the disk type DB management device 3 with reserved physical storage location information. (SP804), a reserved list link request from the disk-type DB management apparatus 3 is accepted (SP805), the reserved list 235 is linked and supplemented (SP806), and the process is terminated.
  • the position information management unit 333 of the disk-type DB management apparatus 3 calculates the replenishment size (SP902).
  • the position information management unit 333 secures physical storage positions in the disk type DB 63 by the calculated replenishment size, replenishes the reserved physical storage position information in the reservation instruction list 61 (SP903), and the in-memory DB management device 2 makes a request for interlocking with the reserved list 235 (SP904), and the processing is terminated.
  • the reserved physical storage position information in use increases, the reserved physical storage position information that is not in use can always be secured by securing and supplementing the physical storage position information. it can.
  • FIG. 14 is a diagram illustrating an example of a display result of reserved physical storage location information.
  • the reserved physical storage location information can be classified for each table in the in-memory DB 236. For example, the user displays the table name, the usage rate of the reserved physical storage location information, and the location information in use for each table using an interface such as a command.
  • the reserved physical storage position information is obtained from the reservation instruction list 61 by the position information management unit 333 of the disk type DB management apparatus 3.
  • the position information is composed of a file, an extent, a page, and a record.
  • the usage rate of the reserved physical storage location information is obtained from the reserved list 235 by the following formula using the location information management unit 233 of the in-memory DB management device 2.
  • Usage rate of reserved physical storage location information number of physical storage location information in use ⁇ number of reserved physical storage location information
  • the reserved list 235 is held in a table format, but may be held in an index format.
  • the reserved physical storage position information is held as the index key 2356 in the index entry 2355 constituting the index, and the physical storage position information 2357 is held together with the index key 2356. it can.
  • the index key 2356 indicates the storage position of the record in the disk type DB 63
  • the physical storage position information 2357 indicates the storage position of the corresponding record in the in-memory DB 236.
  • the physical storage location information 2357 is “0”, it indicates that the storage location of the in-memory DB 236 indicated by the reserved physical storage location information is unused.
  • the physical storage position information 632 in the disk type DB 63 is used as an index.
  • uniqueness can be ensured between the data stored in the in-memory DB 236 and the data stored in the disk type DB 63. If an index exists, the unique index may be used.
  • FIG. 16 is a conceptual diagram showing an update process of the in-memory DB in which a unique key exists.
  • the in-memory DB 236 accepts a record (“CCC” in the example of FIG. 16) addition request, and stores the record “CCC” in the table 2363 and a unique key (“0004” in the example of FIG. 16) acquired from the reserved list 235. to add.
  • the unique key “0004” is added to the record “CCC”, and a record addition request is made to the disk type DB 63. Thereafter, the disk-type DB 63 stores the record “CCC” in the physical storage position to which the unique key “0004” is added.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】第１のデータベースを配置する主記憶を有する第１データベース管理装置へのレコード追加を継続的に受け付けることのできるデータベース管理方法、データベース管理システム及びデータベース管理プログラムを提供する。 【解決手段】データベース管理方法において、第１データベース管理装置は、第１のデータベースに追加するデータの第２のデータベースにおける書き出し先を示す格納位置情報を保持するリストを有し、第１データベース管理装置が、第１のデータベースに任意のデータが追加された時に、当該データにリストから格納位置情報を付加する第１のステップと、格納位置情報を付加したデータを第２のデータベース管理装置に送信し、当該データの追加を要求する第２のステップとを、第２データベース管理装置が、該データの追加の要求に応じて、データに付加された格納位置情報が示す第２のデータベースの格納位置にデータを追加する第３のステップと、を有する。

Description

データベース管理方法、データベース管理システム及びデータベース管理プログラム
　本発明は、データベース管理方法、データベース管理システム及びデータベース管理プログラムに関し、特にインメモリデータベースとディスク型データベースとの間におけるデータ連動に適用して好適なものである。
　従来、インメモリデータベース（以下、「インメモリＤＢ」という。）は、アクセス要求に対する高速なスポンスを提供するために、データを例えば揮発性メモリ上に常駐させ、時間のかかる外部記憶装置への入出力を行わない或いは制限するようになっている。
　ところで、データベース管理システムにおいて、インメモリＤＢは、データがシステム停止時にメモリ上から消失するため、外部記憶装置にデータを保持するディスク型データベース（以下、「ディスク型ＤＢ」という。）にデータをバックアップするようにしている。
　データをディスク型ＤＢにバックアップするためには、インメモリＤＢとディスク型ＤＢとのデータを一致させるデータ連動の技術が必要となる。
　データ連動の技術において、非特許文献４には、連動させる２つのデータベースのテーブルに定義されたユニークインデクスを利用することで、データベースのデータ内の各レコードに対応するレコードを、もう一方のデータベースのデータから一意に識別する技術が開示されている。
　上述したデータ連動の技術で利用されるユニークインデクスは、ユーザのデータベース設計では存在しない場合がある。この場合、ユニークインデクスをデータベースに追加するユーザの手間の増加、ユニークインデクスを格納することによる外部記憶装置の使用量の増加、ユニークインデクスの更新に伴う処理オーバヘッドの増加という問題がある。
　この問題に対して、特許文献１には、異なるデータベース間の物理格納位置情報のマッピング表を作成することで、ユニークインデクスの定義を不要とする技術が開示されている。
　そして、データ連動元にレコードを追加した際、データ連動元へアクセスするだけでなく、データ連動先にもアクセスし、データ連動先が決定した物理格納位置情報を取得して、当該レコードのデータ連動が完了するようになっている。
　これは、非特許文献２及び３に記述されているように（非特許文献３は非特許文献２の日本語訳）、データベース内に空き領域の情報を保持しているため、レコードの追加先である物理格納位置情報を決定するために、当該空き領域の情報を参照するからである。
特開２００１-２７３１７５号公報
松浦　龍夫著「日経システム構築２００６年３月号　特集　使える！インメモリーＤＢ」、日経ＢＰ社、２００６年２月２６日、Ｐ．５０－Ｐ．５２ Jim Gray and Andreas Reuter、Transaction Processing：Concepts and Techniques、Morgan Kaufmann Publishers、１９９３年、Ｐ．７５７－Ｐ．７６０ ジム・グレイ(著)、アンドレアス・ロイター(著)、喜連川　優（翻訳）「トランザクション処理〈下〉―概念と技法」、日経ＢＰ社、２００１年１０月、Ｐ．８９７－Ｐ．９００ Marie Buretta著「Data Replication: Tools and Techniques for Managing Distributed Information」WILEY COMPUTER PUBLISHING、１９９７年、Ｐ．１４４
　しかしながら、特許文献１の技術では、データ連動先の外部記憶装置の障害等を原因とするデータ連動失敗時の再実行に備え、データ連動先で実行するＳＱＬなどのデータ連動時に利用する情報を、データ連動が完了するまで削除することができない。
　ここで、インメモリＤＢは、前述のように大量のデータを高速に処理するシステムで使用するため、レコードの追加が継続的に要求されることが多い。そのため、データ連動が遅延すると、データ連動時に利用する情報が削除できずに蓄積し、外部記憶装置の容量を圧迫する結果、新たな情報の出力ができなくなり、インメモリＤＢへレコードの追加ができなくなる。
　本発明は以上の点を考慮してなされたもので、インメモリＤＢへレコードを追加した際のデータ連動時に高速にデータ連動を行い、インメモリＤＢへのレコードの追加を継続的に受け付けることのできるデータベース管理方法、データベース管理システム及びデータベース管理プログラムを提案するものである。
　かかる課題を解決するため、本発明の一側面は、第１のデータベースを配置する主記憶を有する第１データベース管理装置と、第２のデータベースを配置する二次記憶を有する第２データベース管理装置とがネットワークを介して接続され、前記第１及び第２データベース管理装置が格納するデータを互いに反映させるシステムのデータベース管理方法であって、前記第１データベース管理装置は、前記第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報を保持する第１のリストを備え、前記第１データベース管理装置が、前記第１のデータベースに任意のデータが追加された時に、当該データに前記第１のリストから前記格納位置情報を付加する第１のステップと、前記第１データベース管理装置が、前記格納位置情報を付加した前記データを前記第２データベース管理装置に送信し、該第２データベース管理装置に当該データの追加を要求する第２のステップと、前記第２データベース管理装置が、前記第２データベース管理装置からの前記データの追加の要求に応じて、前記データに付加された前記格納位置情報が示す前記第２のデータベースの格納位置に前記データを追加する第３のステップと、を有することを特徴とするデータベース管理方法。
　さらに、本発明の一側面は、第１のデータベースを配置する主記憶を有する第１データベース管理装置と、第２のデータベースを配置する二次記憶を有する第２データベース管理装置とがネットワークを介して接続され、前記第１及び第２データベース管理装置が格納するデータを互いに反映させるシステムのデータベース管理方法であって、前記第１データベース管理装置は、前記第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報を保持する第１のリストを備え、前記第１のデータベースに任意のデータが追加された時に、当該データに前記第１のリストから前記格納位置情報を付加し、当該格納位置情報を付加した当該データを前記第２データベース管理装置に送信し、前記第２データベース管理装置に当該データの追加を要求し、前記第２データベース管理装置は、前記第１データベース管理装置からの前記データの追加の要求に応じて、前記データに付加された前記格納位置情報が示す前記第２のデータベースの格納位置に前記データを追加することを特徴とする。
　さらに、本発明の一側面は、データベース管理プログラムにおいて、第２のデータベースを配置する二次記憶を有する第２データベース管理装置に接続され、第１のデータベースを配置する主記憶を有するとともに該第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報を保持する第１のリストを有する第１データベース管理装置に、前記第１のデータベースに任意のデータが追加された時に、当該データに前記第１のリストから前記格納位置情報を付加する第１のステップと、前記格納位置情報を付加した前記データを前記第２データベース管理装置に送信し、該第２データベース管理装置に当該データの追加を要求する第２のステップと、を実行させることを特徴とする。
　本発明によれば、第１のデータベースへのレコード追加を継続的に受け付けることのできるデータベース管理方法、データベース管理システム及びデータベース管理プログラムを提供することができる。
本実施の形態によるデータベース管理システムの構成を示すブロック図である。 予約済みリストを説明するための図である。 予約指示リストを説明するための図である。 位置情報予約パラメタファイルを説明するための図である。 本実施の形態によるデータベース管理システムの動作を説明するための概念図である。 本実施の形態によるデータベース管理システムの動作を説明するための概念図である。 インメモリデータベース更新処理を説明するためのフローチャートである。 ディスク型データベース反映処理を説明するためのフローチャートである。 ディスク型データベース更新処理を説明するためのフローチャートである。 インメモリ型データベース反映処理を説明するためのフローチャートである。 予約済みリスト作成処理を説明するためのフローチャートである。 予約指示リスト作成処理を説明するためのフローチャートである。 予約済みリスト補充処理を説明するためのフローチャートである。 予約済み物理格納位置情報の表示結果の例を示す図である。 他の実施の形態による予約済みリストを説明するための図である。 他の実施の形態によるデータベース管理システムの動作を説明するための概念図である。
　以下、図面を用いて、本発明の一実施の形態を詳述する。
（１）本実施の形態によるデータベース管理システムのハードウェア構成
　図１において、１は全体として本実施の形態によるデータベース管理システムを示す。データベース管理システム１は、インメモリＤＢ管理装置２（「第１データベース管理装置」に相当する。）とディスク型ＤＢ管理装置３（「第２のデータベース管理装置」に相当する。）と端末装置４とがネットワーク５を介して接続されている。また、ディスク型ＤＢ管理装置３が外部記憶装置６に接続されている。
　インメモリＤＢ管理装置２は、端末装置４からインメモリデータベース２３６へアクセス要求があった場合の管理やインメモリデータベース２３６のデータに変更があった場合のディスク型ＤＢ６３（第２のデータベースに相当する。）への反映等を行う。また、インメモリＤＢ管理装置２は、ＣＰＵ２１とインタフェース２２とメモリ２３とを備える。
　ＣＰＵ２１は、インメモリＤＢ管理装置２全体の動作制御を司るプロセッサであり、メモリ２３に格納された各種制御プログラムに基づいて必要な処理を実行する。インタフェース２２は、ネットワーク５に接続され、ディスク型ＤＢ管理装置３又は端末装置４とインメモリＤＢ管理装置２との間の通信時にプロトコル制御を行う。
　メモリ２３は、半導体メモリ、ハードディスク等から構成され、ＯＳ（Operating System）などの制御プログラムを保持するために用いられるほか、ＣＰＵ２１のワークメモリとしても用いられる。また、メモリ２３は、ＤＢアクセス要求部２３１とＤＢアクセス処理部２３２と位置情報管理部２３３と予約済みリスト２３５（「第１のリスト」に相当する。）とインメモリＤＢ２３６（「第１のデータベース」に相当する。）とを格納する。
　ＤＢアクセス要求解析部２３１は、端末装置４又はディスク型ＤＢ管理装置３からの要求を解析し、解析した要求に応じて、インメモリＤＢ２３６へのアクセスをＤＢアクセス処理部２３２に要求する。
　ＤＢアクセス処理部２３２は、ＤＢアクセス要求解析部２３１の要求に応じて、インメモリＤＢ２３６にアクセスする。
　位置情報管理部２３３は、インメモリＤＢ２３６へのアクセス要求がレコードの追加である場合、予約済みリスト２３５から、インメモリＤＢ２３６に追加するレコードのディスク型ＤＢ６３における書き出し先を示す物理格納位置情報を取得する。
　なお、本実施の形態では、データの格納位置情報として、物理的格納位置（例えば、ＨＤＤの物理的なアドレス等を適用する例について説明するが、論理的格納位置情報（例えば、ＨＤＤ等から構成される論理ボリュームの論理アドレス等）をデータの格納位置情報としてもよい。
　データ連動要求部２３４は、インメモリＤＢ２３６に更新、追加及び削除等があった場合、その更新、追加及び削除をディスク型ＤＢ６３（「第２のデータベースに相当する。」に反映させるようにディスク型ＤＢ管理装置３に要求する。
　予約済みリスト２３５は、インメモリＤＢ２３６に追加するレコードのディスク型ＤＢ６３における反映先を示す物理格納位置情報を格納する。詳細に説明すると、予約済みリスト２３５は、図２に示すように、テーブル形式で、インメモリＤＢ２３６に追加するレコードのディスク型ＤＢ６３における反映先を示す予約済み物理格納位置情報欄２３５１と、その状態（使用中又は未使用）を示す状態欄２３５２と、予約済み物理格納位置情報数欄２３５３と、使用中物理格納位置情報数欄２３５４とから構成される。また、予約済みリスト２３５は、後述する予約指示リスト６１に基づいて作成される。
　インメモリＤＢ２３６は、半導体メモリ内に形成されるデータベースであり、図５及び６に示すように、テーブル２３６１とインデクス２３６２とを備える。
　テーブル２３６１は、データと、そのデータに対応するディスク型ＤＢ６３におけるデータの物理格納位置の情報とから構成される。インデクス２３６２は、テーブル２３６１のデータを検索するために用いられ、ここでは、ディスク型ＤＢ６３におけるデータの物理格納位置の情報が用いられている。
　ディスク型ＤＢ管理装置３は、外部記憶装置６が格納するディスク型ＤＢ６３に対する問い合わせやリソース管理などのディスク型ＤＢ６３全体の管理を行う。また、ディスク型ＤＢ管理装置３は、ＣＰＵ３１とインタフェース３２とメモリ３３と外部記憶装置入出力インタフェース３４とを備える。
　ＣＰＵ３１は、ディスク型ＤＢ管理装置３全体の動作制御を司るプロセッサであり、メモリ３３に格納された各種制御プログラムに基づいて必要な処理を実行する。インタフェース３２は、ネットワーク５に接続され、インメモリＤＢ管理装置２又は端末装置４とディスク型ＤＢ管理装置３との間の通信時にプロトコル制御を行う。
　メモリ３３は、半導体メモリ、ハードディスク等から構成され、ＯＳ（Operating System）などの制御プログラムを保持するために用いられるほか、ＣＰＵ３１のワークメモリとしても用いられる。また、メモリ３３は、ＤＢアクセス要求部３３１とＤＢアクセス処理部３３２と位置情報管理部３３３とデータ連動要求部３３４と予約指示リストバッファ３３５とＤＢバッファ３３６とを格納する。
　ＤＢアクセス要求解析部３３１は、端末装置４又はインメモリＤＢ管理装置２からの要求を解析し、ＤＢアクセス処理部３３２に、ディスク型ＤＢ６３へのアクセスを要求する。
　ＤＢアクセス処理部３３２は、ＤＢアクセス要求解析部３３１の要求に応じて、ＤＢバッファ３３６を介して、ディスク型ＤＢ６３にアクセスする。
　位置情報管理部３３３は、ディスク型ＤＢ６３に対するアクセス要求がレコードの追加である場合、予約指示リストバッファ３３５を介して、予約指示リスト６１を参照し、予約指示リスト６１（「第２のリスト」に相当する。）に登録されていない物理格納位置情報を取得する。
　データ連動要求部３３４は、ディスク型ＤＢ６３に更新があった場合、その更新をインメモリＤＢ２３６に反映させるようにインメモリＤＢ管理装置２に要求する。
　ディスク型ＤＢ管理装置３は、外部記憶装置６と入出力インタフェース２５０を介して接続されている。
　外部記憶装置６は、予約指示リスト６１と位置情報予約パラメタファイル６２とディスク型ＤＢ６３とを格納する。
　予約指示リスト６１は、図３に示すように、ユーザが予約した、インメモリＤＢ２３６に追加するレコードのディスク型ＤＢ６３における反映先を示す物理格納位置情報欄６１１と、そのサイズの単位を示す予約単位欄６１２とから構成される。ディスク型ＤＢ管理装置３は、予約指示リストバッファ３３５を介して予約指示リスト６１を参照する。予約単位は、ユーザが物理格納位置を予約する単位であり、ファイル、エクステント、ページ及びレコードの何れかである。ここで、ファイルは、データベースのデータを外部記憶装置６に１つのかたまりとして格納するため単位であり、１つ以上のエクステントから構成される。エクステントは、ファイル中の領域を割り当てる単位であり、１つ以上のページから構成される。ページは、外部記憶装置の入出力の単位であり、１つ以上のレコードから構成される。
　位置情報予約パラメタファイル６２は、ユーザが物理格納位置情報を予約するために、事前に作成するファイルである。予約指示リスト６１は、複数の位置情報予約パラメタファイル６２を読み込むことによって作成される。位置情報予約パラメタファイル６２には、テーブル毎に、予約済み物理格納位置情報を登録する。予約の単位は、レコード単位の他、ファイル、エクステント、ページという複数のレコードをまとめた単位での指定をしても良い。例えば、図４に示す例において、「表１」という名前の位置情報予約パラメタファイル６２には、レコード単位で「＃３－１」、「＃３－２」及び「＃３－３」が予約され、ページ単位で「＃５」及び「＃６」が予約され、エクステント単位で「ＥＸＴ３」が予約され、ファイル単位で「ＦＩＬＥ２」が予約されている。
　ディスク型ＤＢ６３は、ハードディスク装置内に形成され、図５及び６に示すようにテーブル６３１を備える。テーブル６３１は、物理格納位置６３２が示す各格納位置に各データを保持する。なお、本実施形態では、ディスク型ＤＢ６３をハードディスク装置内に形成する例について説明するが、本発明は、例えば、インメモリＤＢ管理装置２のメモリ２３を主記憶メモリと位置付けた場合に、二次記憶メモリとしての記憶領域として機能するものであれば、種々の記憶デバイスを適用することができる。例えば、光学ディスク、不揮発の半導体デバイス（例えば、ＳＳＤ（Solid state disk））等でもよい。本実施の形態において、「ディスク」とは、これら回転磁気ディスク（ＨＤＤ等）、光学ディスク及び不揮発の半導体デバイスを含むものとする。
（２）データベース管理システムの動作の概要
　次に、図５及び６を参照して、データベース管理システム１の動作を簡単に説明する。
　インメモリＤＢ２３６は、レコード（図５の例では「ＣＣＣ」）の追加要求を受け付けた場合に、テーブル２３６１にレコード「ＣＣＣ」と、インデクス２３６２と予約済みリスト２３５を参照して取得した予約済みの物理格納位置情報「＃３－１」とを追加する。
　その後、インメモリＤＢ２３６は、物理格納位置情報「＃３－１」をレコード「ＣＣＣ」に付加してディスク型ＤＢ６３に送信し、ディスク型ＤＢ６３に対してレコード追加要求を行う。
　ディスク型ＤＢ６３は、前記レコード追加要求を受け付け、テーブル１１２の前記物理格納位置情報「＃３－１」が示す位置にレコード「ＣＣＣ」を追加する。
　以上のように、データベース管理システム１は、インメモリＤＢ２３６へレコードを追加した際に予約済みリスト２３５を参照し、データ連動先であるディスク型ＤＢ６３の物理格納位置情報６３２を決定する。これにより、ディスク型ＤＢ６３のテーブル６３１を参照しなくとも、データ連動元であるインメモリＤＢ管理装置２３６で連動先を判別することができ、データ連動性能を向上することが可能である。
　また、ディスク型ＤＢ６３が、レコード（図６の例では「ＤＤＤ」）追加要求を受け付けた場合、テーブル６３１にレコード「ＤＤＤ」を追加する。この時、予約指示リストバッファ３３５を介して、予約指示リスト６１を参照し、予約指示リスト６１に登録されている物理格納位置（図６の例では「＃３－１」、「＃３－２」及び「＃３－３」）にはレコードを格納しないようにする。
　その後、ディスク型ＤＢ６３は、レコード「ＤＤＤ」を格納した位置を示す物理格納位置情報１１３（図６の例では「＃４－１」）をレコード「ＤＤＤ」に付加してインメモリＤＢ２３６に送信し、インメモリＤＢ２３６に対して、レコード「ＤＤＤ」の追加を要求する。
　インメモリＤＢ２３６は、レコード「ＤＤＤ」の追加要求を受け付け、テーブル２３６１の空き領域にレコード「ＤＤＤ」及び物理格納位置情報「＃４－１」を追加する。また、インメモリＤＢ２３６は、インデクス２３６２に物理格納位置情報「＃４－１」を追加する。
　以上のように、データベース管理システム１は、ディスク型ＤＢ６３へレコードを追加した場合に、当該レコードの追加先であるディスク型ＤＢ６３の物理格納位置情報６３２をインメモリＤＢ２３６のテーブル２３６１に設定する。インメモリＤＢ２３６に追加されたレコードは、予約済みの物理格納位置情報を利用しないため、予約済みリスト２３５を変更する必要が無い。
（３）データベース管理システム１における具体的な処理
（３－１）インメモリデータベース更新処理
　ここで、図７を参照して、端末装置４からインメモリＤＢ２３６へ更新要求があった場合のインメモリＤＢ２３６の更新処理を説明する。
　まず、インメモリＤＢ管理装置２が端末装置４から更新要求ＳＱＬを受信すると、インメモリＤＢ管理装置２のＤＢアクセス要求解析部２３１は、端末装置４からのインメモリＤＢ２３６に対する更新要求ＳＱＬの解析を行いＳＱＬの種別を決定し（ＳＰ１０１）、ＳＱＬの種別が追加、更新、削除の何れかであるかを判別する（ＳＰ１０２）。
　ステップＳＰ１０２において、ＳＱＬの種別が追加の場合、ＤＢアクセス処理部２３２は、レコードの追加先を決定する（ＳＰ１０３）。位置情報管理部２３３は、予約済みリスト２３５を参照して、予約済みリスト１０４の先頭から予約済み物理格納位置情報を１つ取得し（ＳＰ１０４）、ＤＢアクセス処理部２３２は、テーブル２３６１に、取得した予約済み物理格納位置情報とレコードとを追加し（ＳＰ１０５）、ステップＳＰ１１４に進む。
　ステップＳＰ１０２において、ＳＱＬの種別が更新の場合、ＤＢアクセス処理部２３２は、更新するレコードを選択し（ＳＰ１０６）、選択するレコードが存在するか否かを判別する（ＳＰ１０７）。ステップＳＰ１０７において、否定結果を得た場合（ＳＰ１０７：ＮＯ）、処理を終了する。ステップＳＰ１０７において、肯定結果を得た場合（ＳＰ１０７：ＹＥＳ）、位置情報管理部２３３は、インデクス２３６２を参照して、物理格納位置情報を取得し（ＳＰ１０８）、ＤＢアクセス処理部２３２は、テーブル２３６１におけるレコードを更新し（ＳＰ１０９）、ステップＳＰ１１４に進む。
　ステップＳＰ１０２において、ＳＱＬの種別が削除の場合、ＤＢアクセス処理部２６２は、削除するレコードを選択し（ＳＰ１１０）、選択するレコードが存在するか否かを判別する（ＳＰ１１１）。ステップＳＰ１１１において、否定結果を得た場合（ＳＰ１１１：ＮＯ）、処理を終了する。ステップＳＰ１１１において、肯定結果を得た場合（ＳＰ１１１：ＹＥＳ）、位置情報管理部２６３は、インデクス２３６２を参照して、物理格納位置情報を取得し（ＳＰ１１２）、ＤＢアクセス処理部２６２は、テーブル２３６１におけるレコードを削除し（ＳＰ１１３）、ステップＳＰ１１４に進む。
　ステップＳＰ１０５，ＳＰ１０９，ＳＰ１１３において、レコードを追加、更新、又は削除した後に、データ連動要求部２３４は、ディスク型ＤＢ１１１にデータ連動するためのデータ連動ＳＱＬを生成する（ＳＰ１１４）。ただし、データ連動ＳＱＬには、取得した物理格納位置情報が付加されたレコードが含まれる。そして、データ連動要求部２３４は、ディスク型ＤＢ管理装置３にデータ連動ＳＱＬを送信し、その実行を要求する（ＳＰ１１５）。
　その後、インメモリＤＢ管理装置２は、ＳＱＬに記載された全てのレコードについて処理を終了したか否かを判別する（ＳＰ１１６）。ステップＳＰ１１６において、肯定結果を得た場合（ＳＰ１１６：ＹＥＳ）、処理を終了する。ステップＳＰ１１６において、否定結果を得た場合（ＳＰ１１６：ＮＯ）、ステップＳＰ１０２から処理を繰り返す。
（３－２）ディスク型データベース反映処理
　次に、図８を参照して、インメモリＤＢ２３６に更新があった場合のディスク型ＤＢ６３への反映処理を説明する。
　ディスク型ＤＢ管理装置３のＤＢアクセス要求解析部３３１が、インメモリＤＢ管理装置２がステップＳＰ１１５で送信したデータ連動ＳＱＬを受信した場合（ＳＰ２０１）、ＤＢアクセス要求解析部３３１は、ディスク型ＤＢ６３に対するデータ連動ＳＱＬの解析を行いＳＱＬの種別を決定し（ＳＰ２０２）、ＳＱＬの種別が追加、更新又は削除の何れかであるかを判別する（ＳＰ２０３）。
　ステップＳＰ２０３において、データ連動ＳＱＬの種別が追加の場合、ＤＢアクセス処理部３３２は、データ連動ＳＱＬに含まれる物理格納位置情報からデータ連動ＳＱＬに含まれるレコードの追加先を判別する（ＳＰ２０４）。そして、ＤＢアクセス処理部３３２は、テーブル６３１におけるステップＳＰ２０４で判別した追加先に、レコードを追加し（ＳＰ２０５）、ステップＳＰ２１２に進む。
　ステップＳＰ２０３において、ＳＱＬの種別が更新の場合、ＤＢアクセス処理部３３２は、更新するレコードを選択し（ＳＰ２０６）、選択するレコードが存在するか否かを判別する（ＳＰ２０７）。ステップＳＰ２０７において、否定結果を得た場合（ＳＰ２０７：ＮＯ）、処理を終了する。ステップＳＰ２０７において、肯定結果を得た場合（ＳＰ２０７：ＹＥＳ）、ＤＢアクセス処理部３３２は、テーブル６３１におけるデータ連動ＳＱＬに含まれる物理格納位置情報が示す格納位置に格納されるレコードを更新し（ＳＰ２０８）、ステップＳＰ２１２に進む。
　ステップＳＰ２０３において、ＳＱＬの種別が削除の場合、ＤＢアクセス処理部３３２は、削除するレコードを選択し（ＳＰ２０９）、選択するレコードが存在するか否かを判別する（ＳＰ２１０）。ステップＳＰ２１０において、否定結果を得た場合、処理を終了する（ＳＰ２１０：ＮＯ）。ステップＳＰ２１０において、肯定結果を得た場合（ＳＰ２１０：ＹＥＳ）、ＤＢアクセス処理部３３２は、テーブル６３１におけるデータ連動ＳＱＬに含まれる物理格納位置情報が示す格納位置に格納されるレコードを削除し（ＳＰ２１１）、ステップＳＰ２１２に進む。
　ステップＳＰ２０５、ＳＰ２０８、ＳＰ２１１において、レコードを追加、更新、又は削除した後に、ディスク型ＤＢ管理装置３は、ＳＱＬに記載された全てのレコードについて処理を終了したか否かを判別する（ＳＰ２１２）。ステップＳＰ２１２において、肯定結果を得た場合（ＳＰ２１２：ＹＥＳ）、処理を終了する。ステップＳＰ２１２において、否定結果を得た場合（ＳＰ２１２：ＮＯ）、ステップＳＰ２０３から処理を繰り返す。
このようにして、ディスク型ＤＢ６３にインメモリＤＢ２３６の更新を連動させる。
（３－３）ディスク型データベース更新処理
　次に、図９を参照して、端末装置４からディスク型ＤＢ６３へ更新要求があった場合のディスク型ＤＢ６３の更新処理を説明する。
　まず、ディスク型ＤＢ管理装置３が端末装置４からのディスク型ＤＢ６３に対する更新系ＳＱＬを受信すると、ディスク型ＤＢ管理装置３のＤＢアクセス要求解析部３３１は、受信した更新要求ＳＱＬの解析を行い、ＳＱＬの種別を決定し（ＳＰ３０１）、ＳＱＬの種別が追加、更新、削除の何れかであるかを判別する（ＳＰ３０２）。
　ステップＳＰ３０２において、ＳＱＬの種別が追加の場合、ＤＢアクセス処理部３３２は、レコードの追加先を決定する（ＳＰ３０３）。次に、位置情報管理部２６３は、予約指示リスト６１を参照して、追加先が予約指示のある物理格納位置情報と一致しているか否かを判別する（ＳＰ３０４）。ステップＳＰ３０４において肯定結果を得た場合には（ＳＰ３０４：ＹＥＳ）、ステップＳＰ３０３に戻る。ステップＳＰ３０４において否定結果を得た場合には（ＳＰ３０４：ＮＯ）、ステップＳＰ３０３で決定した追加先にレコードを追加し（ＳＰ３０５）、ステップＳＰ３１４に進む。
　ステップＳＰ３０２において、ＳＱＬの種別が更新の場合、ＤＢアクセス処理部３３２は、更新するレコードの選択を行い（ＳＰ３０６）、選択するレコードがあるか否かを判別する（ＳＰ３０７）。ステップＳＰ３０７において、否定結果を得た場合（ＳＰ３０７：ＮＯ）、処理を終了する。ステップＳＰ３０７において、肯定結果を得た場合（ＳＰ３０７：ＹＥＳ）、位置情報管理部３３３は、物理格納位置情報を取得して（ＳＰ３０８）、ＤＢアクセス処理部３３２は、レコードの更新を行う（ＳＰ３０９）。
　ステップＳＰ３０２において、ＳＱＬの種別が削除の場合、ＤＢアクセス処理部３３２は、削除するレコードの選択を行い（ＳＰ３１０）、選択するレコードがあるか否かを判別する（ＳＰ３１１）。ステップＳＰ３１１において、否定結果を得た場合（ＳＰ３１１：ＮＯ）、処理を終了する。ステップＳＰ３１１において、肯定結果を得た場合（ＳＰ３１１：ＹＥＳ）、位置情報管理部３３３は、物理格納位置情報を取得して（ＳＰ３１２）、ＤＢアクセス処理部３３２は、レコードの削除を行う（ＳＰ３１３）。
　ステップＳＰ３０５，ＳＰ３０９，ＳＰ３１３において、レコードを追加、更新、又は削除した後に、データ連動要求部３３４が、インメモリＤＢ２３６にデータ連動するためのデータ連動ＳＱＬを生成する（ＳＰ３１４）。ただし、データ連動ＳＱＬには、追加先の物理格納情報又は取得した物理格納情報が付加されたレコードを含む。そして、データ連動要求部３３４は、インメモリＤＢ管理装置２にデータ連動ＳＱＬを送信し、その実行を要求する（ＳＰ３１５）。
　その後、ディスク型ＤＢ管理装置３は、ＳＱＬに記載された全てのレコードについて処理を終了したか否かを判別する（ＳＰ３１６）。ステップＳＰ３１６において、肯定結果を得た場合（ＳＰ３１６：ＹＥＳ）、処理を終了する。ステップＳＰ３１６において、否定結果を得た場合（ＳＰ３１６：ＮＯ）、ステップＳＰ３０２から処理を繰り返す。
（３－４）インメモリデータベース反映処理
　次に、図１０を参照して、ディスク型ＤＢ６３に更新があった場合のインメモリＤＢ２３６への反映処理を説明する。
　インメモリＤＢ管理装置２のＤＢアクセス要求解析部２３１が、ディスク型ＤＢ管理装置３がステップＳＰ３１５で送信したデータ連動ＳＱＬを受信した場合（ＳＰ４０１）、ＤＢアクセス要求解析部２３１は、インメモリＤＢ２３６に対するデータ連動ＳＱＬの解析を行いＳＱＬの種別を決定し（ＳＰ４０２）、ＳＱＬの種別が追加、更新又は削除の何れかであるかを判別する（ＳＰ４０３）。
　ステップＳＰ４０３において、データ連動ＳＱＬの種別が追加の場合、ＤＢアクセス処理部２３２は、データ連動ＳＱＬに含まれる物理格納位置情報からデータ連動ＳＱＬに含まれるレコードの追加先を判別する（ＳＰ４０４）。そして、ＤＢアクセス処理部２３２は、テーブル２３６１におけるステップＳＰ４０４で判別した追加先に、レコードを追加し（ＳＰ４０５）、ステップＳＰ４１２に進む。
　ステップＳＰ４０３において、ＳＱＬの種別が更新の場合、ＤＢアクセス処理部２３２は、更新するレコードを選択し（ＳＰ４０６）、選択するレコードが存在するか否かを判別する（ＳＰ４０７）。ステップＳＰ４０７において、否定結果を得た場合（ＳＰ４０７：ＮＯ）、処理を終了する。ステップＳＰ４０７において、肯定結果を得た場合（ＳＰ４０７：ＹＥＳ）、ＤＢアクセス処理部２３２は、テーブル２３６１におけるデータ連動ＳＱＬに含まれる物理格納位置情報が示す格納位置に格納されるレコードを更新し（ＳＰ４０８）、ステップＳＰ４１２に進む。
　ステップＳＰ４０３において、ＳＱＬの種別が削除の場合、ＤＢアクセス処理部２３２は、削除するレコードを選択し（ＳＰ４０９）、選択するレコードが存在するか否かを判別する（ＳＰ４１０）。ステップＳＰ４１０において、否定結果を得た場合（ＳＰ４１０：ＮＯ）、処理を終了する。ステップＳＰ４１０において、肯定結果を得た場合（ＳＰ４１０：ＹＥＳ）、ＤＢアクセス処理部２３２は、テーブル２３６１におけるデータ連動ＳＱＬに含まれる物理格納位置情報が示す格納位置に格納されるレコードを削除し（ＳＰ４１１）、ステップＳＰ４１２に進む。
　ステップＳＰ４０５，ＳＰ４０８，ＳＰ４１１において、レコードを追加、更新、又は削除した後に、インメモリＤＢ管理装置２は、ＳＱＬに記載された全てのレコードについて処理を終了したか否かを判別する（ＳＰ４１２）。ステップＳＰ４１２において、肯定結果を得た場合（ＳＰ４１２：ＹＥＳ）、処理を終了する。ステップＳＰ４１２において、否定結果を得た場合（ＳＰ４１２：ＮＯ）、ステップＳＰ４０３から処理を繰り返す。このようにして、インメモリＤＢ２３６にディスク型ＤＢ６３の更新を連動させる。
（３－５）予約済みリスト作成処理
　ここで、図１１を参照して、インメモリＤＢ管理装置２及びディスク型ＤＢ管理装置３が協働することによって予約済みリスト２３５を作成する処理を説明する。インメモリＤＢ管理装置２は、インメモリＤＢ２３６を作成した後に、予約済みリスト１０４を作成する。
　先ず、インメモリＤＢ管理装置２は、インメモリＤＢ２３６を作成した場合、ディスク型管理装置３にインメモリＤＢ２３６を作成した旨を通知する。
　ディスク型管理装置３がその通知を受信すると、ＤＢアクセス処理部３３２は、ＤＢバッファ３３６を介して、ディスク型ＤＢ６３のデータをエクスポートする（ＳＰ５０１）。次に、位置情報管理部３３３が、予約指示リストバッファ３３５を介して、予約指示リスト６１の予約済み物理格納位置情報をエクスポートし（ＳＰ５０２）、データ連動要求部３３４が、インメモリＤＢ管理装置２に、エクスポートしたデータの読み込み要求を行う（ＳＰ５０３）。
　次に、ディスク型ＤＢ装置３は、ディスク型ＤＢ６３の全データ及び予約指示リスト６１の全予約済み物理格納位置情報を読み込んだか否かを判別する（ＳＰ５０４）。ステップＳＰ５０４において、肯定結果を得ると、処理を終了する。ステップＳＰ５０４において、否定結果を得ると、ステップＳＰ５０１に戻る。
　このようにして、ディスク型ＤＢ装置３は、ディスク型ＤＢ６３の全データ及び予約指示リスト６１の全予約済み物理格納位置情報についてエクスポートし、エクスポートしたデータの読み込み要求をインメモリＤＢ２３６に対して行う。
　一方、インメモリＤＢ管理装置２のＤＢアクセス解析部２３１が、ディスク型ＤＢ管理装置３がステップＳＰ５０３において行った要求を受け付けた場合に（ＳＰ６０１）、ＤＢアクセス処理部２６２は、インメモリＤＢ２３６のテーブル２３６１に対して、ディスク型ＤＢ６３のデータのインポートを行う（ＳＰ６０２）。その後、位置情報管理部２６３が、インデクス２３６２を作成し（ＳＰ６０３）、読み込んだ予約済み物理格納位置情報に基づいて予約済みリスト２３５を作成し（ＳＰ６０４）、処理を終了する。
（３－６）予約指示リスト作成処理
　ここで、図１２を参照して、ディスク型ＤＢ管理装置３が予約指示リスト６１を作成する処理を説明する。
　まず、ディスク型ＤＢ管理装置３の位置情報管理部３３３が、ユーザが作成した位置情報予約パラメタファイル６２を読み込み（ＳＰ７０１）、パラメタファイルの内容を予約指示リスト６１に登録する（ＳＰ７０２）。ディスク型ＤＢ管理装置３は、全ての位置情報予約パラメタファイル６２を読み込んだか否かを判別する（ＳＰ７０３）。ステップＳＰ７０３において、肯定結果（ＳＰ７０３：ＹＥＳ）を得た場合には、処理を終了する。ステップＳＰ７０３において、否定結果を得た場合には（ＳＰ７０３：ＮＯ）、ステップＳＰ７０１に戻る。
　このようにして、ユーザは、複数の位置情報予約パラメタファイル６２を作成することができ、複数の位置情報予約パラメタファイル６２から予約指示リスト６１を作成することができる。
（３－７）予約済みリスト補充処理
　ここで、図１３を参照して、予約済みリスト２３５の物理格納位置が少なくなった場合に、物理格納位置を補充する予約済みリスト補充処理を説明する。本処理は、ステップＳＰ１０４において、位置情報管理部２３３が、予約済みリスト２３５から予約済み物理格納位置情報を取得した時に開始される。
　先ず、インメモリＤＢ管理装置２の位置情報管理部２３３は、予約済みリスト２３５から予約済み物理格納位置情報を取得した場合に、予約済みリスト２３５の未使用状態の位置情報のうち、先頭の情報の状態を使用中に変更する（ＳＰ８０１）。
　次に、位置情報管理部２３３が、予約済みリスト１０４の使用中物理格納位置情報数２３５４から「１」を減算する（ＳＰ８０２）。位置情報管理部２３３は、予約済み物理格納位置情報数における使用中物理格納位置情報数の割合である使用率が８割以上であるか否かを判別する（ＳＰ８０３）。
　ステップＳＰ８０３において、否定結果が得られた場合（即ち使用率が８割以上の場合（ＳＰ８０３：ＹＥＳ））、補充の必要がないと判断し、その時点で処理を終了する。
　ステップＳＰ８０３において、肯定結果が得られた場合（即ち使用率が８割未満の場合（ＳＰ８０３：ＮＯ））、位置情報管理部２３３が、ディスク型ＤＢ管理装置３に予約済み物理格納位置情報の補充を要求し（ＳＰ８０４）、ディスク型ＤＢ管理装置３からの予約済みリスト連動要求を受け付け（ＳＰ８０５）、予約済みリスト２３５を連動させて補充し（ＳＰ８０６）、処理を終了する。
　一方、ディスク型ＤＢ管理装置３の位置情報管理部３３３は、予約済み物理格納位置情報の補充要求を受け付けると（ＳＰ９０１）、補充サイズを計算する（ＳＰ９０２）。補充サイズの計算は、例えば次の計算式で行う。
補充する予約済み物理格納位置情報数
＝補充前の予約済み物理格納位置情報数×０．２
　その後、位置情報管理部３３３は、計算した補充サイズ分だけ、ディスク型ＤＢ６３における物理格納位置を確保し、予約指示リスト６１の予約済み物理格納位置情報を補充し（ＳＰ９０３）、インメモリＤＢ管理装置２に予約済みリスト２３５への連動要求を行い（ＳＰ９０４）、処理を終了する。このようにして、使用中の予約済み物理格納位置情報が多くなった場合には、物理格納位置情報を確保して補充することによって、常に未使用の予約済み物理格納位置情報を確保することができる。
　図１４は、予約済み物理格納位置情報の表示結果の例を示す図である。予約済み物理格納位置情報は、インメモリＤＢ２３６のテーブル毎に分類できる。例えば、ユーザはコマンドなどのインタフェースを用いて、テーブル単位に、テーブル名と予約済み物理格納位置情報の使用率、使用中の位置情報を表示させる。予約済み物理格納位置情報は、ディスク型ＤＢ管理装置３の位置情報管理部３３３が、予約指示リスト６１から求める。位置情報は、ファイル、エクステント、ページ、レコードから構成される。予約済み物理格納位置情報の使用率は、インメモリＤＢ管理装置２の位置情報管理部２３３が、予約済みリスト２３５から以下の計算式で求める。
予約済み物理格納位置情報の使用率
＝使用中物理格納位置情報数÷予約済み物理格納位置情報数
（５）他の実施の形態
　なお、上述の実施の形態では、予約済みリスト２３５をテーブル形式で保持したが、インデクス形式で保持してもよい。
　この場合、図１５に示すように、インデクスを構成するインデクスエントリ２３５５において、予約済み物理格納位置情報をインデクスキー２３５６として保持し、インデクスキー２３５６と合わせて物理格納位置情報２３５７を保持することで実現できる。ここで、インデクスキー２３５６は、ディスク型ＤＢ６３におけるレコードの格納位置を示し、これに対応するインメモリＤＢ２３６のレコードの格納位置を物理格納位置情報２３５７が示す。物理格納位置情報２３５７が「０」の場合、予約済み物理格納位置情報が示すインメモリＤＢ２３６の格納位置が未使用であることを示す。
　また、上述の実施の形態では、ディスク型ＤＢ６３における物理格納位置情報６３２をインデクスとして用いたが、インメモリＤＢ２３６が格納するデータとディスク型ＤＢ６３が格納するデータとの間に一意性が保証できるユニークインデクスが存在する場合には、そのユニークインデクスを用いてもよい。
　図１６は、ユニークキーが存在するインメモリＤＢの更新処理を示す概念図である。インメモリＤＢ２３６は、レコード（図１６の例では「ＣＣＣ」）追加要求を受け付け、テーブル２３６３にレコード「ＣＣＣ」と、予約済みリスト２３５から取得したユニークキー（図１６の例では「０００４」）を追加する。
　その後、ユニークキー「０００４」をレコード「ＣＣＣ」に付加し、ディスク型ＤＢ６３に対して、レコード追加要求を行う。その後、ディスク型ＤＢ６３は、ユニークキー「０００４」が付加されている物理格納位置にレコード「ＣＣＣ」を格納する。
　以上のように、テーブルが既にユニークキーを保持している場合、物理格納位置情報として、ユニークキーを使用し、データを連動することが可能である。
　１……データベース管理システム、２……インメモリＤＢ管理装置、３……ディスク型ＤＢ管理装置、４……端末装置、５……ネットワーク、６……外部記憶装置、６１……予約指示リスト、６３……ディスク型データベース、２３５……予約済みリスト、２３６……インメモリデータベース。

Claims (10)

  1. 　第１のデータベースを配置する主記憶を有する第１データベース管理装置と、第２のデータベースを配置する二次記憶を有する第２データベース管理装置とがネットワークを介して接続され、前記第１及び第２データベース管理装置が格納するデータを互いに反映させるシステムのデータベース管理方法であって、
    　前記第１データベース管理装置は、前記第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報を保持する第１のリストを備え、
    　前記第１データベース管理装置が、前記第１のデータベースに任意のデータが追加された時に、当該データに前記第１のリストから前記格納位置情報を付加する第１のステップと、
    　前記第１データベース管理装置が、前記格納位置情報を付加した前記データを前記第２データベース管理装置に送信し、該第２データベース管理装置に当該データの追加を要求する第２のステップと、
    　前記第２データベース管理装置が、前記第２データベース管理装置からの前記データの追加の要求に応じて、前記データに付加された前記格納位置情報が示す前記第２のデータベースの格納位置に前記データを追加する第３のステップと、を有する
    　ことを特徴とするデータベース管理方法。
  2. 　前記第１データベース管理装置は、前記第１のデータベースが格納するデータと前記第２のデータベースが格納するデータとを対応付ける前記第２のデータベースのデータの格納位置を示す格納位置情報からなるインデクスを備え、
    　前記第１データベース管理装置が、前記第１のデータベースに格納されるデータを更新又は削除した時に、前記インデクスを参照して、当該データに前記第２のデータベースでの前記格納位置情報を付加して、前記第２データベース管理装置に送信し、当該データの更新又は削除を要求する第４のステップと、
    　前記第２データベース管理装置が、前記第１データベース管理装置からの前記データの更新又は削除の要求に応じて、当該格納位置情報が示す第２データベースの格納位置に存在するデータを更新又は削除する第５のステップと、を更に有する
    　ことを特徴とする請求項１に記載のデータベース管理方法。
  3. 　前記格納位置情報には、前記第１のデータベースのデータと前記第２のデータベースのデータとを対応付け且つ前記第１及び第２のデータベースが格納するデータにユニークキーを使用する
    　ことを特徴とする請求項１に記載のデータベース管理方法。
  4. 　前記第２データベース管理装置は、
    　前記第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報をユーザの操作に応じて保持する第２のリストを備え、
    　前記第１のデータベースの作成時に、前記第２のリストが保持する前記格納位置情報を前記第１データベース管理装置に送信し、
    　前記第１データベース管理装置は、
    　受信した前記格納位置情報に基づいて前記リストを作成する
    　ことを特徴とする請求項１に記載のデータベース管理方法。
  5. 　前記第１データベース管理装置は、
    　前記リストに保持された前記格納位置情報のうちのデータが書き込まれている前記格納位置情報の割合を算出し、
    　前記割合が所定の閾値以上の場合に、前記第２データベース管理装置に対して前記第１のリストが保持する前記格納位置情報の補充を要求し、
    　前記第２データベース管理装置は、
    　前記補充を要求された場合に、前記第１のデータベースに追加するデータの前記第２データベースにおける新たな書き出し先を確保し、
    　確保した前記新たな書き出し先の格納位置情報を前記第１データベース管理装置に送信し、
    　前記第１データベース管理装置は、
    　受信した前記新たな書き出し先の格納位置情報を前記第１のリストに補充する
    　ことを特徴とする請求項１に記載のデータベース管理方法。
  6. 　前記第２データベース管理装置は、
    　前記補充を要求された場合に、前記第１のリストに保持されている前記格納位置情報の数が所定数倍になるように、前記第１のデータベースに追加するデータの前記第２のデータベースにおける新たな書き出し先を確保し、
    　確保した前記新たな書き出し先の格納位置情報を前記第１データベース管理装置に送信する
    　ことを特徴とする請求項５に記載のデータベース管理方法。
  7. 　前記第２データベース管理装置は、
    　前記第１のリストに保持された前記格納位置情報を保持する第２のリストを備え、
    　前記第２のデータベースに対してデータの追加を要求された場合に、前記第２のリストに保持された前記格納位置情報が示す格納位置以外の格納位置に当該データを追加し、
    　前記データに、前記データを追加した格納位置の格納位置情報を付加して前記第１のデータベース管理装置に送信し、
    　前記第１データベース管理装置は、
    　前記データと前記データに付加された前記格納位置情報とを受信した場合に、前記インデクスに当該格納位置情報を追加して、前記データを前記インメモリデータベースに追加する
    　ことを特徴とする請求項２に記載のデータベース管理方法。
  8. 　前記第２データベース管理装置は、
    　前記第２のデータベースに対してデータを更新又は削除した場合に、当該データに当該データの格納位置情報を付加して、前記第１データベース管理装置に送信し、当該データの更新又は削除を要求し、
    　前記第１データベース管理装置は、
    　前記データと前記データに付加された前記格納位置情報とを受信した場合に、前記インデクスを参照して、受信した当該格納位置情報に対応する前記第１のデータベースにおけるデータを更新又は削除する
    　ことを特徴とする請求項７に記載のデータベース管理方法。
  9. 　第１のデータベースを配置する主記憶を有する第１データベース管理装置と、第２のデータベースを配置する二次記憶を有する第２データベース管理装置とがネットワークを介して接続され、前記第１及び第２データベース管理装置が格納するデータを互いに反映させるシステムのデータベース管理方法であって、
     
    　前記第１データベース管理装置は、
    　前記第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報を保持する第１のリストを備え、
    　前記第１のデータベースに任意のデータが追加された時に、当該データに前記第１のリストから前記格納位置情報を付加し、当該格納位置情報を付加した当該データを前記第２データベース管理装置に送信し、前記第２データベース管理装置に当該データの追加を要求し、
    　前記第２データベース管理装置は、
    　前記第１データベース管理装置からの前記データの追加の要求に応じて、前記データに付加された前記格納位置情報が示す前記第２のデータベースの格納位置に前記データを追加する
    　ことを特徴とするデータベース管理システム。
  10. 　第２のデータベースを配置する二次記憶を有する第２データベース管理装置に接続され、第１のデータベースを配置する主記憶を有するとともに該第１のデータベースに追加するデータの前記第２のデータベースにおける書き出し先を示す格納位置情報を保持する第１のリストを有する第１データベース管理装置に、
    　前記第１のデータベースに任意のデータが追加された時に、当該データに前記第１のリストから前記格納位置情報を付加する第１のステップと、
    　前記格納位置情報を付加した前記データを前記第２データベース管理装置に送信し、該第２データベース管理装置に当該データの追加を要求する第２のステップと、
    　を実行させることを特徴とするデータベース管理プログラム。
PCT/JP2010/001527 2009-11-18 2010-03-04 データベース管理方法、データベース管理システム及びデータベース管理プログラム WO2011061869A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/389,548 US9002796B2 (en) 2009-11-18 2010-03-04 Database management method, database management system and database management program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009263031A JP5256173B2 (ja) 2009-11-18 2009-11-18 データベース管理方法、データベース管理システム及びデータベース管理プログラム
JP2009-263031 2009-11-18

Publications (1)

Publication Number Publication Date
WO2011061869A1 true WO2011061869A1 (ja) 2011-05-26

Family

ID=44059358

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/001527 WO2011061869A1 (ja) 2009-11-18 2010-03-04 データベース管理方法、データベース管理システム及びデータベース管理プログラム

Country Status (3)

Country Link
US (1) US9002796B2 (ja)
JP (1) JP5256173B2 (ja)
WO (1) WO2011061869A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10114908B2 (en) * 2012-11-13 2018-10-30 International Business Machines Corporation Hybrid table implementation by using buffer pool as permanent in-memory storage for memory-resident data
CN105706068B (zh) * 2013-04-30 2019-08-23 慧与发展有限责任合伙企业 路由存储器流量和i/o流量的存储器网络
KR101679011B1 (ko) * 2014-06-26 2016-11-24 주식회사 알티베이스 데이터베이스에서 데이터 이동을 처리하는 방법 및 장치
JP6690829B2 (ja) * 2015-08-28 2020-04-28 国立大学法人 東京大学 計算機システム、省電力化方法及び計算機
CN107704196B (zh) * 2017-03-09 2020-03-27 深圳壹账通智能科技有限公司 区块链数据存储***和方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001160942A (ja) * 1999-12-02 2001-06-12 Matsushita Electric Ind Co Ltd サーバシステム
WO2008105098A1 (ja) * 2007-02-28 2008-09-04 Fujitsu Limited メモリミラー化制御方法
JP2008310517A (ja) * 2007-06-13 2008-12-25 Hitachi Ltd データ同一化方法、データ同一化プログラム、および、現用系装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3698947B2 (ja) 2000-03-27 2005-09-21 日立ソフトウエアエンジニアリング株式会社 データベース処理方法およびデータベース処理システム
US7403945B2 (en) * 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
US7634507B2 (en) * 2006-08-30 2009-12-15 Inmage Systems, Inc. Ensuring data persistence and consistency in enterprise storage backup systems
WO2008049102A2 (en) * 2006-10-19 2008-04-24 Fair Thomas T System and methods for zero-configuration data backup

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001160942A (ja) * 1999-12-02 2001-06-12 Matsushita Electric Ind Co Ltd サーバシステム
WO2008105098A1 (ja) * 2007-02-28 2008-09-04 Fujitsu Limited メモリミラー化制御方法
JP2008310517A (ja) * 2007-06-13 2008-12-25 Hitachi Ltd データ同一化方法、データ同一化プログラム、および、現用系装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
TAKASHI KUWAUCHI ET AL.: "Shinka shita DWH/BI, .NET Muke Kaihatsu Kino In-Memory DB 'TimesTen' no Zenbo", DB MAGAZINE, vol. 15, no. LL, 1 January 2006 (2006-01-01), pages 80 - 88 *
TATSUYA SUGI ET AL.: "Data Shori o Kosokuka suru In-Memory Architecture", IT ARCHITECT, vol. 22, 14 May 2009 (2009-05-14), pages 44 - 55 *
TSUTOMU HOSOKAWA: "Seino Kakuho no Shoheki wa Nanika, Architect ga Shitteoku beki koto wa Nanika", IT ARCHITECT, vol. 22, 14 May 2009 (2009-05-14), pages 26 - 33 *

Also Published As

Publication number Publication date
JP2011108027A (ja) 2011-06-02
JP5256173B2 (ja) 2013-08-07
US9002796B2 (en) 2015-04-07
US20120209891A1 (en) 2012-08-16

Similar Documents

Publication Publication Date Title
JP5082310B2 (ja) データ移行装置及びプログラム
US8103847B2 (en) Storage virtual containers
US7809779B2 (en) Method of creating symbolic link capable of being compatible with file system, and method and apparatus for accessing file or directory by using symbolic link
US8024363B2 (en) Information processing apparatus, information processing method, program and program recording medium
JP5149912B2 (ja) 複数の異種のソリッドステート・ストレージ・ロケーションの選択的利用
KR101644894B1 (ko) 클라우드 스토리지 서비스 장치 및 방법
JP5869661B2 (ja) ネットワークストレージシステムにリンクされるローカルストレージ
JP4837378B2 (ja) データの改竄を防止する記憶装置
JP5256173B2 (ja) データベース管理方法、データベース管理システム及びデータベース管理プログラム
TW201520889A (zh) 混合儲存的控制方法及混合儲存系統
CN103597440A (zh) 用于创建克隆文件的方法以及采用该方法的文件***
KR101365438B1 (ko) Ｍｔｐ 디바이스가 미디어 파일을 관리하는 방법 및 이를위한 장치
JP4227931B2 (ja) 情報記憶装置、情報格納方法及び情報記憶処理プログラム
US10838641B2 (en) Defragmenting backup objects
CN107172152B (zh) 一种基于ceph集群cap机制统计配额***及方法
JP2010225024A (ja) ストレージ装置とそのファイル制御方法およびストレージシステム
JP4502375B2 (ja) ファイルシステムおよびその制御方法
US8082230B1 (en) System and method for mounting a file system on multiple host computers
JP6470126B2 (ja) ファイルバリアントを作成する方法、計算装置、及びプログラム
WO2014030249A1 (ja) ボリュームのｉ／ｏ性能の検証システム及び検証方法
JP6874348B2 (ja) ストレージ制御装置、およびストレージ制御プログラム
JP6281333B2 (ja) ストレージシステム
US11537597B1 (en) Method and system for streaming data from portable storage devices
US11495262B1 (en) Duplexing data from multiple file systems onto a shared tape
US11204845B2 (en) Workload coordination on disaster recovery site

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10831269

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13389548

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10831269

Country of ref document: EP

Kind code of ref document: A1