JP2001142752A - データベース管理方法 - Google Patents

Abstract

(57)【要約】 【課題】データベース容量の大規模化に伴ってデータベ
ース格納領域を追加する場合に追加したデータベース格
納領域へのデータの再配置が必要となる。 【解決手段】データベースの格納領域としてｍ個のデー
タベース格納領域が与えられた場合、データベースの一
つ又は複数のデータ項目をパーティショニングキーと
し、前記データベースを前記パーティショニングキーに
対してハッシュ関数を適用し、ｎ（ｍ≦ｎ）個の論理的
な単位であるバケットに分割し、当該与えられたデータ
ベース格納領域数に応じて各バケットを管理するデータ
ベース格納領域の対応を決定するハッシュマップ表と、
分配されたバケットを各データベース格納領域内の格納
単位であるセグメントとマッピングさせるためのセグメ
ントハッシュマップ表によってデータベースを管理す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、時系列的に増加し
ていくデータを新たに増設したデータベース格納領域に
データを再配置することによって、データベースの大規
模化の運用を行うデータベース管理システムに関する。

【０００２】

【従来の技術】一般的にデータベースを有するデータベ
ースシステムでは、データベースに保有する情報は時々
刻々変化している。その情報は時間経過と共に新たな情
報が追加され、あらかじめ用意したデータベースを格納
するためのデータベース格納領域の容量よりも大きくな
る場合がある。

【０００３】そのため、大規模なデータベースを扱う場
合、あらかじめデータベースを複数のデータベース格納
領域に分割して格納する方法が採用される。複数のデー
タベース格納領域に分割格納する分割手段として、キー
・レンジ分割、ハッシュ分割、均等分割といった手段が
用意される。各々の分割手段によって、分割したパーテ
ィションを指定したデータベース領域と１対１に対応さ
せたり、複数のパーティションをあるデータベース領域
に対応させたりという手法が採られる。時間経過と共に
新たな情報が追加される場合、２つのデータベースの拡
張方法が考えられる。一つは、分割手段としてキーレン
ジ分割が採用されている場合、新たなキーレンジを追加
したり、あるキーレンジを分割するといった方法があ
る。これは、新たにデータベース領域を追加することな
く操作することも可能である。もう一つは、分割手段は
変更しないで新たにデータベース領域を追加または既存
のデータベース領域を拡張する方法がある。これは、容
量の増大に伴ってデータベース格納領域を増分させる方
法である。これに対して、分割手段としてハッシュ分割
を採用すると、分割に対するオーバヘッドが少なく、デ
ータの増加に対する柔軟性が高い。

【０００４】ただし、あらかじめ用意したデータベース
格納領域は時間と共に新たな情報が追加されるだけでな
く、過去の古いデータを削除する場合もあり、必ずしも
常にデータベース格納領域の容量よりも大きくなるわけ
ではない。このような場合は、データベース再編成を行
うことによって古いデータを削除することによって空き
を作成し、新たに追加される情報を格納するために使用
するようにすることで解決される。

【０００５】しかし、過去のデータを延々と蓄積してい
くようなデータベースシステムでは、将来予測されるデ
ータ量を想定し、あらかじめデータベース格納領域を用
意しておくのは資源管理コストがかかるため、当面、予
想されるデータ量まで格納できるデータベース領域を準
備しておき、実際にデータ量の増加に伴って新たなデー
タベース格納領域が必要になった時点でデータベース格
納領域を追加する運用を行う。

【０００６】データベースに対するデータベース格納領
域の追加は、データベースの定義変更を伴う。最も単純
な方法としては、データベースの内容を一旦バックアッ
プし、データベース格納領域の追加を行う定義変更処理
を行った後、バックアップしたデータベースを再ローデ
ィングするという方法がある。ただし、この方法では大
規模データベースの場合、バックアップを取得する時間
及びバックアップ媒体等にかかるコストが非常に高く、
再ローディングする処理も膨大な時間を要する。

【０００７】第１の公知例として、米国特許４，４１
２，２８５がある。本公知例では、表をハッシュ分割す
るが、あらかじめ複数のバケットに分割し、いくつかの
バケットを仮想プロセッサに対応させて管理する技術が
開示されている。

【０００８】第２の公知例として、特開平６−１３９１
１９号公報には、複数のプロセッサで構成される並列デ
ータベースシステム上に分割されたデータベースをアク
セス頻度によってデータを再編成する技術が開示されて
いる。

【０００９】第３の公知例として、特開平６−３１４２
９９号公報には、複数のプロセッサで構成される並列デ
ータベースシステム上に、階層的にデータベースを分割
する技術が開示されている。

【００１０】第４の公知例として、特開平７−１４１３
９４号公報には、複数のプロセッサで構成される並列デ
ータベースシステム上に分割されたデータベースに対し
て、第５の公知例として、特開平９−２９３００６号公
報には、ハッシュ関数を使用した分割方法を示し、デー
タベース分割数が変更された場合にデータの再配置を必
要とせず、データを新規追加した格納領域に格納しよう
とする技術が開示されている。ただし、本公知例ではデ
ータの再配置は必要ないが、検索時には分割したすべて
の記憶装置を検索するようになっている。

【００１１】

【発明が解決しようとする課題】従来技術における前者
の方法の場合、データベースの大規模化についての問題
が生じる。データベースの大規模化によって再配置が必
要になるのは、データベース領域中の表に対するデータ
の追加が行われることによって、あらかじめ与えられた
データベース格納領域の空きがなくなる場合である。

【００１２】上述したハッシュ分割を採用したデータベ
ースの場合、ハッシング結果は分割数すなわち与えられ
たデータベース格納領域数に依存するため、新たにデー
タベース格納領域を追加する場合、それまで蓄積したデ
ータをすべて新しい分割数の元でハッシングをやりなお
し再格納しなければならない。これは、非常に膨大な時
間と資源を浪費することになり、効率良くシステムを運
用することができない。

【００１３】また、再格納しないで既存の各データベー
ス格納領域から、再配置処理として再ハッシュした結果
によって他のデータベース格納領域にデータを移動させ
る場合、結局、各データベース格納領域中のすべてのデ
ータを読み込まなければならず、再ハッシュしても同じ
データベース格納領域内に残るデータがある場合でも無
駄なデータの読み込みが生じてしまう。

【００１４】本発明の第１の目的は、ハッシュ分割した
データベースに対してデータベース格納領域を追加する
場合に、既存のデータベース格納領域から新たに追加し
たデータベース格納領域に対して最も少ないコストでデ
ータを再配置することを可能とするデータベース格納管
理方法を提供することにある。

【００１５】

【課題を解決するための手段】前記目的を達成するため
に、本発明は、一つ又は複数の外部記憶装置から構成さ
れるデータベース格納領域を管理し、前記データベース
格納領域は物理的に固定長の複数のページから構成され
る複数のセグメントを管理するデータベース管理方法に
おいて、データベースの格納領域としてｍ個のデータベ
ース格納領域が与えられた場合、データベースの一つ又
は複数のデータ項目をパーティショニングキーとし、前
記データベースを前記パーティショニングキーに対して
ハッシュ関数を適用し、ｎ（ｍ≦ｎ）個の論理的な単位
であるバケットに分割し、当該与えられたデータベース
格納領域数に応じて各バケットを管理するデータベース
格納領域の対応を決定するハッシュマップ表と、分配さ
れたバケットを各データベース格納領域内の格納単位で
あるセグメントとマッピングさせるためのセグメントハ
ッシュマップ表によってデータベースを管理することを
特徴とするデータベース管理方法を提供する。

