JP3808941B2 - 並列データベースシステム通信回数削減方法 - Google Patents
並列データベースシステム通信回数削減方法 Download PDFInfo
- Publication number
- JP3808941B2 JP3808941B2 JP21057596A JP21057596A JP3808941B2 JP 3808941 B2 JP3808941 B2 JP 3808941B2 JP 21057596 A JP21057596 A JP 21057596A JP 21057596 A JP21057596 A JP 21057596A JP 3808941 B2 JP3808941 B2 JP 3808941B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- database operation
- server
- statement
- statements
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、デ−タベ−ス管理システムに係り、特にリレ−ショナルデ−タベ−ス管理システムに適した問合せの並列処理に好適な問合せための通信回数の削減方法に関する。
【０００２】
【従来の技術】
事務データ処理を中心にしてリレーショナルデータベース、主にＳＱＬデータベースシステムの適用が進んでいる。
リレーショナルデータベースシステムにおいては、データを複数のデータベース処理サーバに分割して配置して、並列にアクセスすることで、性能の向上を図ることが容易である。このような並列データベースシステムに対する要求は、データ量の増大にともなって強まってきている。
並列データベースシステムについては、DeWitt,D.,et.al.:"Parallel Database Systems: The Future of High Performance Database Systems", CACM, Vol.35, No.6, 1992.に記載されている。
並列データベースシステムの構成としては、ホストからのデータベースに対する問い合わせを解析しコンパイルするサーバ（フロントエンドのデータベースサーバと呼ぶことにする）と、データが格納されるディスク装置にアクセスし、データの操作を行う複数のサーバ（データベース操作サーバと呼ぶことにする）を有する。
【０００３】
以下では、簡単のため、１つのホスト、１つのフロントエンドデータベースサーバと複数のデータベース操作サーバの構成で説明を行う。
しかし、１つ、または、複数のホストからの複数の問い合わせに対して、複数のフロントエンドデータベースサーバが取りあつかうことができる。
この場合でも１つ１つの問い合わせに対しては、１つのホスト、１つのフロントエンドサーバと複数のデータベース操作サーバの構成であり、以下の説明、及び、本発明に問題無く適用される。
【０００４】
一般にデータベースに対する問い合わせであるＳＱＬは、Ｃ言語などの計算機言語に埋めこんだ形で使われることが多い（以下、埋込型ＳＱＬと呼ぶことにする）。
データベースへの検索、及びデータベースへのデータの更新、削除と挿入の１つ１つのデータベースの操作を行う文（以下、データベース操作文と呼ぶことにする）は、データベース操作言語ＳＱＬのＳＱＬデータ文（以下、ＳＱＬ文と呼ぶことにする）によって書かれる。
埋込型ＳＱＬは、Ｃ言語などの計算機言語からＳＱＬ文を実行できるようにし、ＳＱＬ文単独では行えない複雑処理を行えるようにしたものである。
【０００５】
以下に、埋込型ＳＱＬによる、一般的な、並列データベースシステムの内部形式の処理手順の作成、転送と実行の例を記す。
データベース操作の結果に対する加工や制御を、埋込型ＳＱＬで書かれたホストプログラムの制御構文が行う。
ＳＱＬ文は１文ずつホストプログラムとのフロントエンドのデータベースサーバにネットワークを介して送られる。そして、コンパイラによって構文解析、意味解析、最適化、コンパイルを行うことによって、送られたＳＱＬ文に基づいた実際のデータベース操作を行うための内部形式の処理手順を作成する。
【０００６】
作成された処理手順は、実際にデータベース操作を行うデータベース操作サーバにネットワークを通じて転送し起動要求により実行する。
データベース操作サーバはプロセサと１つ以上のディスク装置を有する。
データベース操作サーバのキャッシュに内部形式の処理手順を置くことによって、２回目以降の実行は、実行要求を発しキャッシュにある処理手順を用いる改良案がある。
【０００７】
並列データベースシステムにおいてはデータベース操作サーバは複数存在し、ＳＱＬの処理の並列化がなされる。
ＳＱＬの処理の結果は、必要に応じて他のデータベース操作サーバとネットワークを通じてデータなどのやりとりを行い、最終的にユーザプログラムとのフロントエンドサーバの結果受取り処理を通じて、実行結果がホストプログラムに返され、実行結果の加工や制御を行う。以下ＳＱＬ文１文ずつについて同じ処理を繰り返す。
【０００８】
次に、ストアド・プロシージャという従来技術による並列データベースシステムの内部形式の処理手順の作成、転送と実行の方式の一例を示す。
ストアド・プロシージャは、上記従来技術が１つ１つＳＱＬ文を実行してから実行結果を返すためホストプログラムとフロントエンドのデータベースサーバの間のネットワーク通信量が多いのに対して、通信量を減らすことを１つの目的として、一連のＳＱＬ文からなるトランザクション処理をまとめてコンパイラでコンパイルしてデータベースサーバ側で実行する方式である。
１つのストアド・プロシージャは、名称、各ＳＱＬ文の内部形式の処理手順とif then else、whileなど制御構文（以下、代入などのデータ加工処理を含めて制御処理文と呼ぶことにする）を有する。
制御処理文をＳＱＬ文に含める規格も存在するが、ここでは、制御処理文はＳＱＬ文外のものとして扱うことにする。
制御処理文をＳＱＬ文に含める規格の場合は、ＳＱＬの中の制御構文や代入などの加工処理を本発明でいう制御処理文に対応させ、それ以外を本発明でいうＳＱＬ文に対応させることによって、本発明に適用する。
【０００９】
コンパイルしたストアドプロシジャをフロントエンドのデータベースサーバに蓄えておき、必要に応じてホストプログラムから呼び出して実行する代案もある。
この場合、ホストプログラムは、使用したい名称のストアド・プロシージャをコールすることで、ストアド・プロシージャの実行要求を発し実行を行う。
ストアドプロシジャについては、片山初子:ストアド・プロシージャとトリガーを使いこなす、 NIKKEI OPEN SYSTEMS, No.2, pp.133-144,1993.などに記載されている。
【００１０】
以下に、ストアド・プロシージャを並列データベースシステムに対して適用する場合の実行について一例を記す。
ストアド・プロシージャのＳＱＬ文の処理手順が制御処理文にしたがって１文ずつ実行される。
制御処理文はコンパイルされたコードやインタプリタ用の内部形式など（以下、命令コードと呼ぶことにする）として実行され、その中にＳＱＬ文を実行する命令コードがある。
ＳＱＬ文を実行するときは、各ＳＱＬ文の処理手順は、実際にデータベース操作を行う複数のデータベース操作サーバにネットワークを通じて転送し実行する。
データベース操作サーバのキャッシュに各ＳＱＬ文の処理手順を置くことによって、２回目以降の実行は、実行要求を発しキャッシュにある処理手順を用いる改良案がある。
データベース操作の結果は、必要に応じて他のデータベース操作サーバとネットワークを通じてデータなどのやりとりを行い、最終的にストアド・プロシージャに返され、制御処理文によって加工や制御を行う。以下ＳＱＬ文１文ずつについて同じ処理を繰り返す。ストアド・プロシージャの実行が全て終了するとその実行結果がホストプログラムに返される。
【００１１】
本発明は並列データベースシステムでストアドプロシジャを前提としており、データベースの主流であるリレーショナルデータベース、ＳＱＬにより説明を行う。
しかし、データベース操作文を制御処理文に埋めこんだ問い合わせをフロントエンドのデータベースサーバで解析し、データベース操作文の処理を複数のデータベース操作サーバが行う並列データベースシステムの構成であれば、リレーショナルデータベース、ＳＱＬで無くても適用できる。
例として、データベース操作サーバがオブジェクト指向データベースであり、データベース操作言語がオブジェクト指向操作の言語の場合、データベース操作文として、ＳＱＬ文をオブジェクト指向操作文に置き換えることで適用できる。オブジェクト指向データベースのデータベース操作言語の１つOQLについては、R.G.G.Cattell編：オブジェクトデータベース標準：ODMG-93,共立出版株式会社,pp85-104,1995などに記載されている。
【００１２】
【発明が解決しようとする課題】
埋込型ＳＱＬの場合もストアド・プロシージャの場合も、コンパイルされたＳＱＬ文（データベース操作文）の処理手順は、複数のデータベース操作サーバに対して、ＳＱＬ文１文ごとに転送し実行される。
並列システムで無ければ、サーバは分かれていなく、ホストプログラムとのフロントエンドもデータベース処理も１つのサーバで行われるのでサーバ間の通信ネックは存在しない。
しかし、並列システムの場合は、フロントエンドサーバとデータベース操作サーバ間にＳＱＬ文１文ごとに起動要求が必要になる。そのため、ループによりＳＱＬ文が繰り返し実行される場合は、起動要求の通信回数は、大きなものとなる。通信回数が多くなると通信がネックになって性能が低下する問題が生じる。
【００１３】
ここで、問い合わせの中のＳＱＬ文には同じデータベース操作サーバで実行するものがある。同じサーバで実行するＳＱＬ文の内部形式をまとめて転送し、起動すれば、通信回数は減る。
並列システムに対して、まとめて転送できるＳＱＬ文とはどのようなものか、また、各ＳＱＬ文を実行するデータベース操作サーバは複数あるためどのような方法でまとめるかが問題となる。
【００１４】
本発明は問い合わせの中の複数のＳＱＬ文を、１回の起動要求で実行できる内部形式にまとめて転送し、１回の起動要求で複数のＳＱＬ文を起動することにより、起動要求の回数を減らし、フロントエンドのデータベースサーバとデータベース操作サーバ間の通信回数を減らすことが目的である。
【００１５】
【課題を解決するための手段】
上記目的を達成するために、本発明は、
データベースへの問い合わせを解析するフロントエンドのデータベースサーバと、データベースに対する操作を行う複数のデータベース操作サーバを有し、該フロントエンドのデータベースサーバと複数のデータベース操作サーバとがネットワークで接続された並列データベースシステムにおいて、
前記フロントエンドのデータベースサーバは、複数のデータベース操作文を含んだデータベースへの問い合わせを解析し、対応する内部形式を作成し、該内部形式を実行して内部形式の中のデータベース操作文を複数のデータベース操作サーバに送り実行する過程において、
前記解析時に、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上のデータベース操作文を抽出してグループ化し、
前記内部形式を実行する時に、前記グループ化したデータベース操作文をデータベース操作サーバにまとめて転送し、
前記データベース操作サーバに対して、転送した複数のデータベース操作文を一回の起動要求で起動するようにしている。
【００１６】
また、グループ化した各データベース操作文を転送するデータベース操作サーバを、データベースシステム内の各表と表の分割されているデータベース操作サーバとの対応関係を示す表分割情報に基づき決定するようにしている。
さらに、前記表分割情報に基づき転送先のデータベース操作サーバの決定した前記グループ化した各データベース操作文をそれぞれ転送先のデータベース操作サーバにまとめて転送し、転送した複数のデータベース操作文を一回の起動要求で起動するようにしている。
【００１７】
また、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上の前記データベース操作文に対して同じ識別子を付与することによりグループ化するようにしている。
【００１８】
また、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上の前記データベース操作文と、該データベース操作文を含む制御処理文の夫々とをグループ化するようにしている。
【００１９】
また、同じデータベース操作サーバで一回の実行要求で実行できるデータベース操作文とは、前記の複数のデータベース操作文の中で、内部形式の中で実行する順番が連続しているデータベース操作文であり、分割列の更新操作文の後に同じ表に対するデータベース操作文が存在せず、かつ、先に行うデータベース操作文の結果を変数を媒介として後のデータベース操作文が使用しないデータベース操作文であるようにしている。
【００２０】
また、同じデータベース操作サーバで一回の実行要求で実行できるデータベース操作文とは、前記の複数のデータベース操作文の中で、内部形式の中で実行する順番が連続しているデータベース操作文であり、データベース操作を行う表が１つの同じデータベース操作サーバにあるデータベース操作文であるようにしている。
さらに、前記データベースに対する問い合わせの中にある全てのデータベース操作文のデータベース操作を行う表が１つの同じデータベース操作サーバにある場合、前記データベースに対する問い合わせの内部形式を該データベース操作サーバに転送し、実行するようにしている。
【００２１】
【発明の実施の形態】
以下において本発明の一実施例を図面を用いて説明する。
図１は本発明の実施例の構成図である。
ホストからのデータベースへの問い合わせに対するフロントエンドの役割をするデータベースサーバ１２と、データベースに対する操作を行う役割をする複数のデータベース操作サーバ１３で構成される。
フロントエンドデータベースサーバ１２とデータベース操作サーバ１３は、高速な相互結合ネットワークで繋がっているものとする。
ただし、ネットワークで繋がる複数プロセッサの並列データベースシステムで無く、単一プロセッサのシステムでも、各サーバの役割として並列なプロセスを割り当てていれば、プロセス間の通信回数を削減するものとして本発明に適用可能である。
フロントエンドデータベースサーバ１２は、外部のホスト１１とネットワークで繋がっているものとする。
ただし、本発明はフロントエンドのデータベースサーバ１２とデータベース操作サーバ１３の間の通信回数を削減するのが目的なので、ホストの役割をデータベースシステム側に取り込み、内部の高速なネットワークで繋げる代案や、ホストの役割とフロントエンドのデータベースサーバを１つに統合する代案に対しても本発明を適用できる。
【００２２】
ホスト１１からのストアドプロシジャ１２１をフロントエンドのデータベースサーバ１２で解析（１０１）することでストアドプロシジャの内部形式１２２を作成する。
作成したストアドプロシジャ内部形式１２２は、名称、制御処理文の内部形式、各ＳＱＬ文の内部形式の処理手順を有し、一回の通信で起動する幾つかのグループにグループ分けされている。いっしょに起動するＳＱＬ文が無いＳＱＬ文は、その１つのＳＱＬ文のみでグループを形成する（すなわち、従来通り、そのＳＱＬ文１つを起動する）。
制御処理文を実行（１０２）し、ＳＱＬ文を実行することになると（１０５）、グループごとの処理に入る。
表分割情報１２３をみてグループに対して実行するデータベース処理サーバ１３を決定し、行き先別ＳＱＬ文リストを作成する（１０７）。
続いてデータベース操作を行うため、各ＳＱＬの内部形式を行き先別の内部形式（以下、行き先別ＳＱＬ文内部形式１２４と呼ぶ）にまとめて、行き先別ＳＱＬ文内部形式を作成し（１０８）、データベース処理サーバ１３にＳＱＬ文内部形式を転送し（１０９）、起動要求をかける（１１０）。
データベース操作サーバ１３は、行き先別ＳＱＬ文内部形式１２５を受取り（１１２）、起動要求（１１０）により起動（１１３）し、データベース操作の結果をフロントエンド側１２に返す（１１４）。
各ＳＱＬのデータベース操作の結果はフロントエンドのデータベースサーバ１２で受け取り合成（１１１）し制御処理を続ける。
制御処理が終わるとストアドプロシジャの結果をホスト１１に返す（１０３）。
【００２３】
複数のＳＱＬ文に対し１回の転送（１０９）と起動要求（１１０）で済むため、通信回数が削減される。
データベース処理サーバ１３側のキャッシュメモリに行き先別のＳＱＬの内部形式１２５を置き、２回以上同じＳＱＬを実行する場合起動要求によりキャッシュメモリのＳＱＬを起動する方式もあるが、その場合は、２回目以降は行き先別内部形式生成（１０８）や転送（１０９）はいらない。
その場合でも起動要求が複数のＳＱＬ文に対し１回で済むのは同じであり、本発明の適用ができ発明の効果が期待できる。
ホスト１１からのストアドプロシジャ１２１を解析（１０１）し内部形式１２２を登録しておき、ホスト１１からストアドプロシジャの実行要求を行いストアドプロシジャの実行を行う方式もあるが、その場合でも本発明は解析と実行のフェーズが分れるだけで問題無く適用できる。
その場合１回の通信で起動要求するＳＱＬのグループ分けをストアドプロシージャの実行フェーズに行う代案も適用できる。
【００２４】
図２は、ストアドプロシージャ１２１の例である。
制御構文であるＷＨＩＬＥ文２０２、２０６や、代入文であるＳＥＴ文２０１、２０５が、本発明で制御処理文と呼ぶ文の例である。
ＳＥＬＥＣＴ文２０３やＵＰＤＡＴＥ文２０４が、本発明でデータベース操作文またはＳＱＬ文と呼ぶ文の例である。
データベース操作文は制御処理文中に埋めこまれているという表現を使うことにする。制御処理文中のデータベース操作文のところには暗黙的にデータベース操作文を実行する処理があるものとし、この処理も制御処理文にいれることにする。
これによって、データベースに対する問い合わせ１２１がＳＱＬ文のみの並びの場合でも、本発明を適用できる。
ＳＱＬにはＳＥＬＥＣＴ、ＵＰＤＡＴＥなどデータにアクセスする文の他に、ＣＲＥＡＴＥ文などのデータベースの定義を行う文やカーソルの処理を行う文も存在する。定義やカーソルの処理の文などの、データにアクセスする文以外の文は、データベース操作サーバで行う処理では無いので、従来通り、１つ１つ処理を行う。
【００２５】
実施例ではデータベース操作文としてＳＱＬを用いているが、データベース処理サーバがオブジェクト指向データベースの場合、データベース操作文を、ＳＱＬ文で無く、オブジェクト指向データベース操作言語の参照、更新、削除、挿入のデータベース操作文とすると本発明を適用できる。
データベース操作サーバが複数存在し、制御処理文にデータベース操作文が埋め込まれた形の問い合わせであれば良い。
【００２６】
図３は、実施例における図１のストアドプロシジャ内部形式１２２の例である。
ストアドプロシジャ内部形式１２２は名称３０１、ＳＱＬ文の制御処理文内部形式３０２、ＳＱＬ文内部形式３０３、１回の通信で起動要求するものを同じ番号とする識別子３０４を有する。
制御処理文内部形式はＳＱＬ文内部形式を実行する処理の内部形式を含む。
【００２７】
ＳＱＬ文内部形式は、アクセスする表の識別子や、参照、更新、削除、挿入などのＳＱＬ文の種類、分割カラムの更新かなどの情報を有する。
ストアドプロシジャ内部形式１２２は、図１の解析（１０１）により作成し、その際に、１回の通信で起動要求するものを同じ番号とする識別子３０４がふられる。
制御処理文の１部をいっしょにデータベース処理サーバ１３に送り実行する方式の場合には、制御処理文にも識別子をふる方法や、１回の起動要求で実行できる制御処理文とＳＱＬ文で新たにプロシジャ１２２を作成しポイントする方法が考えられる。
図２の例の場合ＳＱＬ１とＳＱＬ２の識別子３０４が同じ番号であるので１回の起動要求で実行するグループである。
ストアドプロシジャ１２１がＳＱＬ文のみの並びの場合は、制御処理文内部形式は各ＳＱＬ文内部形式を実行する処理の内部形式の並びである。この場合、ＳＱＬ文内部形式の並びを実行順序として、制御処理文内部形式を省略する代案も適用できる。
【００２８】
図４は、実施例における図１の表分割情報１２３の例である。
表分割情報１２３はデータベースシステム内の各表に対し、表の識別子と、その表の分割されているデータベース操作サーバの識別子を有する。
図４の例の場合、表Ｔ１はデータベース処理サーバ１、サーバ２、サーバ３に、表Ｔ２はデータベース処理サーバ１、サーバ２に、表Ｔ３はデータベース処理サーバ２、サーバ３に表Ｔ４はデータベース処理サーバ１に分割している。
分割の種類が分割列のキー範囲やハッシュ値による分割の場合はサーバごとに分割範囲を有する。
ＳＱＬ文のＷＨＥＲＥ句に分割列の条件がある場合に分割範囲によって実行するサーバを限定する改良案を適用できる。
【００２９】
図５は、実施例における図１の行き先別ＳＱＬ文リスト１２４の例である。
行き先別ＳＱＬ文リスト１２４は、解析（１０１）で分けたグループに対して、実行を行うデータベース処理サーバ１３である行き先サーバと、その行き先サーバに転送するＳＱＬ文内部形式識別子を有する。
【００３０】
図６は、実施例における、図１の行き先別ＳＱＬ文内部形式１２５の例である。
行き先であるデータベース操作サーバの識別子６０１、グループ内のＳＱＬ文内部形式の数６０２、ＳＱＬ文内部形式へのポインタ６０３をＳＱＬ内部形式の数６０２分、各ＳＱＬ文内部形式６０４を有する。
複数のＳＱＬ文を１つの内部形式１２５にまとめることにより、１回の起動要求で、複数のＳＱＬ文を逐次または並列に実行することができる。
【００３１】
図７は、実施例の図１の解析（１０１）における１回の起動要求で実行できるＳＱＬ文をグループに分ける処理の処理説明図である。
この処理では解析（１０１）で作成された、ＳＱＬ文の制御処理文順に次の埋め込みＳＱＬ文がある場合、各２つのＳＱＬ文に変数のやりとりなどが無いか調べ、有れば新たな識別子を付与し、無ければ同一の識別子を付ける。
ただし、Ｃ言語のｇｏｔｏ文のようなジャンプを行う制御処理文がある場合は実行順の先後が判定できる単純な場合を除いて本発明の適用は行わない。
また、ループを行う制御処理ごとに複数のＳＱＬ文をグループにする方法をとる場合には、ループを行う制御処理の間のＳＱＬ文は、繰り返し実行されるため、実行順の先後がどちらにもなるものとして適用する。
図７では識別子を１から順に付けて分けているが、同じグループを識別できれば他の識別方法でも良い。分けた後のストアドプロシジャ内部形式の例は前述の図３である。
【００３２】
まずグループに付ける識別子に初期値１を入れる（７０２）。
制御処理文順に次の埋め込みＳＱＬ文があるか判定し（７０３）、無ければ処理を終了する。有ればこれから識別子を付けるＳＱＬ文を取り出し（７０４）、現在調べているグループの識別子を付ける（７０５）。次に（７０６）の判定を行なう。
現在調べているグループのＳＱＬ文１つずつと、（１）変数による結果のやりとりがある（７０７）かを調べ、（２）共に同じ表に対するデータベース操作文であり（７０８）、先に行なうデータベース操作文が分割カラムの更新問い合わせ（７０９）かを調べ、（１）、（２）の条件のいずれかに適合する場合は、１回の起動要求で実行できないためグループを変える（７１１）、（７１２）。
しかし、（１）の条件を満たさず、かつ異なる表を対象とする問い合わせ（７０８）の場合、また、（１）の条件を満たさず、かつ同じ表を対象とする問い合わせ（７０８）であり、かつ（２）の条件を満たさない場合にはグループの識別子をそのままとする。
実行順序、変数のやりとりは制御処理文内部形式に情報があり、ＳＱＬ文がアクセスする表、更新処理か、分割カラム更新か、はＳＱＬ文内部形式に情報がある。
図７の例では内部形式を作成した後、グループ分けを行う例になっているが、グループ分けなどの解析処理を行いやすいように、実行順序、変数のやりとり、ＳＱＬ文がアクセスする表、更新処理か、分割カラム更新か、などの情報を抽出済みの中間形式を作成し、グループ分けをしたあとで実行用の内部形式に変換する代案も適用できる。また、内部形式の作成と並行してグループ分けを進める代案も適用できる。
解析（１０１）により前述の図３のように一回の起動要求で実行するものをまとめたストアドプロシジャ内部形式１２２が作成される。
【００３３】
図８は、実施例の図１のグループ分割決定（１０７）の処理説明図である。
この処理は、１回の起動要求で実行できるものとしてグループ化されているＳＱＬ文に対して、表分割情報１２３を見て、処理手順内部形式の行き先別のリストを作成する。
行き先別に内部形式を変えるのは、データベース操作サーバにより実行するＳＱＬ文が異なるため無駄なＳＱＬ文内部形式の転送を押さえるためである。
【００３４】
まず、１回の起動要求で実行可能なものとしてグループ化されているＳＱＬ文を１つずつ取り出す（８０１）、（８０２）。
表分割情報１２３を見て、そのＳＱＬがアクセスする表が存在するデータベース操作サーバ１３の識別子を取り出す（８０４）。
そのデータベース操作サーバについての行き先別のＳＱＬ文のリスト１２４が存在すれば（８０５）、ＳＱＬ文の識別子を登録し（８０７）、存在しなければ、そのデータベース操作サーバについての行き先別のＳＱＬ文のリスト１２４を作成し（８０６）、登録する（８０７）。
グループ内の全てのＳＱＬについて分割したならば（８０９）、行き先別にＳＱＬ文をまとめる。
ただし、２表以上の表にアクセスするＳＱＬ文については、各表のアクセス用に異なる内部形式の処理手順を作成する方式をとる場合には、ＳＱＬ文では無く、処理手順ごとに行き先別のリストを作成し、以下、各表のアクセス用の処理手順を部分的なＳＱＬ文として１表にアクセスするＳＱＬ文と同等に扱うことで本発明を適用できる。
【００３５】
図９は、実施例の図１の行き先別ＳＱＬ文内部形式生成（１０８）の処理説明図である。
行き先別ＳＱＬ文内部形式１２５の例は前述の図６である。
ＳＱＬ文内部形式をまとめる場合、１回の起動要求で実行するＳＱＬ文の数（６０２）分のポインタ（６０３）を配列で用意し、各ＳＱＬ文の内部形式（６０４）をポイントする。
グループ分割決定１０７により行き先サーバとそこで起動するＳＱＬ文内部形式が行き先別ＳＱＬ文リスト１２４にまとめてある。
【００３６】
行き先別ＳＱＬ文リスト１２４の行き先サーバ１つずつに対して行き先別ＳＱＬ文内部形式１２５を作る（９０１）。
行き先サーバの識別子を入れ（９０２）、起動するＳＱＬ文の数を数えて（９０３）、該数を入れる領域を設けて、この領域に該数を入れ（９０４）、ＳＱＬ文の数分のポインタを用意し（９０５）、ＳＱＬ文内部形式とＳＱＬ内部形式へのポインタをいれる（９０７）、（９０８）。
図９の例では、行き先別に異なる内部形式を作成するが、代案として、グループ内のＳＱＬ文をまとめた内部形式を１つ作成し、データベース操作サーバ側で、アクセスする表の有無などによって起動するＳＱＬを判断する代案も適用できる。
【００３７】
図１０は、実施例の図１の行き先別ＳＱＬ文内部形式転送（１０９）の処理説明図である。
行き先別ＳＱＬ文内部形式を１つずつ取り出し（１００１）、行き先サーバに転送する（１００２）。
行き先別ＳＱＬ文内部形式を受け取ったデータベース操作サーバが受取り報告をフロントエンドのデータベースサーバ１２に返し、全て受け取ったのを確認してから起動要求１１０に移る代案も適用できる。
また、行き先別ＳＱＬ文内部形式を受け取り、そのまま起動を行う代案も考えられるが、その場合、内部形式の転送が起動を兼ねており、転送回数が減っているため、通信回数を減らす発明の効果が期待できる。
【００３８】
図１１は、実施例の図１の行き先別ＳＱＬ文内部形式起動要求１１０の処理説明図である。
１回の通信で起動要求できるグループごとに実行する各データベース操作サーバに起動要求をかける（１１０２）。
データベース操作サーバ１３側は、起動要求を受けると（１１０３）と、行き先別のＳＱＬ文内部形式１２５の配列からポイントされた内部形式６０４を、配列順に逐次に、もしくは、並列に起動する（１１０５）。
１回の起動要求で起動する相手は図６のように複数のＳＱＬ文であるため、起動要求の通信回数が削減される。
データベース操作サーバ１３のキャッシュメモリに行き先別ＳＱＬ文内部形式１２５のキャッシュを置く代案もあるが、いずれにしても複数のＳＱＬ文に対して１回の起動要求ですむため通信回数は削減されるので、本発明が適用できる。
【００３９】
図１２は、実施例における図１の検索結果合成１１１の処理説明図である。
図１３は検索結果合成の例の模式図である。
起動要求したデータベース操作サーバ１３からＳＱＬ文ごとに転送処理が行われ（１２０７）、実行結果を取り出し（１２０８）、実行結果が無くなるまで（１２０９）、結果が転送される（１２１０）。実行結果が無くなると（１２０９）、結果終了の報告を送る（１２１１）。
フロントエンドのデータベースサーバ１２側は、ＳＱＬ文ごとに結果の受取り処理を行う（１２０１）。
結果受取りの処理手順を解析時に作成しても良い。
各データベース操作サーバ１３からの結果は、キューなどにより結果を送られてきた順に取り出される（１２０２）。
起動したデータベース操作サーバ１３から全て結果終了の報告が送られてくるまで（１２０５）、結果を受け取る（１２０４）。結果終了の報告が送られてきたら（１２０５）、（１２０６）の処理を行なう。
結果は共用メモリなどにおいておき、制御処理文内部形式の実行時に取り出される。
図１２では、結果転送１１４や結果受取り１１１をＳＱＬ文ごとに逐次行っているが、制御処理文実行と各ＳＱＬ文の結果受取りを別プロセスで並列に行う改良案も適用できる。
【００４０】
図１４は本発明を具体的なＳＱＬ文や制御処理文に適用する具体例の概要図である。
ストアドプロシジャの内容はＳＱＬ文制御処理文１４０２の内容である。実際は内部形式で表される。
図７の処理説明図と照らして解析処理（１０１）を見ると、制御処理文順にＳＱＬ文１、ＳＱＬ文２となり、ＳＱＬ１の出力はＳＱＬ２の入力とはなっておらず（７０７）、ＳＱＬ１は表Ｔ１を対象にし、ＳＱＬ２は表Ｔ２を対象としているため、ＳＱＬ１とＳＱＬ２は、異なる表を対象とする問い合わせであるため（７０８）、同じグループの識別子がふられる。
また図８の処理説明図と照らしてグループの分割決定処理（１０７）を見ると、ＳＱＬ１とＳＱＬ２は同じ集合Ｚに入る（８０１）。
ＳＱＬ１はＴ１への問い合わせであるため、表分割情報１２３よりサーバ１、サーバ２、サーバ３が取り出され（８０３）、サーバ１、サーバ２、サーバ３の各行き先別のＳＱＬ文リストが作成され（８０６）、ＳＱＬ文１の識別子がこのリストに登録される（８０７）。
ＳＱＬ２はＴ２への問い合わせであるため、表分割情報１２３よりサーバ１、サーバ２が取り出され（８０３）、サーバ１、サーバ２の行き先別のＳＱＬ文リストは上記したように既に作成されているので、サーバ１、サーバ２のＳＱＬ文リストにＳＱＬ文２の識別子が登録される（８０７）。
結果として、サーバ１（１３ａ）にＳＱＬ文１とＳＱＬ文２の処理手順が、サーバ２（１３ｂ）にＳＱＬ文１とＳＱＬ文２の処理手順が、サーバ３（１３ｃ）にＳＱＬ文１の処理手順が、１回の起動要求で実行されるプロシジャとして作成され、転送され実行される。
【００４１】
データベース操作サーバ１３ａ、１３ｂにおいて、ＳＱＬ１とＳＱＬ２の処理は逐次または並列に実行することが可能である。一回の起動要求で実行するデータベース処理の中に、更新、削除、挿入と、同じ表への検索が混ざっていない限り、実行順序は変えられるため並列に実行することも可能なのである。
また各データベース処理サーバ間で同じＳＱＬ文に対して開始の待ち合わせをしないため、サーバによってデータ量の偏りがある場合でも、各サーバごとに最短の時間でＳＱＬの処理が行われる。従来方式だと偏りが大きい処理が終わるのを待たないと次のＳＱＬの処理に進めない。
同様に、データベースサーバごとに実行するＳＱＬ文が異なる場合も、各データベース処理サーバ間で同じＳＱＬ文に対して開始の待ち合わせをしないことから、各サーバごとに最短の時間でＳＱＬの処理が行われる。
【００４２】
図１５は、図１のストアドプロシジャ内部形式１２２の図３とは別の実施例を示す。
ストアドプロシジャ内部形式は名称１５０１、ＳＱＬ文制御処理文内部形式１５０２、ＳＱＬ文内部形式１５０３を有する。
制御処理文内部形式１５０２は、グループにする幾つかのＳＱＬ文と制御処理文の１部分を有する内部形式（以下サブプロシジャ１５２と呼ぶことにする）の呼び出しを有する。
サブプロシジャ１５２を形成しないＳＱＬ文、すなわち、単独で起動されるＳＱＬ文（図の場合、ＳＱＬ文３、ＳＱＬ文７）は従来通りＳＱＬ文内部形式１５０３としてＳＱＬ文制御処理文内部形式１５０２に埋めこまれる。
図３と異なる主要な点は、１回の起動要求で実行できるＳＱＬ文内部形式をサブプロシジャというストアドプロシジャと類似の形式でグループ１５０７にすること、及び、各ＳＱＬ文が埋め込まれている制御処理文内部形式の１部１５０５を一緒にグループにすることである。
サブプロシジャ１５２（図の場合、１５２ａ、１５２ｂ）は名称１５０４、制御処理文の内部形式の１部分１５０５とＳＱＬ文の内部形式の処理手順１５０６を有する。各ＳＱＬ文は同一のデータベース操作サーバにアクセスするものである。
また入力や出力となる変数がある場合は入力変数、出力変数など入出力の情報が必要である。
【００４３】
図１６は、図１の解析（１０１）の図７の実施例とは別の実施例の処理説明図である。
ＳＱＬ文の制御処理文順に複数の各ＳＱＬ文のアクセスする表が同じ１つのデータベース操作サーバ１３にある場合に、サブプロシジャ１５２にまとめる。
ＳＱＬ文の内部形式を制御処理順にサーチし（１６０２）、次のＳＱＬ文があれば、これを取り出しＳＱＬ文２とし（１６０３）、（１６０４）、アクセスする表の分割されているデータベース操作サーバ１３を調べ（１６０５）、サーバ１３が１つであり（１６０６）、同じサーバにアクセスするＳＱＬ文であれば（１６０７）、サブプロシジャを作るためのグループにすることができる（１６０８）。
１つの同じデータベース操作サーバにアクセスする連続するＳＱＬ文のグループができたならば、それらのＳＱＬ文を埋め込む前後の制御処理文内部形式を抽出し、サブプロシジャ１５２を生成する（１６０９）、（１６１１）、（１６１２）。
制御処理文内の変数の入出力によっては、サブプロシジャ１５２の入力、及び、出力となる変数を抽出する。
【００４４】
図１６の例では内部形式を作成した後、グループ分けを行う例になっているが、グループ分けや前後の制御処理文などの解析処理を行いやすいように、実行順序、変数の入出力、ＳＱＬ文がアクセスする表などの情報を抽出済みの中間形式を作成し、グループ分けをしたあとで実行用の内部形式に変換する代案も適用できる。
また、サブプロシジャ１５２の作成と並行してグループ分けを進める代案も適用できる。
図１６の例であると、サブプロシジャ１５２が図１の行き先別ＳＱＬ文内部形式１２５に対応するため、図１の行き先別ＳＱＬ文内部形式生成１０８の処理が必要無い。
また、サブプロシジャ１５２に入力変数がある場合は、起動要求とともに入力の値を転送すれば良い。
結果の合成はＳＱＬ文ごとで無く、サブプロシジャの出力を受け取り使用するのみの簡単な処理になる。
また、ストアドプロシジャ１２１の全てのデータベース操作文が１つの同じデータベース操作サーバ１３に分割してある場合は、サブプロシジャ１５２としてストアドプロシジャごとデータベース操作サーバ１３に転送し実行する改良案を適用できる。
その場合、データベース操作サーバ１３側でのストアドプロシジャの実行結果をフロントエンドのデータベースサーバ１２を介さずに、直接、ホスト１１に返す代案が適用できる。
他にも図７や図１６のように１連の制御処理文やＳＱＬ文が、他のデータベース処理サーバ１３に影響しないことを抽出すれば、図３のようにグループの識別子を付ける方法や図１５のサブプロシジャ１５２を作成する方法などによりグループ分けすることで、１回の起動要求で実行することができるため、本発明を適用できる。
【００４５】
図１７はサブプロシジャ１５２を用いて１回の起動要求で複数のＳＱＬ文を起動する具体例の概要図である。
データベース操作文と制御処理文を含むサブプロシジャ１５２を作成し、各データベース操作サーバ１３で１回の起動要求で起動し、結果はフロントエンドのデータベースサーバ１２で受け取り、ストアドプロシジャの処理に渡す。
【００４６】
図１８は１つの同じデータベース操作サーバにアクセスする複数のＳＱＬ文をまとめて起動する具体例の概要図である。
サブプロシジャとしてストアドプロシジャごとデータベース操作サーバ側で実行する例である。
問い合わせ１２２中のＳＱＬ文のアクセスする表が全てサーバ１であり１つの同じデータベース操作サーバであるため、ストアドプロシジャ内部形式１２２ごとデータベース操作サーバに送り実行する。
結果はフロントエンドのデータベースサーバ１２を経由してホスト１１に返す方法と、直接ホスト１１に返す方法が考えられる。
ストアドプロシジャ１２２ごとデータベース操作サーバ側１３で実行すれば、フロントエンドのデータベースサーバ１２とデータベース操作サーバ１３の間で、起動要求だけでなく、結果のやりとりも無くなるため大幅な通信の削減が見込まれる。
【００４７】
【発明の効果】
以上のように、本発明によれば、複数のデータベース操作文に対し１回の起動要求で実行を行うことで、通信回数を減らし、通信ネックによる性能低下を抑えることができる。
また、表分割情報を用いて、各データベース操作サーバに必要なデータベース操作文のみを送ることで最小限の転送量ですむ。
また、複数のデータベース操作文とともに制御処理文をデータベース操作サーバに送る場合、データベース操作文の結果をデータベース操作サーバ側で制御処理するため、フロントエンドのデータベースサーバとデータベース操作サーバ間で結果転送の通信負荷を削減できる。
また、複数のデータベース操作文が各データベース操作サーバで待ち合わせ無しに実行されるため、データの偏りがある場合に実行時間が短縮される。
【図面の簡単な説明】
【図１】実施例の構成を示す図である。
【図２】ストアドプロシジャの例を示す図である。
【図３】ストアドプロシジャ内部形式の例を示す図である。
【図４】表分割情報の例を示す図である。
【図５】行き先別ＳＱＬ文リストの例を示す図である。
【図６】行き先別ＳＱＬ文内部形式の例を示す図である。
【図７】ＳＱＬ文をグループに分ける処理のフローチャートを示す図である。
【図８】グループ分割決定の処理のフローチャートを示す図である。
【図９】行き先別ＳＱＬ文内部形式生成の処理のフローチャートを示す図である。
【図１０】行き先別ＳＱＬ文内部形式転送の処理のフローチャートを示す図である。
【図１１】行き先別ＳＱＬ文内部形式起動要求の処理のフローチャートを示す図である。
【図１２】検索結果合成の処理のフローチャートを示す図である。
【図１３】検索結果合成の例を示す図である。
【図１４】具体例の概要を示す図である。
【図１５】ストアドプロシジャ内部形式の例を示す図である。
【図１６】ＳＱＬ文をグループに分ける処理のフローチャートを示す図である。
【図１７】具体例の概要を示す図である。
【図１８】具体例の概要を示す図である。
【符号の説明】
１１ ホスト
１２ フロントエンドのデータベースサーバ
１３ データベース操作サーバ
１０１ 解析
１０７ グループ分割決定
１０８ 行き先別ＳＱＬ文内部形式生成
１０９ 行き先別ＳＱＬ文内部形式転送
１１０ 行き先別ＳＱＬ文内部形式起動要求
１１１ ＳＱＬ文結果合成
１２１ ストアドプロシジャ
１２２ ストアドプロシジャ内部形式
１２３ 表分割情報
１２４ 行き先別ＳＱＬ文リスト
１２５ 行き先別ＳＱＬ文内部形式
１５２ サブプロシジャ
２０１、２０２、２０５、２０６ 制御処理文
２０３、２０４ データベース操作文
【発明の属する技術分野】
本発明は、デ−タベ−ス管理システムに係り、特にリレ−ショナルデ−タベ−ス管理システムに適した問合せの並列処理に好適な問合せための通信回数の削減方法に関する。
【０００２】
【従来の技術】
事務データ処理を中心にしてリレーショナルデータベース、主にＳＱＬデータベースシステムの適用が進んでいる。
リレーショナルデータベースシステムにおいては、データを複数のデータベース処理サーバに分割して配置して、並列にアクセスすることで、性能の向上を図ることが容易である。このような並列データベースシステムに対する要求は、データ量の増大にともなって強まってきている。
並列データベースシステムについては、DeWitt,D.,et.al.:"Parallel Database Systems: The Future of High Performance Database Systems", CACM, Vol.35, No.6, 1992.に記載されている。
並列データベースシステムの構成としては、ホストからのデータベースに対する問い合わせを解析しコンパイルするサーバ（フロントエンドのデータベースサーバと呼ぶことにする）と、データが格納されるディスク装置にアクセスし、データの操作を行う複数のサーバ（データベース操作サーバと呼ぶことにする）を有する。
【０００３】
以下では、簡単のため、１つのホスト、１つのフロントエンドデータベースサーバと複数のデータベース操作サーバの構成で説明を行う。
しかし、１つ、または、複数のホストからの複数の問い合わせに対して、複数のフロントエンドデータベースサーバが取りあつかうことができる。
この場合でも１つ１つの問い合わせに対しては、１つのホスト、１つのフロントエンドサーバと複数のデータベース操作サーバの構成であり、以下の説明、及び、本発明に問題無く適用される。
【０００４】
一般にデータベースに対する問い合わせであるＳＱＬは、Ｃ言語などの計算機言語に埋めこんだ形で使われることが多い（以下、埋込型ＳＱＬと呼ぶことにする）。
データベースへの検索、及びデータベースへのデータの更新、削除と挿入の１つ１つのデータベースの操作を行う文（以下、データベース操作文と呼ぶことにする）は、データベース操作言語ＳＱＬのＳＱＬデータ文（以下、ＳＱＬ文と呼ぶことにする）によって書かれる。
埋込型ＳＱＬは、Ｃ言語などの計算機言語からＳＱＬ文を実行できるようにし、ＳＱＬ文単独では行えない複雑処理を行えるようにしたものである。
【０００５】
以下に、埋込型ＳＱＬによる、一般的な、並列データベースシステムの内部形式の処理手順の作成、転送と実行の例を記す。
データベース操作の結果に対する加工や制御を、埋込型ＳＱＬで書かれたホストプログラムの制御構文が行う。
ＳＱＬ文は１文ずつホストプログラムとのフロントエンドのデータベースサーバにネットワークを介して送られる。そして、コンパイラによって構文解析、意味解析、最適化、コンパイルを行うことによって、送られたＳＱＬ文に基づいた実際のデータベース操作を行うための内部形式の処理手順を作成する。
【０００６】
作成された処理手順は、実際にデータベース操作を行うデータベース操作サーバにネットワークを通じて転送し起動要求により実行する。
データベース操作サーバはプロセサと１つ以上のディスク装置を有する。
データベース操作サーバのキャッシュに内部形式の処理手順を置くことによって、２回目以降の実行は、実行要求を発しキャッシュにある処理手順を用いる改良案がある。
【０００７】
並列データベースシステムにおいてはデータベース操作サーバは複数存在し、ＳＱＬの処理の並列化がなされる。
ＳＱＬの処理の結果は、必要に応じて他のデータベース操作サーバとネットワークを通じてデータなどのやりとりを行い、最終的にユーザプログラムとのフロントエンドサーバの結果受取り処理を通じて、実行結果がホストプログラムに返され、実行結果の加工や制御を行う。以下ＳＱＬ文１文ずつについて同じ処理を繰り返す。
【０００８】
次に、ストアド・プロシージャという従来技術による並列データベースシステムの内部形式の処理手順の作成、転送と実行の方式の一例を示す。
ストアド・プロシージャは、上記従来技術が１つ１つＳＱＬ文を実行してから実行結果を返すためホストプログラムとフロントエンドのデータベースサーバの間のネットワーク通信量が多いのに対して、通信量を減らすことを１つの目的として、一連のＳＱＬ文からなるトランザクション処理をまとめてコンパイラでコンパイルしてデータベースサーバ側で実行する方式である。
１つのストアド・プロシージャは、名称、各ＳＱＬ文の内部形式の処理手順とif then else、whileなど制御構文（以下、代入などのデータ加工処理を含めて制御処理文と呼ぶことにする）を有する。
制御処理文をＳＱＬ文に含める規格も存在するが、ここでは、制御処理文はＳＱＬ文外のものとして扱うことにする。
制御処理文をＳＱＬ文に含める規格の場合は、ＳＱＬの中の制御構文や代入などの加工処理を本発明でいう制御処理文に対応させ、それ以外を本発明でいうＳＱＬ文に対応させることによって、本発明に適用する。
【０００９】
コンパイルしたストアドプロシジャをフロントエンドのデータベースサーバに蓄えておき、必要に応じてホストプログラムから呼び出して実行する代案もある。
この場合、ホストプログラムは、使用したい名称のストアド・プロシージャをコールすることで、ストアド・プロシージャの実行要求を発し実行を行う。
ストアドプロシジャについては、片山初子:ストアド・プロシージャとトリガーを使いこなす、 NIKKEI OPEN SYSTEMS, No.2, pp.133-144,1993.などに記載されている。
【００１０】
以下に、ストアド・プロシージャを並列データベースシステムに対して適用する場合の実行について一例を記す。
ストアド・プロシージャのＳＱＬ文の処理手順が制御処理文にしたがって１文ずつ実行される。
制御処理文はコンパイルされたコードやインタプリタ用の内部形式など（以下、命令コードと呼ぶことにする）として実行され、その中にＳＱＬ文を実行する命令コードがある。
ＳＱＬ文を実行するときは、各ＳＱＬ文の処理手順は、実際にデータベース操作を行う複数のデータベース操作サーバにネットワークを通じて転送し実行する。
データベース操作サーバのキャッシュに各ＳＱＬ文の処理手順を置くことによって、２回目以降の実行は、実行要求を発しキャッシュにある処理手順を用いる改良案がある。
データベース操作の結果は、必要に応じて他のデータベース操作サーバとネットワークを通じてデータなどのやりとりを行い、最終的にストアド・プロシージャに返され、制御処理文によって加工や制御を行う。以下ＳＱＬ文１文ずつについて同じ処理を繰り返す。ストアド・プロシージャの実行が全て終了するとその実行結果がホストプログラムに返される。
【００１１】
本発明は並列データベースシステムでストアドプロシジャを前提としており、データベースの主流であるリレーショナルデータベース、ＳＱＬにより説明を行う。
しかし、データベース操作文を制御処理文に埋めこんだ問い合わせをフロントエンドのデータベースサーバで解析し、データベース操作文の処理を複数のデータベース操作サーバが行う並列データベースシステムの構成であれば、リレーショナルデータベース、ＳＱＬで無くても適用できる。
例として、データベース操作サーバがオブジェクト指向データベースであり、データベース操作言語がオブジェクト指向操作の言語の場合、データベース操作文として、ＳＱＬ文をオブジェクト指向操作文に置き換えることで適用できる。オブジェクト指向データベースのデータベース操作言語の１つOQLについては、R.G.G.Cattell編：オブジェクトデータベース標準：ODMG-93,共立出版株式会社,pp85-104,1995などに記載されている。
【００１２】
【発明が解決しようとする課題】
埋込型ＳＱＬの場合もストアド・プロシージャの場合も、コンパイルされたＳＱＬ文（データベース操作文）の処理手順は、複数のデータベース操作サーバに対して、ＳＱＬ文１文ごとに転送し実行される。
並列システムで無ければ、サーバは分かれていなく、ホストプログラムとのフロントエンドもデータベース処理も１つのサーバで行われるのでサーバ間の通信ネックは存在しない。
しかし、並列システムの場合は、フロントエンドサーバとデータベース操作サーバ間にＳＱＬ文１文ごとに起動要求が必要になる。そのため、ループによりＳＱＬ文が繰り返し実行される場合は、起動要求の通信回数は、大きなものとなる。通信回数が多くなると通信がネックになって性能が低下する問題が生じる。
【００１３】
ここで、問い合わせの中のＳＱＬ文には同じデータベース操作サーバで実行するものがある。同じサーバで実行するＳＱＬ文の内部形式をまとめて転送し、起動すれば、通信回数は減る。
並列システムに対して、まとめて転送できるＳＱＬ文とはどのようなものか、また、各ＳＱＬ文を実行するデータベース操作サーバは複数あるためどのような方法でまとめるかが問題となる。
【００１４】
本発明は問い合わせの中の複数のＳＱＬ文を、１回の起動要求で実行できる内部形式にまとめて転送し、１回の起動要求で複数のＳＱＬ文を起動することにより、起動要求の回数を減らし、フロントエンドのデータベースサーバとデータベース操作サーバ間の通信回数を減らすことが目的である。
【００１５】
【課題を解決するための手段】
上記目的を達成するために、本発明は、
データベースへの問い合わせを解析するフロントエンドのデータベースサーバと、データベースに対する操作を行う複数のデータベース操作サーバを有し、該フロントエンドのデータベースサーバと複数のデータベース操作サーバとがネットワークで接続された並列データベースシステムにおいて、
前記フロントエンドのデータベースサーバは、複数のデータベース操作文を含んだデータベースへの問い合わせを解析し、対応する内部形式を作成し、該内部形式を実行して内部形式の中のデータベース操作文を複数のデータベース操作サーバに送り実行する過程において、
前記解析時に、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上のデータベース操作文を抽出してグループ化し、
前記内部形式を実行する時に、前記グループ化したデータベース操作文をデータベース操作サーバにまとめて転送し、
前記データベース操作サーバに対して、転送した複数のデータベース操作文を一回の起動要求で起動するようにしている。
【００１６】
また、グループ化した各データベース操作文を転送するデータベース操作サーバを、データベースシステム内の各表と表の分割されているデータベース操作サーバとの対応関係を示す表分割情報に基づき決定するようにしている。
さらに、前記表分割情報に基づき転送先のデータベース操作サーバの決定した前記グループ化した各データベース操作文をそれぞれ転送先のデータベース操作サーバにまとめて転送し、転送した複数のデータベース操作文を一回の起動要求で起動するようにしている。
【００１７】
また、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上の前記データベース操作文に対して同じ識別子を付与することによりグループ化するようにしている。
【００１８】
また、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上の前記データベース操作文と、該データベース操作文を含む制御処理文の夫々とをグループ化するようにしている。
【００１９】
また、同じデータベース操作サーバで一回の実行要求で実行できるデータベース操作文とは、前記の複数のデータベース操作文の中で、内部形式の中で実行する順番が連続しているデータベース操作文であり、分割列の更新操作文の後に同じ表に対するデータベース操作文が存在せず、かつ、先に行うデータベース操作文の結果を変数を媒介として後のデータベース操作文が使用しないデータベース操作文であるようにしている。
【００２０】
また、同じデータベース操作サーバで一回の実行要求で実行できるデータベース操作文とは、前記の複数のデータベース操作文の中で、内部形式の中で実行する順番が連続しているデータベース操作文であり、データベース操作を行う表が１つの同じデータベース操作サーバにあるデータベース操作文であるようにしている。
さらに、前記データベースに対する問い合わせの中にある全てのデータベース操作文のデータベース操作を行う表が１つの同じデータベース操作サーバにある場合、前記データベースに対する問い合わせの内部形式を該データベース操作サーバに転送し、実行するようにしている。
【００２１】
【発明の実施の形態】
以下において本発明の一実施例を図面を用いて説明する。
図１は本発明の実施例の構成図である。
ホストからのデータベースへの問い合わせに対するフロントエンドの役割をするデータベースサーバ１２と、データベースに対する操作を行う役割をする複数のデータベース操作サーバ１３で構成される。
フロントエンドデータベースサーバ１２とデータベース操作サーバ１３は、高速な相互結合ネットワークで繋がっているものとする。
ただし、ネットワークで繋がる複数プロセッサの並列データベースシステムで無く、単一プロセッサのシステムでも、各サーバの役割として並列なプロセスを割り当てていれば、プロセス間の通信回数を削減するものとして本発明に適用可能である。
フロントエンドデータベースサーバ１２は、外部のホスト１１とネットワークで繋がっているものとする。
ただし、本発明はフロントエンドのデータベースサーバ１２とデータベース操作サーバ１３の間の通信回数を削減するのが目的なので、ホストの役割をデータベースシステム側に取り込み、内部の高速なネットワークで繋げる代案や、ホストの役割とフロントエンドのデータベースサーバを１つに統合する代案に対しても本発明を適用できる。
【００２２】
ホスト１１からのストアドプロシジャ１２１をフロントエンドのデータベースサーバ１２で解析（１０１）することでストアドプロシジャの内部形式１２２を作成する。
作成したストアドプロシジャ内部形式１２２は、名称、制御処理文の内部形式、各ＳＱＬ文の内部形式の処理手順を有し、一回の通信で起動する幾つかのグループにグループ分けされている。いっしょに起動するＳＱＬ文が無いＳＱＬ文は、その１つのＳＱＬ文のみでグループを形成する（すなわち、従来通り、そのＳＱＬ文１つを起動する）。
制御処理文を実行（１０２）し、ＳＱＬ文を実行することになると（１０５）、グループごとの処理に入る。
表分割情報１２３をみてグループに対して実行するデータベース処理サーバ１３を決定し、行き先別ＳＱＬ文リストを作成する（１０７）。
続いてデータベース操作を行うため、各ＳＱＬの内部形式を行き先別の内部形式（以下、行き先別ＳＱＬ文内部形式１２４と呼ぶ）にまとめて、行き先別ＳＱＬ文内部形式を作成し（１０８）、データベース処理サーバ１３にＳＱＬ文内部形式を転送し（１０９）、起動要求をかける（１１０）。
データベース操作サーバ１３は、行き先別ＳＱＬ文内部形式１２５を受取り（１１２）、起動要求（１１０）により起動（１１３）し、データベース操作の結果をフロントエンド側１２に返す（１１４）。
各ＳＱＬのデータベース操作の結果はフロントエンドのデータベースサーバ１２で受け取り合成（１１１）し制御処理を続ける。
制御処理が終わるとストアドプロシジャの結果をホスト１１に返す（１０３）。
【００２３】
複数のＳＱＬ文に対し１回の転送（１０９）と起動要求（１１０）で済むため、通信回数が削減される。
データベース処理サーバ１３側のキャッシュメモリに行き先別のＳＱＬの内部形式１２５を置き、２回以上同じＳＱＬを実行する場合起動要求によりキャッシュメモリのＳＱＬを起動する方式もあるが、その場合は、２回目以降は行き先別内部形式生成（１０８）や転送（１０９）はいらない。
その場合でも起動要求が複数のＳＱＬ文に対し１回で済むのは同じであり、本発明の適用ができ発明の効果が期待できる。
ホスト１１からのストアドプロシジャ１２１を解析（１０１）し内部形式１２２を登録しておき、ホスト１１からストアドプロシジャの実行要求を行いストアドプロシジャの実行を行う方式もあるが、その場合でも本発明は解析と実行のフェーズが分れるだけで問題無く適用できる。
その場合１回の通信で起動要求するＳＱＬのグループ分けをストアドプロシージャの実行フェーズに行う代案も適用できる。
【００２４】
図２は、ストアドプロシージャ１２１の例である。
制御構文であるＷＨＩＬＥ文２０２、２０６や、代入文であるＳＥＴ文２０１、２０５が、本発明で制御処理文と呼ぶ文の例である。
ＳＥＬＥＣＴ文２０３やＵＰＤＡＴＥ文２０４が、本発明でデータベース操作文またはＳＱＬ文と呼ぶ文の例である。
データベース操作文は制御処理文中に埋めこまれているという表現を使うことにする。制御処理文中のデータベース操作文のところには暗黙的にデータベース操作文を実行する処理があるものとし、この処理も制御処理文にいれることにする。
これによって、データベースに対する問い合わせ１２１がＳＱＬ文のみの並びの場合でも、本発明を適用できる。
ＳＱＬにはＳＥＬＥＣＴ、ＵＰＤＡＴＥなどデータにアクセスする文の他に、ＣＲＥＡＴＥ文などのデータベースの定義を行う文やカーソルの処理を行う文も存在する。定義やカーソルの処理の文などの、データにアクセスする文以外の文は、データベース操作サーバで行う処理では無いので、従来通り、１つ１つ処理を行う。
【００２５】
実施例ではデータベース操作文としてＳＱＬを用いているが、データベース処理サーバがオブジェクト指向データベースの場合、データベース操作文を、ＳＱＬ文で無く、オブジェクト指向データベース操作言語の参照、更新、削除、挿入のデータベース操作文とすると本発明を適用できる。
データベース操作サーバが複数存在し、制御処理文にデータベース操作文が埋め込まれた形の問い合わせであれば良い。
【００２６】
図３は、実施例における図１のストアドプロシジャ内部形式１２２の例である。
ストアドプロシジャ内部形式１２２は名称３０１、ＳＱＬ文の制御処理文内部形式３０２、ＳＱＬ文内部形式３０３、１回の通信で起動要求するものを同じ番号とする識別子３０４を有する。
制御処理文内部形式はＳＱＬ文内部形式を実行する処理の内部形式を含む。
【００２７】
ＳＱＬ文内部形式は、アクセスする表の識別子や、参照、更新、削除、挿入などのＳＱＬ文の種類、分割カラムの更新かなどの情報を有する。
ストアドプロシジャ内部形式１２２は、図１の解析（１０１）により作成し、その際に、１回の通信で起動要求するものを同じ番号とする識別子３０４がふられる。
制御処理文の１部をいっしょにデータベース処理サーバ１３に送り実行する方式の場合には、制御処理文にも識別子をふる方法や、１回の起動要求で実行できる制御処理文とＳＱＬ文で新たにプロシジャ１２２を作成しポイントする方法が考えられる。
図２の例の場合ＳＱＬ１とＳＱＬ２の識別子３０４が同じ番号であるので１回の起動要求で実行するグループである。
ストアドプロシジャ１２１がＳＱＬ文のみの並びの場合は、制御処理文内部形式は各ＳＱＬ文内部形式を実行する処理の内部形式の並びである。この場合、ＳＱＬ文内部形式の並びを実行順序として、制御処理文内部形式を省略する代案も適用できる。
【００２８】
図４は、実施例における図１の表分割情報１２３の例である。
表分割情報１２３はデータベースシステム内の各表に対し、表の識別子と、その表の分割されているデータベース操作サーバの識別子を有する。
図４の例の場合、表Ｔ１はデータベース処理サーバ１、サーバ２、サーバ３に、表Ｔ２はデータベース処理サーバ１、サーバ２に、表Ｔ３はデータベース処理サーバ２、サーバ３に表Ｔ４はデータベース処理サーバ１に分割している。
分割の種類が分割列のキー範囲やハッシュ値による分割の場合はサーバごとに分割範囲を有する。
ＳＱＬ文のＷＨＥＲＥ句に分割列の条件がある場合に分割範囲によって実行するサーバを限定する改良案を適用できる。
【００２９】
図５は、実施例における図１の行き先別ＳＱＬ文リスト１２４の例である。
行き先別ＳＱＬ文リスト１２４は、解析（１０１）で分けたグループに対して、実行を行うデータベース処理サーバ１３である行き先サーバと、その行き先サーバに転送するＳＱＬ文内部形式識別子を有する。
【００３０】
図６は、実施例における、図１の行き先別ＳＱＬ文内部形式１２５の例である。
行き先であるデータベース操作サーバの識別子６０１、グループ内のＳＱＬ文内部形式の数６０２、ＳＱＬ文内部形式へのポインタ６０３をＳＱＬ内部形式の数６０２分、各ＳＱＬ文内部形式６０４を有する。
複数のＳＱＬ文を１つの内部形式１２５にまとめることにより、１回の起動要求で、複数のＳＱＬ文を逐次または並列に実行することができる。
【００３１】
図７は、実施例の図１の解析（１０１）における１回の起動要求で実行できるＳＱＬ文をグループに分ける処理の処理説明図である。
この処理では解析（１０１）で作成された、ＳＱＬ文の制御処理文順に次の埋め込みＳＱＬ文がある場合、各２つのＳＱＬ文に変数のやりとりなどが無いか調べ、有れば新たな識別子を付与し、無ければ同一の識別子を付ける。
ただし、Ｃ言語のｇｏｔｏ文のようなジャンプを行う制御処理文がある場合は実行順の先後が判定できる単純な場合を除いて本発明の適用は行わない。
また、ループを行う制御処理ごとに複数のＳＱＬ文をグループにする方法をとる場合には、ループを行う制御処理の間のＳＱＬ文は、繰り返し実行されるため、実行順の先後がどちらにもなるものとして適用する。
図７では識別子を１から順に付けて分けているが、同じグループを識別できれば他の識別方法でも良い。分けた後のストアドプロシジャ内部形式の例は前述の図３である。
【００３２】
まずグループに付ける識別子に初期値１を入れる（７０２）。
制御処理文順に次の埋め込みＳＱＬ文があるか判定し（７０３）、無ければ処理を終了する。有ればこれから識別子を付けるＳＱＬ文を取り出し（７０４）、現在調べているグループの識別子を付ける（７０５）。次に（７０６）の判定を行なう。
現在調べているグループのＳＱＬ文１つずつと、（１）変数による結果のやりとりがある（７０７）かを調べ、（２）共に同じ表に対するデータベース操作文であり（７０８）、先に行なうデータベース操作文が分割カラムの更新問い合わせ（７０９）かを調べ、（１）、（２）の条件のいずれかに適合する場合は、１回の起動要求で実行できないためグループを変える（７１１）、（７１２）。
しかし、（１）の条件を満たさず、かつ異なる表を対象とする問い合わせ（７０８）の場合、また、（１）の条件を満たさず、かつ同じ表を対象とする問い合わせ（７０８）であり、かつ（２）の条件を満たさない場合にはグループの識別子をそのままとする。
実行順序、変数のやりとりは制御処理文内部形式に情報があり、ＳＱＬ文がアクセスする表、更新処理か、分割カラム更新か、はＳＱＬ文内部形式に情報がある。
図７の例では内部形式を作成した後、グループ分けを行う例になっているが、グループ分けなどの解析処理を行いやすいように、実行順序、変数のやりとり、ＳＱＬ文がアクセスする表、更新処理か、分割カラム更新か、などの情報を抽出済みの中間形式を作成し、グループ分けをしたあとで実行用の内部形式に変換する代案も適用できる。また、内部形式の作成と並行してグループ分けを進める代案も適用できる。
解析（１０１）により前述の図３のように一回の起動要求で実行するものをまとめたストアドプロシジャ内部形式１２２が作成される。
【００３３】
図８は、実施例の図１のグループ分割決定（１０７）の処理説明図である。
この処理は、１回の起動要求で実行できるものとしてグループ化されているＳＱＬ文に対して、表分割情報１２３を見て、処理手順内部形式の行き先別のリストを作成する。
行き先別に内部形式を変えるのは、データベース操作サーバにより実行するＳＱＬ文が異なるため無駄なＳＱＬ文内部形式の転送を押さえるためである。
【００３４】
まず、１回の起動要求で実行可能なものとしてグループ化されているＳＱＬ文を１つずつ取り出す（８０１）、（８０２）。
表分割情報１２３を見て、そのＳＱＬがアクセスする表が存在するデータベース操作サーバ１３の識別子を取り出す（８０４）。
そのデータベース操作サーバについての行き先別のＳＱＬ文のリスト１２４が存在すれば（８０５）、ＳＱＬ文の識別子を登録し（８０７）、存在しなければ、そのデータベース操作サーバについての行き先別のＳＱＬ文のリスト１２４を作成し（８０６）、登録する（８０７）。
グループ内の全てのＳＱＬについて分割したならば（８０９）、行き先別にＳＱＬ文をまとめる。
ただし、２表以上の表にアクセスするＳＱＬ文については、各表のアクセス用に異なる内部形式の処理手順を作成する方式をとる場合には、ＳＱＬ文では無く、処理手順ごとに行き先別のリストを作成し、以下、各表のアクセス用の処理手順を部分的なＳＱＬ文として１表にアクセスするＳＱＬ文と同等に扱うことで本発明を適用できる。
【００３５】
図９は、実施例の図１の行き先別ＳＱＬ文内部形式生成（１０８）の処理説明図である。
行き先別ＳＱＬ文内部形式１２５の例は前述の図６である。
ＳＱＬ文内部形式をまとめる場合、１回の起動要求で実行するＳＱＬ文の数（６０２）分のポインタ（６０３）を配列で用意し、各ＳＱＬ文の内部形式（６０４）をポイントする。
グループ分割決定１０７により行き先サーバとそこで起動するＳＱＬ文内部形式が行き先別ＳＱＬ文リスト１２４にまとめてある。
【００３６】
行き先別ＳＱＬ文リスト１２４の行き先サーバ１つずつに対して行き先別ＳＱＬ文内部形式１２５を作る（９０１）。
行き先サーバの識別子を入れ（９０２）、起動するＳＱＬ文の数を数えて（９０３）、該数を入れる領域を設けて、この領域に該数を入れ（９０４）、ＳＱＬ文の数分のポインタを用意し（９０５）、ＳＱＬ文内部形式とＳＱＬ内部形式へのポインタをいれる（９０７）、（９０８）。
図９の例では、行き先別に異なる内部形式を作成するが、代案として、グループ内のＳＱＬ文をまとめた内部形式を１つ作成し、データベース操作サーバ側で、アクセスする表の有無などによって起動するＳＱＬを判断する代案も適用できる。
【００３７】
図１０は、実施例の図１の行き先別ＳＱＬ文内部形式転送（１０９）の処理説明図である。
行き先別ＳＱＬ文内部形式を１つずつ取り出し（１００１）、行き先サーバに転送する（１００２）。
行き先別ＳＱＬ文内部形式を受け取ったデータベース操作サーバが受取り報告をフロントエンドのデータベースサーバ１２に返し、全て受け取ったのを確認してから起動要求１１０に移る代案も適用できる。
また、行き先別ＳＱＬ文内部形式を受け取り、そのまま起動を行う代案も考えられるが、その場合、内部形式の転送が起動を兼ねており、転送回数が減っているため、通信回数を減らす発明の効果が期待できる。
【００３８】
図１１は、実施例の図１の行き先別ＳＱＬ文内部形式起動要求１１０の処理説明図である。
１回の通信で起動要求できるグループごとに実行する各データベース操作サーバに起動要求をかける（１１０２）。
データベース操作サーバ１３側は、起動要求を受けると（１１０３）と、行き先別のＳＱＬ文内部形式１２５の配列からポイントされた内部形式６０４を、配列順に逐次に、もしくは、並列に起動する（１１０５）。
１回の起動要求で起動する相手は図６のように複数のＳＱＬ文であるため、起動要求の通信回数が削減される。
データベース操作サーバ１３のキャッシュメモリに行き先別ＳＱＬ文内部形式１２５のキャッシュを置く代案もあるが、いずれにしても複数のＳＱＬ文に対して１回の起動要求ですむため通信回数は削減されるので、本発明が適用できる。
【００３９】
図１２は、実施例における図１の検索結果合成１１１の処理説明図である。
図１３は検索結果合成の例の模式図である。
起動要求したデータベース操作サーバ１３からＳＱＬ文ごとに転送処理が行われ（１２０７）、実行結果を取り出し（１２０８）、実行結果が無くなるまで（１２０９）、結果が転送される（１２１０）。実行結果が無くなると（１２０９）、結果終了の報告を送る（１２１１）。
フロントエンドのデータベースサーバ１２側は、ＳＱＬ文ごとに結果の受取り処理を行う（１２０１）。
結果受取りの処理手順を解析時に作成しても良い。
各データベース操作サーバ１３からの結果は、キューなどにより結果を送られてきた順に取り出される（１２０２）。
起動したデータベース操作サーバ１３から全て結果終了の報告が送られてくるまで（１２０５）、結果を受け取る（１２０４）。結果終了の報告が送られてきたら（１２０５）、（１２０６）の処理を行なう。
結果は共用メモリなどにおいておき、制御処理文内部形式の実行時に取り出される。
図１２では、結果転送１１４や結果受取り１１１をＳＱＬ文ごとに逐次行っているが、制御処理文実行と各ＳＱＬ文の結果受取りを別プロセスで並列に行う改良案も適用できる。
【００４０】
図１４は本発明を具体的なＳＱＬ文や制御処理文に適用する具体例の概要図である。
ストアドプロシジャの内容はＳＱＬ文制御処理文１４０２の内容である。実際は内部形式で表される。
図７の処理説明図と照らして解析処理（１０１）を見ると、制御処理文順にＳＱＬ文１、ＳＱＬ文２となり、ＳＱＬ１の出力はＳＱＬ２の入力とはなっておらず（７０７）、ＳＱＬ１は表Ｔ１を対象にし、ＳＱＬ２は表Ｔ２を対象としているため、ＳＱＬ１とＳＱＬ２は、異なる表を対象とする問い合わせであるため（７０８）、同じグループの識別子がふられる。
また図８の処理説明図と照らしてグループの分割決定処理（１０７）を見ると、ＳＱＬ１とＳＱＬ２は同じ集合Ｚに入る（８０１）。
ＳＱＬ１はＴ１への問い合わせであるため、表分割情報１２３よりサーバ１、サーバ２、サーバ３が取り出され（８０３）、サーバ１、サーバ２、サーバ３の各行き先別のＳＱＬ文リストが作成され（８０６）、ＳＱＬ文１の識別子がこのリストに登録される（８０７）。
ＳＱＬ２はＴ２への問い合わせであるため、表分割情報１２３よりサーバ１、サーバ２が取り出され（８０３）、サーバ１、サーバ２の行き先別のＳＱＬ文リストは上記したように既に作成されているので、サーバ１、サーバ２のＳＱＬ文リストにＳＱＬ文２の識別子が登録される（８０７）。
結果として、サーバ１（１３ａ）にＳＱＬ文１とＳＱＬ文２の処理手順が、サーバ２（１３ｂ）にＳＱＬ文１とＳＱＬ文２の処理手順が、サーバ３（１３ｃ）にＳＱＬ文１の処理手順が、１回の起動要求で実行されるプロシジャとして作成され、転送され実行される。
【００４１】
データベース操作サーバ１３ａ、１３ｂにおいて、ＳＱＬ１とＳＱＬ２の処理は逐次または並列に実行することが可能である。一回の起動要求で実行するデータベース処理の中に、更新、削除、挿入と、同じ表への検索が混ざっていない限り、実行順序は変えられるため並列に実行することも可能なのである。
また各データベース処理サーバ間で同じＳＱＬ文に対して開始の待ち合わせをしないため、サーバによってデータ量の偏りがある場合でも、各サーバごとに最短の時間でＳＱＬの処理が行われる。従来方式だと偏りが大きい処理が終わるのを待たないと次のＳＱＬの処理に進めない。
同様に、データベースサーバごとに実行するＳＱＬ文が異なる場合も、各データベース処理サーバ間で同じＳＱＬ文に対して開始の待ち合わせをしないことから、各サーバごとに最短の時間でＳＱＬの処理が行われる。
【００４２】
図１５は、図１のストアドプロシジャ内部形式１２２の図３とは別の実施例を示す。
ストアドプロシジャ内部形式は名称１５０１、ＳＱＬ文制御処理文内部形式１５０２、ＳＱＬ文内部形式１５０３を有する。
制御処理文内部形式１５０２は、グループにする幾つかのＳＱＬ文と制御処理文の１部分を有する内部形式（以下サブプロシジャ１５２と呼ぶことにする）の呼び出しを有する。
サブプロシジャ１５２を形成しないＳＱＬ文、すなわち、単独で起動されるＳＱＬ文（図の場合、ＳＱＬ文３、ＳＱＬ文７）は従来通りＳＱＬ文内部形式１５０３としてＳＱＬ文制御処理文内部形式１５０２に埋めこまれる。
図３と異なる主要な点は、１回の起動要求で実行できるＳＱＬ文内部形式をサブプロシジャというストアドプロシジャと類似の形式でグループ１５０７にすること、及び、各ＳＱＬ文が埋め込まれている制御処理文内部形式の１部１５０５を一緒にグループにすることである。
サブプロシジャ１５２（図の場合、１５２ａ、１５２ｂ）は名称１５０４、制御処理文の内部形式の１部分１５０５とＳＱＬ文の内部形式の処理手順１５０６を有する。各ＳＱＬ文は同一のデータベース操作サーバにアクセスするものである。
また入力や出力となる変数がある場合は入力変数、出力変数など入出力の情報が必要である。
【００４３】
図１６は、図１の解析（１０１）の図７の実施例とは別の実施例の処理説明図である。
ＳＱＬ文の制御処理文順に複数の各ＳＱＬ文のアクセスする表が同じ１つのデータベース操作サーバ１３にある場合に、サブプロシジャ１５２にまとめる。
ＳＱＬ文の内部形式を制御処理順にサーチし（１６０２）、次のＳＱＬ文があれば、これを取り出しＳＱＬ文２とし（１６０３）、（１６０４）、アクセスする表の分割されているデータベース操作サーバ１３を調べ（１６０５）、サーバ１３が１つであり（１６０６）、同じサーバにアクセスするＳＱＬ文であれば（１６０７）、サブプロシジャを作るためのグループにすることができる（１６０８）。
１つの同じデータベース操作サーバにアクセスする連続するＳＱＬ文のグループができたならば、それらのＳＱＬ文を埋め込む前後の制御処理文内部形式を抽出し、サブプロシジャ１５２を生成する（１６０９）、（１６１１）、（１６１２）。
制御処理文内の変数の入出力によっては、サブプロシジャ１５２の入力、及び、出力となる変数を抽出する。
【００４４】
図１６の例では内部形式を作成した後、グループ分けを行う例になっているが、グループ分けや前後の制御処理文などの解析処理を行いやすいように、実行順序、変数の入出力、ＳＱＬ文がアクセスする表などの情報を抽出済みの中間形式を作成し、グループ分けをしたあとで実行用の内部形式に変換する代案も適用できる。
また、サブプロシジャ１５２の作成と並行してグループ分けを進める代案も適用できる。
図１６の例であると、サブプロシジャ１５２が図１の行き先別ＳＱＬ文内部形式１２５に対応するため、図１の行き先別ＳＱＬ文内部形式生成１０８の処理が必要無い。
また、サブプロシジャ１５２に入力変数がある場合は、起動要求とともに入力の値を転送すれば良い。
結果の合成はＳＱＬ文ごとで無く、サブプロシジャの出力を受け取り使用するのみの簡単な処理になる。
また、ストアドプロシジャ１２１の全てのデータベース操作文が１つの同じデータベース操作サーバ１３に分割してある場合は、サブプロシジャ１５２としてストアドプロシジャごとデータベース操作サーバ１３に転送し実行する改良案を適用できる。
その場合、データベース操作サーバ１３側でのストアドプロシジャの実行結果をフロントエンドのデータベースサーバ１２を介さずに、直接、ホスト１１に返す代案が適用できる。
他にも図７や図１６のように１連の制御処理文やＳＱＬ文が、他のデータベース処理サーバ１３に影響しないことを抽出すれば、図３のようにグループの識別子を付ける方法や図１５のサブプロシジャ１５２を作成する方法などによりグループ分けすることで、１回の起動要求で実行することができるため、本発明を適用できる。
【００４５】
図１７はサブプロシジャ１５２を用いて１回の起動要求で複数のＳＱＬ文を起動する具体例の概要図である。
データベース操作文と制御処理文を含むサブプロシジャ１５２を作成し、各データベース操作サーバ１３で１回の起動要求で起動し、結果はフロントエンドのデータベースサーバ１２で受け取り、ストアドプロシジャの処理に渡す。
【００４６】
図１８は１つの同じデータベース操作サーバにアクセスする複数のＳＱＬ文をまとめて起動する具体例の概要図である。
サブプロシジャとしてストアドプロシジャごとデータベース操作サーバ側で実行する例である。
問い合わせ１２２中のＳＱＬ文のアクセスする表が全てサーバ１であり１つの同じデータベース操作サーバであるため、ストアドプロシジャ内部形式１２２ごとデータベース操作サーバに送り実行する。
結果はフロントエンドのデータベースサーバ１２を経由してホスト１１に返す方法と、直接ホスト１１に返す方法が考えられる。
ストアドプロシジャ１２２ごとデータベース操作サーバ側１３で実行すれば、フロントエンドのデータベースサーバ１２とデータベース操作サーバ１３の間で、起動要求だけでなく、結果のやりとりも無くなるため大幅な通信の削減が見込まれる。
【００４７】
【発明の効果】
以上のように、本発明によれば、複数のデータベース操作文に対し１回の起動要求で実行を行うことで、通信回数を減らし、通信ネックによる性能低下を抑えることができる。
また、表分割情報を用いて、各データベース操作サーバに必要なデータベース操作文のみを送ることで最小限の転送量ですむ。
また、複数のデータベース操作文とともに制御処理文をデータベース操作サーバに送る場合、データベース操作文の結果をデータベース操作サーバ側で制御処理するため、フロントエンドのデータベースサーバとデータベース操作サーバ間で結果転送の通信負荷を削減できる。
また、複数のデータベース操作文が各データベース操作サーバで待ち合わせ無しに実行されるため、データの偏りがある場合に実行時間が短縮される。
【図面の簡単な説明】
【図１】実施例の構成を示す図である。
【図２】ストアドプロシジャの例を示す図である。
【図３】ストアドプロシジャ内部形式の例を示す図である。
【図４】表分割情報の例を示す図である。
【図５】行き先別ＳＱＬ文リストの例を示す図である。
【図６】行き先別ＳＱＬ文内部形式の例を示す図である。
【図７】ＳＱＬ文をグループに分ける処理のフローチャートを示す図である。
【図８】グループ分割決定の処理のフローチャートを示す図である。
【図９】行き先別ＳＱＬ文内部形式生成の処理のフローチャートを示す図である。
【図１０】行き先別ＳＱＬ文内部形式転送の処理のフローチャートを示す図である。
【図１１】行き先別ＳＱＬ文内部形式起動要求の処理のフローチャートを示す図である。
【図１２】検索結果合成の処理のフローチャートを示す図である。
【図１３】検索結果合成の例を示す図である。
【図１４】具体例の概要を示す図である。
【図１５】ストアドプロシジャ内部形式の例を示す図である。
【図１６】ＳＱＬ文をグループに分ける処理のフローチャートを示す図である。
【図１７】具体例の概要を示す図である。
【図１８】具体例の概要を示す図である。
【符号の説明】
１１ ホスト
１２ フロントエンドのデータベースサーバ
１３ データベース操作サーバ
１０１ 解析
１０７ グループ分割決定
１０８ 行き先別ＳＱＬ文内部形式生成
１０９ 行き先別ＳＱＬ文内部形式転送
１１０ 行き先別ＳＱＬ文内部形式起動要求
１１１ ＳＱＬ文結果合成
１２１ ストアドプロシジャ
１２２ ストアドプロシジャ内部形式
１２３ 表分割情報
１２４ 行き先別ＳＱＬ文リスト
１２５ 行き先別ＳＱＬ文内部形式
１５２ サブプロシジャ
２０１、２０２、２０５、２０６ 制御処理文
２０３、２０４ データベース操作文
Claims (8)
- データベースへの問い合わせを解析するフロントエンドのデータベースサーバと、データベースに対する操作を行う複数のデータベース操作サーバを有し、該フロントエンドのデータベースサーバと複数のデータベース操作サーバとがネットワークで接続された並列データベースシステムにおいて、
前記フロントエンドのデータベースサーバは、複数のデータベース操作文を含んだデータベースへの問い合わせを解析し、対応する内部形式を作成し、該内部形式を実行して内部形式の中のデータベース操作文を複数のデータベース操作サーバに送り実行する過程において、
前記解析時に、同じデータベース操作サーバで一回の起動要求で実行できる１つ以上のデータベース操作文を抽出してグループ化し、
前記内部形式を実行する時に、前記グループ化したデータベース操作文をデータベース操作サーバにまとめて転送し、
前記データベース操作サーバに対して、転送した複数のデータベース操作文を一回の起動要求で起動することを特徴とする並列データベースシステム通信回数削減方法。 - 請求項１記載の並列データベースシステム通信回数削減方法において、
グループ化した各データベース操作文を転送するデータベース操作サーバを、データベースシステム内の各表と表の分割されているデータベース操作サーバとの対応関係を示す表分割情報に基づき決定することを特徴とする並列データベースシステム通信回数削減方法。 - 請求項２記載の並列データベースシステム通信回数削減方法において、
前記表分割情報に基づき転送先のデータベース操作サーバの決定した前記グループ化した各データベース操作文をそれぞれ転送先のデータベース操作サーバにまとめて転送し、転送した複数のデータベース操作文を一回の起動要求で起動することを特徴とする並列データベースシステム通信回数削減方法。 - 請求項１記載の並列データベースシステム通信回数削減方法において、
同じデータベース操作サーバで一回の起動要求で実行できる１つ以上の前記データベース操作文に対して同じ識別子を付与することによりグループ化することを特徴とする並列データベースシステム通信回数削減方法。 - 請求項１記載の並列データベースシステム通信回数削減方法において、
同じデータベース操作サーバで一回の起動要求で実行できる１つ以上の前記データベース操作文と、該データベース操作文を含む制御処理文の夫々とをグループ化することを特徴とする並列データベースシステム通信回数削減方法。 - 請求項１記載の並列データベースシステム通信回数削減方法において、
同じデータベース操作サーバで一回の実行要求で実行できるデータベース操作文とは、前記の複数のデータベース操作文の中で、内部形式の中で実行する順番が連続しているデータベース操作文であり、分割列の更新操作文の後に同じ表に対するデータベース操作文が存在せず、かつ、先に行うデータベース操作文の結果を変数を媒介として後のデータベース操作文が使用しないデータベース操作文であることを特徴とする並列データベースシステム通信回数削減方法。 - 請求項１記載の並列データベースシステム通信回数削減方法において、
同じデータベース操作サーバで一回の実行要求で実行できるデータベース操作文とは、前記の複数のデータベース操作文の中で、内部形式の中で実行する順番が連続しているデータベース操作文であり、データベース操作を行う表が１つの同じデータベース操作サーバにあるデータベース操作文であることを特徴とする並列データベースシステム通信回数削減方法。 - 請求項７記載の並列データベースシステム通信回数削減方法において、
前記データベースに対する問い合わせの中にある全てのデータベース操作文のデータベース操作を行う表が１つの同じデータベース操作サーバにある場合、前記データベースに対する問い合わせの内部形式を該データベース操作サーバに転送し、実行することを特徴とする並列データベースシステム通信回数削減方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP21057596A JP3808941B2 (ja) | 1996-07-22 | 1996-07-22 | 並列データベースシステム通信回数削減方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP21057596A JP3808941B2 (ja) | 1996-07-22 | 1996-07-22 | 並列データベースシステム通信回数削減方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1040146A JPH1040146A (ja) | 1998-02-13 |
| JP3808941B2 true JP3808941B2 (ja) | 2006-08-16 |
Family
ID=16591590
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP21057596A Expired - Fee Related JP3808941B2 (ja) | 1996-07-22 | 1996-07-22 | 並列データベースシステム通信回数削減方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3808941B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1308852C (zh) * | 1999-01-29 | 2007-04-04 | 株式会社数字设计 | 数据传输方法和数据传输系统 |
| JP3598495B2 (ja) * | 1999-01-29 | 2004-12-08 | 株式会社 デジタルデザイン | データ転送方法、コンピュータ読み取り可能な記録媒体及びデータ転送システム |
| CA2307155A1 (en) | 2000-04-28 | 2001-10-28 | Ibm Canada Limited-Ibm Canada Limitee | Execution of database queries including filtering |
| JP4131514B2 (ja) | 2003-04-21 | 2008-08-13 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ネットワークシステム、サーバ、データ処理方法及びプログラム |
| AU2004235104A1 (en) * | 2003-04-25 | 2004-11-11 | Thomson Reuters Global Resources | Distributed search methods, architectures, systems, and software |
| US20050198437A1 (en) * | 2004-03-08 | 2005-09-08 | Mukherjee Shubhendu S. | Method and system for coalescing coherence messages |
| JP2006209316A (ja) * | 2005-01-26 | 2006-08-10 | Nec Corp | データベースアクセス管理システム、管理方法及びそのプログラム |
| KR100836619B1 (ko) * | 2006-11-24 | 2008-06-10 | 엔에이치엔(주) | Ｐ２ｐ 시스템에서 피어 관리 서버 및 피어 관리 방법 |
| JP2011171983A (ja) * | 2010-02-18 | 2011-09-01 | Sony Corp | 情報処理装置、情報処理方法およびコンピュータ読み取り可能な記録媒体 |
| JP5614340B2 (ja) * | 2011-03-16 | 2014-10-29 | 富士通株式会社 | システム、認証情報管理方法、およびプログラム |
| JP5652282B2 (ja) | 2011-03-18 | 2015-01-14 | 富士通株式会社 | 検索制御プログラム、検索制御方法、検索システム |
-
1996
- 1996-07-22 JP JP21057596A patent/JP3808941B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1040146A (ja) | 1998-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3747525B2 (ja) | 並列データベースシステム検索方法 | |
| US7921416B2 (en) | Formal language and translator for parallel processing of data | |
| JP3742177B2 (ja) | 並列データベースシステムルーチン実行方法 | |
| US7966311B2 (en) | Systems and methods for processing queries | |
| JP2755390B2 (ja) | データベース処理装置及びデータベース処理方法 | |
| US7769789B2 (en) | High performant row-level data manipulation using a data layer interface | |
| US6256621B1 (en) | Database management system and query operation therefor, including processing plural database operation requests based on key range of hash code | |
| EP1240604B1 (en) | A method and apparatus for improving the performance of a generated code cache search operation through the use of static key values | |
| US6374236B1 (en) | Parallel optimized triggers in parallel processing database systems | |
| US6556988B2 (en) | Database management apparatus and query operation therefor, including processing plural database operation requests based on key range of hash code | |
| JPH1125096A (ja) | データベースをサーチする方法およびコンピュータシステム | |
| US20050256897A1 (en) | Providing the timing of the last committed change to a row in a database table | |
| US9171036B2 (en) | Batching heterogeneous database commands | |
| US6421666B1 (en) | Mechanism for sharing ancillary data between a family of related functions | |
| US11314736B2 (en) | Group-by efficiency though functional dependencies and non-blocking aggregation functions | |
| CN111581234B (zh) | Rac多节点数据库查询方法、装置及系统 | |
| JP3808941B2 (ja) | 並列データベースシステム通信回数削減方法 | |
| US11704317B2 (en) | Partial group by for eager group by placement query plans | |
| US6938036B2 (en) | Query modification analysis | |
| US6353819B1 (en) | Method and system for using dynamically generated code to perform record management layer functions in a relational database manager | |
| US6470331B1 (en) | Very large table reduction in parallel processing database systems | |
| JPH11134368A (ja) | 言語管理プログラムインタフェース | |
| US7974968B2 (en) | Direct call threaded code | |
| CN110119275A (zh) | 一种分布式内存列式数据库编译执行器架构 | |
| US6438536B1 (en) | Method and system for dynamically generating code to enhance the performance of a relational database manager that provides access to a relational database |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040316 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060516 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060519 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |