US20030004975A1 - Database management system with rebalance architectures - Google Patents

Database management system with rebalance architectures Download PDF

Info

Publication number
US20030004975A1
US20030004975A1 US09/987,839 US98783901A US2003004975A1 US 20030004975 A1 US20030004975 A1 US 20030004975A1 US 98783901 A US98783901 A US 98783901A US 2003004975 A1 US2003004975 A1 US 2003004975A1
Authority
US
United States
Prior art keywords
data
storages
storage
rebalance
request
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US09/987,839
Inventor
Yukio Nakano
Nobuo Kawamura
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Assigned to HITACHI, LTD. reassignment HITACHI, LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KAWAMURA, NOBUO, NAKANO, YUKIO
Publication of US20030004975A1 publication Critical patent/US20030004975A1/en
Priority to US11/357,158 priority Critical patent/US7577694B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99952Coherency, e.g. same view to multiple users
    • Y10S707/99953Recoverability
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99956File allocation

Definitions

  • the present invention relates to a database for data management based on table, and more particularly to a database system suitable to rebalance data among shared database files at the time of changing the number of storages for storing therein table data as divided.
  • One of such conventional table division systems is a hash division system in which a hash function is used for values of columns which make up a table for uniform division.
  • a hash function is used for values of columns which make up a table for uniform division.
  • table data are uniformly stored in respective disks (storages), a load can be uniformly distributed thereinto.
  • U.S. Pat. Nos. 6,145,067; 5,917,999 and 5,564,116 disclose disk array systems wherein, when a storage is added, data rebalance among shared database files has to be carried out concurrently with data access (read, write).
  • data access read, write
  • a node for accepting an access request obtains information during data rebalance, it is required to perform data transfer between associated nodes for data rebalance and then to inform its information to the node for acceptance of the access request, thus resulting in generation of a communication overhead.
  • a database management system which includes a storage having a first storage area corresponding to a plurality of storages for saving a plurality of data items and a second storage area corresponding to a storage to be added to or disconnected from the plurality of storages, an acceptance section connected to the storage for accepting a data processing request, the data processing request including data processing in the plurality of storages and data rebalance between the storages, and a plurality of executors connected to the acceptance section for sequentially executing at least any of the data processing in the plurality of storages and the data rebalance.
  • the storage may have a storage area correspondence table indicative of combinations of predetermined data items to be shared by the plurality of storages and to be sharedly stored thereby according to the request of addition or disconnection to cause the data rebalance between the storages.
  • the acceptance section has a during-rebalance flag indicating that ‘during rebalance’ of the plurality of storages by addition or disconnection to or from the plurality of storages. According to a data processing request to the data items stored in the plurality of storages, the acceptance section can refer to the during-rebalance flag and reflect data update even on the storages subjected to the data rebalance.
  • the system in accordance with the invention of the present application may include means, in response to a rebalance request of data to be rebalanced in a storage added according to an addition request, for adding data position information to data before subjected to the rebalance execution by the data rebalance request in the plurality of storages, and means for deleting the data added with the data position information before subjected to the rebalance execution in response to the rebalance request after the rebalance execution by the rebalance request.
  • a database management method which can be realized in the above system.
  • the method includes steps of allocating a plurality of data items in a table to a plurality of storages for their storage; storing the table data in the storages determined according to a specified division rule (method); when a request is issued to add a storage for storage of the table data, determining part of the data stored in the existing storages which is to be moved to the addition storage with use of information about the existing and additional storages according to the specified division method and performing data rebalance operation to move all the determined data to the additional storage; when a request for search, update delete to the table is issued during the data rebalance execution, searching for, updating or deleting the table data stored in the existing storages and in the additional storage; and when a request of insert in the table is issued, inserting the data determined by the specified data division method in the storages together with information about existing and additional storages.
  • a specified division rule method
  • a parallel database method which includes steps of allocating a plurality of data items in a table as table data to a plurality of storages for their storage and storing the table data in storages determined by a specified division method; when a request is issued to search, update or delete the table is issued, performing parallel operation over the respective storages; when a request is issued to add a storage for storage of the table data, determining part of the data stored in existing storage parts which is to be moved to the additional storage according to a specified division method with use of information about the existing and additional storages; performing data rebalance operation to move all the determined data to the additional storage; when a request is issued to search, update or delete the table during the data rebalance operation, performing parallel operation in the existing storages over the table data stored therein to search for, update or delete the table data; after completing all the operations of the existing storages, performing parallel operation over the respective storages to search, update or delete the table in the additional storage; and when a request is issued to search, update or delete the table is issued,
  • a database method which includes steps of allocating a plurality of data items in a table as the table data to a plurality of storages for their storage; storing the table data in the storages determined by a specified division method; when a request is issued to add a storage for storage of the table data therein, determining part of the data stored in existing storages which is to be moved to the additional storage according to the specified division method with use of information about the existing and additional storages, copying the determined data from the existing storages to the additional storage, and adding position information of the copied data on the additional storage to the data of the storages as a copy source; when, the copy of all the data to be moved o the additional storage is completed, performing data rebalance operation to delete all the data of the copy source; when a request is issued to search the table during the data rebalance execution, searching the existing storages for associated data stored therein; when a request is issued to update or delete the table, updating or
  • FIG. 1 is a block diagram of an exemplary arrangement of a database system in accordance with the present invention.
  • FIG. 2 is a block diagram of an exemplary structure of a hardware section in the database system of FIG. 1;
  • FIG. 3 is exemplary registration contents of a table showing hash function value storage position correlation
  • FIGS. 4A and 4B are diagrams for explaining a first example of accepting and executing a database processing request during rebalance operation of a database management system in FIG. 1;
  • FIG. 5 is a block diagram of a first exemplary detailed arrangement of the database management system in FIG. 1; prior to the rebalance operation thereof;
  • FIG. 6 shows an example of a stock table to be managed by the database management system of FIG. 5;
  • FIG. 7 is a flowchart for explaining a first example of processing operation of a DBMS acceptance section in FIG. 5;
  • FIG. 8 is a flowchart for explaining a second example of processing operation of the DBMS acceptance section in FIG. 5;
  • FIG. 9 is a flowchart for explaining a third example of processing operation of a DBMS acceptance section in FIG. 5;
  • FIG. 10 is a diagram for explaining the first operational example of the database management system of FIG. 5 associated with the rebalance operation
  • FIGS. 11A and 11B show a flowchart for explaining an example of the rebalance operation of the database management system of FIG. 10;
  • FIG. 12 is a block diagram of an exemplary detailed arrangement of the database system of FIG. 1 after the rebalance operation
  • FIG. 13 is a block diagram of a second exemplary detailed arrangement of the database management system in FIG. 1 prior to the rebalance operation;
  • FIG. 14 is a flowchart for explaining an example of search execution target determining operation of a DBMS acceptance section in FIG. 13;
  • FIG. 15 is a flowchart for explaining an example of update/delete execution target determining operation of the DBMS acceptance section in FIG. 13;
  • FIG. 16 is a flowchart for explaining an example of update execution target determining operation of the DBMS acceptance section in FIG. 13;
  • FIG. 17 is a flowchart for explaining an example of delete execution target determining operation of the DBMS acceptance section in FIG. 13;
  • FIG. 18 is a flowchart for explaining an example of insert execution target determining operation of the DBMS acceptance section in FIG. 13;
  • FIG. 19 is a flowchart for explaining another example of insert execution target determining operation of the DBMS acceptance section in FIG. 13;
  • FIG. 20 is a diagram of another exemplary arrangement of the database management system of FIG. 13 associated with the rebalance operation
  • FIG. 21A and 21B shows a flowchart for explaining an example of rebalance operation of the database management system of FIG. 20;
  • FIGS. 22A and 22B are diagrams for explaining a second example of accepting and executing a database processing request in the rebalance operation of the database system of FIG. 1;
  • FIGS. 23 to 25 are diagrams for explaining the data processing of the rebalance operation necessary when the number of storages are reduced in accordance with the invention.
  • FIG. 1 is a block diagram of an exemplary arrangement of a database system in accordance with an embodiment of the present invention
  • FIG. 2 is a block diagram of an example of a hardware section in the database system of FIG. 1
  • FIG. 3 shows exemplary registration contents of a table of hash function value storage position correspondence in FIG. 1
  • FIG. 4 shows diagrams for explaining a first example of accepting and executing a database processing request in rebalance operation of a database management system in FIG. 1.
  • a database management system (which is also shown by DBMS in the drawings) 300 forming one section of the database system of the present invention, which includes a central processing unit (CPU), an input device, a display unit and so on, functions to perform database processing such as data search, update, delete, or insert (add) on the basis of a request from a plurality of user terminals 330 a to 330 c each having a computer function.
  • the database management system 300 includes a DBMS acceptance node 400 and DBMS execution nodes 410 a to 410 c , which have each a computer function and are interconnected by a network 301 .
  • the DBMS acceptance node 400 has a CPU 401 and a main memory 402 and also is connected to an external storage 318 in the form of a hard disk drive (HDD) or the like.
  • the CPU 401 executes a DBMS acceptance program 310 a stored in the main memory 402
  • the DBMS acceptance section 310 in FIG. 1 can perform respective functions in the DBMS acceptance operation.
  • the DBMS execution nodes 410 a to 410 c have CPU's 411 a to CPU 411 c and main memories 412 a to 412 c respectively, and are also connected to external storages 325 a to 325 c respectively.
  • the CPU's 411 a to CPU 411 c execute respective DBMS execution programs (which is shown by DBMS execution PGM's in the drawings) 320 a to 320 c stored in the main memories 412 a to 412 c
  • the DBMS execution programs 320 a to 320 c in FIG. 1 can perform respective functions for the DBMS execution.
  • the DBMS acceptance program 310 a and DBMS execution programs 320 a to 320 c are usually stored in a recording medium including an optical disc such as CD-ROM (compact disc-read only memory) or DVD (digital video disc/digital versatile disc). These programs are installed from these recording medium to the external storage 318 and external storages 325 a to 325 c to be loaded into the main memory 402 and main memories 412 a to 412 c.
  • a recording medium including an optical disc such as CD-ROM (compact disc-read only memory) or DVD (digital video disc/digital versatile disc).
  • the DBMS acceptance section 310 has a request acceptor 311 , an analyzer 312 , a processing procedure generator 313 , an execution destination decider 314 , an execution request/result receiver 315 , a returner 316 , and a rebalance executor 102 .
  • the DBMS executors 320 a to 320 c have searches 321 a to 321 c , updates 322 a to 322 c , deletes 323 a to 323 c , and inserts 324 a to 324 c respectively.
  • the DBMS acceptance section 310 accepts from user terminals a processing request 330 such as data processing and rebalance operation via the request acceptor 311 , analyzes the request in the analyzer 312 therein, and generates a processing procedure to realize the request in the processing procedure generator 313 .
  • the execution destination decider 314 determines which one of the DBMS executors should execute the generated processing procedure on the basis of data division conditions
  • the execution request/result receiver 315 issues an execution request to the determined DBMS executor and receives its execution result from the DBMS executor.
  • the received result is returned from the returner 316 to the user.
  • the analyzer 312 , processing procedure generator 313 and execution destination decider 314 refer to a hash function value storage position correspondence table 317 or table definition information 319 stored in the external storage 318 , and acquire information for determination of a data storage destination or information about the table.
  • table definition information 319 Stored in the table definition information 319 are, for example, storage area information 340 for management of storages having the table stored as divided therein, addition area information 341 for management of a storage for storage area addition, and a during-rebalance flag 342 indicative of ‘during rebalance operation’. Details of respective constituent elements of the table definition information 319 will be explained later in connection with a specific example with reference to FIGS. 5 to 12 .
  • the DBMS executors 320 a to 320 c in response to an instruction of search, update, delete or insert received from the DBMS acceptance section 310 , activate the searches 321 a to 321 c , updates 322 a to 322 c , deletes 323 a to 323 c or inserts 324 a to 324 c , execute its processing procedure, and return the execution result to the DBMS acceptance section 310 .
  • the DBMS executors 320 a to 320 c access table data 326 stored in the external storages 325 a to 325 c.
  • the execution destination decider 314 of the DBMS acceptance section 310 selects a plurality of executors ( 320 a to 320 c )
  • the execution request/result receiver 315 of the DBMS acceptance section 310 may issue an execution request to all the selected DBMS executors ( 320 a to 320 c ) simultaneously to execute parallel processing in the respective DBMS executors ( 320 a to 320 c ).
  • the table 317 showing its details in FIG. 3 is used to determine a storage position based on the hash function value.
  • data is divided into up to 10 parts according to the number of external storages connected.
  • the table also shows information about storage areas where data is stored at the time of the division by the hash function values.
  • the database management system 300 in the database system having such an arrangement as shown in FIG. 1 copes with it in such a manner as to be explained below.
  • the rebalance executor 102 in the DBMS acceptance section 310 refers to the hash function value storage position correspondence table 317 , determines data to be moved from existing storages such as the external storages 325 a and 325 b to an additional storage (external storage 325 c ), and moves all the data determined as to be moved to the additional storage (external storage 325 c ).
  • the database management system executes the search, update or delete operation for the existing storages (external storages 325 a and 325 b ) and the additional storage (external storage 325 c ) respectively.
  • the database management system refers to the hash function value storage position correspondence table 317 , and inserts the data in the associated storage (any of the external storages 325 a to 325 c ).
  • the database management system 300 in FIG. 1 is of a parallel database type which performs parallel processing operation over storages when it is required to search for, update and delete table data. If it is required to search for, update and delete the table data during execution of data rebalance operation, then the system performs parallel processing operation over existing storages (external storages 325 a and 325 b ) to search fir, update and delete the table data stored therein. After fully completing the processing of the existing storages, the system sequentially performs the search, update and delete operations over the additional storage and external storage 325 c .
  • the system refers to the hash function value storage position correspondence table 317 including information on the existing storages (external storages 325 a and 325 b ) and information on the additional storage (external storage 325 c ), and inserts the data in one of the storages (external storages 325 a , 325 b and 325 c ) determined by the execution destination decider 314 .
  • operation 100 of search, update and delete operation is carried out in the storages 120 and 130 over data 121 to 125 and 131 to 135 ; and an insert operation 101 of such data 133 as to provide a hash function value of 3 is carried out in the storage 130 .
  • a rebalance operation 102 a selects data to be moved to the storage 140 from data stored in the storages 120 and 130 and moves the selected data to the storage 140 to provide hash function values of 7, 2 and 3.
  • This data move operation is carried out in such a procedure as to first search for data of the storages 120 and 130 to be moved, insert it in the storage 140 and then delete the data of the storages 120 and 130 .
  • the data operation 100 of search, update or delete is carried out in both existing and additional areas. That is, the data operation is carried out in the storages 120 , 130 and 140 .
  • the data in question is locked so that the rebalance operation 102 a is prohibited from referring to the data unless otherwise specifically stated by the user.
  • the data insert operation 101 to provide a hash function value of 3 during the rebalance operation stores the data in question in the storage 140 as an additional area to be moved.
  • data to provide a hash function value of 7 is stored in the storage 120 or 140 and data to provide hash function values of 2 and 3 is stored in the storage 120 or 140 .
  • the operation 100 of search, update or delete refers to both the existing and additional areas, the operation 100 can carry out the search, update or delete operation regardless of whether the data is stored in the existing storages or additional storage.
  • FIG. 5 is a block diagram of a first detailed example of the arrangement of the database management system in FIG. 1 prior to its rebalance operation
  • FIG. 6 shoes exemplary contents of a stock table to be managed by the database management system of FIG. 5
  • FIG. 7 is a flowchart for explaining a first example of the processing operation of a DBMS acceptance section in FIG. 5
  • FIG. 8 is a flowchart for explaining a second example of the processing operation of the DBMS acceptance section in FIG. 5
  • FIG. 9 is a flowchart for explaining a third example of the processing operation of the DBMS acceptance section in FIG. 5
  • FIG. 10 is a diagram for explaining the arrangement and operation of the database management system in FIG. 5 associated with the rebalance operation
  • FIG. 11 is a flowchart for explaining an exemplary rebalance operation of the database management system of FIG. 10
  • FIG. 12 is a block diagram of an exemplary specific arrangement of the database system after the rebalance operation.
  • a DBMS acceptance section 600 and DBMS executors 610 a to 610 c in the database management system in the database system of FIG. 5 have substantially the same functions as the DBMS acceptance section 310 and DBMS executors 320 a to 320 c in the database management system 300 in FIG. 1.
  • a hash function value storage position correspondence table 635 Stored in a storage 630 connected to the DBMS acceptance section 600 are a hash function value storage position correspondence table 635 having the same contents as the hash function value storage position correspondence table 317 shown in FIG. 3 as well as table definition information 631 defined for each table.
  • the table definition information 631 has a storage area (shown by “additional area” in the drawings) 632 indicative of a table storage place, additional area information (shown by “additional area” in the drawing) 633 , and a during-rebalance flag 634 indicative of “during rebalance”.
  • the DBMS executors execute search, update, delete or insert operation in response to an instruction received from the DBMS acceptance section 600 .
  • a hash function used for the division is set to have values of residues obtained when identification numbers (product codes) of products in storage data 621 and 622 are divided by the maximum division number 10.
  • the database treated in this example is a stock table 500 associated with clothing which includes items of product code 510 , product name 520 , color 530 , unit price 540 and stock amount 550 .
  • the distribution of the hash function value storage position correspondence table 635 i.e., the hash function value storage position correspondence table 317 of FIG. 3 in the two-division case is applied to the hash function value calculated for the value of the product code 510 .
  • the DBMS acceptance section 600 accepts the request at a request acceptor 601 , analyzes the accepted request at an analyzer 602 , generates a processing procedure at a processing procedure generator 603 to realize the analyzed request, and determines one or ones of the DBMS executors which execute(s) the generated processing procedure at an execution destination decider 604 .
  • the decider first refers to the value of the during-rebalance flag 634 in the table definition information 631 of the storage 630 to judge whether or not the rebalance operation is being executed (step S 701 ).
  • the decider determines the area defined in the storage area 632 as its execution destination (step S 702 ).
  • the DBMS executors 610 a and 610 b are determined as the execution destinations. The operation when the judgement result at the step S 701 indicates that the rebalance operation is being executed will be explained later.
  • an execution request/result receiver 605 in the DBMS acceptance section 600 issues an execution request to the execution destinations and receives their execution results therefrom.
  • the execution request/result receiver first refers to the value of the during-rebalance flag 634 and judges whether or not the rebalance operation is being executed (step S 711 ).
  • the receiver determines that the rebalance operation is not being executed, it issues a simultaneous execution request to all the DBMS executors determined by the execution destination decider 604 (step S 712 ) and receives execution results from the DBMS executors (step S 713 ).
  • the DBMS acceptance section 600 in FIG. 5 returns the last-received execution result through the operation of a returner 606 .
  • the operation when the judgement result at the step S 711 indicates that the rebalance operation is being executed will be explained later.
  • the DBMS acceptance section 600 performs the operations of the request acceptor 601 , analyzer 602 and processing procedure generator 603 , and determines an execution destination as an insert destination at the execution destination decider 604 .
  • the decider 604 first refers to the value of the during-rebalance flag 634 in the table definition information 631 of the storage 630 in FIG. 5 and judges whether or not the rebalance operation is being executed (step S 721 ).
  • the decider calculates a hash function value on the basis of the data to be inserted, and selects an insert execution destination from the areas defined in the storage area 632 with use of the hash function value obtained by referring to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3) (step S 722 ).
  • the operation when the result judged at the step S 721 indicates the rebalance operation is being executed will be explained later.
  • the DBMS acceptance section refers to the value of the product code of the insert data and finds a hash function value.
  • the DBMS acceptance section selects the storage 620 a ; while, when the hash function values are 1, 8, 5, 2 and 3, the DBMS acceptance section selects the storage 620 b.
  • the DBMS acceptance section 600 issues an insert execution request and receives its result from and at the execution request/result receiver 605 , and returns the last-received result from the returner 606 .
  • the rebalance executor set the during-rebalance flag 634 in the table definition information 631 of the storage 630 in FIG. 5 at “during execution of the rebalance operation” (step S 1101 ), finds the numbers of divisions before and after the area addition by referring to the storage area information 632 and additional area information 633 , and finds data to be moved by referring to the hash function value storage position correspondence table 635 (step S 1102 ).
  • a single area is added to change the system from the two-division type to a three-division type in FIG. 10.
  • data indicative of the hash function values of 2, 7 and 3 is to be moved on the basis of the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 of FIG. 3).
  • the rebalance executor 1100 issues a data search request to the DBMS executor having the to-be-moved data thus found and stored therein (step S 1103 ).
  • the rebalance executor issues a search request to the DBMS executors 610 a and 610 b.
  • the DBMS executors 610 a and 610 b when receiving the search request from the rebalance executor 1100 searches for one case of data and return its result to the DBMS acceptance section 600 .
  • the DBMS acceptance section 600 accepts the data corresponding to one case returned from the DBMS executors 610 a and 610 b (step S 1104 ), calculates a hash function value based on the value of the accepted data, finds a move destination by referring to the hash function value storage position correspondence table 635 (step S 1105 ), and issues an insert request to the DBMS executor as the move destination (step S 1106 ).
  • the DBMS executor when receiving the insert request executes data insert operation and informs the DBMS acceptance section 600 of its insert completion (step S 614 ).
  • the DBMS acceptance section 600 accepts a notification indicative of the data insert completion (step S 1107 ) and issues a delete request to delete the insert original data (step S 1108 ).
  • the DBMS executor 610 a searches for data 1000 having a product code value of 677 and returns it to the DBMS acceptance section 600 . Since the data move destination is the storage 620 c , the rebalance executor 1100 issues an insert request to the DBMS executor 610 c to store data 1001 in the storage 620 c.
  • the rebalance executor 1100 issues a request to the DBMS executor 610 a to delete the data 1000 having a product code value of 677.
  • a delete 613 a in the DBMS executor 610 a deletes the corresponding data.
  • the DBMS executor 610 a informs the DBMS acceptance section 600 of the delete completion.
  • the DBMS acceptance section 600 accepts the data delete completion notification (step S 1109 ), and extracts next search data and examines the presence or absence of the next search data (step S 1110 ).
  • the DBMS acceptance section 600 accepts data at the steps S 1110 to S 1104 and repetitively performs the insert and delete operations until the data becomes null.
  • the DBMS acceptance section 600 adds contents of the additional area information 633 in the storage area 632 (S 1111 ), deletes contents of the additional area information 633 (S 1112 ), and erases the during-rebalance flag 634 (S 1113 ).
  • storage data 621 a is stored in the storage 620 a
  • storage data 622 is stored in the storage 620 b
  • storage data 623 is stored in the storage 620 c , as shown in FIG. 12.
  • the DBMS acceptance section 600 determines the areas defined in the storage area 632 and additional area information 633 of the table definition information 631 in the storage 630 as execution destinations (step S 703 ).
  • the DBMS executors 610 a , 610 b and 610 c are determined as execution destinations.
  • the execution request/result receiver 605 in the DBMS acceptance section 600 performs its execution request/result receiving operation, which will be explained by referring to FIG. 8.
  • the DBMS acceptance section 600 refers to the during-rebalance flag 634 in the table definition information 631 of the storage 630 and judges whether or not the rebalance operation is being executed (step S 711 ). Since the rebalance operation is being executed, the DBMS acceptance section 600 , on the basis of the execution destination determined at the step S 703 in the execution destination determination process of FIG. 7, first issues an execution request to the DBMS executors associated with the storages defined in the storage area 632 (step S 714 ).
  • the DBMS acceptance section 600 issues a execution request to the DBMS executor associated with the storage defined in the additional area 633 (step S 716 )and receives an execution result from the DBMS executor subjected to the execution request (step S 717 ).
  • the DBMS acceptance section 600 returns the last received result through the operation of the step S 606 .
  • the storages 620 a and 620 b are defined in the storage area 632 in the table definition information 631 of the storage 630 and the storage 620 c is defined in the additional area 633 .
  • the DBMS acceptance section 600 first issues a search, update and delete execution request to the DBMS executors 610 a and 610 b , and after receiving all their results therefrom, the DBMS acceptance section issues the search, update and delete execution request to the DBMS executor 610 c and receives its result.
  • the DBMS acceptance section 600 performs the operations of the request acceptor 601 , analyzer 602 , processing procedure generator 603 and execution destination decider 604 in FIG. 10, and the operation of the execution destination decider 604 is as shown in FIG. 9.
  • the DBMS acceptance section 600 finds a hash function value based on the data to be inserted, refers to the hash function value storage position correspondence table 635 , and selects an insert destination from the areas defined in the storage area information 632 and additional area 633 on the basis of the hash function values (step S 723 ).
  • the DBMS acceptance section 600 refers to the value of the product code for the data to be inserted and finds hash function values.
  • the DBMS acceptance section selects the storage 620 a .
  • the hash function values are 1, 8 and 5
  • the DBMS acceptance section selects the storage 620 b .
  • the acceptance section selects the storage 620 c.
  • the execution request/result receiver 605 performs its operation over the selected insert destination and the section 600 returns the last-received result from the returner 606 .
  • Such data being searched for, updated, deleted or inserted is locked, so that it is prohibited that another user or rebalance operation performs search, update or delete operation thereover, unless otherwise specifically stated by the user.
  • data to be subjected to a move operation for each data case during the rebalance operation is also locked, so that another user is prohibited from performing search, update or delete operation thereover until the move operation is completed.
  • the system can accept the search, update or delete processing request to node table data during the rebalance operation and sequentially execute the DBMS executors.
  • the system performs searching operation over the data stored in the existing storages.
  • the system first processes the data stored in the existing storages as update/delete object.
  • position information indicative of a copy destination to the additional storage is added to the data to be updated and deleted, the system performs the same update/delete operation over the data of the copy destination.
  • the system stores the insert data in the existing storages and also even in the additional storage as a move destination, and adds storage position information to the additional storage to the data stored in the existing storages.
  • FIGS. 13 to 21 explanation will be made as to the operation of a database system as a second embodiment which has such an arrangement as mentioned above, and wherein data division is based on the hash function value storage position correspondence table 317 shown in FIGS. 1 and 3 and the stock table of FIG. 6 is applied to the database system of FIG. 1.
  • FIG. 13 is a block diagram of a second detailed example of the arrangement of the database management system in FIG. 1 prior to rebalance operation
  • FIG. 14 is a flowchart for explaining an example of search execution destination determining operation of a DBMS acceptance section in FIG. 13
  • FIG. 15 is a flowchart for explaining an example of update/delete execution destination determining operation of the DBMS acceptance section in FIG. 13
  • FIG. 16 is a flowchart for explaining an example of update execution destination determining operation of the DBMS acceptance section in FIG. 13
  • FIG. 17 is a flowchart for explaining an example of delete execution destination determining operation of the DBMS acceptance section in FIG. 13, FIG.
  • FIG. 18 is a flowchart for explaining an example of insert execution destination determining operation of the DBMS acceptance section in FIG. 13
  • FIG. 19 is a flowchart for explaining an example of insert execution destination determining operation of the DBMS acceptance section in FIG. 13
  • FIG. 20 is a diagram of the database management system of FIG. 13 for explaining the rebalance operation thereof
  • FIG. 21 is a flowchart for explaining an example of the rebalance operation of the database management system of FIG. 20
  • FIG. 22 is a diagram for explaining a second example of accepting and executing a database processing request during the rebalance operation in the database system of FIG. 1.
  • a DBMS acceptance section 600 a performs respective operations of the request acceptor 601 , analyzer 602 and processing procedure generator 603 , and determines an execution destination through the operation of the execution destination decider 604 .
  • the areas defined in the storage area 632 are merely determined to be the execution destinations as detailed in FIG. 14 (step S 1301 ).
  • the DBMS executors 610 a and 610 b are determined as the execution destinations. And the DBMS acceptance section 600 a issues a search execution request from the execution request/result receiver 605 to the execution destinations thus determined, receives their results, and returns the last-received result thereto from the returner 606 .
  • the DBMS acceptance section 600 a performs the respective operations of the request acceptor 601 , analyzer 602 and processing procedure generator 603 , and determines an execution destination through the operation of the execution destination decider 604 .
  • the execution destination determining operation as in the search request, the areas defined in the storage area 632 are merely determined as execution destinations as shown in FIG. 15 (step S 1401 ).
  • the DBMS executors 610 a and 610 b are determined as the execution destinations. And the DBMS acceptance section 600 a issues an update/delete execution request from the execution request/result receiver 605 to the execution destinations thus determined, receives their results, and returns the last-received result from the returner 606 .
  • the DBMS executors 610 a and 610 b search for the data to be updated/deleted (steps S 1501 and SA 1601 ) and execute the update/delete operation through the operations of updates 612 a and 612 b and deletes 613 a and 613 b (steps S 1502 and S 1602 ) as shown in FIGS. 16 and 17.
  • the DBMS executor refers to the update/delete data and judges whether or not position information indicative of a copy destination is added to the data (steps S 1503 and S 1603 ). If the position information indicative of the copy destination is added, then the DBMS executor executes the update/delete operation over data to be copied (steps S 1506 and S 1606 ).
  • the DBMS executor extracts the data to be next updated/deleted and judges whether or not the next data is present (steps S 1504 and S 1604 ). In the presence of the next data, the DBMS executor repeats the operations of the steps S 1501 and S 1601 and subsequent steps until the data is fully searched for. In the absence of the next data, when the searching operation of all the data is completed, the DBMS executor informs the DBMS acceptance section 600 a of the execution completion (steps S 1505 and S 1605 ).
  • the DBMS acceptance section 600 a in FIG. 13 performs the operations of the request acceptor 601 , analyzer 602 and processing procedure generator 603 , and determines an insert destination through the operation of the execution destination decider 604 .
  • the insert destination determining operation is as shown in FIG. 18.
  • the DBMS acceptance section first refers to the during-rebalance flag 634 and judges whether or not the rebalance operation is being executed (step S 1701 ). In this case, the DBMS acceptance section determines that the rebalance operation is not being executed, finds a hash function value from the data to be inserted, refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), and selects an insert destination from the areas defined in the storage area 632 on the basis of the hash function value (step S 1702 ).
  • the DBMS acceptance section refers to the value of a product code for the insert data and finds its hash function value.
  • the hash function values are 0, 9, 4, 6 and 7, the DBMS acceptance section selects the storage 620 a .
  • the hash function values are 1, 8, 5, 2 and 3, the DBMS acceptance section selects the storage 620 b.
  • the DBMS acceptance section 600 a issues an insert execution request from the execution request/result receiver 605 to the selected insert destination and receives its result therefrom.
  • the execution request issuance and result reception are carried out according to a procedure as shown in FIG. 19.
  • the DBMS acceptance section 600 a in FIG. 13 refers to the during-rebalance flag 634 and judges whether or not the rebalance operation is being executed (step S 1801 ).
  • the DBMS acceptance section issues an insert execution request to the DBMS executor associated with the storage selected through the deciding operation of the execution destination decider 604 (step A 1802 ), and receives its result therefrom (step S 1803 ).
  • the DBMS acceptance section returns the last-received result. The operation of the DBMS acceptance section when determining that the rebalance operation is being executed will be explained later.
  • DBMS acceptance section first sets the during-rebalance flag 634 in FIG. 13 in ‘during rebalance’ during the execution of the rebalance operation (step S 2001 ), refers to the storage area information 632 and additional area information 633 , finds the number of divisions before the area addition and the number of division after the area division, refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), and finds data to be moved (step S 2002 ).
  • the DBMS acceptance section issues a data search request to the DBMS executor having the move data found at the step S 2002 (step S 2003 ).
  • the DBMS acceptance section issues the search request to the DBMS executors 610 a and 610 b.
  • the DBMS executors 610 a and 610 b when receiving the search request from the DBMS acceptance section 600 a search for one case of data and return its result to the DBMS acceptance section 600 a .
  • the DBMS acceptance section 600 a receives one case of result in the rebalance executor 1901 (step S 2004 ), calculates a hash function value based on the received data value, refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), finds a move destination (DBMS executor 610 c in FIG. 20)(step S 2005 ), and issues an insert request to the move destination (step S 2006 ).
  • the DBMS executor 610 c when receiving the insert request inserts the data in the storage 620 c through the operation of an insert 614 c , and informs the DBMS acceptance section 600 a of data insert position information and insert operation completion.
  • the DBMS acceptance section 600 a receives the data insert position information and insert operation completion at the rebalance executor 1901 (step S 2007 ), and adds move-destination data insert position information to the move source data (step S 2008 ).
  • the DBMS executor 610 a searches for data (‘trainer’) 1911 having a product code value of 677, returns it to the DBMS acceptance section 600 a . Since the data move destination is the storage 620 c , the DBMS acceptance section 600 a issues an insert request to the DBMS executor 610 c and data 1921 is stored in the storage 620 c . And after completion of the insert operation, the move-destination position information 1921 is added to the data 1911 of the move source of the DBMS executor 610 a.
  • trainer data
  • the rebalance executor 1901 of the DBMS acceptance section 600 a in FIG. 13 reads next search data and judges whether or not the next data is present (step S 2009 ). In the presence of the next data, the rebalance executor repeats the data acceptance, move-destination specifying, data inserting and move-destination position information adding operations of the steps S 2004 to S 2008 until the operation of the data is fully completed.
  • the DBMS acceptance section issues a delete request of the data added with the move-destination position information to the DBMS executor having so far stored therein the move data (step S 2010 ).
  • the DBMS executor when receiving the delete request searches for and deletes the target data. After completion of the delete operation, the DBMS executor informs the DBMS acceptance section 600 a of the delete completion.
  • the DBMS acceptance section 600 a receives the delete completion of the data (step S 2011 ), adds the additional area information 633 to the storage area information 632 (step S 2012 ), deletes the additional area information 633 (step S 2013 ), and erases the during-rebalance flag (step S 2014 ).
  • the DBMS acceptance section 600 a in FIGS. 13 and 20 accepts a request at the request acceptor 601 , analyzes the request at the analyzer 602 , generates a processing procedure at the processing procedure generator 603 and determines an execution destination at the execution destination decider 604 .
  • the areas defined in the storage area 632 of the table definition information 631 of the storage 630 in FIG. 20 are determined as the execution destinations as shown in FIG. 14 (step S 1301 ).
  • the DBMS acceptance section issues a search execution request to the DBMS executors 610 a and 610 b.
  • the execution request/result receiver 605 issues the search execution request to the execution destinations determined by the execution destination decider 604 , and receives their results. And the returner 606 returns the last received result received by the execution request/result receiver 605 .
  • the DBMS acceptance section 600 a accepts the request at the request acceptor 601 , analyzes the request at the analyzer 602 , generates a processing procedure at the processing procedure generator 603 , and determines an execution destination at the execution destination decider 604 .
  • the execution destination determining operation as shown in FIG. 15, the areas defined in the storage area 632 in the table definition information 631 of the storage 630 in FIG. 20 are defined as the execution destinations (step S 1401 ).
  • the DBMS acceptance section issued an update or delete execution request to the DBMS executors 610 a and 610 b.
  • the DBMS executors 610 a and 610 b search for (steps S 1501 and S 1601 ), updates or deletes (steps S 1502 and S 1602 ) data specified by the deletes 613 a and 613 b , as shown in FIGS. 16 and 17.
  • DBMS acceptance section refers to the update or delete data, judges whether or not position information indicative of a copy destination is added to the update or delete data (steps S 1503 and S 1603 ). When the position information is added, the DBMS acceptance section updates or deletes data at the copy destination (steps S 1506 and S 1606 ).
  • the DBMS acceptance section reads next data specified to be updated or deleted and judges whether or not the next data is present (steps S 1504 and S 1604 ).
  • the DBMS acceptance section repeats the operations of the steps S 1501 and S 1601 and subsequent steps until all the data is searched for.
  • the DBMS executors 610 a to 610 b inform the DBMS acceptance section 600 a of the execution completion (steps S 1505 and S 1605 ).
  • the DBMS acceptance section 600 a receives the execution completion notification from the DBMS executors 610 a and 610 b in this way, the DBMS acceptance section returns the last received result. That is, the execution request/result receiver 605 receives the results and the returner 606 returns the result last received at the execution request/result receiver 605 .
  • the DBMS acceptance section 600 a in FIGS. 13 and 20 performs the respective operations of the request acceptor 601 , analyzer 602 and processing procedure generator 603 , and determines an insert destination at the execution destination decider 604 .
  • the insert destination determining operation is as shown in FIG. 18.
  • the DBMS acceptance section first refers to the during-rebalance flag 634 and determines whether or not the rebalance operation is being executed (step S 1701 ). Because the rebalance operation is being executed, the DBMS acceptance section finds a hash function value based on the data to be inserted (step S 1701 ), refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS.
  • step S 1703 determines an insert destination (1) (to be arbitrarily inserted) from the storage area 632 on the basis of the hash function value (step S 1703 ), and determines an insert destination (2) (to be arbitrarily inserted) from the areas defined in the storage area 632 and the area defined in the additional area 633 (step S 1704 ).
  • the storage 620 a is selected.
  • the storage 620 b is selected.
  • the storage 620 c is selected.
  • the DBMS acceptance section 600 a issues an insert execution request from the execution request/result receiver 605 to the insert destination thus selected, and receives their results.
  • the issuance of the execution request and acceptance of the results are as shown in FIG. 19.
  • the execution request/result receiver 605 in FIG. 20 first refers to the during-rebalance flag 634 in the table definition information 631 of the storage 630 and judges whether or not the rebalance operation is being executed (step S 1801 ).
  • the DBMS acceptance section examines whether the storage as the insert destination (1) coincides with the storage as the insert destination (2) (step S 1804 ). When finding a coincidence therebetween, the DBMS acceptance section issues an insert execution request to the determined insert destination (step S 1805 ), and receives its result (step S 1806 ).
  • the DBMS acceptance section issues an insert execution request first to the insert destination (2) (step S 1807 ) and, after completion of the insert operation at the associated DBMS executor, receives insert destination data storage position information therefrom (step S 1808 ).
  • the DBMS acceptance section adds the data storage position information received at the time of completion of insert operation to the insert destination (2) to the insert data, issues an insert execution request to the insert destination (1) (step S 1809 ), and, after the associated DBMS executor completes the insert operation, receives its result (step S 1810 ).
  • the insert destination (1) is the same as the insert destination (2), that is, the same storage 620 a .
  • the inserts (1) and (2) are the same as the insert storage 620 b .
  • the DBMS acceptance section issues an insert request to the respective DBMS executors 610 a and 610 b and receives their insert results.
  • the insert destination (1) is the storage 620 a and the insert destination (2) is the storage 620 c .
  • the DBMS acceptance section issues an insert request first to the DBMS executor 610 c corresponding to the storage 620 c , receives insert position information data, and issues an insert request of data added with the insert position data received by the DBMS executor 610 c to the DBMS executor 610 a corresponding to the storage 620 a.
  • the hash function values are 2 and 3
  • the insert destination (1) is the storage 620 b
  • the insert destination (2) is the storage 620 c .
  • the DBMS acceptance section first issues an insert request to the DBMS executor 610 c associated with the storage 620 c , receives insert position information data, and the issues an insert request of data added with the insert position data received at the DBMS executor 610 c to the DBMS executor 610 b associated with the storage 620 b.
  • the execution destination of the search, update, delete or insert operation has been determined for all the storages having the date stored therein in this example. However, in the case of the search, update, delete or insert operation having a condition added thereto, the limited execution destination can be executed.
  • hash function values of 0, 4, 6, 7 and 9 are stored in a storage 2120 and hash function values of 1, 2, 3, 5 and 8 are stored in a storage 2130 respectively as divided.
  • a search operation 2100 is executed by the storages 2120 and 2130
  • an update/delete operation 2100 is executed by the storages 2120 and 2130
  • such insert operation of data 2131 as to provide a hash function values of 3 is executed by the storage 2130 .
  • a rebalance operation 2103 selects data 2121 to be moved to the storage 2140 from the data stored in the storages 2120 and 2130 , copies the selected data 2121 to the storage 2140 , and adds storage position information 2122 of data 2142 copied to the copy source data 2121 .
  • the copy of the data 2121 is carried out by the search operation of the move data of the storages 2120 and 2130 and by the insert operation to the data 2142 .
  • the data 2121 is locked so that another user is prohibited from performing the search, update, or delete operation.
  • the search operation 2100 during such rebalance operation is executed in the existing areas. That is, the search operation is executed in the storages 2120 and 2130 . Further update/delete operation 2101 during the rebalance operation is also executed in the existing area. When the copy destination position information is added to the data to be updated/deleted, however, the update/delete operation is executed even over data indicated by the copy destination position information.
  • the data 2141 is stored in the storage 2140 and the data 2131 added with the data position information 2132 is stored in the storage 2130 .
  • the system can accept search, update, delete and insert processing requests to the table being rebalanced during the rebalance operation and can execute them concurrently.
  • the operation of the insert destination decider find a hash function based on data to be inserted, refers to the hash function value storage position correspondence table 635 , and selects an insert destination from one of the areas defined in the storage area information 632 by the hash function other than the area defined in the disconnection area information 636 .
  • the database system and database management method in this example performs its data management operation according to a procedure which follows.
  • the system When the data as the update or delete object is added with position information indicative of a copy destination to the additional storage, the system performs the same update or delete operation over the data of the copy destination. Further, when an insert request to the table data is issued, the system stores the data in the storage determined according to the division rule specified only for the existing storages. Further, in a division method which is applied to the storages including the additional storage, when the data is to be moved to the additional storage, the system stores the data even in the additional storage and adds storage position information thereof to the additional storage to the data stored in the existing storages.
  • the database system and database management method in this example at the time of performing rebalance operation over the data stored in the existing storages due to addition of a storage to be rebalanced in table data of a relational database management system of storing as divided into a plurality of storages, can execute database services such as search, update, delete and insert concurrently.
  • the present invention is not limited to the embodiments explained with reference to FIGS. 1 to 25 but may be modified in various ways so long as it does not depart from its gist or subject matter.
  • the database system and database management system have used three storages in the present embodiment, the number of such storages may be two or four or more.
  • the present invention is not limited only to the use of the hash function as in the present embodiment, but a key range division method or a round robin division method may be employed.
  • the DBMS 300 has been configured with computers as shown in FIG. 2 as its hardware configuration.
  • the DBMS may be configured with computers provided with input devices such as keyboards and display devices such as CRT (cathode ray tube).
  • input devices such as keyboards
  • display devices such as CRT (cathode ray tube).
  • CRT cathode ray tube
  • FD flexible disk
  • the program can be downloaded from a communication device via a network and then installed.

