JPH0778118A - 資源競合回避スケジューリング方法 - Google Patents

Abstract

(57)【要約】 【目的】 オンライントランザクション処理（ＯＬＴ
Ｐ）とバッチ処理との競合を回避するようスケジュール
し、高速な問合せ処理を実現することにある。 【構成】 問合せがＯＬＴＰに属するかバッチ処理（Ｂ
Ｐ）に属するかを判定しておき、ＢＰ問合せ１００を投
入するＢＰ問合せ投入時間とＯＬＴＰ問合せ１０２を投
入するＯＬＴＰ問合せ投入時間からなるオンライントラ
ンザクション／バッチ処理投入間隔１０３を設定し、該
投入間隔における前記ＢＰ問合せ投入時間と前記ＯＬＴ
Ｐ問合せ投入時間の割合を設定し、前記ＢＰ問合せ投入
時間にはＢＰ問合せ１００の実行のみを行ない、ＯＬＴ
Ｐ問合せ１０１の実行は待機させ、前記ＯＬＴＰ問合せ
投入時間にはＯＬＴＰ問合せ１０２の実行のみを行なう
ようにスケジュールしている。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、デ−タベ−ス処理装置
に関し、特にリレ−ショナルデ−タベ−ス管理システム
に適した問合せの並列処理に好適な問合せ処理方法に関
する。

【０００２】

【従来の技術】デ−タベ−ス管理システム（以下ＤＢＭ
Ｓと略記）、特にリレ−ショナルＤＢＭＳは、非手続き
的な言語で表現された問合せを処理して、内部処理手順
を決定し、実行する。このデータベース言語としてＳＱ
Ｌが用いられる（Ｄａｔａｂａｓｅ Ｌａｎｇｕａｇｅ
ＳＱＬ ＩＳＯ ９０７５：１９８９）。従来の問合
せ処理の主な方法には、予め設定した規則に基づいて単
一の内部処理手順を決定するものと、各種統計情報を用
いて選定された複数の候補処理手順から、コスト評価に
より、最適と思われるものを決定するものとがある。前
者は、処理手順作成のための負荷は小さいけれども、一
律に設定された規則の妥当性に問題があり、選ばれた内
部処理手順の最適性にも問題がある。後者は、各種統計
情報の管理と、複数の候補処理手順の作成及びそれらの
コスト評価のための負荷があるものの、最適な処理手順
を与える。上記両者の組合せ技術として、例えば、Ｓａ
ｔｏｈ，Ｋ．，ｅｔ．ａｌ．“Ｌｏｃａｌ ａｎｄ Ｇ
ｌｏｂａｌ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｍｅｃｈａｎ
ｉｓｍｓ ｆｏｒ Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂ
ａｓｅ”， Ｐｒｏｃ．ＶＬＤＢ， １９８５．があ
る。また、多くのＤＢＭＳは、問合せ解析処理と問合せ
実行処理の２フェーズの処理を経て、問合せ処理が実現
される。ホスト言語（ＣＯＢＯＬ、ＰＬ／Ｉ等）に問合
せ言語を組み込む場合、当アプリケ−ションプログラム
実行前に予め問合せを問合せ解析処理し、実行形式であ
る１つの内部処理手順を作成している。この問合せ表現
では、多くの場合検索条件式にはホスト言語の変数が記
述される。この変数に定数が代入されるのは、既に問合
せ解析処理された結果の内部処理手順の実行時、すなわ
ち問合せ実行時である。この場合の問題点としては、変
数に代入される値に従って複数の最適な処理手順が考え
られることである。この問題を解決するために、プロプ
ロセス処理時に複数の処理手順を作成しておき、問合せ
実行時に変数に代入された値に従って処理手順を選択す
るものがある（特開平１−１９４０２８、Ｇｒａｅｆ
ｅ，Ｇ．，ｅｔ．ａｌ．”Ｄｙｎａｍｉｃ Ｑｕｅｒｙ
Ｅｖａｌｕａｔｉｏｎ Ｐｌａｎｓ”， Ｐｒｏｃ．
ＡＣＭ−ＳＩＧＭＯＤ， １９８９．）。

【０００３】さらに、ＣＰＵ性能、ディスク容量の延び
を上回るトランザクション量、データベース量増大に対
応して、スケーラブルな並列データベースシステムのユ
ーザ要件が強まっている。データベースシステムに対す
るユーザの性能要件として、数万を超える同時実行ユー
ザ数への対応、テラバイト単位の検索トランザクション
の出現、表サイズに比例しない応答時間の保証がある。
並列データベースシステムは、近年のハードウェアコス
トの低減と相まって、注目を浴びている（ＤｅＷｉｔ
ｔ，Ｄ．，ｅｔ．ａｌ．：”ＰａｒａｌｌｅｌＤａｔａ
ｂａｓｅ Ｓｙｓｔｅｍｓ： Ｔｈｅ Ｆｕｔｕｒｅ
ｏｆ ＨｉｇｈＰｅｒｆｏｒｍａｎｃｅ Ｄａｔａｂａ
ｓｅ Ｓｙｓｔｅｍｓ”， ＣＡＣＭ， Ｖｏｌ．３
５， Ｎｏ．６， １９９２．）。そのようなシステム
では密結合あるいは疎結合にプロセッサを接続し、デー
タベース処理を複数のプロセッサに静的／動的に処理を
配分し、スケジュールする必要がある。並列度を増せば
応答性能は向上するが、過度の並列度は逆にオーバヘッ
ドの増大、他トランザクションの応答時間の延び等の影
響がある。そのため、適度な並列度の設定が重要であ
る。一般的に、デ−タベ−ス処理において、処理対象と
なるデ−タは二次記憶装置上に存在し、各デ−タベ−ス
演算に対して大量デ−タの読み出し及び転送が必要とな
る。並列デ−タベ−スシステムにおいても、データベー
スが各プロセッサに分割格納され、転送するデ−タが大
量となる場合、デ−タ転送時間がデ−タベ−スシステム
の性能ネックとなる。そこで、二次記憶装置からデ−タ
を転送する時間を有効活用する方法が考えられる。これ
は、デ−タの転送時間と当該デ−タに対するデ−タベ−
ス処理に要する時間とをオ−バラップさせるものであ
り、従来技術として良く知られている。この方式を相互
結合ネットワークで接続されるプロセッサ群間のデータ
転送にも適用可能である。ここで、デ−タベ−スはユ−
ザから２次元のテ−ブル形式で見られる表から成るもの
とし、当該表の行あるいはロウとするものである。ま
た、ロウは、１つ以上の属性（これを「カラム」とい
う）からなる。