【００１６】

【発明の実施の形態】以下、本発明の一実施例を添付図
面を用いて具体的に説明する。

【００１７】図２は本実施形態のコンピュータシステム
のハードウエア構成の一例を示す図である。コンピュー
タシステム１０は、ＣＰＵ１２、主記憶装置１４、磁気
ディスク装置等の外部記憶装置２０及び多数の端末３０
で構成される。主記憶装置１４上には、データベース管
理システム４０が置かれ、複数の外部記憶装置２０を使
用してデータベース管理システム４０が管理するデータ
ベースを格納するデータベース領域５０ａ，５０ｂ，５
０ｃ，５０ｄ、データベースの定義情報を管理するデー
タベース定義情報格納領域６０およびデータベースに対
する更新操作に関する更新履歴情報を管理するデータベ
ースログ格納領域７０が構成される。。さらに、データ
ベース管理システム４０を実現するプログラムも外部記
憶装置２０上に格納される。

【００１８】図１は本発明におけるデータベースの管理
形態を示す。図２で示したデータベース定義情報格納領
域６０では、データベースシステムを構成するデータベ
ース格納領域やデータベースの定義情報が格納される。
データベース格納領域管理表６１は、データベースシス
テム内のデータベースを格納する領域として定義された
データベース格納領域に関する情報を管理する。データ
ベース格納領域構成ファイル管理表６２は、データベー
ス格納領域定義時に指定された図２に示す外部記憶装置
上に割り当てたファイルの構成に関する情報を管理す
る。データベース管理表６３は、特にリレーショナルデ
ータベース管理システムのような場合に定義された表を
管理する。データベース構成列管理表６４は、定義され
た表を構成する列に関する情報を管理する。データベー
ス分割管理表６５は、表定義時にデータベースシステム
内に定義されたデータベース格納領域を指定してデータ
を分割して格納した場合の表とデータベース格納領域の
関連情報を持つ。ハッシュマップ表６６は、本発明で必
要とするデータベース内に定義された表を複数のデータ
ベース格納領域に分割して格納する場合に、その分割方
法としてハッシュ分割方法が指定されると、指定された
データベース格納領域数に対応してハッシュバケットに
分割した場合の各ハッシュバケットをどのデータベース
格納領域に格納するかを決定する対応表を持つ。

【００１９】次に、データベース格納領域５０ａ，５０
ｂ，５０ｃ，５０ｄの構成について説明する。ハッシュ
分割された表について、データベース格納領域内での管
理方法を示す。定義された表について、ハッシュバケッ
トに分割する場合、ハッシュマップ表によってハッシュ
バケットの要素番号が決定されると、決定された要素番
号のハッシュバケットのデータを格納する物理的に固定
長の複数のページから構成されるセグメント５４にデー
タを格納した場合の先頭セグメント番号を管理するセグ
メントハッシュマップ表５１と、データベース格納領域
内に確保されたすべてのセグメントの割当をビットマッ
プとして管理するためのセグメントビットマップ表５２
と、割り当てたセグメント５４内のページの割当をビッ
トマップとして管理し、なおかつ、同じハッシュバケッ
トの要素番号で複数のセグメントが割り当てられる場合
にセグメント間のチェインを管理するページビットマッ
プ表５３から構成される。

【００２０】図３は、図２で示したデータベース定義情
報格納領域６０に格納されたデータベース定義情報の一
実施例として詳細に示したものである。データベース格
納領域として、ＤＤＩＣＡＲＥＡ，ＤＢＡＲＥＡ１，Ｄ
ＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４が定義
されている場合にデータベース格納領域管理表６１及び
データベース格納領域構成ファイル管理表６２に格納さ
れた情報を示す。データベース格納領域管理表６１は、
データベース領域名、種別、構成ファイル数、サーバ
名、ページ長、セグメントサイズ及びセグメント数の列
から構成される。また、データベース格納領域構成ファ
イル管理表は、データベース領域名、番号、及び構成フ
ァイル名の列で構成される。当該データベースでは、Ｄ
ＤＩＣＡＲＥＡというデータベース格納領域が定義され
ると、その種別としてデータベース定義情報格納領域で
あることを示す’Ｄ’という情報で識別され、当該デー
タベース格納領域を構成するファイル数である１、図１
におけるデータベース格納領域で示したセグメント５４
を構成するページのサイズであるページ長として４０９
６バイト、当該セグメントを構成するページ数として５
０ページ、さらに当該データベース格納領域に割り当て
られるセグメント数５０が定義情報として格納される。
同様に、ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥ
Ａ３，ＤＢＡＲＥＡ４が定義されると、データベース格
納領域の種別としてデータベース格納領域であることを
識別する’Ｕ’、及び構成ファイル数、サーバ名、ペー
ジ長、セグメントサイズ、セグメント数の情報が各々格
納される。これに対して、データベース格納領域構成フ
ァイル管理表６２には、各データベース格納領域を構成
するファイル名と複数のファイルで構成される場合に
は、その通番が情報として格納される。

【００２１】次に当該データベースで「ＺＡＩＫＯ」表
が定義された場合について、当該表の定義情報がデータ
ベース管理表６３、データベース構成列管理表６４、及
びデータベース分割管理表６５にどのように格納される
かについて説明する。「ＺＡＩＫＯ」表の定義文の一例
を示す。

【００２２】 CREATE TABLE ZAIKO ( SCODE CHAR(10), SNAME CHAR(10), COL CHAR(4), TANKA INTEGER, ZSURYO INTEGER) HASH BY SCODE IN(DBAREA1,DBARE2,DBAREA3,DBAREA4) ; 上記定義によって、「ＺＡＩＫＯ」表は４つの列ＳＣＯ
ＤＥ，ＳＮＡＭＥ，ＣＯＬ，ＴＡＮＫＡ，ＺＳＵＲＹＯ
で構成され、ＳＣＯＤＥ列をパーティショニングキーと
してハッシュ分割し、ハッシュ分割したデータは、デー
タベース格納領域ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，Ｄ
ＢＡＲＥＡ３，ＤＢＡＲＥＡ４に分割して格納するよう
指示されている。当該定義内容によって、データベース
管理表６３には表名、所有者、構成列数、分割方法、指
定したデータベース格納領域数を示す分割数、及びパー
ティショニングキー情報としてＳＣＯＤＥ列であること
を示すためデータベース構成列管理表内の列番号が格納
される。データベース構成列管理表６４には、「ＺＡＩ
ＫＯ」表を構成する５つの列の定義情報として、列名、
表名、所有者、表を構成する列の順番を示す列番号、デ
ータ型、データ長が格納される。さらに、データベース
分割管理表６５には、「ＺＡＩＫＯ」表を４つのデータ
ベース格納領域に分割して格納するため、表名、データ
ベース格納領域の定義順を示す番号、及びデータベース
格納領域名が格納される。

【００２３】図４では、図２に示したハッシュマップ表
６６を示す。本発明の実施例として当該データベースで
は、データベースの表を複数のデータベース格納領域に
分割する場合の最大データベース格納領域数を５１２と
する。また、このとき、ハッシュ分割での最大ハッシュ
バケット数を１，０２４とする。ハッシュマップ表６６
は、一つ一つの表のハッシュバケットの要素番号とデー
タベース格納領域との対応を示すようにする方法も考え
られるが、データベース定義情報格納領域６０の容量増
大を防止するため、２〜５１２分割までのすべてのデー
タベース格納領域指定数に応じ、ハッシュ関数によって
求められたハッシュバケット要素番号と図３に示したデ
ータベース分割管理表の「番号」列の値との対応表を持
つようにしている。最も簡単な例として２分割の例を挙
げる。２分割の場合、ハッシュマップ表の第１エントリ
を参照し、ハッシュバケット要素番号の０〜５１１まで
がデータベース格納領域の指定番号の０に格納すること
を示し、ハッシュバケット要素番号の５１２〜１０２３
まではデータベース格納領域の指定番号の１に格納する
ことを示す。それに対して、該当する表のデータベース
分割管理表の番号０および１を参照してデータベース格
納領域が決定される。次に、３分割の場合は、２分割状
態のデータベースから１つのデータベース格納領域が追
加された場合に追加されたデータベース格納領域に対し
て既存の２つの分割されたデータベース格納領域のハッ
シュバケットから３分の１ずつハッシュバケットを移動
するようにさせたハッシュマップ表となる。したがっ
て、ハッシュバケット要素番号０〜３４１までの３４２
個のハッシュバケットがデータベース分割管理表の指定
番号０のデータベース格納領域に格納することを示し、
ハッシュバケット要素番号５１２〜８５３までの３４１
個のハッシュバケットがデータベース分割管理表の指定
番号１のデータベース格納領域に格納することを示し、
ハッシュバケット要素番号３４２〜５１１及び８５４〜
１０２３までの合計３４１個のハッシュバケットがデー
タベース分割管理表の指定番号２のデータベース格納領
域に格納することを示す。３分の１に分ける場合、割り
切れない場合にはデータベース分割管理表の指定番号の
小さい方にハッシュバケットが多く残るように調整す
る。これによって、データの再配置が行われる場合に少
しでも移動するデータ量を削減できる。さらに４分割の
場合も同様に、３分割状態のデータベースから１つのデ
ータベース格納領域が追加された場合に追加されたデー
タベース格納領域に対して既存の３つの分割されたデー
タベース格納領域のハッシュバケットから４分の１ずつ
ハッシュバケットを移動するようにさせたハッシュマッ
プ表となる。この場合、ハッシュバケット要素番号０〜
２５５までの２５６個のハッシュバケットがデータベー
ス分割管理表の指定番号０のデータベース格納領域に格
納することを示し、ハッシュバケット要素番号５１２〜
７６７までの２５６個のハッシュバケットがデータベー
ス分割管理表の指定番号１のデータベース格納領域に格
納することを示し、ハッシュバケット番号３４２〜４６
９までの１２８個、ハッシュバケット要素番号８５４〜
９８１までの１２８個の合計２５６個のハッシュバケッ
トがデータベース分割管理表の指定番号２のデータベー
ス格納領域に格納することを示し、ハッシュバケット要
素番号２５６〜３４１までの８６個、ハッシュバケット
要素番号４７０〜５１１までの４２個、ハッシュバケッ
ト要素番号７６８〜８５３までの８５個、ハッシュバケ
ット要素番号９８２〜１０２３までの４３個の合計２５
６個のハッシュバケットがデータベース分割管理表の指
定番号３のデータベース格納領域に格納することを示
す。このようにして、最大分割数である５１２分割まで
のハッシュバケットの対応表が保持されている。したが
って、データベースの表定義時に決定したデータベース
格納領域数によって参照するハッシュマップ表のエント
リを決定すればよいことになる。

【００２４】次に、図１におけるセグメントハッシュマ
ップ表５１、セグメントビットマップ表５２、ページビ
ットマップ表５３、およびセグメント５４に関して図５
のデータベースの表へのデータ挿入処理の概略フローお
よび図６を用いて詳細に示す。データベースの表に対し
てデータの挿入処理要求が行われる場合、「ＺＡＩＫ
Ｏ」表を例にとると以下のような要求がデータベース管
理システムに対して発行される。

【００２５】INSERT INTO ZAIKO VALUES('101','フ゛ラウ
ス','red',35000,62) 上記、要求が与えられた場合、まず、図２におけるデー
タベース定義情報格納領域６０からデータベース定義情
報を取得する（ステップ４１０）。取得した情報の中か
ら、「ＺＡＩＫＯ」表はパーティショニングキーＳＣＯ
ＤＥ列でハッシュ分割することが判明する。したがっ
て、ＳＣＯＤＥ列に指定された値’１０１’に対してハ
ッシュ関数を施す（ステップ４１１）。ハッシュ関数を
施した結果、図４におけるハッシュマップ表のハッシュ
バケット要素番号が決定される。ここでは、ハッシュバ
ケット要素番号が２５６となったとする。そして、当該
「ＺＡＩＫＯ」表はデータベース格納領域４つに分割す
ることが与えられているので、図４におけるハッシュマ
ップ表の分割数４のハッシュマップ表のハッシュバケッ
ト要素番号２５６のエントリを参照し、データベース分
割管理表内の番号３がデータ格納するデータベース格納
領域であることがわかる（ステップ４１２）。データベ
ース分割管理表の「番号」列が３であるデータベース格
納領域名を検索することによって、データベース格納領
域名が’ＤＢＡＲＥＡ４’であることが確定する。デー
タベース格納領域が決定したので、次にデータベース格
納領域’ＤＢＡＲＥＡ４’内の格納するセグメントを決
定するため、「ＺＡＩＫＯ」表のセグメントハッシュマ
ップ表５１を参照する。セグメントハッシュマップ表５
１を参照する場合、先ほど求めたハッシュバケット要素
番号２５６を使ってセグメントハッシュマップ表内の配
列番号２５６のエントリを参照する（ステップ４１
３）。ここで、セグメントハッシュマップ表６６内の配
列番号２５６には、図６で示すように当該ハッシュバケ
ット要素番号を持つデータのセグメント数及びセグメン
ト先頭ポインタとして先頭セグメント管理テーブルの番
号が保持されている。ステップ４１４によって、このセ
グメント数が０又は先頭セグメント管理テーブルの番号
が０かどうかを判定することによってセグメントが割り
当てられているか否かをチェックする。もし、０の場合
はまだセグメントが割り当てられていない、すなわち、
当該ハッシュバケット要素番号に該当するデータが１件
も格納されていないので、図１におけるセグメントビッ
トマップ表を参照し、セグメントを確保する処理を行う
（ステップ４１５）。図１におけるセグメントビットマ
ップ表５２は、当該データベース格納領域内に確保でき
る全セグメント数分のビットマップで管理されており、
空きビットをサーチすることによって見つかった空きセ
グメントを新規セグメントとして確保する。そして確保
したセグメントのページ割当状況を管理するセグメント
管理テーブルを図１におけるページビットマップ表５３
から確保し、セグメントハッシュマップ表の配列番号２
５６のエントリにセグメント数として１を設定し、セグ
メント先頭ポインタとして確保したセグメント番号を設
定する。また、確保したセグメント管理テーブルには、
次のセグメントがまだ割り当てられていないことを示す
ため、ＮＥＸＴポインタには０を設定する（ステップ４
１６）。次に、確保したセグメントからデータを格納す
るページを決定する。新規に確保したセグメントの場
合、セグメント管理テーブル中に含まれるページビット
マップ領域はすべてのビットが空きページの状態とな
る。先頭ページを使用することを決定し、先頭ビットを
使用状態に更新する。また、ステップ４１４によってす
でに該当ハッシュバケットのセグメントが確保されてい
る場合は、セグメント管理テーブルのチェインをたど
り、最終セグメントのセグメント管理テーブルのページ
ビットマップ領域を参照し、最終ページ番号をアクセス
する。最終ページ番号のページを入力し、挿入するレコ
ード（行）が格納できる空き領域が存在すれば当該ペー
ジを挿入ページとして決定する（ステップ４１７）。も
し、空き領域が存在しなければ先ほどのセグメント管理
テーブルから空きページを検索し、空きページがあれば
当該ページを挿入ページとして決定する。さらに、当該
セグメント中に空きページが存在しない場合は、セグメ
ントビットマップ表を検索し、空きセグメントを確保す
るようにする。空きセグメントも存在しない場合は、ハ
ッシュバケット要素番号に該当するすべてのセグメント
管理テーブルのチェインを辿り、核セグメント管理テー
ブルから空きページをサーチすることによって挿入ペー
ジを決定する。それでも、空きページが存在しない場合
は、当該データベース格納領域内に空き領域が存在しな
いことになり、挿入不可となる。こうして、正常に決定
された挿入ページに行を格納することによって行の挿入
処理が完了する（ステップ４１８）。行挿入に際して
は、当然であるが図２におけるデータベースログ格納領
域７０に対して挿入処理に関するログを取得しておく必
要がある。

【００２６】以上のように行を挿入する場合、ハッシュ
関数によって定められたデータベース格納領域を決定
し、さらにデータベース格納領域内でもハッシュバケッ
ト要素番号に該当するセグメントにデータを格納するた
め、他のパーティショニングキー値によって求められた
異なるハッシュバケット要素番号のデータは明確に別セ
グメントに格納される。さらに、複数のユーザから行を
挿入する要求が発生した場合、同じデータベース格納領
域内であっても分割キー値が異なれば格納するセグメン
トも異なるので、同一セグメントへの挿入といった競合
を大幅に抑止することも可能になる。

【００２７】次に、データベースに対する問合せとして
検索要求が発行された場合の検索処理の処理の流れを図
７に示す。データベースの表に対してデータの検索処理
要求が行われる場合、「ＺＡＩＫＯ」表を例にとると以
下のような要求がデータベース管理システムに対して発
行される。

【００２８】SELECT SCODE,SNAME,COL,TANKA,ZSURYO FR
OM ZAIKO WHERE SNO='101' 上記要求が与えられた場合、まず、図２におけるデータ
ベース定義情報格納領域６０からデータベース定義情報
を取得する（ステップ４２０）。取得した情報の中か
ら、「ＺＡＩＫＯ」表はパーティショニングキーＳＣＯ
ＤＥ列でハッシュ分割していることが判明する。次に当
該検索要求の探索条件中にパーティショニングキーであ
るＳＣＯＤＥ列に対する条件指定があるか否かをチェッ
クする（ステップ４２１）。当該問い合わせの場合、Ｓ
ＮＯ列に対する条件が指定されているので、ハッシュ関
数を適用することによってデータベース格納領域を決定
する。ハッシュ関数を施した結果、図３におけるハッシ
ュマップ表のハッシュバケット要素番号が決定される。
ここでは、ハッシュバケット要素番号が２５６となった
とする。そして、当該「ＺＡＩＫＯ」表はデータベース
格納領域４つに分割することが与えられているので、図
４におけるハッシュマップ表の分割数４のハッシュマッ
プ表のハッシュバケット要素番号２５６のエントリを参
照し、データベース分割管理表内の番号３がデータ格納
するデータベース格納領域であることがわかる（ステッ
プ４２３）。データベース分割管理表の「番号」列が３
であるデータベース格納領域名を検索することによっ
て、データベース格納領域名が’ＤＢＡＲＥＡ４’であ
ることが確定する。データベース格納領域が決定したの
で、次にデータベース格納領域’ＤＢＡＲＥＡ４’内の
当該ハッシュバケット要素番号に該当するセグメントを
決定するため、「ＺＡＩＫＯ」表のセグメントハッシュ
マップ表５１を参照する。セグメントハッシュマップ表
５１を参照する場合、先ほど求めたハッシュバケット要
素番号２５６を使ってセグメントハッシュマップ表内の
配列番号２５６のエントリを参照する（ステップ４２
４）。セグメントハッシュマップ表の配列番号２５６の
エントリ中に設定された先頭セグメント管理テーブル番
号が存在する場合は、セグメント管理テーブルのチェイ
ンを辿りながら、全セグメントの割当ページを検索対象
として探索条件を評価する（ステップ４２５）。もし、
該当するエントリ中にセグメント番号が設定されていな
い場合は検索対象データがないということになり、検索
結果は０件となる。また、ステップ４２１によってパー
ティショニングキーであるＳＮＯ列に対する条件指定が
ない場合は、すべてのデータベース格納領域が検索対象
になる。すべてのデータベース格納領域が検索対象とな
った場合、各データベース格納領域内のセグメントハッ
シュマップ表に設定されたセグメント番号が０でないも
のを対象に各要素番号のセグメントチェインを辿りなが
ら探索条件評価を行う（ステップ４２６ないし４２
７）。

【００２９】以上のようにデータベース検索の場合、パ
ーティショニングキーに対する条件が指定されると、検
索対象となるデータベース格納領域を絞り込むだけでな
く、データベース格納領域内のセグメントを絞り込むこ
とができるので、アクセスする必要のないセグメントを
検索対象から除外することができる。

【００３０】本発明によるデータベース分割格納方法を
用い、データの再配置を行う場合の実施例を図８及び図
９を用いて説明する。データベースシステム構成として
は、図２に示した構成を用い、データベースの定義とし
ては、図３で示した「ＺＡＩＫＯ」表を用いて、当該
「ＺＡＩＫＯ」表に対して新規にデータベース格納領域
「ＤＢＡＲＥＡ５」を追加する場合のデータベース再配
置処理の流れを図８に示し、その場合のデータベースの
データの移動方法を図９に示す。データベース再配置処
理は、図９に示したようにデータベース管理システム４
０内の一つの処理プログラムであるデータベース再配置
処理部４３０として動作する。まず、データベース再配
置処理要求としてデータベース格納領域「ＤＢＡＲＥＡ
５」の追加が要求されると、新規に追加したデータベー
ス格納領域を含めた分割数でのハッシュマップ表を図４
に示した各分割数毎のハッシュマップ対応表から求める
（ステップ４３１）。ここでは、４分割されたデータベ
ースに対してデータベース格納領域を一つ追加するので
５分割の場合のハッシュマップ表を求めることになる。
次に求めたハッシュマップ表から追加データベース格納
領域が管理するハッシュバケット要素番号を抜き出した
リストを作成する（ステップ４３２）。つまり、５分割
の場合のハッシュマップ表の各配列の中の番号が４であ
る配列番号をハッシュバケット要素番号として取り出せ
ば良い。こうして追加したデータベース格納領域が管理
すべきハッシュバケット要素番号が判明したので、現在
の分割数である４分割のハッシュマップ表を参照し、先
ほど取り出したハッシュバケット要素番号のハッシュバ
ケットを現在管理しているデータベース格納領域の番号
を取得する（ステップ４３３）。データベース格納領域
の番号が判明すれば、図３におけるデータベース定義情
報格納領域６０中のデータベース分割管理表６５からデ
ータベース格納領域名を得ることができる。こうして得
られた追加したデータベース格納領域への移動対象とな
るハッシュバケット要素番号と既存のデータベース格納
領域との対応表を作成し、既存のデータベース格納領域
毎に移動対象ハッシュバケット要素番号をソートするよ
うに対応表を作成しておくと処理を既存のデータベース
格納領域毎に行えるようにすることができる。まず、デ
ータベース格納領域「ＤＢＡＲＥＡ１」から処理を開始
する。図９を用いながら説明する。データベース格納領
域「ＤＢＡＲＥＡ１」からは、ハッシュバケット要素番
号０から２５５までの５分の１であるハッシュバケット
要素番号２０４から２５５までが移動対象となり、図８
における移動対象セグメント抽出処理（ステップ４３
４）では、図９におけるデータベース格納領域「ＤＢＡ
ＲＥＡ１」５０ａ中のセグメントハッシュマップ表５１
ａを参照し、ハッシュバケット要素番号２０４から順番
に２５５までのセグメント先頭番号を取出しながら、ペ
ージビットマップ表５３ａ中のセグメント管理テーブル
のチェインを辿り、セグメント５４ａをセグメント入出
力バッファ４２に読み込む。セグメント入出力バッファ
にはセグメント単位で読み込み処理を行うが、各セグメ
ント管理テーブルのページビットマップ領域を参照する
ことによって使用されていない、すなわち空きページに
ついては読み込まないようにするか、移動先のデータベ
ース格納領域の当該セグメントを割り当てた際にページ
ビットマップ情報もコピーすればセグメント単位で読み
込んでも問題ない。こうしてセグメント入出力バッファ
４２に読み込んだセグメントを追加データベース格納領
域「ＤＢＡＲＥＡ５」５０ｅに反映する処理を行う（ス
テップ４３５）。反映処理とは、次の手順で行われる。

【００３１】（１）セグメント単位で処理を行うので追
加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅ中の
セグメントビットマップ表から空きビットをサーチし、
新規に１個のセグメントを確保する。

【００３２】（２）新規に当該ハッシュバケット用のセ
グメントを確保した場合は、セグメントハッシュマップ
表５３ａの先頭セグメント先頭ポインタを更新する。こ
のとき、当該ハッシュバケット用セグメント数に１を加
える。

【００３３】（２）確保したセグメントを管理するセグ
メント管理テーブルをページビットマップ表５３ｅから
確保する。確保したセグメント管理テーブル内のページ
ビットマップは、移動前のページビットマップ内容をコ
ピーすればよい。このとき、当該ハッシュバケット用の
セグメントがすでに割り当てられている場合はセグメン
ト管理テーブルの最後尾に当該テーブルをチェインさせ
る。

【００３４】（３）確保したセグメントに対してセグメ
ント入出力バッファ４２から書きこむ。

【００３５】上記手順によって反映処理終了後、既存の
データベース格納領域「ＤＢＡＲＥＡ１」５０ａの移動
完了したセグメントの削除処理を行う（ステップ４３
６）。移動完了したセグメントの削除処理は、次の手順
で行われる。

【００３６】（１）セグメントハッシュマップ表５１ａ
の該当ハッシュバケット要素番号のセグメント先頭ポイ
ンタを参照し、ページビットマップ表５３ａのセグメン
ト管理テーブルをＮＥＸＴポインタを辿りながら、セグ
メントビットマップ表５２ａ内の該当セグメントのビッ
トを空きビットに更新する。

【００３７】（２）該当ハッシュバケットのすべてのセ
グメントについてセグメントビットマップ表５２ａのビ
ットを空きビットに更新したら、セグメントハッシュマ
ップ表内の該当ハッシュバケット要素番号のセグメント
数を０に更新する（ステップ４３７）。

【００３８】以上の手順で各既存のデータベース格納領
域内の移動対象となるハッシュバケットすべてを移動し
たかどうかをチェックし（ステップ４３８）、データベ
ース格納領域「ＤＢＡＲＥＡ４」までステップ４３４か
ら４３７までを行い、すべてのデータベース格納領域の
処理が終了した場合、データベース定義情報格納領域６
０内のデータベース定義情報を更新する（ステップ４３
９）。更新する内容は、追加したデータベース格納領域
の情報をデータベース領域管理表６１およびデータベー
ス格納領域構成ファイル菅表に追加し、「ＺＡＩＫＯ」
表に追加したデータベース格納領域の情報として、デー
タベース管理表６３の分割数を５に更新し、データベー
ス分割管理表６５には追加したデータベース格納領域
「ＤＢＡＲＥＡ５」及び番号として４の情報を追加する
ことである。

【００３９】このようにデータベースの再配置処理で
は、各既存のデータベース格納領域から１レコードずつ
データを読み込む必要がなく、セグメント単位で読み込
み、追加したデータベース格納領域に書きこみを行えば
よい。また、移動対象でないハッシュバケットは一切、
読み込む必要がない。

【００４０】次に、本発明によるデータの再配置に関す
る第２の実施例として並列データベースシステムにおけ
るデータの再配置処理を示す。

【００４１】図１０は、並列データベースシステムのハ
ードウエア構成の一例を示す図である。一つのコンピュ
ータシステム１０は、図２と同様にＣＰＵ１２、主記憶
装置１４、磁気ディスク装置等の外部記憶装置２０で構
成される。当該並列データベースシステムでは。複数の
コンピュータシステム及び複数台の端末３０がネットワ
ークに接続されている。当該並列データベースシステム
を構成するデータベース管理システム４０内に各処理構
成単位が配置される。フロントエンドサーバ４１（以下
ＦＥＳと呼ぶ）は、端末３０からの問合せを受信し、問
合せの処理手順を生成するコンポーネントである。当該
ＦＥＳには、トランザクション等に関するログを記録す
るためのデータベースログ格納領域７０を持つ。バック
エンドサーバ４３ａ，４３ｂ，４３ｃ，４３ｄ（以下、
ＢＥＳと呼ぶ）はＦＥＳからの処理手順を受信して、各
々ＢＥＳ１，ＢＥＳ２，ＢＥＳ３，ＢＥＳ４が管理する
データベース格納領域５０ａ，５０ｂ，５０ｃ，５０ｄ
をアクセスすることによってＦＥＳにその処理結果を返
す。このとき、各々のデータベース格納領域に対して行
われたデータベースの変更に関するログやトランザクシ
ョンに関するログが、データベースログ格納領域７０
ａ，７０ｂ，７０ｃ，及び７０ｄに格納される。データ
ディクショナリサーバ４２（以下、ＤＩＣと呼ぶ）は、
データベースに関する定義情報を管理し、その定義情報
はデータベース定義情報格納領域７０に格納され、デー
タベース定義情報の変更に関するログやトランザクショ
ンに関するログが、データベースログ格納領域７０に格
納される。ＦＥＳでは、要求された問合せでアクセスす
るデータベースの定義情報をＤＩＣから取得する。図１
０でも示すように、一つのコンピュータシステム内にＢ
ＥＳを複数配置することができる。これは、一つのコン
ピュータシステム内に複数のＢＥＳを配置することによ
って、並列処理能力を高めることができる。ここでは、
各々のコンピュータシステムにそれぞれ２つのＢＥＳを
配置する構成をとる。当該並列データベースシステムの
ハードウエア構成を利用し、先に挙げた「ＺＡＩＫＯ」
表を定義した場合のデータベース定義情報格納領域７０
の管理情報について図１１に示す。非並列データベース
システムの場合の実施例として示した図３のデータベー
ス定義情報格納領域７０とは基本的な管理情報に違いは
ない。異なる点は、データベース領域管理表６１に含ま
れるサーバ名である。各データベース格納領域をどのサ
ーバで管理しているかを管理するための情報が付加され
る。つまり、「ＺＡＩＫＯ」表は４つのデータベース格
納領域ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ
３，ＤＢＡＲＥＡ４に分割され、ＤＢＡＲＥＡ１はＢＥ
Ｓ１、ＤＢＡＲＥＡ２はＢＥＳ２、ＤＢＡＲＥＡ３はＢ
ＥＳ３、ＤＢＡＲＥＡ４はＢＥＳ４にてデータベース処
理を行うようにＦＥＳが処理を振り分けるのである。

【００４２】次に、当該並列データベースシステムに対
して図１０に示すように新規にコンピュータシステムを
追加し、データベースコンポーネントとしてＢＥＳ５
４３ｅを追加し、さらに追加したＢＥＳ５にデータベー
ス格納領域「ＤＢＡＲＥＡ５」を追加した場合に、戦術
した「ＺＡＩＫＯ」表のデータの再配置がどう行われる
かについて説明する。

【００４３】最初に、ＢＥＳ５では再配置処理としてデ
ータ受信処理を実行する。図１３にＢＥＳ５におけるデ
ータ受信処理の概略処理フローを示す。ＢＥＳ５では、
追加するデータベース格納領域ＤＢＡＲＥＡ５を含めた
５分割時のハッシュマップ表をＤＩＣのデータベース定
義情報格納領域から取り出す（ステップ４４１）。次に
求めたハッシュマップ表から追加データベース格納領域
が管理するハッシュバケット要素番号を抜き出したリス
トを作成する（ステップ４４２）。つまり、５分割の場
合のハッシュマップ表の各配列の中の番号が４である配
列番号をハッシュバケット要素番号として取り出せば良
い。こうして追加したデータベース格納領域が管理すべ
きハッシュバケット要素番号が判明したので、現在の分
割数である４分割のハッシュマップ表を参照し、先ほど
取り出したハッシュバケット要素番号のハッシュバケッ
トを現在管理しているデータベース格納領域の番号及び
サーバ名をＤＩＣから取得する（ステップ４４３）。デ
ータベース格納領域の番号が判明すれば、図１１におけ
るデータベース定義情報格納領域６０中のデータベース
分割管理表６５からデータベース格納領域名を得ること
ができる。また、各データベース格納領域を管理してい
るサーバ名はデータベース領域管理表より求めることが
できる。こうして得られた追加したデータベース格納領
域への移動対象となるハッシュバケット要素番号と既存
のデータベース格納領域との対応表を作成し、既存のデ
ータベース格納領域毎に移動対象ハッシュバケット要素
番号をソートするように対応表を作成しておくと処理を
既存のデータベース格納領域毎に行えるようにすること
ができる。次に、ＢＥＳ５からデータベース格納領域Ｄ
ＢＡＲＥＡ１からＤＢＡＲＥＡ４までを管理しているＢ
ＥＳ１からＢＥＳ４に対して、移動対象となるハッシュ
バケット要素番号とデータベース格納領域を入力情報と
し移動対象セグメント抽出処理要求を送信する（ステッ
プ４４４）。移動対象セグメント抽出処理要求の電文を
受信した各ＢＥＳでのデータ抽出処理の処理の流れを図
１３に示す。ＢＥＳ１からＢＥＳ４までが、当該電文を
受信する（ステップ４６１）。各ＢＥＳでは、電文の内
容を解析し、再配置におけるデータ抽出対象となったデ
ータベース格納領域とハッシュバケット要素番号の組合
せで抽出処理を開始する。例えば、ＢＥＳ１においては
データベース格納領域ＤＢＡＲＥＡ１ ５０ａから処理
を開始する。図１２を用いながら説明する。データベー
ス格納領域「ＤＢＡＲＥＡ１」５０ａからは、ハッシュ
バケット要素番号０から２５５までの５分の１であるハ
ッシュバケット要素番号２０４から２５５までが移動対
象となり、図１２におけるデータベース格納領域「ＤＢ
ＡＲＥＡ１」５０ａ中のセグメントハッシュマップ表５
１ａを参照し、ハッシュバケット要素番号２０４から順
番に２５５までのセグメント先頭番号を取出しながら、
ページビットマップ表５３ａ中のセグメント管理テーブ
ルのチェインを辿りながらセグメント５４ａをセグメン
ト入力バッファ４５ａに読み込む（ステップ４６２）。
そして、当該データベース格納領域からの移動対象セグ
メントすべてを読み込んだか否かをチェックし（ステッ
プ４６３）、検索終了でない場合はデータ抽出処理要求
を送信したＢＥＳ５に対して、セグメント入力バッファ
４５ａからハッシュバケット要素番号とともに送信を行
う（ステップ４６４）。ＢＥＳ１から送信されたデータ
は、ＢＥＳ５において各ＢＥＳからのデータ受信処理に
て受信する（図１３のステップ４４５）。このとき、す
べてのＢＥＳからのデータ送信が終了したか否かをチェ
ックし（ステップ４４６）、データを受信した場合は、
追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅへ
の移動対象セグメントの反映処理を行う。反映処理と
は、次の手順で行われる。

【００４４】（１）セグメント単位で処理を行うので追
加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅ中の
セグメントビットマップ表５２ｅから空きビットをサー
チし、新規に１個のセグメントを確保する。

【００４５】（２）新規に当該ハッシュバケット用のセ
グメントを確保した場合は、セグメントハッシュマップ
表５３ｅの先頭セグメント先頭ポインタを更新する。さ
らに、当該ハッシュバケット用セグメント数に１を加え
る。

【００４６】（２）確保したセグメントを管理するセグ
メント管理テーブルをページビットマップ表５３ｅから
確保する。確保したセグメント管理テーブル内のページ
ビットマップは、移動前のページビットマップ内容をコ
ピーすればよい。このとき、当該ハッシュバケット用の
セグメントがすでに割り当てられている場合はセグメン
ト管理テーブルの最後尾に当該テーブルをチェインさせ
る。

【００４７】（３）確保したセグメントに対してセグメ
ント出力バッファ４３ａから書きこむ。

【００４８】本データ受信処理は、各ＢＥＳからデータ
を受信できるようにセグメント出力バッファ４６ａから
４６ｄまでが用意される。１回のデータ受信処理が終了
する毎に受信したセグメントの反映処理が完了したこと
を送信先に通知する（ステップ４４８）。これに対し
て、ＢＥＳ１では図１４のステップ４６５によりセグメ
ント反映完了通知の受信処理によって、通知を受け取
る。セグメント反映完了通知を受信すると、移動したセ
グメントの削除処理を行う（ステップ４６６）。移動完
了したセグメントの削除処理は、次の手順で行われる。

【００４９】（１）セグメントハッシュマップ表５１ａ
の該当ハッシュバケット要素番号のセグメント先頭ポイ
ンタを参照し、ページビットマップ表５３ａのセグメン
ト管理テーブルをＮＥＸＴポインタを辿りながら、セグ
メントビットマップ表５２ａ内の該当セグメントのビッ
トを空きビットに更新する。

【００５０】（２）該当ハッシュバケットのすべてのセ
グメントについてセグメントビットマップ表５２ａのビ
ットを空きビットに更新したら、セグメントハッシュマ
ップ表内の該当ハッシュバケット要素番号のセグメント
数を０に更新する（ステップ４６７）。

【００５１】以上の手順でデータ抽出側のＢＥＳは、ス
テップ４６２から４６７までを繰返し、すべての移動対
象セグメントの送信が完了した場合（ステップ４６
３）、当該ＢＥＳからのデータ送信が終了したことをＢ
ＥＳ５に通知する（ステップ４６８）。

【００５２】一方、ＢＥＳ５においてもステップ４４５
から４４８までを繰返し、ＢＥＳ１からＢＥＳ４までの
すべてのＢＥＳからデータ送信完了通知を受け取ったら
（ステップ４４６）、ＤＩＣのデータベース定義情報を
更新する（ステップ４４９）。更新する内容は、追加し
たデータベース格納領域の情報をデータベース領域管理
表６１およびデータベース格納領域構成ファイル菅表に
追加し、「ＺＡＩＫＯ」表に追加したデータベース格納
領域の情報として、データベース管理表６３の分割数を
５に更新し、データベース分割管理表６５には追加した
データベース格納領域「ＤＢＡＲＥＡ５」及び番号とし
て４の情報を追加することである。

【００５３】以上のように並列データベースシステムに
おいても、各ＢＥＳの各既存のデータベース格納領域か
ら１レコードずつデータを読み込む必要がなく、セグメ
ント単位で読み込み、追加したデータベース格納領域を
管理するＢＥＳにセグメント単位で転送し、書き込み処
理を行えばよい。また、移動対象でないハッシュバケッ
トは一切、読み込む必要がない。

【００５４】次に本発明に係るデータベースの分割方法
の第２の実施例を図１５および図１６を用いて説明す
る。

【００５５】図１５は、表の第１の分割方法としてキー
・レンジ分割を行い、さらに各キー・レンジで分割され
たパーティションをハッシュ分割している様子を示す。
先述した「ＺＡＩＫＯ」表を例にとり、その分割方法を
変更したものである。このときの、データベース定義情
報格納領域内の管理情報を図１６に示す。図１１に示し
たデータベース定義情報格納領域の管理情報との相違点
は、データベース管理表６３及びデータベース分割管理
表６５である。「ＺＡＩＫＯ」表の表の定義として、
「ＳＣＯＤＥ」列に対してキーレンジ分割する際の分割
条件が与えられ、さらに「ＳＣＯＤＥ」列または別の列
でもよいがハッシュ分割することが与えられたとする。
データベース管理表６３には、分割方法としてキーレン
ジ分割であることを示す「ＲＡＮＧＥ」という値が保持
され、第１のパーティショニングキーとして「ＳＣＯＤ
Ｅ」列であることを示すための列番号である１、第２の
サブパーティショニングキーとして「ＳＣＯＤＥ」列で
あることを示すための列番号である１が保持される。そ
して、データベース分割管理表６５には、第１のパーテ
ィションに対応するデータベース格納領域の通番と第２
のサブパーティションに対応するデータベース格納領域
の通番が保持され、各々の分割条件が保持されることを
示す。例えば、分割条件が「Ｃ１＞１００」の場合、デ
ータベース格納領域の通番は０で、そのパーティション
内にデータベース格納領域として「ＤＢＡＲＥＡ１
１」、「ＤＢＡＲＥＡ１２」、「ＤＢＡＲＥＡ１３」が
指定され、さらにハッシュ関数によって各々サブ番号と
して０、１、２と割り当てられる。これは、単に第１の
分割条件がハッシュ分割であった場合と同様に考えるこ
とができる。したがって、第１のパーティション内をあ
らかじめハッシュバケットに分割しておけば、各パーテ
ィションに対してデータベース格納領域を追加する場
合、各パーティション内の分割数に対応させたハッシュ
マップ表を選択すればよいことになる。

【００５６】以上、説明したように本実施例によれば、
データベースのデータをあらかじめ固定された複数のハ
ッシュバケットに分割し、かつ、データベース格納領域
内で物理的に独立したセグメントにハッシュバケットを
格納するので、新規に追加したデータベース格納領域に
対するデータの再配置処理時に移動対象のハッシュバケ
ットのデータのみを再配置対象とすることができる。

【００５７】また、再配置処理によって移動したセグメ
ントは開放されるので、他のハッシュバケットの格納セ
グメントとして再利用が可能となり、データベース格納
領域の空きに無駄がない。

【００５８】

【発明の効果】以上、説明したように本発明によれば、
データベースのデータをあらかじめ固定された複数のハ
ッシュバケットに分割し、かつ、データベース格納領域
内で物理的に独立したセグメントにハッシュバケットを
格納するので、新規に追加したデータベース格納領域に
対するデータの再配置処理時に移動対象のハッシュバケ
ットのデータのみを再配置対象とすることができる。

【図面の簡単な説明】

【図１】本発明の特長となるデータベース格納領域の構
成を示す。

【図２】本発明を実施するためのデータベース管理シス
テムの構成図を示す。

【図３】データベース定義情報を管理する表の情報を示
す。

【図４】本発明の特徴となるハッシュマップ表を示す。

【図５】本実施例に係る表へのデータの挿入処理の概略
フローを示す。

【図６】本実施例に係るセグメントマップ表とページビ
ットマップ表との関連を示す。

【図７】本実施例に係る表の検索処理の概略処理フロー
を示す。

【図８】本発明によるデータベース再配置処理の概略処
理フローを示す。

【図９】本発明によるデータベース再配置処理のデータ
の流れを示す。

【図１０】本発明を実施するための並列データベースシ
ステムの構成図を示す。

【図１１】並列データベースシステムにおけるデータベ
ース定義情報を管理する表の情報を示す。

【図１２】並列データベースシステムにおけるデータベ
ース再配置処理のデータの流れを示す。

【図１３】本発明によるデータベース再配置のデータ受
信処理の概略処理フローを示す。

【図１４】本発明によるデータベース再配置のデータ送
信処理の概略処理フローを示す。

【図１５】本発明によるキーレンジ分割した場合の表の
例を示す。

【図１６】キーレンジ分割した表のデータベース定義情
報を管理する表の情報を示す。

【符号の説明】

１０：コンピュータシステム、１２：ＣＰＵ、１４：主
記憶装置、２０：外部記憶装置、３０：端末、４０：デ
ータベース管理システム、５０：データベース格納領
域、５１：セグメントハッシュマップ表、５２：セグメ
ントビットマップ表、５３：ページビットマップ表、５
４：セグメント、６１：データベース格納領域管理表、
６２：データベース格納領域構成管理表、６３：データ
ベース管理表、６４：データベース構成列管理表、６
５：データベース分割管理表、６６：ハッシュマップ
表、６０：データベース定義情報格納領域、７０：デー
タベースログ格納領域。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 星野 隆一 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 笠尾 英明 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウェアエンジニアリング株式会 社内 Ｆターム(参考） 5B075 NK45 NR03 5B082 BA09 CA11 EA01 EA02

Claims (7)

【特許請求の範囲】
1. 【請求項１】一つ又は複数の外部記憶装置から構成され
   るデータベース格納領域を管理し、前記データベース格
   納領域は物理的に固定長の複数のページから構成される
   複数のセグメントを管理するデータベース管理方法にお
   いて、 データベースの格納領域としてｍ個のデータベース格納
   領域が与えられた場合、 前記データベースの一つ又は複数のデータ項目をパーテ
   ィショニングキーとし、前記データベースを前記パーテ
   ィショニングキーに対してハッシュ関数を適用し、ｎ
   （ｍ≦ｎ）個の論理的な単位であるバケットに分割し、 前記与えられたデータベース格納領域数に応じて各バケ
   ットを管理するデータベース格納領域の対応を決定する
   ハッシュマップ表と、 前記分配されたバケットを各データベース格納領域内の
   格納単位であるセグメントとマッピングさせるためのセ
   グメントハッシュマップ表によってデータベースを管理
   することを特徴とするデータベース管理方法。
2. 【請求項２】請求項１記載のデータベース管理方法にお
   いて、 パーティショニングキーに対してキーレンジ分割が指定
   された場合、 前記各キーレンジに対してデータベース格納領域が与え
   られる場合、前記パーティショニングキーと同じデータ
   項目又は前記パーティショニングキーとは異なるデータ
   項目を第２のパーティショニングキーとして、データベ
   ースを前記第２のパーティショニングキーに対してハッ
   シュ関数を適用し、ｎ個の論理的な単位であるバケット
   に分割し、 前記バケットを各データベース格納領域内の格納単位で
   あるセグメントとマッピングさせるためのセグメントハ
   ッシュマップ表によってデータベースを管理することを
   特徴とするデータベース管理方法。
3. 【請求項３】請求項１記載のデータベース管理方法にお
   いて、 データベース格納領域の追加が要求された場合、全バケ
   ット数を既存のデータベース格納領域と追加したデータ
   ベース格納領域を加えた全データベース格納領域数で均
   等にバケットを分けた場合の各データベース格納領域の
   バケット数を基に、 既存の各データベース領域から前記バケット数より多い
   バケットを選択し、選択されたバケットを前記追加した
   データベース格納領域の前記バケット数を満たすように
   再配置するようハッシュマップ表を更新し、 前記各データベース領域から移動対象に選択されたバケ
   ットを前記セグメントハッシュマップ表を参照し、セグ
   メント単位で追加したデータベース格納領域に転送し、 前記追加したデータベース領域にデータ転送が完了する
   と前記転送したデータベース格納領域中の転送したセグ
   メント群を削除することを特徴とするデータベース管理
   方法。
4. 【請求項４】請求項１記載のデータベース管理方法にお
   いて、 ハッシュ関数によって分割するバケット数をユーザの指
   定によって設定できることを特徴とするデータベース管
   理方法。
5. 【請求項５】請求項３のデータベース管理方法におい
   て、 データベース格納領域の追加によってデータの再配置が
   行われた場合、データ転送が完了したセグメント群を削
   除する場合、前記セグメントのコピーを更新前ログとし
   て取得することなく、前記データベース格納領域中のセ
   グメントを管理するセグメントビットマップ表に対して
   前記削除セグメントのビットを空き状態に書き換え、当
   該ビットの更新前状態及び更新後状態を更新ログとして
   取得し、 データの再配置が完了する前に障害によって失敗した場
   合、前記削除セグメントに対する更新前ログを前記セグ
   メントビットマップ表に書き戻すことによって回復する
   ことを特徴とするデータベース管理方法。
6. 【請求項６】請求項１記載のデータベース管理方法にお
   いて、 データベース格納領域の追加が要求された場合、既存の
   各データベース格納領域内に含まれるハッシュバケット
   のセグメント数の合計を算出し、既存のすべてのデータ
   ベース格納領域の平均セグメント数を算出し、追加した
   データベース格納領域数を含めた全データベース格納領
   域数で平均セグメント数を算出することによって、 前記算出した既存のすべてのデータベース格納領域の平
   均セグメント数と前記追加したデータベース格納領域数
   を含めた全データベース格納領域数で平均セグメント数
   の差分を算出し、前記算出した差分のセグメント数に近
   似させるように前記各既存のデータベース格納領域から
   ハッシュバケットを追加したデータベース格納領域にデ
   ータを再配置することによって、再配置の対象となった
   ハッシュバケットによってハッシュマップ表を更新する
   ことを特徴とするデータベース管理方法。
7. 【請求項７】請求項２記載のデータベース管理方法にお
   いて、 あるキーレンジ・パーティションに対してデータベース
   格納領域の追加が要求された場合、前記キーレンジ・パ
   ーティション内の全バケット数を前記キーレンジ・パー
   ティション内の既存のデータベース格納領域と追加した
   データベース格納領域を加えた全データベース格納領域
   数で均等にバケットを分けた場合の書くデータベース格
   納領域数を基に、 既存の各データベース領域かた前記バケット数より多い
   バケットを選択し、選択されたバケットを千期追加した
   データベース格納領域の前記バケット数を満たすように
   再配置するようハッシュマップ表を更新し、 前記各データベース領域から移動対象に選択されたバケ
   ットを前記セグメントハッシュマップ表を参照し、セグ
   メント単位で追加したデータベース格納領域に転送し、 前記追加したデータベース領域にデータ転送が完了する
   と前記転送したデータベース格納領域中の転送したセグ
   メント群を削除することを特徴とするデータベース管理
   方法。