Abstract

A database system for storing table data as divided in a plurality of storages has a processing request acceptance section and an execution section which, at the time of rebalancing already stored data in response to addition of a storage, can execute inquiry operations concurrently. The system determines data to be moved from existing storages to the additional storage. When search, update and delete processing requests are issued during execution of the rebalance operation of copying the data to the additional storage and deleting the original data, both the DBMS acceptance section and DBMS executor section execute the operation corresponding to the requests. When an insert processing request is issued, the system determines a data insert destination on the basis of contents of a step of dividing the data from the existing storages to the additional storage.

Description

    CROSS-REFERENCES TO RELATED APPLICATION
  • This application relates to copending patent application Ser. No. 09/702,351 entitled “DATABASE MANAGEMENT METHODS AND EQUIPMENT, AND DATABASE MANAGEMENT PROGRAM STORAGE MEDIA” filed by Nobuo Kawamura on Oct. 31, 2000.[0001]
  • BACKGROUND OF THE INVENTION
  • The present invention relates to a database for data management based on table, and more particularly to a database system suitable to rebalance data among shared database files at the time of changing the number of storages for storing therein table data as divided. [0002]
  • B. Bergsten et al., “Overview of Parallel Architectures for Databases”, THE COMPUTER JOURNAL, Vol. 36, No, 8, 1993, pp. 734-740 teaches an architecture wherein the processing load of a relational database management system (RDBMS) is distributed into a plurality of processors for parallel execution. D. J. DeWitt et al., Parallel Database Systems: The future of Database Processing or a Passing Fad?, SIGMOND RECORD, Vol. 19, No. 4, December 1990, pp. 104-112 discloses a database system wherein table data are stored as divided in a plurality of disks (storages) for distribution of disk access in RDBMS. [0003]
  • One of such conventional table division systems is a hash division system in which a hash function is used for values of columns which make up a table for uniform division. In this system, since table data are uniformly stored in respective disks (storages), a load can be uniformly distributed thereinto. [0004]
  • However, as the amount of data increases, this will involve lack of capacities of the storages or performance deterioration. To avoid this, it becomes necessary to increase the number of disks for storage of table data by increasing the number of divisions. [0005]
  • U.S. Pat. Nos. 6,145,067; 5,917,999 and 5,564,116 disclose disk array systems wherein, when a storage is added, data rebalance among shared database files has to be carried out concurrently with data access (read, write). In the data rebalance technique of these disk array systems, however, it is necessary to share information on, e.g., position during data rebalance. In other words, in order that a node for accepting an access request obtains information during data rebalance, it is required to perform data transfer between associated nodes for data rebalance and then to inform its information to the node for acceptance of the access request, thus resulting in generation of a communication overhead. [0006]
  • Accordingly, even when the data rebalance technique in the aforementioned disk array systems is applied to a database system, it is difficult to effectively execute the data rebalance processing and data access parallelly or concurrently. That is, it is required in the database that the data rebalance and data access be executed concurrently while eliminating the need for sharing information such as a position during the data rebalance. [0007]
  • The problem in the prior art is that database processing such as search, update, delete or insert to a table cannot be executed during data rebalance execution caused by changing the number of storages for storing tables. [0008]
  • SUMMARY OF THE INVENTION
  • It is therefore an object of the present invention to provide a database system, database management method and program, which, even during data rebalance execution of table data, can perform acceptance and execution of a database processing request such as search, update, delete or insert concurrently with the rebalance execution and with improved operability and performance of a database. [0009]
  • In accordance with an aspect of the present invention, the above object is attained by providing a database management system which includes a storage having a first storage area corresponding to a plurality of storages for saving a plurality of data items and a second storage area corresponding to a storage to be added to or disconnected from the plurality of storages, an acceptance section connected to the storage for accepting a data processing request, the data processing request including data processing in the plurality of storages and data rebalance between the storages, and a plurality of executors connected to the acceptance section for sequentially executing at least any of the data processing in the plurality of storages and the data rebalance. [0010]
  • The storage may have a storage area correspondence table indicative of combinations of predetermined data items to be shared by the plurality of storages and to be sharedly stored thereby according to the request of addition or disconnection to cause the data rebalance between the storages. [0011]
  • The acceptance section has a during-rebalance flag indicating that ‘during rebalance’ of the plurality of storages by addition or disconnection to or from the plurality of storages. According to a data processing request to the data items stored in the plurality of storages, the acceptance section can refer to the during-rebalance flag and reflect data update even on the storages subjected to the data rebalance. [0012]
  • The system in accordance with the invention of the present application may include means, in response to a rebalance request of data to be rebalanced in a storage added according to an addition request, for adding data position information to data before subjected to the rebalance execution by the data rebalance request in the plurality of storages, and means for deleting the data added with the data position information before subjected to the rebalance execution in response to the rebalance request after the rebalance execution by the rebalance request. [0013]
  • In accordance with another aspect of the present invention, there is provided a database management method which can be realized in the above system. The method includes steps of allocating a plurality of data items in a table to a plurality of storages for their storage; storing the table data in the storages determined according to a specified division rule (method); when a request is issued to add a storage for storage of the table data, determining part of the data stored in the existing storages which is to be moved to the addition storage with use of information about the existing and additional storages according to the specified division method and performing data rebalance operation to move all the determined data to the additional storage; when a request for search, update delete to the table is issued during the data rebalance execution, searching for, updating or deleting the table data stored in the existing storages and in the additional storage; and when a request of insert in the table is issued, inserting the data determined by the specified data division method in the storages together with information about existing and additional storages. In accordance with a further aspect of the present invention, there is provided a parallel database method which includes steps of allocating a plurality of data items in a table as table data to a plurality of storages for their storage and storing the table data in storages determined by a specified division method; when a request is issued to search, update or delete the table is issued, performing parallel operation over the respective storages; when a request is issued to add a storage for storage of the table data, determining part of the data stored in existing storage parts which is to be moved to the additional storage according to a specified division method with use of information about the existing and additional storages; performing data rebalance operation to move all the determined data to the additional storage; when a request is issued to search, update or delete the table during the data rebalance operation, performing parallel operation in the existing storages over the table data stored therein to search for, update or delete the table data; after completing all the operations of the existing storages, performing parallel operation over the respective storages to search, update or delete the table in the additional storage; and when a request is issued to insert data in the table, inserting the data determined by the specified data division method in the existing and additional storages together with information about the existing and additional storages. [0014]
  • In accordance with a further aspect of the present invention, there is provided a database method which includes steps of allocating a plurality of data items in a table as the table data to a plurality of storages for their storage; storing the table data in the storages determined by a specified division method; when a request is issued to add a storage for storage of the table data therein, determining part of the data stored in existing storages which is to be moved to the additional storage according to the specified division method with use of information about the existing and additional storages, copying the determined data from the existing storages to the additional storage, and adding position information of the copied data on the additional storage to the data of the storages as a copy source; when, the copy of all the data to be moved o the additional storage is completed, performing data rebalance operation to delete all the data of the copy source; when a request is issued to search the table during the data rebalance execution, searching the existing storages for associated data stored therein; when a request is issued to update or delete the table, updating or deleting associated data stored in the existing storages; when position information indicative of a copy target to the additional storage is added to the data to be updated or deleted, updating or deleting even data of the copy target; when a request is issued to insert data in the table, storing the data in the existing storages determined by the specified division method; when the data to be added is judged as to be moved by the specified division method even to the additional storage, storing the data even in the additional storage as a move target; and adding storage position information to the additional storage to the data stored in the existing storages. [0015]
  • The aforementioned systems and methods can be selected and executed depending on the defined table.[0016]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of an exemplary arrangement of a database system in accordance with the present invention; [0017]
  • FIG. 2 is a block diagram of an exemplary structure of a hardware section in the database system of FIG. 1; [0018]
  • FIG. 3 is exemplary registration contents of a table showing hash function value storage position correlation; [0019]
  • FIGS. 4A and 4B are diagrams for explaining a first example of accepting and executing a database processing request during rebalance operation of a database management system in FIG. 1; [0020]
  • FIG. 5 is a block diagram of a first exemplary detailed arrangement of the database management system in FIG. 1; prior to the rebalance operation thereof; [0021]
  • FIG. 6 shows an example of a stock table to be managed by the database management system of FIG. 5; [0022]
  • FIG. 7 is a flowchart for explaining a first example of processing operation of a DBMS acceptance section in FIG. 5; [0023]
  • FIG. 8 is a flowchart for explaining a second example of processing operation of the DBMS acceptance section in FIG. 5; [0024]
  • FIG. 9 is a flowchart for explaining a third example of processing operation of a DBMS acceptance section in FIG. 5; [0025]
  • FIG. 10 is a diagram for explaining the first operational example of the database management system of FIG. 5 associated with the rebalance operation; [0026]
  • FIGS. 11A and 11B show a flowchart for explaining an example of the rebalance operation of the database management system of FIG. 10; [0027]
  • FIG. 12 is a block diagram of an exemplary detailed arrangement of the database system of FIG. 1 after the rebalance operation; [0028]
  • FIG. 13 is a block diagram of a second exemplary detailed arrangement of the database management system in FIG. 1 prior to the rebalance operation; [0029]
  • FIG. 14 is a flowchart for explaining an example of search execution target determining operation of a DBMS acceptance section in FIG. 13; [0030]
  • FIG. 15 is a flowchart for explaining an example of update/delete execution target determining operation of the DBMS acceptance section in FIG. 13; [0031]
  • FIG. 16 is a flowchart for explaining an example of update execution target determining operation of the DBMS acceptance section in FIG. 13; [0032]
  • FIG. 17 is a flowchart for explaining an example of delete execution target determining operation of the DBMS acceptance section in FIG. 13; [0033]
  • FIG. 18 is a flowchart for explaining an example of insert execution target determining operation of the DBMS acceptance section in FIG. 13; [0034]
  • FIG. 19 is a flowchart for explaining another example of insert execution target determining operation of the DBMS acceptance section in FIG. 13; [0035]
  • FIG. 20 is a diagram of another exemplary arrangement of the database management system of FIG. 13 associated with the rebalance operation; [0036]
  • FIGS. 21A and 21B shows a flowchart for explaining an example of rebalance operation of the database management system of FIG. 20; [0037]
  • FIGS. 22A and 22B are diagrams for explaining a second example of accepting and executing a database processing request in the rebalance operation of the database system of FIG. 1; and [0038]
  • FIGS. [0039] 23 to 25 are diagrams for explaining the data processing of the rebalance operation necessary when the number of storages are reduced in accordance with the invention.
  • DESCRIPTION OF THE EMBODIMENTS
  • Embodiments of the present invention will be detailed by referring to the accompanying drawings. [0040]
  • FIG. 1 is a block diagram of an exemplary arrangement of a database system in accordance with an embodiment of the present invention, FIG. 2 is a block diagram of an example of a hardware section in the database system of FIG. 1, FIG. 3 shows exemplary registration contents of a table of hash function value storage position correspondence in FIG. 1, and FIG. 4 shows diagrams for explaining a first example of accepting and executing a database processing request in rebalance operation of a database management system in FIG. 1. [0041]
  • As shown in FIG. 2, a database management system (which is also shown by DBMS in the drawings) [0042] 300 forming one section of the database system of the present invention, which includes a central processing unit (CPU), an input device, a display unit and so on, functions to perform database processing such as data search, update, delete, or insert (add) on the basis of a request from a plurality of user terminals 330 a to 330 c each having a computer function. The database management system 300 includes a DBMS acceptance node 400 and DBMS execution nodes 410 a to 410 c, which have each a computer function and are interconnected by a network 301.
  • The [0043] DBMS acceptance node 400 has a CPU 401 and a main memory 402 and also is connected to an external storage 318 in the form of a hard disk drive (HDD) or the like. When the CPU 401 executes a DBMS acceptance program 310 a stored in the main memory 402, the DBMS acceptance section 310 in FIG. 1 can perform respective functions in the DBMS acceptance operation.
  • The [0044] DBMS execution nodes 410 a to 410 c have CPU's 411 a to CPU 411 c and main memories 412 a to 412 c respectively, and are also connected to external storages 325 a to 325 c respectively. When the CPU's 411 a to CPU 411 c execute respective DBMS execution programs (which is shown by DBMS execution PGM's in the drawings) 320 a to 320 c stored in the main memories 412 a to 412 c, the DBMS execution programs 320 a to 320 c in FIG. 1 can perform respective functions for the DBMS execution.
  • The [0045] DBMS acceptance program 310 a and DBMS execution programs 320 a to 320 c are usually stored in a recording medium including an optical disc such as CD-ROM (compact disc-read only memory) or DVD (digital video disc/digital versatile disc). These programs are installed from these recording medium to the external storage 318 and external storages 325 a to 325 c to be loaded into the main memory 402 and main memories 412 a to 412 c.
  • A [0046] DBMS acceptance section 310 and the DBMS execution programs 320 a to 320 c in the DBMS 300 shown in FIG. 1, which correspond to the DBMS acceptance node 400 and DBMS execution nodes 410 a to 410 c shown in FIG. 2, are interconnected by the network 301.
  • The [0047] DBMS acceptance section 310 has a request acceptor 311, an analyzer 312, a processing procedure generator 313, an execution destination decider 314, an execution request/result receiver 315, a returner 316, and a rebalance executor 102. The DBMS executors 320 a to 320 c have searches 321 a to 321 c, updates 322 a to 322 c, deletes 323 a to 323 c, and inserts 324 a to 324 c respectively.
  • The [0048] DBMS acceptance section 310 accepts from user terminals a processing request 330 such as data processing and rebalance operation via the request acceptor 311, analyzes the request in the analyzer 312 therein, and generates a processing procedure to realize the request in the processing procedure generator 313.
  • Then the [0049] execution destination decider 314 determines which one of the DBMS executors should execute the generated processing procedure on the basis of data division conditions, the execution request/result receiver 315 issues an execution request to the determined DBMS executor and receives its execution result from the DBMS executor. The received result is returned from the returner 316 to the user.
  • The [0050] analyzer 312, processing procedure generator 313 and execution destination decider 314 refer to a hash function value storage position correspondence table 317 or table definition information 319 stored in the external storage 318, and acquire information for determination of a data storage destination or information about the table.
  • Stored in the [0051] table definition information 319 are, for example, storage area information 340 for management of storages having the table stored as divided therein, addition area information 341 for management of a storage for storage area addition, and a during-rebalance flag 342 indicative of ‘during rebalance operation’. Details of respective constituent elements of the table definition information 319 will be explained later in connection with a specific example with reference to FIGS. 5 to 12.
  • The [0052] DBMS executors 320 a to 320 c, in response to an instruction of search, update, delete or insert received from the DBMS acceptance section 310, activate the searches 321 a to 321 c, updates 322 a to 322 c, deletes 323 a to 323 c or inserts 324 a to 324 c, execute its processing procedure, and return the execution result to the DBMS acceptance section 310.
  • During the execution of the processing procedure, the [0053] DBMS executors 320 a to 320 c access table data 326 stored in the external storages 325 a to 325 c.
  • In such processing, when the [0054] execution destination decider 314 of the DBMS acceptance section 310 selects a plurality of executors (320 a to 320 c), the execution request/result receiver 315 of the DBMS acceptance section 310 may issue an execution request to all the selected DBMS executors (320 a to 320 c) simultaneously to execute parallel processing in the respective DBMS executors (320 a to 320 c).
  • Explanation will now be made as to the data dividing operation in the [0055] DBMS 300. In this example, when data are stored as divided, a hash function is applied to the data to be stored to generate values of from 0 to 9, and the data are distributed to respective storage destinations according to the generated values.
  • The table [0056] 317 showing its details in FIG. 3 is used to determine a storage position based on the hash function value. In this example, data is divided into up to 10 parts according to the number of external storages connected. The table also shows information about storage areas where data is stored at the time of the division by the hash function values.
  • For example, when data is stored as divided into two storages, as shown items of “[0057] area 0” and “area 1” at the time of two divisions in the hash function value storage position correspondence table 317, data about hash function values of 0, 4, 6, 7 and 9 are stored in the “area 0”, and data about hash function values of 1, 2, 3, 5 and 8 are stored in the “area 1”.
  • When a storage area was added, even data to be moved by the [0058] rebalance executor 102 can be found from the hash function value storage position correspondence table 317. When a single storage is added and two divisions are changed to three divisions, for example, “area 2” is added and data of hash function values of 2, 7 and 3 are stored in “area 2”, as in the case of three divisions in the hash function value storage position correspondence table 317. Thus it is only required to move the data of the hash function values of 2, 7 and 3 so far stored in “area 0” and “area 1” to “area 2” as an addition area.
  • Similarly, in the case of changing from two divisions to five divisions, “[0059] area 2”, “area 3” and “area 4” are added, data of hash function values of 2 and 7; 3 and 6; and 4 and 5 are moved to “area 2”, “area 3” and “area 4” respectively.
  • For data moving operation when such a storage area was added, that is, for rebalance and acceptance of a request of database processing (such as search, update, delete, or insert); the [0060] database management system 300 in the database system having such an arrangement as shown in FIG. 1 copes with it in such a manner as to be explained below.
  • More specifically, when it is required to add a storage for table data such as an [0061] external storage 325 c external storage, the rebalance executor 102 in the DBMS acceptance section 310 refers to the hash function value storage position correspondence table 317, determines data to be moved from existing storages such as the external storages 325 a and 325 b to an additional storage (external storage 325 c), and moves all the data determined as to be moved to the additional storage (external storage 325 c).
  • When such processing as to search for, update or delete data in the table is required during execution of the data rebalance operation; the database management system executes the search, update or delete operation for the existing storages ([0062] external storages 325 a and 325 b) and the additional storage (external storage 325 c) respectively. When it is required to insert data in the table, the database management system refers to the hash function value storage position correspondence table 317, and inserts the data in the associated storage (any of the external storages 325 a to 325 c).
  • Assume that the [0063] database management system 300 in FIG. 1 is of a parallel database type which performs parallel processing operation over storages when it is required to search for, update and delete table data. If it is required to search for, update and delete the table data during execution of data rebalance operation, then the system performs parallel processing operation over existing storages ( external storages 325 a and 325 b) to search fir, update and delete the table data stored therein. After fully completing the processing of the existing storages, the system sequentially performs the search, update and delete operations over the additional storage and external storage 325 c. Further, when it is required to insert data in the table data, the system refers to the hash function value storage position correspondence table 317 including information on the existing storages ( external storages 325 a and 325 b) and information on the additional storage (external storage 325 c), and inserts the data in one of the storages ( external storages 325 a, 325 b and 325 c) determined by the execution destination decider 314.
  • Explanation will be made in more detail by referring to FIG. 4 as to how to control the data moving operation by the [0064] database management system 300 in FIG. 1 in accordance with the present invention when a storage area is added, that is, as to operation of accepting and executing a database processing request during rebalance operation.
  • Explanation will be made as to the rebalance operation as well as the search, update, delete and insert operations during the rebalance operation when there is a table wherein data indicative of the hash function values of 0, 4, 6, 7 and [0065] 9 are stored as divided in a storage 120 and data indicative of the hash function values of 1, 2, 3, 5 and 8 are stored as divided in a storage 130 as shown in FIG. 4A.
  • In the arrangement shown in FIG. 4A, [0066] operation 100 of search, update and delete operation is carried out in the storages 120 and 130 over data 121 to 125 and 131 to 135; and an insert operation 101 of such data 133 as to provide a hash function value of 3 is carried out in the storage 130.
  • When a [0067] storage 140 was added as shown in FIG. 4B (a combination of the storages 120 and 130 is called an existing area and the storage 140 is called an additional area), a rebalance operation 102 a selects data to be moved to the storage 140 from data stored in the storages 120 and 130 and moves the selected data to the storage 140 to provide hash function values of 7, 2 and 3.
  • This data move operation is carried out in such a procedure as to first search for data of the [0068] storages 120 and 130 to be moved, insert it in the storage 140 and then delete the data of the storages 120 and 130.
  • In the database system, during the operation after the search for the data to be moved until the deletion of the old data already moved, the data is locked so that another user is prohibited from searching for, updating or deleting the data. [0069]
  • In the present embodiment, during the execution of the [0070] rebalance operation 102 a, the data operation 100 of search, update or delete is carried out in both existing and additional areas. That is, the data operation is carried out in the storages 120, 130 and 140. In this connection, during such search, update or delete operation, the data in question is locked so that the rebalance operation 102 a is prohibited from referring to the data unless otherwise specifically stated by the user.
  • The data insert [0071] operation 101 to provide a hash function value of 3 during the rebalance operation stores the data in question in the storage 140 as an additional area to be moved.
  • When another user tries to search for, update or delete the data being moved through the [0072] rebalance operation 102 a, he must wait until the data move operation is completed because access to the data is locked. However, after the completion of the data move operation releases the lock, he can resume the operation so far awaited.
  • Further, even when another user tries to move the data being searched for, updated or deleted through the [0073] rebalance operation 102 a, he must wait because access to the data is locked, until the lock is released. Once the lock is released, however, he can resume the rebalance operation so far awaited.
  • Thus it can be prevented that data be unduly updated in its value or deleted. [0074]
  • During the execution of the [0075] rebalance operation 102 a, data to provide a hash function value of 7 is stored in the storage 120 or 140 and data to provide hash function values of 2 and 3 is stored in the storage 120 or 140. However, since the operation 100 of search, update or delete refers to both the existing and additional areas, the operation 100 can carry out the search, update or delete operation regardless of whether the data is stored in the existing storages or additional storage.
  • Further, when data to be rebalanced is inserted in a rebalance destination, excessive rebalance operation to the existing areas can be avoided. [0076]
  • Through the above operation, it becomes possible to accept and concurrently execute search, update, delete and insert processing requests to table data during the rebalance operation. [0077]
  • Such processing operation will be explained in detail in connection with specific examples of FIGS. [0078] 5 to 12.
  • FIG. 5 is a block diagram of a first detailed example of the arrangement of the database management system in FIG. 1 prior to its rebalance operation, FIG. 6 shoes exemplary contents of a stock table to be managed by the database management system of FIG. 5, FIG. 7 is a flowchart for explaining a first example of the processing operation of a DBMS acceptance section in FIG. 5, FIG. 8 is a flowchart for explaining a second example of the processing operation of the DBMS acceptance section in FIG. 5, FIG. 9 is a flowchart for explaining a third example of the processing operation of the DBMS acceptance section in FIG. 5, FIG. 10 is a diagram for explaining the arrangement and operation of the database management system in FIG. 5 associated with the rebalance operation, FIG. 11 is a flowchart for explaining an exemplary rebalance operation of the database management system of FIG. 10, and FIG. 12 is a block diagram of an exemplary specific arrangement of the database system after the rebalance operation. [0079]
  • A [0080] DBMS acceptance section 600 and DBMS executors 610 a to 610 c in the database management system in the database system of FIG. 5 have substantially the same functions as the DBMS acceptance section 310 and DBMS executors 320 a to 320 c in the database management system 300 in FIG. 1.
  • Stored in a [0081] storage 630 connected to the DBMS acceptance section 600 are a hash function value storage position correspondence table 635 having the same contents as the hash function value storage position correspondence table 317 shown in FIG. 3 as well as table definition information 631 defined for each table. The table definition information 631 has a storage area (shown by “additional area” in the drawings) 632 indicative of a table storage place, additional area information (shown by “additional area” in the drawing) 633, and a during-rebalance flag 634 indicative of “during rebalance”.
  • Storages [0082] 620 a and 620 b connected to the DBMS executors 610 a and 610 b respectively have storage data 621 and 622 of stock tables in the form of a database. The DBMS executors execute search, update, delete or insert operation in response to an instruction received from the DBMS acceptance section 600.
  • In this example, it is assumed that the number of divisions is set at 10 as a maximum, a hash function used for the division is set to have values of residues obtained when identification numbers (product codes) of products in [0083] storage data 621 and 622 are divided by the maximum division number 10.
  • As shown in FIG. 6, the database treated in this example is a stock table [0084] 500 associated with clothing which includes items of product code 510, product name 520, color 530, unit price 540 and stock amount 550.
  • When the stock table [0085] 500 of FIG. 6 is applied to the database system of FIG. 5 and data is stored as divided in the storages 620 a and 620 b with use of the value of the product code 510, the distribution of the hash function value storage position correspondence table 635, i.e., the hash function value storage position correspondence table 317 of FIG. 3 in the two-division case is applied to the hash function value calculated for the value of the product code 510.
  • As a result, data indicative of hash function values of 0, 9, 4, 6 and 7 are stored in the [0086] storage 620 a, and data indicative of hash function values of 1, 8, 5, 2 and 3 are stored in the storage 620 b. Further, storages A and B are defined in the storage area 632 of the table definition information 631 in the storage 630.
  • When a search, update or delete request is issued under this condition, the [0087] DBMS acceptance section 600 accepts the request at a request acceptor 601, analyzes the accepted request at an analyzer 602, generates a processing procedure at a processing procedure generator 603 to realize the analyzed request, and determines one or ones of the DBMS executors which execute(s) the generated processing procedure at an execution destination decider 604.
  • In details of the operation of the [0088] execution destination decider 604, as shown in FIG. 7, the decider first refers to the value of the during-rebalance flag 634 in the table definition information 631 of the storage 630 to judge whether or not the rebalance operation is being executed (step S701). When determining that the rebalance operation is not being executed, the decider determines the area defined in the storage area 632 as its execution destination (step S702).
  • In the example of FIG. 5, since the storages A and B are defined in the [0089] storage area 632, the DBMS executors 610 a and 610 b are determined as the execution destinations. The operation when the judgement result at the step S701 indicates that the rebalance operation is being executed will be explained later.
  • For the execution destinations thus determined, an execution request/[0090] result receiver 605 in the DBMS acceptance section 600 issues an execution request to the execution destinations and receives their execution results therefrom. In details of the operation of the execution request/result receiver 605, as shown in FIG. 8, the execution request/result receiver first refers to the value of the during-rebalance flag 634 and judges whether or not the rebalance operation is being executed (step S711).
  • When the receiver determines that the rebalance operation is not being executed, it issues a simultaneous execution request to all the DBMS executors determined by the execution destination decider [0091] 604 (step S712) and receives execution results from the DBMS executors (step S713).
  • The [0092] DBMS acceptance section 600 in FIG. 5 returns the last-received execution result through the operation of a returner 606. In this connection, the operation when the judgement result at the step S711 indicates that the rebalance operation is being executed will be explained later.
  • When an insert request is issued to the database management system in FIG. 5, the [0093] DBMS acceptance section 600 performs the operations of the request acceptor 601, analyzer 602 and processing procedure generator 603, and determines an execution destination as an insert destination at the execution destination decider 604.
  • In details of the operation of the [0094] execution destination decider 604 to determine an insert execution destination, as shown in FIG. 9, the decider 604 first refers to the value of the during-rebalance flag 634 in the table definition information 631 of the storage 630 in FIG. 5 and judges whether or not the rebalance operation is being executed (step S721).
  • When determining that the rebalance operation is not being executed, the decider calculates a hash function value on the basis of the data to be inserted, and selects an insert execution destination from the areas defined in the [0095] storage area 632 with use of the hash function value obtained by referring to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3) (step S722). In this connection, the operation when the result judged at the step S721 indicates the rebalance operation is being executed will be explained later.
  • In the example of FIG. 5, the DBMS acceptance section refers to the value of the product code of the insert data and finds a hash function value. When the hash function values are 0, 9, 4, 6 and 7, the DBMS acceptance section selects the [0096] storage 620 a; while, when the hash function values are 1, 8, 5, 2 and 3, the DBMS acceptance section selects the storage 620 b.
  • For the insert destination thus selected, the [0097] DBMS acceptance section 600 issues an insert execution request and receives its result from and at the execution request/result receiver 605, and returns the last-received result from the returner 606.
  • In the database management system of FIG. 5, when a [0098] storage 620 c is added as a storage area of the stock table as shown in FIG. 10, a storage C is defined in the additional area information 633 of the storage 630, a rebalance operation request is generated, and the operation of a rebalance executor 1100 is started.
  • Explanation will be made as to details of the rebalance operation of the [0099] rebalance executor 1100 with reference to FIG. 11. More specifically, the rebalance executor set the during-rebalance flag 634 in the table definition information 631 of the storage 630 in FIG. 5 at “during execution of the rebalance operation” (step S1101), finds the numbers of divisions before and after the area addition by referring to the storage area information 632 and additional area information 633, and finds data to be moved by referring to the hash function value storage position correspondence table 635 (step S1102).
  • A single area is added to change the system from the two-division type to a three-division type in FIG. 10. Thus it will be appreciated that data indicative of the hash function values of 2, 7 and 3 is to be moved on the basis of the hash function value storage position correspondence table [0100] 635 (hash function value storage position correspondence table 317 of FIG. 3).
  • The [0101] rebalance executor 1100 issues a data search request to the DBMS executor having the to-be-moved data thus found and stored therein (step S1103). In FIG. 10, since data indicative of the hash function value of 7 to be moved is stored in the storage 620 a and data indicative of the hash function values of 2 and 3 are stored in the storage 620 b, the rebalance executor issues a search request to the DBMS executors 610 a and 610 b.
  • The [0102] DBMS executors 610 a and 610 b when receiving the search request from the rebalance executor 1100 searches for one case of data and return its result to the DBMS acceptance section 600.
  • In FIGS. 11A and 11B, the [0103] DBMS acceptance section 600 accepts the data corresponding to one case returned from the DBMS executors 610 a and 610 b (step S1104), calculates a hash function value based on the value of the accepted data, finds a move destination by referring to the hash function value storage position correspondence table 635 (step S1105), and issues an insert request to the DBMS executor as the move destination (step S1106).
  • The DBMS executor when receiving the insert request executes data insert operation and informs the [0104] DBMS acceptance section 600 of its insert completion (step S614). The DBMS acceptance section 600 accepts a notification indicative of the data insert completion (step S1107) and issues a delete request to delete the insert original data (step S1108).
  • For example, in the case of the [0105] rebalance executor 1100 in FIG. 10, the DBMS executor 610 a searches for data 1000 having a product code value of 677 and returns it to the DBMS acceptance section 600. Since the data move destination is the storage 620 c, the rebalance executor 1100 issues an insert request to the DBMS executor 610 c to store data 1001 in the storage 620 c.
  • After the insert completion, the [0106] rebalance executor 1100 issues a request to the DBMS executor 610 a to delete the data 1000 having a product code value of 677.
  • When the [0107] DBMS executor 610 a receives the delete request from the rebalance executor 1100, a delete 613 a in the DBMS executor 610 a deletes the corresponding data. After completing the delete operation, the DBMS executor 610 a informs the DBMS acceptance section 600 of the delete completion. The DBMS acceptance section 600 accepts the data delete completion notification (step S1109), and extracts next search data and examines the presence or absence of the next search data (step S1110).
  • In the presence of the next data, the [0108] DBMS acceptance section 600 accepts data at the steps S1110 to S1104 and repetitively performs the insert and delete operations until the data becomes null. When the next data becomes null and the move operation of all the data is fully terminated, the DBMS acceptance section 600 adds contents of the additional area information 633 in the storage area 632 (S1111), deletes contents of the additional area information 633 (S1112), and erases the during-rebalance flag 634 (S1113).
  • After the rebalance operation is completed in this way, [0109] storage data 621 a is stored in the storage 620 a, storage data 622 is stored in the storage 620 b, and storage data 623 is stored in the storage 620 c, as shown in FIG. 12.
  • Explanation will next be made as to the operation of the system when a data search, update and delete request and a data insert request are issued during the rebalance operation, that is, as to the database management method according to the present invention. [0110]
  • Explanation will first be made in connection with a case where a data search, update and delete request was issued. In the [0111] DBMS acceptance section 600 in FIG. 10, in this case, the request acceptor 601, analyzer 602 and processing procedure generator 603 performs their operations and the execution destination decider 604 performs its execution destination determining operation. In the execution destination determining operation, the DBMS acceptance section 600 refers to the during-rebalance flag and judges whether or not the rebalance operation is being executed as shown in FIG. 7.
  • At this time, if the rebalance operation is being executed, then the [0112] DBMS acceptance section 600 determines the areas defined in the storage area 632 and additional area information 633 of the table definition information 631 in the storage 630 as execution destinations (step S703). In the example of FIG. 10, since the storages 620 a and 620 b are defined in the storage area 632 as storages A and B and the storage 620 c is defined in the additional area 633 as the storage C, the DBMS executors 610 a, 610 b and 610 c are determined as execution destinations.
  • For the execution destinations thus determined, the execution request/[0113] result receiver 605 in the DBMS acceptance section 600 performs its execution request/result receiving operation, which will be explained by referring to FIG. 8.
  • That is, the [0114] DBMS acceptance section 600 refers to the during-rebalance flag 634 in the table definition information 631 of the storage 630 and judges whether or not the rebalance operation is being executed (step S711). Since the rebalance operation is being executed, the DBMS acceptance section 600, on the basis of the execution destination determined at the step S703 in the execution destination determination process of FIG. 7, first issues an execution request to the DBMS executors associated with the storages defined in the storage area 632 (step S714).
  • When accepting execution results from all the DBMS executors as the execution request destinations (step S[0115] 715), the DBMS acceptance section 600 issues a execution request to the DBMS executor associated with the storage defined in the additional area 633 (step S716)and receives an execution result from the DBMS executor subjected to the execution request (step S717).
  • The [0116] DBMS acceptance section 600 returns the last received result through the operation of the step S606.
  • In the example of FIG. 10, the [0117] storages 620 a and 620 b are defined in the storage area 632 in the table definition information 631 of the storage 630 and the storage 620 c is defined in the additional area 633. Thus the DBMS acceptance section 600 first issues a search, update and delete execution request to the DBMS executors 610 a and 610 b, and after receiving all their results therefrom, the DBMS acceptance section issues the search, update and delete execution request to the DBMS executor 610 c and receives its result.
  • When an insert request is issued during the rebalance operation, the [0118] DBMS acceptance section 600 performs the operations of the request acceptor 601, analyzer 602, processing procedure generator 603 and execution destination decider 604 in FIG. 10, and the operation of the execution destination decider 604 is as shown in FIG. 9.
  • That is, in the step S[0119] 721 wherein the during-rebalance flag is referred to to judge whether or not the rebalance operation is being executed, since the rebalance operation is being executed, the DBMS acceptance section 600 finds a hash function value based on the data to be inserted, refers to the hash function value storage position correspondence table 635, and selects an insert destination from the areas defined in the storage area information 632 and additional area 633 on the basis of the hash function values (step S723).
  • In the example of FIG. 10, the [0120] DBMS acceptance section 600 refers to the value of the product code for the data to be inserted and finds hash function values. When the hash function values are 0, 9, 4 and 6, the DBMS acceptance section selects the storage 620 a. When the hash function values are 1, 8 and 5, the DBMS acceptance section selects the storage 620 b. When the hash function values are 2, 7 and 3, the acceptance section selects the storage 620 c.
  • And in the [0121] DBMS acceptance section 600, the execution request/result receiver 605 performs its operation over the selected insert destination and the section 600 returns the last-received result from the returner 606.
  • Such data being searched for, updated, deleted or inserted is locked, so that it is prohibited that another user or rebalance operation performs search, update or delete operation thereover, unless otherwise specifically stated by the user. Similarly, data to be subjected to a move operation for each data case during the rebalance operation is also locked, so that another user is prohibited from performing search, update or delete operation thereover until the move operation is completed. [0122]
  • All the storages having data stored therein have been checked in order to determine the execution destination of the search, update or delete operation in the present embodiment. When the search, update or delete operation is added with a condition, however, the check can be carried out over only limited one of the storages as the execution destination. When the storages as the execution destination are limited in the search, update or delete operation during the rebalance operation, it is only required to perform update or delete operation over the additional area, only when data to be rebalanced is stored in the storage of the execution destination. [0123]
  • Through the above operation, even when another user issues a search, update or delete processing request during rebalance operation, the system can accept the search, update or delete processing request to node table data during the rebalance operation and sequentially execute the DBMS executors. [0124]
  • Explanation will next be made as to a database system in accordance with another embodiment of the present invention. In this database system, when data stored in existing storages determined by hash division is subjected to rebalance operation due to addition of a storage, for example, the system copies the data determined to be moved from the existing storages to the additional storage, adds position information of the data on the additional storage to the data within the storages as copy sources, and, after completing the copying operation of all the data to be moved to the additional storage, deletes all the data of the copy sources. [0125]
  • And when a search request to the table data is issued during the execution of the data rebalance operation, the system performs searching operation over the data stored in the existing storages. When an update/delete request to the table data is issued during the rebalance operation, the system first processes the data stored in the existing storages as update/delete object. When position information indicative of a copy destination to the additional storage is added to the data to be updated and deleted, the system performs the same update/delete operation over the data of the copy destination. [0126]
  • Further, when an insert request to the table data is issued during the execution of the rebalance operation and the data in question is to be moved to the additional storage, the system stores the insert data in the existing storages and also even in the additional storage as a move destination, and adds storage position information to the additional storage to the data stored in the existing storages. [0127]
  • The basic arrangement of the database system performing such operation as mentioned above is the same as that of the system of FIG. 1, or may be the same as that of the system of FIG. 2. [0128]
  • By referring to FIGS. [0129] 13 to 21, explanation will be made as to the operation of a database system as a second embodiment which has such an arrangement as mentioned above, and wherein data division is based on the hash function value storage position correspondence table 317 shown in FIGS. 1 and 3 and the stock table of FIG. 6 is applied to the database system of FIG. 1.
  • FIG. 13 is a block diagram of a second detailed example of the arrangement of the database management system in FIG. 1 prior to rebalance operation, FIG. 14 is a flowchart for explaining an example of search execution destination determining operation of a DBMS acceptance section in FIG. 13, FIG. 15 is a flowchart for explaining an example of update/delete execution destination determining operation of the DBMS acceptance section in FIG. 13, FIG. 16 is a flowchart for explaining an example of update execution destination determining operation of the DBMS acceptance section in FIG. 13, FIG. 17 is a flowchart for explaining an example of delete execution destination determining operation of the DBMS acceptance section in FIG. 13, FIG. 18 is a flowchart for explaining an example of insert execution destination determining operation of the DBMS acceptance section in FIG. 13, FIG. 19 is a flowchart for explaining an example of insert execution destination determining operation of the DBMS acceptance section in FIG. 13, FIG. 20 is a diagram of the database management system of FIG. 13 for explaining the rebalance operation thereof, FIG. 21 is a flowchart for explaining an example of the rebalance operation of the database management system of FIG. 20, and FIG. 22 is a diagram for explaining a second example of accepting and executing a database processing request during the rebalance operation in the database system of FIG. 1. [0130]
  • In the database system of FIG. 13, when a search request is issued, a [0131] DBMS acceptance section 600 a performs respective operations of the request acceptor 601, analyzer 602 and processing procedure generator 603, and determines an execution destination through the operation of the execution destination decider 604. In the execution destination determining operation of this example, the areas defined in the storage area 632 are merely determined to be the execution destinations as detailed in FIG. 14 (step S1301).
  • In the example of FIG. 13, since the storages A and B are defined in the [0132] storage area 632, the DBMS executors 610 a and 610 b are determined as the execution destinations. And the DBMS acceptance section 600 a issues a search execution request from the execution request/result receiver 605 to the execution destinations thus determined, receives their results, and returns the last-received result thereto from the returner 606.
  • Even with respect to data update or delete, when its request is issued, the [0133] DBMS acceptance section 600 a performs the respective operations of the request acceptor 601, analyzer 602 and processing procedure generator 603, and determines an execution destination through the operation of the execution destination decider 604. In the execution destination determining operation, as in the search request, the areas defined in the storage area 632 are merely determined as execution destinations as shown in FIG. 15 (step S1401).
  • In the example of FIG. 13, since the storages A and B are defined in the [0134] storage area 632, the DBMS executors 610 a and 610 b are determined as the execution destinations. And the DBMS acceptance section 600 a issues an update/delete execution request from the execution request/result receiver 605 to the execution destinations thus determined, receives their results, and returns the last-received result from the returner 606.
  • The [0135] DBMS executors 610 a and 610 b search for the data to be updated/deleted (steps S1501 and SA1601) and execute the update/delete operation through the operations of updates 612 a and 612 b and deletes 613 a and 613 b (steps S1502 and S1602) as shown in FIGS. 16 and 17.
  • Further, the DBMS executor refers to the update/delete data and judges whether or not position information indicative of a copy destination is added to the data (steps S[0136] 1503 and S1603). If the position information indicative of the copy destination is added, then the DBMS executor executes the update/delete operation over data to be copied (steps S1506 and S1606).
  • Thereafter or in the steps S[0137] 1503 and S1603, when the position information is not added, the DBMS executor extracts the data to be next updated/deleted and judges whether or not the next data is present (steps S1504 and S1604). In the presence of the next data, the DBMS executor repeats the operations of the steps S1501 and S1601 and subsequent steps until the data is fully searched for. In the absence of the next data, when the searching operation of all the data is completed, the DBMS executor informs the DBMS acceptance section 600 a of the execution completion (steps S1505 and S1605).
  • When an insert request is issued, the [0138] DBMS acceptance section 600 a in FIG. 13 performs the operations of the request acceptor 601, analyzer 602 and processing procedure generator 603, and determines an insert destination through the operation of the execution destination decider 604. In this example, the insert destination determining operation is as shown in FIG. 18.
  • More specifically, the DBMS acceptance section first refers to the during-[0139] rebalance flag 634 and judges whether or not the rebalance operation is being executed (step S1701). In this case, the DBMS acceptance section determines that the rebalance operation is not being executed, finds a hash function value from the data to be inserted, refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), and selects an insert destination from the areas defined in the storage area 632 on the basis of the hash function value (step S1702).
  • In the example of FIG. 13, the DBMS acceptance section refers to the value of a product code for the insert data and finds its hash function value. When the hash function values are 0, 9, 4, 6 and 7, the DBMS acceptance section selects the [0140] storage 620 a. When the hash function values are 1, 8, 5, 2 and 3, the DBMS acceptance section selects the storage 620 b.
  • The [0141] DBMS acceptance section 600 a issues an insert execution request from the execution request/result receiver 605 to the selected insert destination and receives its result therefrom. The execution request issuance and result reception are carried out according to a procedure as shown in FIG. 19.
  • More specifically, the [0142] DBMS acceptance section 600 a in FIG. 13 refers to the during-rebalance flag 634 and judges whether or not the rebalance operation is being executed (step S1801). When the rebalance operation is not executed, the DBMS acceptance section issues an insert execution request to the DBMS executor associated with the storage selected through the deciding operation of the execution destination decider 604 (step A1802), and receives its result therefrom (step S1803). And the DBMS acceptance section returns the last-received result. The operation of the DBMS acceptance section when determining that the rebalance operation is being executed will be explained later.
  • As in the case of the example of FIG. 10, when the [0143] storage 620 c as a storage area of the stock table is added to the database system of FIG. 13 as shown in FIG. 20, a storage C is defined in the additional area 633 of the storage 630 and the operation of a rebalance executor 1901 is started by a rebalance operation request.
  • In the rebalance operation, as shown in FIG. 21, DBMS acceptance section first sets the during-[0144] rebalance flag 634 in FIG. 13 in ‘during rebalance’ during the execution of the rebalance operation (step S2001), refers to the storage area information 632 and additional area information 633, finds the number of divisions before the area addition and the number of division after the area division, refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), and finds data to be moved (step S2002).
  • In the example of FIG. 20, since a single area is added to the two division tables to form three division tables, it will be appreciated that data having hash function values of 2, 7 and 3 is to be moved from the hash function value storage position correspondence table [0145] 317 of FIG. 3.
  • Next, the DBMS acceptance section issues a data search request to the DBMS executor having the move data found at the step S[0146] 2002 (step S2003). In the example of FIG. 20, since the hash function value of 7 for the move data is stored in the storage 620 a and the hash function values of 2 and 3 are stored in the storage 620 b, the DBMS acceptance section issues the search request to the DBMS executors 610 a and 610 b.
  • The [0147] DBMS executors 610 a and 610 b when receiving the search request from the DBMS acceptance section 600 a search for one case of data and return its result to the DBMS acceptance section 600 a. The DBMS acceptance section 600 a receives one case of result in the rebalance executor 1901 (step S2004), calculates a hash function value based on the received data value, refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), finds a move destination (DBMS executor 610 c in FIG. 20)(step S2005), and issues an insert request to the move destination (step S2006).
  • The [0148] DBMS executor 610 c when receiving the insert request inserts the data in the storage 620 c through the operation of an insert 614 c, and informs the DBMS acceptance section 600 a of data insert position information and insert operation completion.
  • The [0149] DBMS acceptance section 600 a receives the data insert position information and insert operation completion at the rebalance executor 1901 (step S2007), and adds move-destination data insert position information to the move source data (step S2008).
  • In the example of FIG. 20, the [0150] DBMS executor 610 a searches for data (‘trainer’) 1911 having a product code value of 677, returns it to the DBMS acceptance section 600 a. Since the data move destination is the storage 620 c, the DBMS acceptance section 600 a issues an insert request to the DBMS executor 610 c and data 1921 is stored in the storage 620 c. And after completion of the insert operation, the move-destination position information 1921 is added to the data 1911 of the move source of the DBMS executor 610 a.
  • After the operation of the step S[0151] 2008, the rebalance executor 1901 of the DBMS acceptance section 600 a in FIG. 13 reads next search data and judges whether or not the next data is present (step S2009). In the presence of the next data, the rebalance executor repeats the data acceptance, move-destination specifying, data inserting and move-destination position information adding operations of the steps S2004 to S2008 until the operation of the data is fully completed.
  • When the next data becomes null move operation of all the data is completed in a step S[0152] 2009, the DBMS acceptance section issues a delete request of the data added with the move-destination position information to the DBMS executor having so far stored therein the move data (step S2010).
  • The DBMS executor when receiving the delete request searches for and deletes the target data. After completion of the delete operation, the DBMS executor informs the [0153] DBMS acceptance section 600 a of the delete completion. Thus the DBMS acceptance section 600 a receives the delete completion of the data (step S2011), adds the additional area information 633 to the storage area information 632 (step S2012), deletes the additional area information 633 (step S2013), and erases the during-rebalance flag (step S2014).
  • When the rebalance operation is completed in this way, data [0154] 621 (stock table) so far stored in the storage 620 a and data 622 (stock table) so far stored in the storage 620 b in FIG. 20 are rebalanced as in the case of FIG. 12 so that the storage data 621 a is placed in the storage 620 a, the storage data 622 a is placed in the storage 620 b, and the storage data 623 is placed in the storage 620 c.
  • Explanation will then be made in connection with a case where a search or update, delete and insert processing request is issued during such rebalance operation. [0155]
  • When a search processing request is issued during the rebalance operation, first of all, the [0156] DBMS acceptance section 600 a in FIGS. 13 and 20 accepts a request at the request acceptor 601, analyzes the request at the analyzer 602, generates a processing procedure at the processing procedure generator 603 and determines an execution destination at the execution destination decider 604.
  • In the execution-destination determining operation, the areas defined in the [0157] storage area 632 of the table definition information 631 of the storage 630 in FIG. 20 are determined as the execution destinations as shown in FIG. 14 (step S1301).
  • In the example of FIG. 20, since the storages A and B are defined in the [0158] storage area 632, the DBMS acceptance section issues a search execution request to the DBMS executors 610 a and 610 b.
  • That is, the execution request/[0159] result receiver 605 issues the search execution request to the execution destinations determined by the execution destination decider 604, and receives their results. And the returner 606 returns the last received result received by the execution request/result receiver 605.
  • Next, when an update or delete processing request is issued during the rebalance operation, the [0160] DBMS acceptance section 600 a accepts the request at the request acceptor 601, analyzes the request at the analyzer 602, generates a processing procedure at the processing procedure generator 603, and determines an execution destination at the execution destination decider 604.
  • In the execution destination determining operation, as shown in FIG. 15, the areas defined in the [0161] storage area 632 in the table definition information 631 of the storage 630 in FIG. 20 are defined as the execution destinations (step S1401).
  • In the example of FIG. 20, since the storages A and B are defined in the [0162] storage area 632, the DBMS acceptance section issued an update or delete execution request to the DBMS executors 610 a and 610 b.
  • The [0163] DBMS executors 610 a and 610 b search for (steps S1501 and S1601), updates or deletes (steps S1502 and S1602) data specified by the deletes 613 a and 613 b, as shown in FIGS. 16 and 17.
  • Further, DBMS acceptance section refers to the update or delete data, judges whether or not position information indicative of a copy destination is added to the update or delete data (steps S[0164] 1503 and S1603). When the position information is added, the DBMS acceptance section updates or deletes data at the copy destination (steps S1506 and S1606).
  • Thereafter or in the steps S[0165] 1503 and S1603, if the position information is not added, the DBMS acceptance section reads next data specified to be updated or deleted and judges whether or not the next data is present (steps S1504 and S1604).
  • In the presence of the next data, the DBMS acceptance section repeats the operations of the steps S[0166] 1501 and S1601 and subsequent steps until all the data is searched for. In the absence of the next data, when the searching operation of all the data is completed, the DBMS executors 610 a to 610 b inform the DBMS acceptance section 600 a of the execution completion (steps S1505 and S1605).
  • When the [0167] DBMS acceptance section 600 a receives the execution completion notification from the DBMS executors 610 a and 610 b in this way, the DBMS acceptance section returns the last received result. That is, the execution request/result receiver 605 receives the results and the returner 606 returns the result last received at the execution request/result receiver 605.
  • When an insert request is issued, the [0168] DBMS acceptance section 600 a in FIGS. 13 and 20 performs the respective operations of the request acceptor 601, analyzer 602 and processing procedure generator 603, and determines an insert destination at the execution destination decider 604. In this example, the insert destination determining operation is as shown in FIG. 18.
  • More specifically, the DBMS acceptance section first refers to the during-[0169] rebalance flag 634 and determines whether or not the rebalance operation is being executed (step S1701). Because the rebalance operation is being executed, the DBMS acceptance section finds a hash function value based on the data to be inserted (step S1701), refers to the hash function value storage position correspondence table 635 (hash function value storage position correspondence table 317 in FIGS. 1 and 3), determines an insert destination (1) (to be arbitrarily inserted) from the storage area 632 on the basis of the hash function value (step S1703), and determines an insert destination (2) (to be arbitrarily inserted) from the areas defined in the storage area 632 and the area defined in the additional area 633 (step S1704).
  • In the example of FIG. 20, when the hash function values are 0, 9, 4, 6 and 7, the [0170] storage 620 a is selected as the insert destination (1); while, when the hash function values are 1, 8, 5, 2 and 3, the storage 620 b is selected.
  • When the hash function values are 0, 9, 4 and 6, the [0171] storage 620 a is selected. When the hash function values are 1, 8 and 5, the storage 620 b is selected. When the hash function values are 2, 7 and 3, the storage 620 c is selected.
  • The [0172] DBMS acceptance section 600 a issues an insert execution request from the execution request/result receiver 605 to the insert destination thus selected, and receives their results. The issuance of the execution request and acceptance of the results are as shown in FIG. 19.
  • More specifically, the execution request/[0173] result receiver 605 in FIG. 20 first refers to the during-rebalance flag 634 in the table definition information 631 of the storage 630 and judges whether or not the rebalance operation is being executed (step S1801).
  • Since the rebalance executor is now being executed, the DBMS acceptance section examines whether the storage as the insert destination (1) coincides with the storage as the insert destination (2) (step S[0174] 1804). When finding a coincidence therebetween, the DBMS acceptance section issues an insert execution request to the determined insert destination (step S1805), and receives its result (step S1806).
  • When insert destination (1) is different from the insert destination (2) in the examination result of the step S[0175] 1804, the DBMS acceptance section issues an insert execution request first to the insert destination (2) (step S1807) and, after completion of the insert operation at the associated DBMS executor, receives insert destination data storage position information therefrom (step S1808).
  • Next, the DBMS acceptance section adds the data storage position information received at the time of completion of insert operation to the insert destination (2) to the insert data, issues an insert execution request to the insert destination (1) (step S[0176] 1809), and, after the associated DBMS executor completes the insert operation, receives its result (step S1810).
  • In the example of FIG. 20, when the hash function values are 0, 9, 4 and 6, the insert destination (1) is the same as the insert destination (2), that is, the [0177] same storage 620 a. When the hash function values are 1, 8 and 5, the inserts (1) and (2) are the same as the insert storage 620 b. Thus the DBMS acceptance section issues an insert request to the respective DBMS executors 610 a and 610 b and receives their insert results.
  • When the hash function value is 7, the insert destination (1) is the [0178] storage 620 a and the insert destination (2) is the storage 620 c. Thus the DBMS acceptance section issues an insert request first to the DBMS executor 610 c corresponding to the storage 620 c, receives insert position information data, and issues an insert request of data added with the insert position data received by the DBMS executor 610 c to the DBMS executor 610 a corresponding to the storage 620 a.
  • Similarly, the hash function values are 2 and 3, the insert destination (1) is the [0179] storage 620 b and the insert destination (2) is the storage 620 c. Thus the DBMS acceptance section first issues an insert request to the DBMS executor 610 c associated with the storage 620 c, receives insert position information data, and the issues an insert request of data added with the insert position data received at the DBMS executor 610 c to the DBMS executor 610 b associated with the storage 620 b.
  • During such search, update, delete or insert operation, since data being processed is locked, another user or rebalance operation is prohibited from performing the search, update, delete or insert operation unless otherwise specifically stated by the user. Similarly, since even data to be moved for each data case during the rebalance operation is also locked, another user is prohibited from performing the search, update, delete or insert operation until the move operation is completed. [0180]
  • The execution destination of the search, update, delete or insert operation has been determined for all the storages having the date stored therein in this example. However, in the case of the search, update, delete or insert operation having a condition added thereto, the limited execution destination can be executed. [0181]
  • The rebalance operation and the search, update, delete or insert operation during the rebalance operation in the aforementioned second embodiment will be summarized as follows with reference to FIG. 22. [0182]
  • First in FIG. 22A, it is assumed that hash function values of 0, 4, 6, 7 and 9 are stored in a [0183] storage 2120 and hash function values of 1, 2, 3, 5 and 8 are stored in a storage 2130 respectively as divided.
  • When there are database tables thus divided, a [0184] search operation 2100 is executed by the storages 2120 and 2130, an update/delete operation 2100 is executed by the storages 2120 and 2130, and such insert operation of data 2131 as to provide a hash function values of 3 is executed by the storage 2130.
  • When a [0185] storage 2140 is added as shown in FIG. 22B (a combination of the storage 2120 and 2130 being called an existing are and the storage 2140 being called an additional area), a rebalance operation 2103 selects data 2121 to be moved to the storage 2140 from the data stored in the storages 2120 and 2130, copies the selected data 2121 to the storage 2140, and adds storage position information 2122 of data 2142 copied to the copy source data 2121.
  • The copy of the [0186] data 2121 is carried out by the search operation of the move data of the storages 2120 and 2130 and by the insert operation to the data 2142. During a time from the copy of the move target data 2121 to the add of the storage position information to the data 2121, the data 2121 is locked so that another user is prohibited from performing the search, update, or delete operation.
  • The [0187] search operation 2100 during such rebalance operation is executed in the existing areas. That is, the search operation is executed in the storages 2120 and 2130. Further update/delete operation 2101 during the rebalance operation is also executed in the existing area. When the copy destination position information is added to the data to be updated/deleted, however, the update/delete operation is executed even over data indicated by the copy destination position information.
  • That is, when the update/delete operation is executed in the [0188] storage 2120 and 2130 to update/delete the data 2121 and 2131 added with the copy destination position information 2122 and 2132, the update/delete operation is executed even over the data 2141 and 2142 of the storage 2140 indicated by the copy destination position information 2122 and 2132.
  • In this connection, the data being searched/updated/deleted is locked so that the rebalance operation is prohibited from referring to the data unless otherwise specifically stated by another user. [0189]
  • Next, in the [0190] insert operation 2102 of such data 2131 as to provide a hash function value of 3 during the rebalance operation, the data 2141 is stored in the storage 2140 and the data 2131 added with the data position information 2132 is stored in the storage 2130.
  • When another user tries to perform search/update/delete operation over the data being moved during the rebalance operation, he has to wait until the move operation of the data is completed because the data is locked to prohibit access thereto. However once the lock is release due to the move completion of the data, his operation so far awaited can be resumed. [0191]
  • Further, even when the rebalance operation tries to move the data being searched/updated/deleted, the lock of the data causes prohibition of access to the data. Thus the move operation has to be awaited until the user release the lock. Once the lock is released, the rebalance operation so far awaited can be resumed. Thus it can be prevented that the value of the data be unduly updated or the data be deleted. [0192]
  • Further, since the data moved through the rebalance operation remains in the existing areas even during the rebalance operation, only execution in the existing areas enables search operation of all the data. [0193]
  • In this manner, in the database system of the second embodiment, the data moved by the rebalance operation is added. Therefore, when the update/delete operation is executed over the data indicated by the position information at the time of updating/deleting the data added with the position information, the update/delete operation can be realized even over the data moved by the rebalance operation. [0194]
  • Further, when data to be rebalanced is stored in the same format as data being rebalanced, generation of excessive rebalance operation can be prevented. [0195]
  • As a result, the system can accept search, update, delete and insert processing requests to the table being rebalanced during the rebalance operation and can execute them concurrently. [0196]
  • In the database management system of the arrangement allowing realization of both of the aforementioned first and second embodiments, when the function operation of either one of the first and second embodiments is selected on the basis of the presence or absence of a column type or index included in the table, the rebalance operation and the search, update, delete and insert operations optimum for the attribute of the table can be executed. [0197]
  • Similarly, it is also possible to reduce the number of storages for data storage. [0198]
  • In the database management system of FIG. 23, such storage areas of a stock table as shown in FIG. 24 and the [0199] storage 620 c is disconnected. Thus when the storage C is defined in a disconnection area information 636 of the storage 630 and a rebalance processing request is generated, the operation of a rebalance operation executor 1101 is started.
  • The details of the rebalance operation of the [0200] rebalance operation executor 1101 are nearly the same as when the aforementioned explanation based on FIG. 11, but data to be moved corresponds to all the data stored in the disconnection area. Further, the number of area divisions is reduced from three to two so that, on the basis of the hash function value storage position correspondence table 635, data indicative of hash function values of 2, 7 and 3 stored in the storage 620 c and having a hash function value of 7 is moved to the storage 620 a, and data indicative of hash function values of 2 and 3 is moved to the storage 620 b.
  • When the rebalance operation is completed, the data are stored in the [0201] storages 620 a and 620 b as shown in FIG. 25.
  • The operation when data search, update or delete request is issued during the rebalance operation is nearly the same as the aforementioned description. The operation when an insert request is issued during the rebalance operation is nearly the same as the aforementioned description, except for the operation of the insert destination decider. [0202]
  • The operation of the insert destination decider find a hash function based on data to be inserted, refers to the hash function value storage position correspondence table [0203] 635, and selects an insert destination from one of the areas defined in the storage area information 632 by the hash function other than the area defined in the disconnection area information 636.
  • As has been explained in connection with FIGS. [0204] 1 to 25, the database system and database management method in this example performs its data management operation according to a procedure which follows.
  • (a) In the database system for allocating the data of the table having a plurality of data items to a plurality of storages and storing the table data in storages determined by a specified division rule (method) such as, e.g., hash function, when a storage is required to be added for storage of the table data, the system determines data to be moved to the additional storage according to the hash function with use of information on the existing and additional storages, performs the data rebalance operation to move all the determined data to the additional storage. Further, when a search, update or delete request to the table data is issued during the data rebalance operation, the system executes the search, update or delete operation over the existing and additional storages for storage of the data in question. When an insert request to the table data is issued, the system determines one of the existing and additional storages for the data to be inserted according to the division rule using the hash function and inserts the data in question in the determined storage. [0205]
  • (b) In the parallel database system for performing parallel operation over the respective storages when a search, update or delete request to the table data is issued, in particular, when a storage is required to be added for storage of the table data, the system determines data to be moved from the existing storages to the additional storage according to the division rule using the hash function or the like with use of information on the existing and additional storage, and performs rebalance operation over all the determined data to be moved to the additional storage. When search, update and delete requests to the table data are issued during the data rebalance operation, the system performs parallel operation of search, update and delete in the existing and additional storages. When the operation of the existing storage is fully completed, the system performs parallel operations of search, update and delete over the additional storage. Further, when an insert request to the table data is issued, the system inserts the data in the storage determined according to the data division rule using the hash function including information about the existing and additional storages. [0206]
  • (c) When a storage is required to be added for storage of the table data, the system first copies data to be determined as moved according to the division rule using the hash function or the like from the existing storage to the additional storage, and adds position information of the copied data on the additional storage to the data of the storage as the copy source. And when completing the copying operation of all the data to be moved in this way, the system executes the data rebalance operation to delete all the data of the copy source. Further, when a search request to the table data is issued during the execution of the data rebalance operation, the system performs search operation over the data stored in the existing storages. When an update or delete request is issued, the system performs update or delete operation over the data stored in the existing storages. When the data as the update or delete object is added with position information indicative of a copy destination to the additional storage, the system performs the same update or delete operation over the data of the copy destination. Further, when an insert request to the table data is issued, the system stores the data in the storage determined according to the division rule specified only for the existing storages. Further, in a division method which is applied to the storages including the additional storage, when the data is to be moved to the additional storage, the system stores the data even in the additional storage and adds storage position information thereof to the additional storage to the data stored in the existing storages. [0207]
  • Any one of the above techniques (a) to (c) is selected and executed depending on a table to be processed. [0208]
  • In this way, the database system and database management method in this example, at the time of performing rebalance operation over the data stored in the existing storages due to addition of a storage to be rebalanced in table data of a relational database management system of storing as divided into a plurality of storages, can execute database services such as search, update, delete and insert concurrently. [0209]
  • The present invention is not limited to the embodiments explained with reference to FIGS. [0210] 1 to 25 but may be modified in various ways so long as it does not depart from its gist or subject matter. For example, although the database system and database management system have used three storages in the present embodiment, the number of such storages may be two or four or more. Even with regard to the data division rule (method) to the respective storages, the present invention is not limited only to the use of the hash function as in the present embodiment, but a key range division method or a round robin division method may be employed.
  • In the present embodiment, the [0211] DBMS 300 has been configured with computers as shown in FIG. 2 as its hardware configuration. However, like the user terminals 330 a to 330 c, the DBMS may be configured with computers provided with input devices such as keyboards and display devices such as CRT (cathode ray tube). Though explanation has been made in connection with the case where an optical disk is used as the recording medium in the present embodiment, a flexible disk (FD) may be used as the recording medium. Even with respect to program installation, the program can be downloaded from a communication device via a network and then installed.

Claims (24)

What is claimed is:
1. A database management system connected to a plurality of storages for storing a plurality of data items, comprising:
a storage having a first storage area corresponding to a plurality of storages for storing a plurality of data items and having a second storage area corresponding to a storage to be added to or disconnected from said plurality of storages;
an acceptance section connected to the storage for accepting a data processing request, said data processing request including data processing in said plurality of storages and data rebalance between said plurality of storages; and
a plurality of executors connected to said acceptance section for sequentially executing at least any of the data processing in the plurality of storages and the data rebalance.
2. A database management system as set forth in claim 1, wherein said storage has a storage area correspondence table showing combinations of predetermined data items to be sharedly shared by said plurality of storages according to said request of addition or disconnection to cause the data rebalance between the storages.
3. A database management system as set forth in claim 1, wherein said acceptance section has a rebalance flag indicating that said plurality of storages are being rebalanced due to addition or disconnection to said plurality of storages, and said acceptance section, in response to a data processing request to said data items stored in said plurality of storages, refers to said rebalance flag and reflects data update even on the storages subjected to the data rebalance.
4. A database management system as set forth in claim 3, further comprising mean, in response to a rebalance request of data to be rebalanced in a storage added according to said addition request, for adding data position information to data before subjected to the rebalance execution by said data rebalance request in said plurality of storages, and means for deleting the data added with the data position information and before subjected to execution of the rebalance execution after the execution of the rebalance execution by the rebalance request.
5. A database management system as set forth in claim 1, further comprising means, in response to a rebalance request of data to be rebalanced in a storage added according to said addition request, for adding data position information to data before subjected to the rebalance execution by said data rebalance request in said plurality of storages, and means, in response to said data processing request of update or delete to data in said plurality of storages, for deleting data corresponding to the data to be updated or deleted but added with said data position information after the rebalance execution.
6. A database management program installed in a database management system connected a plurality of storages for storing a plurality of data items via an interface, said program being capable of being read by a computer, said program comprising the steps of:
setting first information indicative of a plurality of storages for storing the plurality of data items in a first storage area;
setting second information indicative of a storage to be subjected to a request of add or disconnect to said plurality of storages in a second storage area;
accepting a database processing request at an acceptance section connected to said storages, sad database processing request including processing of data in the plurality of storages and data rebalance between said plurality of storages; and
sequentially executing at least any of the data processing in the plurality of storages and the data rebalance in a plurality of executors.
7. A database management program as set forth in claim 6, further comprising a step of storing in said storages a storage area correspondence table showing combinations of predetermined data items to be sharedly stored by said plurality of storages in response to said request of addition or disconnection to cause data rebalance between the storages.
8. A database management program as set forth in claim 6, further comprising a step of setting rebalance information indicating that said plurality of storages being rebalanced due to addition or disconnection to the plurality of storages in a rebalance flag, and a step of, in response to a data processing request to said data items stored in said plurality of storages, referring to said rebalance flag and reflecting data update even on the storages subjected to the data rebalance.
9. A database management program as set forth in claim 8, further comprising a step of, in response to a rebalance request of data to be rebalanced in a storage added according to said addition request, adding data position information to data before subjected to the rebalance execution by said data rebalance request in said plurality of storages, and a step of deleting the data added with the data position information and before subjected to execution of the rebalance execution after the execution of the rebalance execution by the rebalance request.
10. A database management program as set forth in claim 6, further comprising a step of, in response to a rebalance request of data to be rebalanced in a storage added according to said addition request, adding data position information to data before subjected to the rebalance execution by said data rebalance request in said plurality of storages, and a step of, in response to said data processing request of update or delete to data in said plurality of storages, deleting data corresponding to the data to be updated or deleted but added with said data position information after the rebalance execution.
11. A database system connected to a plurality of storages for storing a table of data having a plurality of data items, said table data being determined according to a predetermined division rule and stored in the storages, said system comprising:
rebalance operation means for determining data to be moved between the storages due to any one of addition and disconnection of a storage to be connected according to said division rule and moving the determined data;
means for accepting a search request, update request, delete request or insert request to said table data during execution of the rebalance operation of the rebalance operation means;
means, in response to the accepted search, update or delete request, for performing search, update or delete operation over said storages; and
means, in response to the accepted insert request, for determining a storage destination of data to be inserted from said storage according to said division rule and inserting the data to be inserted in the determined storage.
12. A database system as set forth in claim 11, further comprising means, in response to said accepted search, update and delete requests, for parallelly executing search, update and delete operations over existing storages, and after completion of the parallel execution of the existing storages, for parallelly executing search, update and delete operations over an additional storage.
13. A database system as set forth in claim 12, further comprising means, in response to the accepted insert request, for determining a storage destination of data to be inserted from said additional storage according to said division rule and for inserting the insert object data in the determined storage.
14. A database system connected to a plurality of storages for storing a table of data having a plurality of data items, said table data being determined according to a predetermined division rule and stored in the storages, said system comprising:
rebalance operation means for determining data to be moved from existing storages to an additional storage according to said division rule, copying the determined data from said existing storages to said additional storage, previously adding copy position information in the additional storage to copy source data in the existing storages, and after completing the copy operation of all the data determined to be moved to said additional storage, deleting all the copy source data in said existing storages;
means for accepting search, update, delete and insert requests for said table data during execution of rebalance operation of said rebalance operation means;
means, in response to the accepted search request, for performing search operation over data stored in said existing storages;
means, in response to the accepted update and delete requests, for performing update and delete operations over the data stored in said existing storages, and, when said copy position information is added to data to be updated and deleted, for performing update and delete operations even over data as a copy destination in said additional storage; and
means, in response to the accepted insert request, for storing data to be inserted in one of said existing storages determined according to said division rule before addition thereof in said additional storage, and when said additional storage is a storage destination of said insert object data according to said division rule after addition of said additional storage, for storing said insert object data in said additional storage, and adding storage position information of said insert object data in said additional storage to the insert object data in said existing storages.
15. A database management method for a database system connected to a plurality of storages for storing a table of data having a plurality of data items, said table data being determined according to a predetermined division rule and stored in the storages, said method comprising the steps of:
determining data to be moved between the storages according to said division rule due to any one of addition and disconnection of a storage to be connected and moving the determined data for rebalance operation;
accepting search, update, delete and insert requests to said table data during execution of said rebalance operation in said rebalance operation step;
in response to the accepted search, update and delete requests, executing search, update and delete operations for said storages; and
in response to the accepted insert request, determining a storage destination of data to be inserted from said storages according to said division rule.
16. A database management method as set forth in claim 15, further comprising a step of, in response to said accepted search, update and delete requests, parallelly executing search, update and delete operations over the existing storages and, after completing the parallel operation, parallelly executing the search, update and delete operations over said additional storage.
17. A database management method as set forth in claim 16, further comprising a step of, in response to the accepted insert request, determining a storage destination of the data to be inserted from said existing and additional storages according to said division rule and inserting said insert object data in the determined storage.
18. A database management method for a database system connected to a plurality of storages for storing a table of data having a plurality of data items, said table data being determined according to a predetermined division rule and stored in the storages, said method comprising the steps of:
determining data to be moved from existing storages to an additional storage according to said division rule due to addition of a storage for storing said table data and copying the determined data from said existing storages to said additional storage;
previously adding copy position information in said additional storage to data as a copy source in said existing storages and, after completing the copy operation of all the data determined to be moved to said additional storage, deleting all the data as the copy source in said existing storages for rebalance operation;
accepting search, update, delete and insert requests to said table data during execution of said rebalance operation step;
in response to the accepted search request, performing search operation over the data stored in said existing storages;
in response to the accepted update and delete requests, performing update and delete operations over the data stored in said existing storages and, when said copy position information is added to data to be updated and deleted, performing update and delete operations even over a copy destination data in said additional storage; and
in response to the accepted insert request, storing the insert object data in one of the existing storages determined according to said division rule before adding said insert object data in said additional storage and, when said additional storage is a storage destination of said insert object data according to said division rule after adding said additional storage, storing said insert object data even in said additional storage and adding storage position information of said insert object data in said additional storage in the insert object data in said existing storages.
19. A database management method as set forth in claim 18, further comprising a step of selecting and executing operations of said steps in said database management method set forth in claim 18 according to definition of said table.
20. A program read into a computer for executing steps for database management, comprising the steps of:
determining data to be moved between storages according to said division rule due to any one of addition and disconnection of a storage connected and to be connected and moving the determined data for rebalance operation;
accepting search, update, delete and insert requests over said table data during execution of said rebalance operation of said rebalance operation step;
in response to the accepted search, update and delete requests, performing search, update and delete operations over said storages; and
in response to the accepted insert request, determining a storage destination of the insert object data from said storages according to said division rule and inserting said insert object data in the determined storage.
21. A program as set forth in claim 20, further comprising steps, in response to said accepted search, update and delete requests, for parallelly executing search, update and delete operations over existing storages, and after completion of the parallel execution of the existing storages, for parallelly executing search, update and delete operations over an additional storage.
22. A program as set forth in claim 21, further comprising means, in response to the accepted insert request, for determining a storage destination of data to be inserted from said additional storage according to said division rule and for inserting the insert object data in the determined storage.
23. A program read into a computer for executing steps for database management, comprising the steps of:
determining data to be moved from existing storages to an additional storage according to said division rule, copying the determined data from said existing storages to said additional storage, previously adding copy position information in the additional storage to copy source data in the existing storages, and after completing the copy operation of all the data determined to be moved to said additional storage, deleting all the copy source data in said existing storages;
accepting search, update, delete and insert requests for said table data during execution of rebalance operation of said rebalance operation means;
in response to the accepted search request, performing search operation over data stored in said existing storages;
in response to the accepted update and delete requests, performing update and delete operations over the data stored in said existing storages, and, when said copy position information is added to data to be updated and deleted, performing update and delete operations even over data as a copy destination in said additional storage; and
in response to the accepted insert request, storing data to be inserted in one of said existing storages determined according to said division rule before addition thereof in said additional storage, and when said additional storage is a storage destination of said insert object data according to said division rule after addition of said additional storage, for storing said insert object data in said additional storage, and adding storage position information of said insert object data in said additional storage to the insert object data in said existing storages.
24. A program read into a computer and run over a database under control of a computer to execute steps for database management, comprising the steps of:
at the time of starting the program, confirming presence or absence of an area for storing information for identification of an additional storage for storing table data and information indicative of ‘in rebalance operation’ during which data is moved to said additional storage, and, in the absence of the area, securing said area.
US09/987,839 2001-06-27 2001-11-16 Database management system with rebalance architectures Abandoned US20030004975A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/357,158 US7577694B2 (en) 2001-06-27 2006-02-21 Database management system with rebalance architectures

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2001194075A JP4183400B2 (en) 2001-06-27 2001-06-27 Database system, database management method and program
JP2001-194075 2001-06-27

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/357,158 Division US7577694B2 (en) 2001-06-27 2006-02-21 Database management system with rebalance architectures

Publications (1)

Publication Number Publication Date
US20030004975A1 true US20030004975A1 (en) 2003-01-02

Family

ID=19032259

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/987,839 Abandoned US20030004975A1 (en) 2001-06-27 2001-11-16 Database management system with rebalance architectures
US11/357,158 Expired - Fee Related US7577694B2 (en) 2001-06-27 2006-02-21 Database management system with rebalance architectures

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/357,158 Expired - Fee Related US7577694B2 (en) 2001-06-27 2006-02-21 Database management system with rebalance architectures

Country Status (2)

Country Link
US (2) US20030004975A1 (en)
JP (1) JP4183400B2 (en)

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153457A1 (en) * 2002-09-09 2004-08-05 Martin Fischer Methods and systems for controlling access to a data object
US20040162953A1 (en) * 2003-02-19 2004-08-19 Kabushiki Kaisha Toshiba Storage apparatus and area allocation method
US20040167943A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US20050071383A1 (en) * 2003-09-29 2005-03-31 Axel Herbst Efficient deletion of archived data
US20060129768A1 (en) * 2002-09-09 2006-06-15 Thorsten Pferdekaemper Methods and systems for archiving data
US20060149736A1 (en) * 2002-09-09 2006-07-06 Thorsten Pferdekaemper Electronic data structure for controlling access to data objects using locks
US20060149696A1 (en) * 2002-09-09 2006-07-06 Thorsten Pferdekaemper Method and systems for controlling access to a data object by means of locks
US20060155704A1 (en) * 2002-09-09 2006-07-13 Martin Fischer Methods and systems for moving data using locks
US20060242203A1 (en) * 2002-09-09 2006-10-26 Pferdekaeemper Thorsten Methods and systems for data moving using locks
US7174347B1 (en) * 2002-02-14 2007-02-06 Ncr Corp. Loading data using links in a database
US20080046487A1 (en) * 2004-05-27 2008-02-21 Yasuhiro Kamada Data processing system and method with data sharing for the same
US20080154961A1 (en) * 2006-12-21 2008-06-26 Dougall Scott C J Local digital asset storage management technique
GB2484396A (en) * 2010-10-04 2012-04-11 Dell Products Lp Rebalancing of data in storage cluster when adding a new node
US20160055229A1 (en) * 2005-12-29 2016-02-25 Amazon Technologies, Inc. Method and apparatus for stress management in a searchable data service
US9400799B2 (en) 2010-10-04 2016-07-26 Dell Products L.P. Data block migration
US9489429B2 (en) 2011-11-16 2016-11-08 Hitachi, Ltd. Computer system, data management method, and program
JP2017062541A (en) * 2015-09-24 2017-03-30 日本電気株式会社 Data management device, data management method, and program
WO2017050179A1 (en) * 2015-09-25 2017-03-30 阿里巴巴集团控股有限公司 Method and device for updating inventory system data
US20170177222A1 (en) * 2014-03-08 2017-06-22 Diamanti, Inc. Methods and systems for data storage using solid state drives
US10628353B2 (en) 2014-03-08 2020-04-21 Diamanti, Inc. Enabling use of non-volatile media-express (NVMe) over a network
CN113111014A (en) * 2021-04-07 2021-07-13 山东英信计算机技术有限公司 Method, device and equipment for cleaning non-hot data in cache and storage medium
TWI734730B (en) * 2017-01-19 2021-08-01 香港商阿里巴巴集團服務有限公司 Method and device for updating inventory system data
US11269670B2 (en) 2014-03-08 2022-03-08 Diamanti, Inc. Methods and systems for converged networking and storage
US11921658B2 (en) 2014-03-08 2024-03-05 Diamanti, Inc. Enabling use of non-volatile media-express (NVMe) over a network

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7035880B1 (en) 1999-07-14 2006-04-25 Commvault Systems, Inc. Modular backup and retrieval system used in conjunction with a storage area network
US6658436B2 (en) 2000-01-31 2003-12-02 Commvault Systems, Inc. Logical view and access to data managed by a modular data and storage management system
US7434219B2 (en) 2000-01-31 2008-10-07 Commvault Systems, Inc. Storage of application specific profiles correlating to document versions
US7003641B2 (en) 2000-01-31 2006-02-21 Commvault Systems, Inc. Logical view with granular access to exchange data managed by a modular data and storage management system
EP1442387A4 (en) 2001-09-28 2008-01-23 Commvault Systems Inc System and method for archiving objects in an information store
US7454569B2 (en) 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
WO2005050381A2 (en) 2003-11-13 2005-06-02 Commvault Systems, Inc. Systems and methods for performing storage operations using network attached storage
JP4854973B2 (en) 2005-03-09 2012-01-18 富士通株式会社 Storage control program, storage control method, storage control device, and storage control system
JP4581962B2 (en) 2005-10-27 2010-11-17 株式会社日立製作所 Information retrieval system, index management method and program
US7734669B2 (en) 2006-12-22 2010-06-08 Commvault Systems, Inc. Managing copies of data
JP5084310B2 (en) 2007-03-16 2012-11-28 日本電気株式会社 Database server capable of rearranging data distributed to multiple processors, rearrangement method, and program
US20080294492A1 (en) * 2007-05-24 2008-11-27 Irina Simpson Proactively determining potential evidence issues for custodial systems in active litigation
US8396838B2 (en) 2007-10-17 2013-03-12 Commvault Systems, Inc. Legal compliance, electronic discovery and electronic document handling of online and offline copies of data
US8572043B2 (en) 2007-12-20 2013-10-29 International Business Machines Corporation Method and system for storage of unstructured data for electronic discovery in external data stores
US8112406B2 (en) * 2007-12-21 2012-02-07 International Business Machines Corporation Method and apparatus for electronic data discovery
US8140494B2 (en) 2008-01-21 2012-03-20 International Business Machines Corporation Providing collection transparency information to an end user to achieve a guaranteed quality document search and production in electronic data discovery
JP5203733B2 (en) * 2008-02-01 2013-06-05 株式会社東芝 Coordinator server, data allocation method and program
US8275720B2 (en) 2008-06-12 2012-09-25 International Business Machines Corporation External scoping sources to determine affected people, systems, and classes of information in legal matters
US8769048B2 (en) 2008-06-18 2014-07-01 Commvault Systems, Inc. Data protection scheduling, such as providing a flexible backup window in a data protection system
US8352954B2 (en) 2008-06-19 2013-01-08 Commvault Systems, Inc. Data storage resource allocation by employing dynamic methods and blacklisting resource request pools
US9128883B2 (en) 2008-06-19 2015-09-08 Commvault Systems, Inc Data storage resource allocation by performing abbreviated resource checks based on relative chances of failure of the data storage resources to determine whether data storage requests would fail
US9830563B2 (en) 2008-06-27 2017-11-28 International Business Machines Corporation System and method for managing legal obligations for data
US8489439B2 (en) 2008-06-30 2013-07-16 International Business Machines Corporation Forecasting discovery costs based on complex and incomplete facts
US8073729B2 (en) 2008-09-30 2011-12-06 International Business Machines Corporation Forecasting discovery costs based on interpolation of historic event patterns
US8484069B2 (en) 2008-06-30 2013-07-09 International Business Machines Corporation Forecasting discovery costs based on complex and incomplete facts
US8515924B2 (en) 2008-06-30 2013-08-20 International Business Machines Corporation Method and apparatus for handling edge-cases of event-driven disposition
US8327384B2 (en) 2008-06-30 2012-12-04 International Business Machines Corporation Event driven disposition
US8725688B2 (en) 2008-09-05 2014-05-13 Commvault Systems, Inc. Image level copy or restore, such as image level restore without knowledge of data object metadata
US20100070474A1 (en) 2008-09-12 2010-03-18 Lad Kamleshkumar K Transferring or migrating portions of data objects, such as block-level data migration or chunk-based data migration
US8204869B2 (en) * 2008-09-30 2012-06-19 International Business Machines Corporation Method and apparatus to define and justify policy requirements using a legal reference library
US20110040600A1 (en) * 2009-08-17 2011-02-17 Deidre Paknad E-discovery decision support
US20120239688A1 (en) * 2009-12-04 2012-09-20 Takatoshi Yanase Table lookup apparatus, table lookup method, and table lookup system
US8250041B2 (en) 2009-12-22 2012-08-21 International Business Machines Corporation Method and apparatus for propagation of file plans from enterprise retention management applications to records management systems
US8655856B2 (en) 2009-12-22 2014-02-18 International Business Machines Corporation Method and apparatus for policy distribution
US8935248B2 (en) * 2010-05-17 2015-01-13 United States Postal Service Localized data affinity system and hybrid method
US8832148B2 (en) 2010-06-29 2014-09-09 International Business Machines Corporation Enterprise evidence repository
US8566903B2 (en) 2010-06-29 2013-10-22 International Business Machines Corporation Enterprise evidence repository providing access control to collected artifacts
US8402359B1 (en) 2010-06-30 2013-03-19 International Business Machines Corporation Method and apparatus for managing recent activity navigation in web applications
US9021198B1 (en) 2011-01-20 2015-04-28 Commvault Systems, Inc. System and method for sharing SAN storage
US8849762B2 (en) 2011-03-31 2014-09-30 Commvault Systems, Inc. Restoring computing environments, such as autorecovery of file systems at certain points in time
CN102819535A (en) * 2011-06-10 2012-12-12 戴尔产品有限公司 Data block migration
WO2013005812A1 (en) * 2011-07-01 2013-01-10 日本電気株式会社 Distributed positioning device and distributed positioning method
US10157184B2 (en) * 2012-03-30 2018-12-18 Commvault Systems, Inc. Data previewing before recalling large data files
US9633216B2 (en) 2012-12-27 2017-04-25 Commvault Systems, Inc. Application of information management policies based on operation with a geographic entity
US9459968B2 (en) 2013-03-11 2016-10-04 Commvault Systems, Inc. Single index to query multiple backup formats
KR20150045073A (en) * 2013-10-18 2015-04-28 ㈜윈웨이시스템 Data Operating Method And System supporting the same
JP2015132972A (en) * 2014-01-14 2015-07-23 株式会社野村総合研究所 Data relocation system
US10169121B2 (en) 2014-02-27 2019-01-01 Commvault Systems, Inc. Work flow management for an information management system
US9648100B2 (en) 2014-03-05 2017-05-09 Commvault Systems, Inc. Cross-system storage management for transferring data across autonomous information management systems
US9823978B2 (en) 2014-04-16 2017-11-21 Commvault Systems, Inc. User-level quota management of data objects stored in information management systems
US9740574B2 (en) 2014-05-09 2017-08-22 Commvault Systems, Inc. Load balancing across multiple data paths
US10346371B2 (en) * 2014-07-11 2019-07-09 Hitachi, Ltd. Data processing system, database management system, and data processing method
US9852026B2 (en) 2014-08-06 2017-12-26 Commvault Systems, Inc. Efficient application recovery in an information management system based on a pseudo-storage-device driver
US11249858B2 (en) 2014-08-06 2022-02-15 Commvault Systems, Inc. Point-in-time backups of a production application made accessible over fibre channel and/or ISCSI as data sources to a remote application by representing the backups as pseudo-disks operating apart from the production application and its host
US9444811B2 (en) 2014-10-21 2016-09-13 Commvault Systems, Inc. Using an enhanced data agent to restore backed up data across autonomous storage management systems
US9766825B2 (en) 2015-07-22 2017-09-19 Commvault Systems, Inc. Browse and restore for block-level backups
US10296368B2 (en) 2016-03-09 2019-05-21 Commvault Systems, Inc. Hypervisor-independent block-level live browse for access to backed up virtual machine (VM) data and hypervisor-free file-level recovery (block-level pseudo-mount)
US10838821B2 (en) 2017-02-08 2020-11-17 Commvault Systems, Inc. Migrating content and metadata from a backup system
US10740193B2 (en) 2017-02-27 2020-08-11 Commvault Systems, Inc. Hypervisor-independent reference copies of virtual machine payload data based on block-level pseudo-mount
US10891069B2 (en) 2017-03-27 2021-01-12 Commvault Systems, Inc. Creating local copies of data stored in online data repositories
US10776329B2 (en) 2017-03-28 2020-09-15 Commvault Systems, Inc. Migration of a database management system to cloud storage
US11074140B2 (en) 2017-03-29 2021-07-27 Commvault Systems, Inc. Live browsing of granular mailbox data
US10664352B2 (en) 2017-06-14 2020-05-26 Commvault Systems, Inc. Live browsing of backed up data residing on cloned disks
US10795927B2 (en) 2018-02-05 2020-10-06 Commvault Systems, Inc. On-demand metadata extraction of clinical image data
US10789387B2 (en) 2018-03-13 2020-09-29 Commvault Systems, Inc. Graphical representation of an information management system
US10860443B2 (en) 2018-12-10 2020-12-08 Commvault Systems, Inc. Evaluation and reporting of recovery readiness in a data storage management system
US11308034B2 (en) 2019-06-27 2022-04-19 Commvault Systems, Inc. Continuously run log backup with minimal configuration and resource usage from the source machine
KR20230171757A (en) * 2022-06-14 2023-12-21 쿠팡 주식회사 Electronic apparatus and managing database method thereof

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5564116A (en) * 1993-11-19 1996-10-08 Hitachi, Ltd. Array type storage unit system
US5917999A (en) * 1991-01-31 1999-06-29 Hitachi, Ltd. Storage unit subsystem
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
US6145067A (en) * 1997-11-06 2000-11-07 Nec Corporation Disk array device
US6330653B1 (en) * 1998-05-01 2001-12-11 Powerquest Corporation Manipulation of virtual and live computer storage device partitions
US6405284B1 (en) * 1998-10-23 2002-06-11 Oracle Corporation Distributing data across multiple data storage devices in a data storage system
US6578039B1 (en) * 1999-11-12 2003-06-10 Hitachi, Ltd. Database management methods and equipment, and database management program storage media
US6813623B2 (en) * 2001-06-15 2004-11-02 International Business Machines Corporation Method and apparatus for chunk based transaction logging with asynchronous input/output for a database management system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0228877A (en) 1988-07-19 1990-01-30 Nec Corp Range division changing system
US6061761A (en) * 1997-10-06 2000-05-09 Emc Corporation Method for exchanging logical volumes in a disk array storage device in response to statistical analyses and preliminary testing
GB9811574D0 (en) * 1998-05-30 1998-07-29 Ibm Indexed file system and a method and a mechanism for accessing data records from such a system

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5917999A (en) * 1991-01-31 1999-06-29 Hitachi, Ltd. Storage unit subsystem
US5564116A (en) * 1993-11-19 1996-10-08 Hitachi, Ltd. Array type storage unit system
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
US6145067A (en) * 1997-11-06 2000-11-07 Nec Corporation Disk array device
US6330653B1 (en) * 1998-05-01 2001-12-11 Powerquest Corporation Manipulation of virtual and live computer storage device partitions
US6405284B1 (en) * 1998-10-23 2002-06-11 Oracle Corporation Distributing data across multiple data storage devices in a data storage system
US6578039B1 (en) * 1999-11-12 2003-06-10 Hitachi, Ltd. Database management methods and equipment, and database management program storage media
US6813623B2 (en) * 2001-06-15 2004-11-02 International Business Machines Corporation Method and apparatus for chunk based transaction logging with asynchronous input/output for a database management system