【０００４】

【発明が解決しようとする課題】上記従来技術は、問合
せ最適化処理とはユ−ザが入力した問合せから、デ−タ
ベ−スシステムの各種統計情報を基にして、最も効率の
良い処理手順をＤＢＭＳが自動判定するものである。さ
らに、問合せの選択条件式に変数が埋め込まれている場
合には、複数の処理手順を問合せ解析時に展開してお
き、問合せ実行時に当変数に代入される値に従って処理
手順を選択することによって、最適な処理手順が選択さ
れる。ユーザにおける主要業務は、オンライントランザ
クション処理（以下、ＯＬＴＰと略記する）とバッチ処
理に分類できる。従来までＯＬＴＰは、基幹ＤＢの最新
情報をアクセスし、オンライン情報を提供する。１トラ
ンザクションで多くとも十数問合せを含み、各問合せで
１〜数件のロウをアクセスするため、ロック資源は少な
くてすむが、スループットが重視される。バッチ処理
は、多くの場合単一の問合せでも大量データをアクセス
し、更新あるいは集計情報を出力する。バッチ処理は、
ロック資源を大量に取得し、処理する必要がある。バッ
チ処理で、ＯＬＴＰがアクセス対象とする基幹ＤＢを競
合してアクセスすると、バッチ処理のロック占有時間が
長いために、ＯＬＴＰがロック競合の多発によりスルー
プットが大幅に低下する。そのため、ＯＬＴＰとバッチ
処理は競合がなくなるように運用している。すなわち、
バッチ処理で、検索バッチ処理はノーロックモード（ロ
ックを取得しないで、バッチ処理を実行するため、最新
ＤＢではなく、汚れ読みとなる。すなわち、ノーロック
モードでは、ロックがされて更新が行なわれたページも
読み取るため、更新されたページがコミット（更新内容
をデータベースに反映させるためディスクに格納する）
されれば問題ないが、更新されたページがロールバック
（コミットすることなく破棄する）された場合にはデー
タベースに反映されない情報を読み取ることにな
る。）、更新バッチ処理はＯＬＴＰと運用時間帯を分け
るか２つのＤＢシステムを構築して日、週、月遅れでＤ
Ｂを反映することで対処してきた。そのため、最新のＤ
Ｂ情報が取得できない問題があった。並列データベース
処理では、各ノード（プロセッサあるいはプロセッサと
ディスク装置との対）へデータベース演算が分割され、
各ノードで各データベース演算が並列にあるいはパイプ
ライン的に動作する。従来技術によれば、ＯＬＴＰとバ
ッチ処理で発行される問合せに区別なく処理が行われる
ため、上記問題が発生する。そこで、本発明では、ＯＬ
ＴＰとバッチ処理が共存する場合、ＯＬＴＰをグループ
化することによって、バッチ処理との競合を回避する。
また、ＯＬＴＰの応答性能をＯＬＴＰグループとバッチ
処理の投入間隔時間で保証する。さらに、ユーザから投
入されたＯＬＴＰ及びバッチ処理の要求資源の範囲を推
定する。本発明の目的は、ＯＬＴＰとバッチ処理に対応
したスケジューリングを適用し、バッチ処理との競合を
回避することにより、高速な問合せ処理を実現すること
にある。

【０００５】

【課題を解決するための手段】上記目的を達成するた
め、データベースに対するユーザからの問合せを解析し
て対応する処理手順を決定し、それを実行し、複数のプ
ロセッサノードがネットワークにより接続され、各プロ
セッサノードが、ユーザからの問合せの解析、最適化、
処理手順作成を実行するフロントエンドサーバ機能と、
前記処理手順を基にしてデータベースをアクセスするバ
ックエンドサーバ機能と、データベースシステムの定義
情報を一括管理するディクショナリサーバ機能と、デー
タベース更新履歴情報を格納、管理するジャーナルサー
バ機能を備える並列データベースシステムにおいて、各
ノードで実行される処理手順を問合せ解析時あるいは問
合せ実行時に作成しておき、問合せ実行時に各ノードで
実行する処理手順を決定し、前記問合せがオンライント
ランザクション処理（ＯＬＴＰ）に属するかバッチ処理
（ＢＰ）に属するか判定し、ＢＰ問合せ投入時間とＯＬ
ＴＰ問合せ投入時間からなるオンライントランザクショ
ン／バッチ処理投入間隔を設定し、該投入間隔における
前記ＢＰ問合せ投入時間と前記ＯＬＴＰ問合せ投入時間
の割合を設定し、前記ＢＰ問合せ投入時間にはＢＰ問合
せの実行のみを行ない、ＯＬＴＰ問合せの実行は待機さ
せ、前記ＯＬＴＰ問合せ投入時間にはＯＬＴＰ問合せの
実行のみを行なうようにしている。さらに、前記問合せ
がＯＬＴＰに属するかＢＰに属するかの判定を、問合せ
でアクセスするページ数、獲得ロック資源数、ヒットロ
ウ数等に基づく所定の閾値により行ない、ＯＬＴＰ問合
せの実行中にも該ＯＬＴＰ問合せに対して前記判定を行
ない、前記所定の閾値を超えた場合、該ＯＬＴＰ問合せ
をＢＰ問合せとするようにしている。また、前記並列デ
ータベースシステムにおいて、ＢＰ問合せにおいては、
第１のプロセッサノード群には読みだし対象となるデー
タベースが格納され、データ読みだし処理、データ分割
処理を実行し、第２のプロセッサノード群では結合処理
のための部分列ソート処理、完全列作成処理、突き合わ
せ処理を実行し、第３のプロセッサノード群ではＢＰ問
合せで要求したデータの受け取り処理を実行し、ＯＬＴ
Ｐ問合せにおいては、第１のプロセッサノード群には読
みだし対象となるデータベースが格納され、データ読み
だし処理を実行し、第３のプロセッサノード群ではＯＬ
ＴＰ問合せで要求したデータの受け取り処理を実行する
場合、デ−タベ−スに対するユ−ザからの問合せを解析
して対応する内部処理手順を決定し、問合せ解析処理時
あるいは問合せ実行処理時に入力された問合せの解析結
果とデ−タベ−スシステムの最適化情報とから単一ある
いは複数の内部処理手順を選定、格納する過程と、各ノ
ード単位で実行される単一あるいは複数の処理手順を問
合せ実行処理時に選択する過程と、該処理手順を実行す
る過程と、稼働中のシステムでＯＬＴＰ問合せとＢＰ問
合せが競合している場合には、前記選択する過程は、複
数の処理手順からなる問合せが前記第２のプロセッサノ
ード群を利用する内部処理手順を優先的に選択する過程
を含むようにしている。

【０００６】

【作用】上記手段を取ることにより、オンライントラン
ザクション／バッチ処理投入間隔内で一定時間ＢＰ問合
せが実行され、残りの時間ＯＬＴＰ問合せが実行され、
投入間隔毎にＢＰ問合せとＯＬＴＰ問合せが確実に実行
され、ＯＬＴＰの応答性能が保証される。また、ＢＰ問
合せ投入時間にはＢＰ問合せの実行のみを行ない、ＯＬ
ＴＰ問合せの実行は待機させ、前記ＯＬＴＰ問合せ投入
時間にはＯＬＴＰ問合せの実行のみが行なわれるので、
ＢＰ問合せとＯＬＴＰ問合せの競合を回避することがで
きる。また、稼働中のシステムでＯＬＴＰ問合せとＢＰ
問合せが競合している場合には、ＢＰ問合せとなる可能
性が非常に高い複数の処理手順からなる問合せが前記第
２のプロセッサノード群を利用する内部処理手順を優先
的に選択するようにしているため、ＢＰ問合せとＯＬＴ
Ｐ問合せの競合を回避することができる。

【０００７】

【実施例】以下、本発明の実施例を図面に基づいて詳細
に説明する。図１は、本発明の一実施例が適用された並
列デ−タベ−スシステムの実行例を説明する図である。
本発明の好適な一実施例であるが、後述することにす
る。図２は、従来のデ−タベ−スシステムの一実現例で
ある。デ−タベ−スシステムは、ユ−ザが作成したアプ
リケ−ションプログラム（以下、ＡＰと略記する）１
０、１１と、問合せ処理、リソ−ス管理等デ−タベ−ス
システム全体の管理を行うＤＢＭＳ２０と、デ−タベ−
ス処理において、入出力処理対象となるデ−タの読書き
を行い、計算機システム全体の管理を受け持つオペレ−
ティングシステム（以下では、オペレ−ティングシステ
ムをＯＳと略記する）３０と、デ−タベ−ス処理対象と
なるデ−タを格納するデ−タベ−ス４０と、データベー
スの定義情報を管理するディクショナリ５０と、データ
ベースの更新履歴情報を管理するジャーナル６０から構
成される。ＤＢＭＳ２０は、他データベース管理システ
ムと接続されている。上記ＤＢＭＳ２０は、システム全
体の管理、制御に加えて、入出力の管理等を行うシステ
ム制御部２１と、問合せの構文解析、意味解析を行う問
合せ解析２２０、適切な処理手順を生成する静的最適化
処理２２１、及び処理手順に対応したコ−ドの生成を行
なうコード生成２２２、静的最適化処理２２１で生成さ
れた処理手順候補から最適なものを選択する動的最適化
処理２２３、当コードの解釈実行を行うコード解釈実行
部２２４から成る論理処理部２２と、当ＤＢＭＳ２０で
処理対象となるデータを格納するデータベース／ディク
ショナリ／ジャーナルバッファ２４と、アクセスしたデ
−タの条件判定、編集、レコード追加等を実現するデ−
タアクセス処理２３０、データベースレコ−ドの読み書
き等を制御するデ−タベ−ス／ディクショナリ／ジャー
ナルバッファ制御２３１、入出力対象となるデ−タの格
納位置を管理するマッピング処理２３２、及びシステム
で共用するリソースの排他制御を実現する排他制御２３
３とから成るデータベースの物理処理を実行する物理処
理部２３とから構成されている。

【０００８】図３、４、５、６は、本発明が適用される
並列デ−タベ−スシステムの一実現例である。後述する
ように複数のプロセッサノードが高速ネットワークによ
り接続し、各ノードは少なくとも１台のＣＰＵと少なく
とも１台のディスク装置とから構成されか、少なくとも
１台のＣＰＵから構成され、各ノードにはデータベース
に対する問合せ要求を処理するためのプログラムが実装
されるものとする。各ノードは、以下の機能が実装され
る。図３は、ユーザからの問合せの解析、最適化、処理
手順作成を実行するフロントエンドサーバ（以下、ＦＥ
Ｓと略記）機能である。図４は、格納されたデータベー
スをＦＥＳで作成された処理手順を基にしてデータベー
スをアクセスするバックエンドサーバ（以下、ＢＥＳと
略記）機能である。図５は、データベースシステムの定
義情報を一括管理するディクショナリサーバ（以下、Ｄ
Ｓと略記）機能である。図６は、各ノードで実行される
データベース更新履歴情報を格納、管理するジャーナル
サーバ（以下、ＪＳと略記）機能である。基本的に、各
ノードで実現される機能は、図２で述べた従来のデータ
ベースシステムの実現機能と同等のものである。

【０００９】ただし、図３に示すフロントエンドサーバ
機能においては、システム全体の管理、制御を行うシス
テム制御部２１に、各ノードで実行される問合せのスケ
ジューリングを行うスケジューリング処理２１０、そし
て、オンライントランザクション処理（ＯＬＴＰ）とバ
ッチ処理（ＢＰ）の投入時間を監視する投入時間監視処
理が実現される。また、図４に示すバックエンドサーバ
機能においてはシステム全体の管理、制御を行うシステ
ム制御部２１に、各ノードで実行される問合せのスケジ
ューリングを行うスケジューリング処理２１０が実現さ
れる。

【００１０】図７は、本発明が適用されるハードウェア
構成の一例を示すものである。具体的には、図７は、プ
ロセッサ及びディスク装置がノードを構成する並列プロ
セッサシステムでの適用例である。図７は、プロセッサ
６１〜６６及びディスク装置７０〜７５が相互結合ネッ
トワーク８０で接続される。また、プロセッサ６５に示
すように、他システムと接続されてもよい。図８、９
は、本発明が適用された並列データベースシステムの処
理例を示す。問合せは、ＯＬＴＰ問合せとＢＰ問合せに
分類できる。ＯＬＴＰ問合せは、インデクス経由の数件
までのロウアクセスと特徴付けられる。また、ＢＰ問合
せは、結合処理、集計グループ化処理等集合的なロウア
クセスの特徴を持つ。ＯＬＴＰ問合せの例として、以下
のような問合せが考えられる。 ＳＥＬＥＣＴ Ｔ１．Ｃ３ ＦＲＯＭ Ｔ１ ＷＨＥＲＥ Ｔ１．Ｃ１＝Ｐ（ただし、Ｃ１カラムに
インデクス有、また、Ｐは、例えば、１０などの値であ
る） 上記問合せの意味は、表１のカラムＣ１がＰ（例えば、
１０）の値を取るときの表１のカラムＣ３の値を求め
よ、ということである。ノード１（９０）からノード４
（９１）に表Ｔ１が各々格納され、データ取り出し処理
が実行される。ノード１２（９７）では、問合せ実行時
に設定される変数値に従ってノード１〜４のいずれのノ
ードに検索対象となるデータが格納されるか決定する。
これらのノード群は、相互結合ネットワーク８０で接続
される。ＢＰ処理の例では、データベースに対する検索
要求に並列処理を適用する。この処理のためのＢＰ問合
せは、以下のようになる。 ＳＥＬＥＣＴ Ｔ１．Ｃ３，Ｔ２．Ｃ３ ＦＲＯＭ Ｔ１，Ｔ２ ＷＨＥＲＥ Ｔ１．Ｃ１＝Ｔ２．Ｃ１ ＡＮＤ Ｔ１．Ｃ２＝Ｑ（ただし、Ｑは、例えば、１
０などの値である） 上記問合せの意味は、表１のカラムＣ１の値と表２のカ
ラムＣ１の値が等しく、かつ表１のカラムＣ２の値がＱ
（例えば、１０）であるときの表１のカラムＣ３の値と
表２のカラムＣ３の値を求めよ、ということである。ス
ロットソート処理は、データが格納されるページを対象
とするページ内のソート処理を指し、スロット順に読み
だせば、昇順にロウがアクセス可能とする。Ｎウェイマ
ージ処理は、Ｎウェイのバッファを用いて、各マージ段
でＮ本のソート連を入力にして最終的に１本のソート連
を作成する。ノード１（９０）からノード４（９１）に
表Ｔ１が、ノード５（９２）からノード８（９３）に表
Ｔ２が各々格納され、データ取り出し処理及びデータ分
配処理が実行される。また、ノード９（９４）からノー
ド１１（９６）では、ノード１〜４及びノード５〜８か
ら出力されるデータを受け取り、ソート処理及び結合処
理を実行する。さらに、ノード１２（９７）では、ノー
ド９〜１１から出力される結果のデータを受け取る。こ
れらのノード群は、相互結合ネットワーク８０で接続さ
れ、ノード１〜４及びノード５〜８とノード９〜１１と
が並列に、しかもパイプライン的に動作する（以下、並
列パイプライン動作と呼ぶ）。また、ノード９〜１１と
ノード１２とも同様にパイプライン動作する。

【００１１】また、各ノードで実行される処理手順は非
同期に実行され、各ノードの各処理手順を実行するに当
って、各ノードの処理手順でアクセスするデータベース
の各分割格納単位毎にすべて読み終えた、あるいは他の
ノード群からの入力がない等の判断で各ノードの処理手
順の実行を制御し、ＢＰ問合せの各ノード間でのデータ
転送時、当該単一のトランザクションのデータからなる
ページ情報を転送し、ＯＬＴＰ問合せの各ノード間での
データ転送時、当該複数のトランザクションのデータか
らなるページ情報をページ満杯あるいは一定時間間隔Ｉ
のタイミングで転送する。

【００１２】図１は、本発明の一実施例を説明する図で
あり、図８のＯＬＴＰ問合せと図９のＢＰ問合せが混在
した実行例である。また、図１０は、従来のデータベー
スシステムでのＯＬＴＰ問合せとＢＰ問合せが混在した
実行例である。図１、１０は、ｘ軸が時刻、ｙ軸が各ノ
ードに格納されるデータベース資源としての表であるこ
とを示す。具体的には、１００は、図９のＢＰ問合せの
実行例、１０１は、ＢＰ問合せ１００が実行中に投入さ
れた図８のＯＬＴＰ問合せ群、１０２は、ＢＰ問合せ１
００が終了後に投入されたＯＬＴＰ問合せ群、１０３
は、オンライントランザクション／バッチ処理投入間隔
の時間、１０４は、従来のデータベースシステムでのＢ
Ｐ問合せの実行例である。

【００１３】図１０は、ＢＰ問合せ１０４の実行中にＯ
ＬＴＰ問合せ１０１が投入された状況を示す。ＢＰ問合
せ１０４の実行のためにロック資源が既に獲得されてい
るために、ＯＬＴＰ問合せ１０１が投入されても実行で
きずにＢＰ問合せ１０４の終了を待つ必要がある。その
ため、ＯＬＴＰ問合せ１０１が投入された時刻で実行さ
れずに、結果的に１０２の時点で実行されることにな
る。図１は、本発明の一実施例を説明する図であり、並
列デ−タベ−スシステムにおける実行例を説明する図で
ある。本発明の実施例では、オンライントランザクショ
ン／バッチ処理投入間隔１０３を設定し、この間隔１０
３内でＢＰ問合せに対して或る投入時間を割り当て、残
りの投入時間をＯＬＴＰ問合せに割り当てる。この投入
間隔１０３でのＢＰ問合せ処理とＯＬＴＰ問合せ処理の
実行が終了すると、次の投入間隔に移り、この投入間隔
１０３でＢＰ問合せ処理とＯＬＴＰ問合せ処理が実行さ
れる。この投入間隔１０３およびこの投入間隔内でＢＰ
問合せ処理とＯＬＴＰ問合せ処理に割り当てられる時間
の割合はデータベース管理者の指定で決められる。図１
では、ＢＰ問合せ１００の実行中にＯＬＴＰ問合せ１０
１が投入された状況を示している。ＢＰ問合せ１００の
実行のためにロック資源が既に獲得されている可能性が
あるため、ＯＬＴＰ問合せ１０１を実行しない。そのた
め、ＯＬＴＰ問合せ１０１が投入された時刻で実行され
ずに、１０２の時点で実行されることになる。オンライ
ントランザクション／バッチ処理投入間隔１０３でＢＰ
問合せを投入することでＯＬＴＰ問合せへの影響を最小
化する。また、ＯＬＴＰ問合せ１０１の実行は遅れるも
のの、ＢＰ問合せ１００とＯＬＴＰ問合せ１０１とのロ
ック競合がないため、ＢＰ問合せ１００がスケジュール
した通りに終了し、さらに、１０２の時点で実行される
ＯＬＴＰ問合せもＢＰ問合せとのロック競合がない。オ
ンライントランザクション／バッチ処理投入間隔１０３
は、データベース管理者の指定で決められる。ＢＰ問合
せとＯＬＴＰ問合せを２０％、８０％の比率でスケジュ
ールすると仮定すると、オンライントランザクション／
バッチ処理投入間隔１０３の内、２０％がＢＰ問合せの
実行に費やされ、残りの８０％がＯＬＴＰ問合せの実行
に用いられる。ただし、ＯＬＴＰ問合せの最大遅れ時間
が、少なくともオンライントランザクション／バッチ処
理投入間隔１０３の２０％になるため、この遅れ時間を
考慮して投入間隔を決定する必要がある。なお、オンラ
イントランザクション／バッチ処理投入間隔１０３を設
定し、該投入間隔内でＢＰ問合せに対して投入時間が割
り当てられるので、長い処理時間を必要とするＢＰは複
数に分割されていることが望ましく、この分割はアプリ
ケーションプログラムで発行するＳＱＬを予め分割して
おくことにより可能である。もし、ＢＰ問合せ処理が上
記の投入間隔で終らなければエラーとして処理してもよ
く、また、終るまで待つようにしてもよい。

【００１４】図１１、１２、１３、１４、１５、１６、
１７、１８、１９は、本発明を適用したＤＢＭＳの処理
のフロ−チャ−トである。ＤＢＭＳは、問合せ実行前に
行われる問合せの解析処理（２２０）、静的最適化処理
（２２１）、コード生成（２２２）を実現する問合せ解
析処理４００（図１１の（ａ））と、変数に定数を代入
し、処理手順を選択する動的最適化処理（２２３）、問
合せのコード解釈実行（２２４）を実現している問合せ
実行処理４１０（図１１の（ｂ））と、各ノードで実行
する処理手順の割当て、実行情報取得、解放を行うスケ
ジューリング処理（２１０）（図１７、１８）と、オン
ライントランザクション処理（ＯＬＴＰ）とバッチ処理
（ＢＰ）の投入時間を監視する投入時間監視処理（２１
１）（図１９）からなる。

【００１５】各処理部概要について述べる。 （ａ）問合せ解析処理４００ 問合せ解析２２０……入力された問合せ文の構文解析、
意味解析を実行 静的最適化処理２２１……問合せで出現する条件式から
条件を満足するデ−タの割合を推定し、予め設定してい
る規則を基に、有効なアクセスパス候補（特にインデク
スを選出する）を作成し、処理手順の候補を作成 コード生成２２２……処理手順候補を実行形式に展開 （ｂ）問合せ実行処理４１０ 動的実行時最適化２２３……代入された定数に基づき、
各ノード群で実行する処理手順を決定 コード解釈実行２２４……当処理手順を解釈、実行 各処理部の詳細な処理フローの説明を行う。

【００１６】静的最適化処理２２１は、図１１の（ｄ）
に示すように、問合せに出現する条件式の述語選択率推
定（２２１０）、インデクス等からなるアクセスパスの
剪定（２２１１）、これらアクセスパスを組合せた処理
手順候補の生成（２２１２）からなる。述語選択率推定
２２１０では、図１１の（ｅ）に示すように、問合せ条
件式に変数が出現するか否かチェックする（２２１０
１）。変数が出現すれば、当条件式にカラム値分布情報
があるかチェックする（２２１０４）。存在すれば終了
する。存在しなければ、条件式の種別に応じてディフォ
ルト値を設定し（２２１０５）、終了する。変数が出現
しなければ、当条件式にカラム値分布情報があるかチェ
ックする（２２１０４）。存在しなければ、条件式の種
別に応じてディフォルト値を設定し（２２１０５）、終
了する。存在すれば、カラム値分布情報を用いて選択率
を算出する（２２１０３）。

【００１７】図１２はアクセスパス剪定のフローチャー
トである。アクセスパス剪定２２１１では、問合せ条件
式で出現するカラムのインデクスをアクセスパス候補と
して登録する（２２１１０）。次に、問合せでアクセス
対象となる表が複数ノードに分割格納されているかチェ
ックする（２２１１１）。分割格納されていれば、パラ
レルテーブルスキャンをアクセスパス候補として登録す
る（２２１１３）。分割格納されていなければ、テ−ブ
ルスキャンをアクセスパス候補として登録する（２２１
１３）。各条件式の選択率が既に設定済みか否かチェッ
クする（２２１１４）。設定済みであれば、各表に関し
て選択率が最小となる条件式のインデクスをアクセスパ
スの最優先度とする（２２１１５）。設定済みでなけれ
ば、各条件式の選択率の最大値／最小値を取得する（２
２１１６）。最後に、ＣＰＵ性能、ＩＯ性能等システム
特性より各アクセスパスの選択基準を算出し（２２１１
７）、単一あるいは複数のインデクスを組合せたアクセ
スパスでの選択率が上記選択基準を下回るものだけアク
セスパス候補として登録する（２２１１８）。

【００１８】図１３は処理手順候補生成のフローチャー
トである。処理手順候補生成２２１２は、問合せでアク
セス対象となる表が複数ノードに分割格納されているか
チェックする（２２１２０）。分割格納されていれば、
２２１２５へ。分割格納されていなければ、処理手順候
補にソート処理が含まれているか否かをチェックする
（２２１２１）。含まれていれば、２２１２５へ。含ま
れていなければ、問合せでアクセス対象となる表のアク
セスパスが唯一であるかチェックし（２２１２２）、唯
一であれば単一の処理手順を作成し（２２１２３）、唯
一でなければ複数の処理手順を作成し（２２１２４）、
終了する。２２１２５では、結合可能な２ウェイ結合へ
問合せを分解する。分割格納される表の格納ノード群に
対応して、データ読みだし／データ分配処理手順とスロ
ットソート処理手順を候補として登録する（２２１２
６）。結合処理ノード群に対応して、スロットソート処
理手順、Ｎウェイマージ処理手順、及び突き合わせ処理
手順を候補として登録する（２２１２７）。要求データ
出力ノードに要求データ出力処理手順を登録する（２２
１２８）。最後に、分解結果に対して評価がすべて終了
すれば（２２１２９）、終了する。

【００１９】図１４はコード生成のフローチャートであ
る。コード生成２２２は、処理手順候補が唯一か否かを
チェックする（２２２０）。唯一であれば、２２２３
へ。唯一でなければ、カラム値分布情報等からなる最適
化情報を処理手順に埋込み（２２２１）、問合せ実行時
に代入された定数に基づいて処理手順を選択するデータ
構造を作成する（２２２２）。最後に、処理手順を実行
形式へ展開する（２２２３）。上記最適化情報は、少な
くともＣＰＵ性能、ディスク性能、ネットワーク性能か
らなるシステム特性情報と、データベースで定義された
表のロウ数、ページ数、カラム値分布情報、表分割情報
からなるデータベース特性情報からなる。

【００２０】図１５は動的最適化処理のフローチャート
である。動的最適化処理２２３は、まず、問合せ開始時
であるか否か判定し、問合せ開始時でなければ処理を終
了し、問合せ開始時ならば２２３００に進む。当該問合
せでアクセスする資源（表等）の範囲を処理手順から推
定する（２２３００）。作成されている処理手順が単一
か否かをチェックする（２２３０１）。単一であれば、
ＯＬＴＰ問合せの可能性が高いので、終了する。単一で
なければ、ＢＰ問合せの可能性が高いので２２３０４以
降のステップに進む。代入された定数を基に選択率を算
出する（２２３０２）。処理手順候補に並列な処理手順
が含まれるか否かチェックする（２２３０３）。含まれ
ていなければ、アクセスパスの選択基準に従って処理手
順を選択し（２２３１０）、スケジューリング処理を呼
出し（２２３１１）、終了する。含まれていれば、ディ
クショナリから上記最適化情報を入力し（２２３０
４）、データ取り出し／データ分配のための処理時間を
各システム特性を考慮し、算出する（２２３０５）。当
処理時間から結合処理に割当てるノード数ｐを決定する
（２２３０６）。現在稼働中のシステムにおいて、当該
問合せでアクセスする表が既にＯＬＴＰ問合せとＢＰ問
合せで競合しているかチェックする（２２３０７）。競
合していれば、ＢＰ問合せの内部処理手順としてデータ
ベースが格納されていない第２のノード群を優先利用す
るよう設定する（２２３０８）。次に、データ分配情報
を最適化情報を基にして作成し（２２３０９）、２２３
１０へ。アクセスパスの選択基準に従って処理手順を選
択し（２２３１３）、スケジューリング処理を呼出し
（２２３１１）、終了する。

【００２１】図１６はコード解釈実行のフローチャート
である。コード解釈実行２２４は、選択された実行形式
の処理手順を解釈実行する（２２４０）。当該コードが
ＢＥＳで実行中であるかチェックする（２２４１）。Ｂ
ＥＳで実行中であれば、アクセスページ数、獲得したロ
ック資源数、ヒットロウ数、ロック待ち状態等を問合せ
結果のデータとともにＦＥＳへ通知する（２２４２）。
次に、スケジューリング処理を呼出し（２２４３）、終
了する。

【００２２】図１７、図１８はスケジューリング処理の
フローチャートである。スケジューリング処理２１０
は、問合せ開始時か否かチェックする（２１０００）。
問合せ開始時でなければ、２１０１６へ。問合せ開始時
であれば、当該トランザクションがＢＰか否かチェック
する（２１００１）。当該トランザクションがＢＰであ
れば、当該問合せをＢＰ問合せとする（２１００２）。
次に、当該問合せでアクセスするすべての表がＢＰ処理
中か否かチェックする（２１００３）。ＢＰ処理中であ
れば、当該問合せがＢＰ問合せか否かチェックする（２
１００４）。ＢＰ問合せであれば、ＢＰキューへ登録し
（２１００５）、そうでなければＯＬＴＰキューへ登録
し（２１００６）、終了する。ＢＰ処理中でなければ、
当該問合せでアクセスするすべての表がＯＬＴＰ処理中
か否かチェックする（２１０１０）。ＯＬＴＰ処理中で
あれば、当該問合せがＢＰ問合せか否かチェックする
（２１００７）。ＢＰ問合せであれば、ＢＰキューへ登
録し（２１００８）、そうでなければ当該問合せを実行
し（２１００９）、終了する。ＯＬＴＰ処理中でなけれ
ば、当該問合せでアクセスする表が実行処理中か否かチ
ェックする（２１０１１）。実行処理中であれば、当該
問合せがＢＰ問合せか否かチェックする（２１０１
３）。ＢＰ問合せであれば、ＢＰキューへ登録し（２１
０１４）、そうでなければ当該問合せを実行し（２１０
１５）、終了する。実行中でなければ、当該問合せを実
行し（２１０１２）、終了する。

【００２３】問合せがＢＰ問合せであるか否かの判定は
ステップ２１００１、２１００４、２１００７、２１０
１３で行なわれるが、問合せがＢＰ問合せであるか否か
は、次の判断基準に基づき判定される。すなわち、ペー
ジロックを実装するシステムとロウロックを前提にする
システムとを比較すると、ロックの競合の割合は、デー
タベース処理で発行する１つのＳＱＬ文の選択率によっ
て、コミットまで保持するロック資源（ロウ、あるいは
ページ）の範囲が決まる。選択率とは、問合せでアクセ
スする表のロウ、あるいはページの内、ヒットする（条
件を満足する）ことによってロックを保持することにな
った資源の比率である。 選択率 ロウロック範囲 ページロック範囲 １％ヒット １％ １０％ ５％ヒット ５％ ５０％ １０％ヒット １０％ ７０％ １００％ヒット １００％ １００％ 上のロック範囲から判断して、表の７０％以上の資源が
ロックされればＢＰ問合せとすると、ページロック前提
で「１つの１０％ヒットのＳＱＬ文の実行で表の７０％
以上の資源がロック」、「２つの５％ヒットのＳＱＬ文
の実行で表の１００％の資源がロック（２つのＳＱＬ文
間ではロック範囲に依存関係はないとする）」となるこ
とが分かる。ＢＰ問合せとする閾値（例えば、「ロック
される資源が表の７０％」を１つの閾値とする）は、デ
ータベース管理者が決定する。

【００２４】問合せ開始時でなければ、問合せ実行中か
否かをチェックする（２１０１６）。問合せ実行中であ
れば、資源アクセスの閾値（上記のＢＰ問合せとする閾
値）を越えたかチェックする（２１０１７）。越えてい
れば、当該問合せをＢＰ問合せ、当該トランザクション
をＢＰとし（２１０１８）、終了する。すなわち、問合
せ開始時にＯＬＴＰと判定されても、問合せ実行中に上
記閾値を超えればＢＰ問合せとする。問合せ実行中でな
ければ、すなわち問合せ終了時であれば、他トランザク
ションで当該問合せでアクセスした表が使用中か否かを
チェックする（２１０１９）。使用中でなければ、当該
問合せでアクセスした表を未実行中とし（２１０２
０）、終了する。

【００２５】図１９は投入時間監視処理のフローチャー
トである。投入時間監視処理２１１は、システムの起動
と共に開始され、常にＦＥＳでバックグラウンドで実行
される。すなわち、スケジューリング処理２１０とは非
同期に動作する。投入時間監視処理２１１は、システム
開始時にオンライントランザクション／バッチ処理投入
間隔を設定する（２１１０）。ＢＰキューに問合せが存
在すれば（２１１１）、ＢＰキューからＢＰ問合せを取
り出し（２１１２）、当該問合せを実行する（２１１
３）。次に、ＢＰ問合せの実行が終了していれば２１１
５へ、それ以外であれば、ＢＰ問合せの実行が終了する
まで監視する（２１１４）。ＯＬＴＰキューに問合せが
存在すれば（２１１５）、ＯＬＴＰキューからＯＬＴＰ
問合せを取り出し（２１１６）、当該問合せを実行する
（２１１７）。それ以外であれば、投入間隔が経過した
か否かをチェックする（２１１８）。経過していなけれ
ば２１１５へ、経過していれば２１１１へ進む。したが
って、ＢＰ問合せを実行する間は、２１１１から２１１
４を実行し、ＯＬＴＰ問合せの実行中は、２１１５から
２１１８を実行することになる。

【００２６】ＯＬＴＰ問合せ群を投入する時間間隔は多
くの場合、データベース管理者からの指定で決まると考
えられるが、システムで適切に決定してもよい。また、
ＯＬＴＰ問合せ群の実行時、各ノード間で転送されるデ
ータについては、複数のトランザクションに関与するデ
ータをページにまとめ、当該ページの満杯あるいは一定
時間の経過のタイミングで転送する方法を採用してもよ
い。また、上記実施例では、ＯＬＴＰ問合せとＢＰ問合
せとを全く競合させないで時間を分けてスケジュールし
ているが、他の方法として、ＢＰ問合せの実行中にＯＬ
ＴＰ問合せを投入して実行させ、ロック資源がＢＰ問合
せと競合した時点で、該ＯＬＴＰ問合せの既に獲得した
ロック資源を全て開放した後、ＯＬＴＰキューに登録す
るようにしてもよい。

【００２７】以上、処理フロ−を説明した。本発明は、
統計情報を用いた規則とコスト評価との併用に限らず、
適当なデ−タベ−ス参照特性情報を与える処理手順が得
られるものであれば、例えばコスト評価のみ、規則利用
のみ、コスト評価と規則利用の併用等の最適化処理を行
うＤＢＭＳにも適用できる。本発明は、密結合／疎結合
マルチプロセッサシステム大型計算機のソフトウェアシ
ステムを介して実現することも、また各処理部のために
専用プロセッサが用意された密結合／疎結合複合プロセ
ッサシステムを介して実現することも可能である。ま
た、単一プロセッサシステムでも、各処理手順のために
並列なプロセスを割当てていれば、適用可能である。

【００２８】

【発明の効果】本発明によれば、オンライントランザク
ション／バッチ処理投入間隔内で一定時間ＢＰ問合せが
実行され、残りの時間ＯＬＴＰ問合せが実行され、投入
間隔毎にＢＰ問合せとＯＬＴＰ問合せが確実に実行され
るため、ＯＬＴＰの応答性能が保証される。また、ＢＰ
問合せ投入時間にはＢＰ問合せの実行のみを行ない、Ｏ
ＬＴＰ問合せの実行は待機させ、前記ＯＬＴＰ問合せ投
入時間にはＯＬＴＰ問合せの実行のみが行なわれるの
で、ＢＰ問合せとＯＬＴＰ問合せの競合が回避される。
また、これらにより高速な問合せ処理を実現することが
できる。さらに、稼働中のシステムでＯＬＴＰ問合せと
ＢＰ問合せが競合している場合には、ＢＰ問合せとなる
可能性が非常に高い複数の処理手順からなる問合せが前
記第２のプロセッサノード群を利用する内部処理手順を
優先的に選択するようにしているため、ＢＰ問合せとＯ
ＬＴＰ問合せの競合が回避される。また、これにより高
速な問合せ処理を実現することができる。

【図面の簡単な説明】

【図１】本発明の一実施例が適用された並列デ−タベ−
スシステムの実行例を説明する図である。

【図２】従来のデータベースシステムの構成を示す図で
ある。

【図３】本発明が適用される並列データベースシステム
におけるフロントエンドサーバ機能を示す図である。

【図４】本発明が適用される並列データベースシステム
におけるバックエンドサーバ機能を示す図である。

【図５】本発明が適用される並列データベースシステム
におけるディクショナリサーバ機能を示す図である。

【図６】本発明が適用される並列データベースシステム
におけるジャーナルサーバ機能を示す図である。

【図７】本発明が適用される並列データベースシステム
のハードウェア構成を示す図である。

【図８】本発明が適用される並列データベースシステム
におけるオンライントランザクション処理の概要を示す
図である。

【図９】本発明が適用される並列データベースシステム
におけるバッチ処理の概要を示す図である。

【図１０】従来のデータベースシステムでのＯＬＴＰ問
合せとＢＰ問合せが混在した実行例を説明する図であ
る。

【図１１】並列データベース管理システムにおける概略
の処理フローチャートを示す図である。

【図１２】アクセスパス剪定のフローチャートを示す図
である。

【図１３】処理手順候補生成のフローチャートを示す図
である。

【図１４】コード生成のフローチャートを示す図であ
る。

【図１５】動的最適化処理のフローチャートを示す図で
ある。

【図１６】コード解釈実行のフローチャートを示す図で
ある。

【図１７】スケジューリング処理のフローチャートを示
す図である。

【図１８】図１７のフローチャートに続くフローチャー
トを示す図である。

【図１９】投入時間監視処理のフローチャートを示す図
である。

【符号の説明】

１０、１１ アプリケーションプログラム ２０ データベース管理システム ２１ システム制御部 ２２ 論理処理部 ２４ データベース／ディクショナリ／ジャーナルバッ
ファ ３０ オペレーティングシステム ４０ データベース ５０ ディクショナリ ６０ ジャーナル ６１、６２、６３、６４、６５、６６ プロセッサ ７０、７１、７２、７３、７４、７５ ディスク装置 ８０ 相互結合ネットワーク ９０、９１、９２、９３、９４、９５、９６、９７ ノ
ード １００、１０４ ＢＰ問合せ １０１、１０２ ＯＬＴＰ問合せ １０３ オンライントランザクション／バッチ処理投入
間隔

Claims (3)

【特許請求の範囲】
1. 【請求項１】 データベースに対するユーザからの問合
   せを解析して対応する処理手順を決定し、それを実行
   し、複数のプロセッサノードがネットワークにより接続
   され、各プロセッサノードが、ユーザからの問合せの解
   析、最適化、処理手順作成を実行するフロントエンドサ
   ーバ機能と、前記処理手順を基にしてデータベースをア
   クセスするバックエンドサーバ機能と、データベースシ
   ステムの定義情報を一括管理するディクショナリサーバ
   機能と、データベース更新履歴情報を格納、管理するジ
   ャーナルサーバ機能を備える並列データベースシステム
   において、各ノードで実行される処理手順を問合せ解析
   時あるいは問合せ実行時に作成しておき、問合せ実行時
   に各ノードで実行する処理手順を決定し、前記問合せが
   オンライントランザクション処理（以下、ＯＬＴＰと記
   す）に属するかバッチ処理（以下、ＢＰと記す）に属す
   るか判定し、判定されたＯＬＴＰ問合せとＢＰ問合せの
   実行をスケジュールする資源競合回避スケジューリング
   方法であって、 ＢＰ問合せ投入時間とＯＬＴＰ問合せ投入時間からなる
   オンライントランザクション／バッチ処理投入間隔を設
   定し、該投入間隔における前記ＢＰ問合せ投入時間と前
   記ＯＬＴＰ問合せ投入時間の割合を設定し、 前記ＢＰ問合せ投入時間にはＢＰ問合せの実行のみを行
   ない、ＯＬＴＰ問合せの実行は待機させ、前記ＯＬＴＰ
   問合せ投入時間にはＯＬＴＰ問合せの実行のみを行なう
   ようにしたことを特徴とする資源競合回避スケジューリ
   ング方法。
2. 【請求項２】 請求項１記載の資源競合回避スケジュー
   リング方法において、前記問合せがＯＬＴＰに属するか
   ＢＰに属するかの判定を、問合せでアクセスするページ
   数、獲得ロック資源数、ヒットロウ数等に基づく所定の
   閾値により行ない、ＯＬＴＰ問合せの実行中にも該ＯＬ
   ＴＰ問合せに対して前記判定を行ない、前記所定の閾値
   を超えた場合、該ＯＬＴＰ問合せをＢＰ問合せとするこ
   とを特徴とする資源競合回避スケジューリング方法。
3. 【請求項３】 データベースに対するユーザからの問合
   せを解析して対応する処理手順を決定し、それを実行
   し、複数のプロセッサノードがネットワークにより接続
   され、各プロセッサノードが、ユーザからの問合せの解
   析、最適化、処理手順作成を実行するフロントエンドサ
   ーバ機能と、前記処理手順を基にしてデータベースをア
   クセスするバックエンドサーバ機能と、データベースシ
   ステムの定義情報を一括管理するディクショナリサーバ
   機能と、データベース更新履歴情報を格納、管理するジ
   ャーナルサーバ機能を備える並列データベースシステム
   における資源競合回避スケジューリング方法であって、 ＢＰ問合せにおいては、第１のプロセッサノード群には
   読みだし対象となるデータベースが格納され、データ読
   みだし処理、データ分割処理を実行し、第２のプロセッ
   サノード群では結合処理のための部分列ソート処理、完
   全列作成処理、突き合わせ処理を実行し、第３のプロセ
   ッサノード群ではＢＰ問合せで要求したデータの受け取
   り処理を実行し、ＯＬＴＰ問合せにおいては、第１のプ
   ロセッサノード群には読みだし対象となるデータベース
   が格納され、データ読みだし処理を実行し、第３のプロ
   セッサノード群ではＯＬＴＰ問合せで要求したデータの
   受け取り処理を実行する場合、 デ−タベ−スに対するユ−ザからの問合せを解析して対
   応する内部処理手順を決定し、問合せ解析処理時あるい
   は問合せ実行処理時に入力された問合せの解析結果とデ
   −タベ−スシステムの最適化情報とから単一あるいは複
   数の内部処理手順を選定、格納する過程と、 各ノード単位で実行される単一あるいは複数の処理手順
   を問合せ実行処理時に選択する過程と、該処理手順を実
   行する過程と、 稼働中のシステムでＯＬＴＰ問合せとＢＰ問合せが競合
   している場合には、前記選択する過程は、複数の処理手
   順からなる問合せが前記第２のプロセッサノード群を利
   用する内部処理手順を優先的に選択する過程を含むこと
   を特徴とする資源競合回避スケジューリング方法。