Cited By (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7174347B1 (en) * 2002-02-14 2007-02-06 Ncr Corp. Loading data using links in a database
US20040243773A1 (en) * 2002-09-09 2004-12-02 Martin Fischer Methods and systems for moving data objects
US20060129768A1 (en) * 2002-09-09 2006-06-15 Thorsten Pferdekaemper Methods and systems for archiving data
US7457933B2 (en) * 2002-09-09 2008-11-25 Sap Ag Methods and systems for archiving data
US20060101094A1 (en) * 2002-09-09 2006-05-11 Martin Fischer Methods and systems for moving data objects
US7693881B2 (en) * 2002-09-09 2010-04-06 Sap Ag Methods and systems for moving data using locks
US7693890B2 (en) * 2002-09-09 2010-04-06 Sap Ag Methods and systems for moving data objects
US7653667B2 (en) * 2002-09-09 2010-01-26 Sap Ag Methods and systems for data moving using locks
US20040153457A1 (en) * 2002-09-09 2004-08-05 Martin Fischer Methods and systems for controlling access to a data object
US7756814B2 (en) 2002-09-09 2010-07-13 Sap Ag Methods and systems for controlling access to a data object
US7756813B2 (en) 2002-09-09 2010-07-13 Sap Ag Electronic data structure for controlling access to data objects using locks
US7222142B2 (en) * 2002-09-09 2007-05-22 Sap Ag Methods and systems for moving data objects utilizing data identifiers and lock objects
US20060149696A1 (en) * 2002-09-09 2006-07-06 Thorsten Pferdekaemper Method and systems for controlling access to a data object by means of locks
US20060155704A1 (en) * 2002-09-09 2006-07-13 Martin Fischer Methods and systems for moving data using locks
US20060242203A1 (en) * 2002-09-09 2006-10-26 Pferdekaeemper Thorsten Methods and systems for data moving using locks
US20060149736A1 (en) * 2002-09-09 2006-07-06 Thorsten Pferdekaemper Electronic data structure for controlling access to data objects using locks
US20040162953A1 (en) * 2003-02-19 2004-08-19 Kabushiki Kaisha Toshiba Storage apparatus and area allocation method
US7266649B2 (en) * 2003-02-19 2007-09-04 Kabushiki Kaisha Toshiba Storage apparatus and area allocation method
US7743208B2 (en) 2003-02-19 2010-06-22 Kabushiki Kaisha Toshiba Storage apparatus and area allocation method
US20080091910A1 (en) * 2003-02-19 2008-04-17 Kabushiki Kaisha Toshiba Storage apparatus and area allocation method
US7496555B2 (en) 2003-02-26 2009-02-24 Permabit, Inc. History preservation in a computer storage system
US7912855B2 (en) 2003-02-26 2011-03-22 Permabit Technology Corporation History preservation in a computer storage system
US9104716B2 (en) 2003-02-26 2015-08-11 Permabit, Inc. History preservation in a computer storage system
US20040205112A1 (en) * 2003-02-26 2004-10-14 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US20040168058A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US20040167938A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US20040167902A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US7293027B2 (en) 2003-02-26 2007-11-06 Burnside Acquisition, Llc Method for protecting history in a file system
US7318072B2 (en) * 2003-02-26 2008-01-08 Burnside Acquisition, Llc History preservation in a computer storage system
US8095516B2 (en) 2003-02-26 2012-01-10 Permabit Technology Corporation History preservation in a computer storage system
US20040167939A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US7363326B2 (en) 2003-02-26 2008-04-22 Burnside Acquisition, Llc Archive with timestamps and deletion management
US8055628B2 (en) 2003-02-26 2011-11-08 Permabit Technology Corporation History preservation in a computer storage system
US20040167934A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US7467144B2 (en) 2003-02-26 2008-12-16 Burnside Acquisition, Llc History preservation in a computer storage system
US7478096B2 (en) 2003-02-26 2009-01-13 Burnside Acquisition, Llc History preservation in a computer storage system
US20040167901A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US7987197B2 (en) 2003-02-26 2011-07-26 Permabit Technology Corporation History preservation in a computer storage system
US20040167903A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US7979397B2 (en) 2003-02-26 2011-07-12 Permabit Technology Corporation History preservation in a computer storage system
US20040168057A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc. A Massachusetts Corporation History preservation in a computer storage system
US20040167898A1 (en) * 2003-02-26 2004-08-26 Margolus Norman H. History preservation in a computer storage system
US7734595B2 (en) 2003-02-26 2010-06-08 Permabit Technology Corporation Communicating information between clients of a data repository that have deposited identical data items
US20040167940A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US7747583B2 (en) 2003-02-26 2010-06-29 Permabit Technology Corporation History preservation in a computer storage system
US20040167935A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc. History preservation in a computer storage system
US20040167943A1 (en) * 2003-02-26 2004-08-26 Permabit, Inc., A Massachusetts Corporation History preservation in a computer storage system
US20060026220A1 (en) * 2003-02-26 2006-02-02 Permabit, Inc. History preservation in a computer storage system
US7930315B2 (en) 2003-02-26 2011-04-19 Permabit Technology Corporation History preservation in a computer storage system
US7506002B2 (en) * 2003-09-29 2009-03-17 Sap Ag Efficient deletion of archived data
US20050071383A1 (en) * 2003-09-29 2005-03-31 Axel Herbst Efficient deletion of archived data
US20080046487A1 (en) * 2004-05-27 2008-02-21 Yasuhiro Kamada Data processing system and method with data sharing for the same
US10789251B2 (en) * 2005-12-29 2020-09-29 Amazon Technologies, Inc. Method and apparatus for stress management in a searchable data service
US20160055229A1 (en) * 2005-12-29 2016-02-25 Amazon Technologies, Inc. Method and apparatus for stress management in a searchable data service
US20080154961A1 (en) * 2006-12-21 2008-06-26 Dougall Scott C J Local digital asset storage management technique
US7680993B2 (en) * 2006-12-21 2010-03-16 Tandberg Television, Inc. Local digital asset storage management technique
US9996264B2 (en) * 2010-10-04 2018-06-12 Quest Software Inc. Data block migration
GB2484396B (en) * 2010-10-04 2014-02-19 Dell Products Lp Data block migration
US9400799B2 (en) 2010-10-04 2016-07-26 Dell Products L.P. Data block migration
GB2484396A (en) * 2010-10-04 2012-04-11 Dell Products Lp Rebalancing of data in storage cluster when adding a new node
US20170031598A1 (en) * 2010-10-04 2017-02-02 Dell Products L.P. Data block migration
US10929017B2 (en) * 2010-10-04 2021-02-23 Quest Software Inc. Data block migration
US20180356983A1 (en) * 2010-10-04 2018-12-13 Quest Software Inc. Data block migration
US9489429B2 (en) 2011-11-16 2016-11-08 Hitachi, Ltd. Computer system, data management method, and program
US20170177222A1 (en) * 2014-03-08 2017-06-22 Diamanti, Inc. Methods and systems for data storage using solid state drives
US10628353B2 (en) 2014-03-08 2020-04-21 Diamanti, Inc. Enabling use of non-volatile media-express (NVMe) over a network
US10635316B2 (en) * 2014-03-08 2020-04-28 Diamanti, Inc. Methods and systems for data storage using solid state drives
US10860213B2 (en) 2014-03-08 2020-12-08 Diamanti, Inc. Methods and systems for data storage using solid state drives
US11269670B2 (en) 2014-03-08 2022-03-08 Diamanti, Inc. Methods and systems for converged networking and storage
US11269518B2 (en) 2014-03-08 2022-03-08 Diamanti, Inc. Single-step configuration of storage and network devices in a virtualized cluster of storage resources
US11921658B2 (en) 2014-03-08 2024-03-05 Diamanti, Inc. Enabling use of non-volatile media-express (NVMe) over a network
JP2017062541A (en) * 2015-09-24 2017-03-30 日本電気株式会社 Data management device, data management method, and program
WO2017050179A1 (en) * 2015-09-25 2017-03-30 阿里巴巴集团控股有限公司 Method and device for updating inventory system data
TWI734730B (en) * 2017-01-19 2021-08-01 香港商阿里巴巴集團服務有限公司 Method and device for updating inventory system data
CN113111014A (en) * 2021-04-07 2021-07-13 山东英信计算机技术有限公司 Method, device and equipment for cleaning non-hot data in cache and storage medium

Also Published As

Publication number Publication date
JP4183400B2 (en) 2008-11-19
US20060143248A1 (en) 2006-06-29
US7577694B2 (en) 2009-08-18
JP2003006021A (en) 2003-01-10

Similar Documents

Publication Publication Date Title
US7577694B2 (en) Database management system with rebalance architectures
US6668263B1 (en) Method and system for efficiently searching for free space in a table of a relational database having a clustering index
US7325041B2 (en) File distribution system in which partial files are arranged according to various allocation rules associated with a plurality of file types
US6438562B1 (en) Parallel index maintenance
US6405198B1 (en) Complex data query support in a partitioned database system
US7113957B1 (en) Row hash match scan join using summary contexts for a partitioned database system
US7054852B1 (en) Performance of join operations in parallel database systems
US6487546B1 (en) Apparatus and method for aggregate indexes
US7305386B2 (en) Controlling visibility in multi-version database systems
US20070100873A1 (en) Information retrieving system
EP0355132A4 (en) Computer program license management system
US7162478B2 (en) System and method for correlated fragmentations in databases
US20200133950A1 (en) Method and mechanism for efficient re-distribution of in-memory columnar units in a clustered rdbms on topology change
US7080072B1 (en) Row hash match scan in a partitioned database system
JP3367140B2 (en) Database management method
JPH06139119A (en) System and method for managing data base
US7228309B1 (en) Facilitating maintenance of indexes during a reorganization of data in a database
JP2006302307A (en) Storage device management method
JP3806609B2 (en) Parallel database system and distributed file system
JPH05307478A (en) Constituting method for data base management system
JP3769775B2 (en) Distributed link information maintenance method
US7734592B2 (en) Method for reducing a data repository
CN113392089B (en) Database index optimization method and readable storage medium
JPH09293055A (en) System and method for exclusive control over shared file in loosely coupled multiple computer system, and medium for storing exclusive control program
JP2000348063A (en) Method and system for database management

Legal Events

Date Code Title Description
AS Assignment

Owner name: HITACHI, LTD., JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NAKANO, YUKIO;KAWAMURA, NOBUO;REEL/FRAME:012311/0289;SIGNING DATES FROM 20011022 TO 20011023

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION