JP2010066922A - データベース管理方法、データベース管理プログラム、および、データベース管理システム - Google Patents
データベース管理方法、データベース管理プログラム、および、データベース管理システム Download PDFInfo
- Publication number
- JP2010066922A JP2010066922A JP2008231402A JP2008231402A JP2010066922A JP 2010066922 A JP2010066922 A JP 2010066922A JP 2008231402 A JP2008231402 A JP 2008231402A JP 2008231402 A JP2008231402 A JP 2008231402A JP 2010066922 A JP2010066922 A JP 2010066922A
- Authority
- JP
- Japan
- Prior art keywords
- sql
- pool
- standby
- unit
- execution
- 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.)
- Withdrawn
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】データベースの前処理結果を効率的に管理して、データベースの処理性能を高めること。
【解決手段】更新対象のデータを格納する待機系ＤＢ２０１を有する待機系サーバ３は、実行系サーバ２からデータ処理要求の発行履歴データ１１１を受信すると、受信した発行履歴データ１１１のデータ処理要求に従って、待機系ＤＢ２０１のデータを更新することで、実行系ＤＢ１０１と待機系ＤＢ２０１とをデータ同期するとともに、受信した発行履歴データ１１１からデータ処理要求ごとの発行頻度を抽出し、抽出した発行頻度が多いほど、そのデータ処理要求が実行系ＳＱＬプール１０３に記憶される優先度合いを高くする旨のプール管理ルール１１４を作成し、実行系サーバ２のプール管理ルール１１４を更新する。
【選択図】図１
【解決手段】更新対象のデータを格納する待機系ＤＢ２０１を有する待機系サーバ３は、実行系サーバ２からデータ処理要求の発行履歴データ１１１を受信すると、受信した発行履歴データ１１１のデータ処理要求に従って、待機系ＤＢ２０１のデータを更新することで、実行系ＤＢ１０１と待機系ＤＢ２０１とをデータ同期するとともに、受信した発行履歴データ１１１からデータ処理要求ごとの発行頻度を抽出し、抽出した発行頻度が多いほど、そのデータ処理要求が実行系ＳＱＬプール１０３に記憶される優先度合いを高くする旨のプール管理ルール１１４を作成し、実行系サーバ２のプール管理ルール１１４を更新する。
【選択図】図１
Description
本発明は、データベース管理方法、データベース管理プログラム、および、データベース管理システムに関する技術である。
動的ＳＱＬはクライアントが発行するまでＳＱＬ文が確定しないため、クライアントの実行時にＳＱＬを前処理する必要がある。なおＳＱＬの前処理とは、Ｃ言語のコンパイルに相当するものである。
一回前処理したＳＱＬの前処理結果を保持しておき、同一ＳＱＬに対する二度目以降の前処理を省略する技術をＳＱＬプールと呼ぶ。ＳＱＬプールは揮発性のメモリ上に置くのが一般的である。
一回前処理したＳＱＬの前処理結果を保持しておき、同一ＳＱＬに対する二度目以降の前処理を省略する技術をＳＱＬプールと呼ぶ。ＳＱＬプールは揮発性のメモリ上に置くのが一般的である。
特許文献１に開示されているシステムは、システム終了時に前処理結果を不揮発性の記憶装置に退避することにより、ＳＱＬプールの有効性を高めている。
特開２００３−２７１４２８号公報
データベース管理システムの処理性能は、データベースへのアクセスだけでなく、ＳＱＬの前処理時間に左右される。
ＳＱＬ文が固定であればコンパイルと同時に前処理することができるが、ＳＱＬ文は固定ではなくＳＱＬ実行時にＳＱＬ文を作成して前処理を行う動的ＳＱＬを使用するのが一般的である。
また、システムの構成上、実行時の前処理が必須であるデータベース管理システムも存在する。
ＳＱＬ文が固定であればコンパイルと同時に前処理することができるが、ＳＱＬ文は固定ではなくＳＱＬ実行時にＳＱＬ文を作成して前処理を行う動的ＳＱＬを使用するのが一般的である。
また、システムの構成上、実行時の前処理が必須であるデータベース管理システムも存在する。
近年データベースへのアクセスは、ＣＰＵの６４ビット化に伴い使用できるメモリが増えたことにより、メモリ上にデータのすべてを配置するインメモリＤＢが幅広く利用できるようになったため、メモリ上のアクセス速度が高速化している。
データベースへのアクセスが高速化したことにより、更なる性能向上のためには動的ＳＱＬの前処理の高速化が重要となっている。
動的ＳＱＬの前処理に関しては、前処理自体を高速化する方法と、一回前処理した結果をキャッシュしておくＳＱＬプールを使用する方法と、の２つの方法がある。
前処理自体を高速化することも重要ではあるが、クライアントの発行するＳＱＬの前処理結果がＳＱＬプールに存在する確率を高めること、つまりキャッシュヒット率を高めることも重要である。
動的ＳＱＬの前処理に関しては、前処理自体を高速化する方法と、一回前処理した結果をキャッシュしておくＳＱＬプールを使用する方法と、の２つの方法がある。
前処理自体を高速化することも重要ではあるが、クライアントの発行するＳＱＬの前処理結果がＳＱＬプールに存在する確率を高めること、つまりキャッシュヒット率を高めることも重要である。
本発明は、このような背景に鑑みてなされたものであり、データベースの前処理結果を効率的に管理して、データベースの処理性能を高めることを、主な目的とする。
前記課題を解決するため、本発明は、クライアントからのデータ処理要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムによるデータベース管理方法であって、
更新対象のデータを格納する実行系ＤＢを有する前記実行系サーバが、
前記データ処理要求と、その前処理結果を対応づけて記憶する実行系ＳＱＬプールと、
前記データ処理要求ごとに前記実行系ＳＱＬプールに記憶される優先度合いを示すプール管理ルールと、を有し、
更新対象のデータを格納する待機系ＤＢを有する前記待機系サーバが、
前記実行系サーバから前記データ処理要求の発行履歴データを受信すると、
前記受信した発行履歴データのデータ処理要求に従って、前記待機系ＤＢのデータを更新することで、前記実行系ＤＢと前記待機系ＤＢとをデータ同期するとともに、
前記受信した発行履歴データから前記データ処理要求ごとの発行頻度を抽出し、前記抽出した発行頻度が多いほど、そのデータ処理要求が前記実行系ＳＱＬプールに記憶される優先度合いを高くする旨の前記プール管理ルールを作成し、前記実行系サーバの前記プール管理ルールを更新することを特徴とする。
その他の手段は、後記する。
更新対象のデータを格納する実行系ＤＢを有する前記実行系サーバが、
前記データ処理要求と、その前処理結果を対応づけて記憶する実行系ＳＱＬプールと、
前記データ処理要求ごとに前記実行系ＳＱＬプールに記憶される優先度合いを示すプール管理ルールと、を有し、
更新対象のデータを格納する待機系ＤＢを有する前記待機系サーバが、
前記実行系サーバから前記データ処理要求の発行履歴データを受信すると、
前記受信した発行履歴データのデータ処理要求に従って、前記待機系ＤＢのデータを更新することで、前記実行系ＤＢと前記待機系ＤＢとをデータ同期するとともに、
前記受信した発行履歴データから前記データ処理要求ごとの発行頻度を抽出し、前記抽出した発行頻度が多いほど、そのデータ処理要求が前記実行系ＳＱＬプールに記憶される優先度合いを高くする旨の前記プール管理ルールを作成し、前記実行系サーバの前記プール管理ルールを更新することを特徴とする。
その他の手段は、後記する。
本発明によれば、データベースの前処理結果を効率的に管理して、データベースの処理性能を高めることが可能となった。
以下、第１実施形態によるデータベース管理システムについて、図面を参照して説明する。
図１は、第１実施形態のデータベース管理システムを示す構成図である。データベース管理システムは、クライアント１、実行系サーバ２、および、待機系サーバ３がネットワーク９で接続されて構成される。なお、待機系サーバ３の台数は、１台でもよいし、複数台のクラスタリング構成でもよい。
ネットワーク９は、例えば、ＩＰ（Internet Protocol）ネットワークとして、または、各サーバ（実行系サーバ２および待機系サーバ３）がブレードサーバである場合には内部バスとして、構成される。
なお、図１の各装置（クライアント１、実行系サーバ２、待機系サーバ３）は、それぞれ演算処理を行う際に用いられる記憶手段としてのメモリ９２、前記演算処理を行うＣＰＵ（Central Processing Unit）９１、および、ネットワーク９を介して他装置と通信を行う通信インターフェース２０を少なくとも備えるコンピュータとして構成される。なお、メモリ９２は、ＲＡＭ（Random Access Memory）などにより構成される。ＣＰＵ９１は、メモリ９２上のプログラムを実行する。
クライアント１は、実行系サーバ２に対して、実行系サーバ２が管理するデータベースである実行系ＤＢ１０１に対してアクセスを要求する。
この要求するアクセスは、ＳＱＬを発行して前処理結果を取得する第１工程と、前処理結果を使用して実行系ＤＢ１０１に参照および更新を行う第２工程とに分かれる。以下、本実施形態では、第１工程とその効果を中心に説明する。
この要求するアクセスは、ＳＱＬを発行して前処理結果を取得する第１工程と、前処理結果を使用して実行系ＤＢ１０１に参照および更新を行う第２工程とに分かれる。以下、本実施形態では、第１工程とその効果を中心に説明する。
実行系サーバ２および待機系サーバ３は、障害対策としての冗長構成を採用する。待機系サーバ３は、実行系サーバ２に障害が発生したとき、実行系サーバ２の役割を代行することにより、障害が発生した実行系サーバ２の業務を引き継ぐ。
よって、実行系サーバ２および待機系サーバ３は、名称こそ異なるものの、同じサーバ装置が実行系サーバ２として動作する時間帯もあれば、待機系サーバ３として動作する時間帯もある。そのため、実行系サーバ２および待機系サーバ３は、同じ装置構成を採用している。
つまり、実行系サーバ２および待機系サーバ３は、符号の下２桁が同じ構成要素同士が同じ構成要素である。例えば、実行系ＤＢ１０１は、待機系ＤＢ２０１と対応する。
なお、同じ構成要素を有していても、各構成要素について、現在実行している系によって、休止している構成要素も存在する。例えば、サーバが実行系サーバ２として動作しているときには、分析予測部１２０は休止しているが、そのサーバが待機系サーバ３に系切替されたときには、分析予測部２２０として稼動を開始する。
なお、同じ構成要素を有していても、各構成要素について、現在実行している系によって、休止している構成要素も存在する。例えば、サーバが実行系サーバ２として動作しているときには、分析予測部１２０は休止しているが、そのサーバが待機系サーバ３に系切替されたときには、分析予測部２２０として稼動を開始する。
実行系サーバ２および待機系サーバ３は、障害時に実行系サーバ２から待機系サーバ３に役割を円滑に引き継ぐため、実行系ＤＢ１０１と待機系ＤＢ２０１とは、同期処理を行う。以下のいずれかの同期処理により、実行系ＤＢ１０１と待機系ＤＢ２０１とでデータ内容が同一になるようにする。
例えば、同期処理の一例として、実行系サーバ２は、待機系サーバ３に、発行履歴データ１１１が示すＳＱＬの処理を実行系ＤＢ１０１に適用することで、実行系ＤＢ１０１を更新し、その更新内容を差分形式のログとして送信する。待機系サーバ３は、受信した差分形式のログを待機系ＤＢ２０１に反映する。
または、同期処理の別の一例として、実行系サーバ２は、待機系サーバ３に、発行履歴データ１１１の更新内容を差分形式のログとして送信する。待機系サーバ３は、受信した差分形式のログを発行履歴データ２１１に反映する。そして、待機系サーバ３は、発行履歴データ２１１が示すＳＱＬの処理を待機系ＤＢ２０１に適用することで、実行系ＤＢ１０１と待機系ＤＢ２０１とでデータ内容が同一になるようにする。
例えば、同期処理の一例として、実行系サーバ２は、待機系サーバ３に、発行履歴データ１１１が示すＳＱＬの処理を実行系ＤＢ１０１に適用することで、実行系ＤＢ１０１を更新し、その更新内容を差分形式のログとして送信する。待機系サーバ３は、受信した差分形式のログを待機系ＤＢ２０１に反映する。
または、同期処理の別の一例として、実行系サーバ２は、待機系サーバ３に、発行履歴データ１１１の更新内容を差分形式のログとして送信する。待機系サーバ３は、受信した差分形式のログを発行履歴データ２１１に反映する。そして、待機系サーバ３は、発行履歴データ２１１が示すＳＱＬの処理を待機系ＤＢ２０１に適用することで、実行系ＤＢ１０１と待機系ＤＢ２０１とでデータ内容が同一になるようにする。
実行系前処理部１０２および待機系前処理部２０２は、ＳＱＬの前処理を行う。実行系前処理部１０２は、クライアント１が発行するＳＱＬの前処理を行い、待機系前処理部２０２は、実行系前処理部１０２および分析予測部２２０から受信したＳＱＬの前処理を行う。
実行系ＳＱＬプール１０３および待機系ＳＱＬプール２０３は、データベースを操作するコマンドである動的ＳＱＬの前処理結果を、対応づけて管理する。実行系ＳＱＬプール１０３および待機系ＳＱＬプール２０３は、それぞれプール管理ルール１１４およびプール管理ルール２１４に従い、前処理結果の格納および破棄を行う。
実行系サーバ２は、クライアント１が発行したＳＱＬ、および、発行した時刻を対応づけて組として、発行履歴データ１１１として保持する。
実行系サーバ２は、例えば、実行系ＤＢ１０１と待機系ＤＢ２０１との同期処理のタイミングで、発行履歴データ１１１を待機系サーバ３に送信する。待機系サーバ３は、受信した発行履歴データ１１１を自身の発行履歴データ２１１に書き込む。
なお、発行履歴データ１１１を送信するタイミングは、同期処理のタイミングに限らず、性能劣化が少ないタイミングであれば、いつでも送信し得る。
実行系サーバ２は、例えば、実行系ＤＢ１０１と待機系ＤＢ２０１との同期処理のタイミングで、発行履歴データ１１１を待機系サーバ３に送信する。待機系サーバ３は、受信した発行履歴データ１１１を自身の発行履歴データ２１１に書き込む。
なお、発行履歴データ１１１を送信するタイミングは、同期処理のタイミングに限らず、性能劣化が少ないタイミングであれば、いつでも送信し得る。
分析予測部２２０は、書き込まれた発行履歴データ２１１を分析し、今後クライアント１が発行するＳＱＬ、および、そのＳＱＬを発行する確率を、発行予測リスト２１３として予測する。待機系サーバ３は、予測した発行予測リスト２１３を、実行系サーバ２の発行予測リスト１１３に送信する。
なお、発行予測リスト２１３を作成する装置として、待機系サーバ３を採用することにより、以下の効果を得ることができる。
まず、待機系サーバ３は冗長系システムの構成要素として、実行系サーバ２とともに既に導入されている装置である。よって、新たに装置を新設するよりも、導入コストを抑えることができる。
次に、待機系サーバ３は、実行系サーバ２に障害が発生する前には、実行系サーバ２との同期処理だけを実行すればよいので、比較的負荷が低い装置である。よって、予測演算を行う余力があり、発行予測リスト２１３を作成する装置として、適している。つまり、待機系サーバ３の余裕のある計算資源を使用できるため、計算コストが高い予測手法が使用でき、高い精度で予測ができる。
さらに、発行履歴データ１１１から発行履歴データ２１１への通信処理は、冗長系システムの基本機能であるデータ同期処理に使用されるとともに、発行予測リスト２１３を計算するための入力パラメータにも使用される。しかし、待機系サーバ３とは別の休眠装置が発行予測リスト２１３を作成すると、実行系サーバ２は、その休眠装置に対して新たに発行履歴データ１１１を送信する処理が発生してしまう。よって、待機系サーバ３を用いることで、通信処理を新たに発生させることを抑制できる。
なお、発行予測リスト２１３を作成する装置として、待機系サーバ３を採用することにより、以下の効果を得ることができる。
まず、待機系サーバ３は冗長系システムの構成要素として、実行系サーバ２とともに既に導入されている装置である。よって、新たに装置を新設するよりも、導入コストを抑えることができる。
次に、待機系サーバ３は、実行系サーバ２に障害が発生する前には、実行系サーバ２との同期処理だけを実行すればよいので、比較的負荷が低い装置である。よって、予測演算を行う余力があり、発行予測リスト２１３を作成する装置として、適している。つまり、待機系サーバ３の余裕のある計算資源を使用できるため、計算コストが高い予測手法が使用でき、高い精度で予測ができる。
さらに、発行履歴データ１１１から発行履歴データ２１１への通信処理は、冗長系システムの基本機能であるデータ同期処理に使用されるとともに、発行予測リスト２１３を計算するための入力パラメータにも使用される。しかし、待機系サーバ３とは別の休眠装置が発行予測リスト２１３を作成すると、実行系サーバ２は、その休眠装置に対して新たに発行履歴データ１１１を送信する処理が発生してしまう。よって、待機系サーバ３を用いることで、通信処理を新たに発生させることを抑制できる。
実行系プール管理部１１０および待機系プール管理部２１０は、発行予測リスト１１３および発行予測リスト２１３から、プール管理ルール１１４およびプール管理ルール２１４を変更する。
プール管理ルール１１４およびプール管理ルール２１４は、実行系ＳＱＬプール１０３および待機系ＳＱＬプール２０３が格納するＳＱＬの取捨選択を行うためのルールである。
プール管理ルール１１４およびプール管理ルール２１４は、実行系ＳＱＬプール１０３および待機系ＳＱＬプール２０３が格納するＳＱＬの取捨選択を行うためのルールである。
表１は、実行系ＳＱＬプール１０３の一例を示す表である。実行系ＳＱＬプール１０３は、ＳＱＬ文と、そのＳＱＬ文に対して前処理が実行された結果である前処理結果と、を対応づけて管理する。
ここで、ＳＱＬ文の先頭には、理解の手助けとして、ＳＱＬ文を特定するためのＩＤを括弧書きで表記する。例えば、１行目の「SELECT * FROM T1」には、ＩＤ＝１が割り当てられている。
なお、実行系ＳＱＬプール１０３は、表１で示した情報に限定されず、その他の情報（前処理の実行時刻など）をさらに対応づけて管理してもよい。
ここで、ＳＱＬ文の先頭には、理解の手助けとして、ＳＱＬ文を特定するためのＩＤを括弧書きで表記する。例えば、１行目の「SELECT * FROM T1」には、ＩＤ＝１が割り当てられている。
なお、実行系ＳＱＬプール１０３は、表１で示した情報に限定されず、その他の情報（前処理の実行時刻など）をさらに対応づけて管理してもよい。
表２は、待機系ＳＱＬプール２０３の一例を示す表である。待機系ＳＱＬプール２０３は、実行系ＳＱＬプール１０３と同じデータ構成である。しかし、待機系ＳＱＬプール２０３に格納されている各レコードは、実行系ＳＱＬプール１０３に格納されている各レコードとは、一致しないこともある。
表３は、発行履歴データ１１１の一例を示す表である。発行履歴データ１１１は、ＳＱＬ文およびその発行時刻を組にして保持する。
なお、実行系ＳＱＬプール１０３は、表３で示した情報に限定されず、その他の情報（ＳＱＬ文を発行したクライアント１の装置ＩＤなど）をさらに対応づけて管理してもよい。
また、発行履歴データ２１１には、８時台のＳＱＬしか表記されていないが、９時台以降も存在し、その記載を省略する。
なお、実行系ＳＱＬプール１０３は、表３で示した情報に限定されず、その他の情報（ＳＱＬ文を発行したクライアント１の装置ＩＤなど）をさらに対応づけて管理してもよい。
また、発行履歴データ２１１には、８時台のＳＱＬしか表記されていないが、９時台以降も存在し、その記載を省略する。
表４は、発行確率遷移表１１２の一例を示す表である。発行確率遷移表１１２は、各ＳＱＬ文について、時系列ごとの発行確率の実測値を示す。
つまり、発行履歴データ１１１から発行確率遷移表１１２の作成方法は、次の式の通りである。
発行確率遷移表１１２における所定ＳＱＬ文のＸ時台の発行確率＝（発行履歴データ１１１で所定ＳＱＬ文がＸ時台に発行された回数）／（発行履歴データ１１１でＸ時台に発行されたＳＱＬ文の総数）
つまり、発行履歴データ１１１から発行確率遷移表１１２の作成方法は、次の式の通りである。
発行確率遷移表１１２における所定ＳＱＬ文のＸ時台の発行確率＝（発行履歴データ１１１で所定ＳＱＬ文がＸ時台に発行された回数）／（発行履歴データ１１１でＸ時台に発行されたＳＱＬ文の総数）
表５は、時系列ごとの予測を行うときの、発行予測リスト１１３の一例を示す表である。発行予測リスト１１３は、各ＳＱＬ文について、時系列ごとの発行確率の予測値を示す。
発行確率を時系列ごとに区切るデータ形式により、クライアント１が発行するＳＱＬが周期的に変化する場合、予測精度を高くすることができる。
発行確率を時系列ごとに区切るデータ形式により、クライアント１が発行するＳＱＬが周期的に変化する場合、予測精度を高くすることができる。
表６は、時系列に依存しない予測を行うときの、発行予測リスト１１３の一例を示す表である。表５との違いは、発行確率を時系列ごとに区切らずに、１つのＳＱＬ文に対して１つの値とする点にある。
発行確率を時系列ごとに区切らないデータ形式により、クライアント１が発行するＳＱＬが周期的に変化しない場合、表５と比べて発行予測リスト１１３のデータ量が少なくて済むために、計算量と通信量を節約することができる。
発行確率を時系列ごとに区切らないデータ形式により、クライアント１が発行するＳＱＬが周期的に変化しない場合、表５と比べて発行予測リスト１１３のデータ量が少なくて済むために、計算量と通信量を節約することができる。
表７は、時系列ごとに適用する、プール管理ルール１１４の一例を示す表である。プール管理ルール１１４は、ＳＱＬ文ごとに、時系列ごとの管理ルールを示す。
管理ルールは、実行系ＳＱＬプール１０３にＳＱＬ文が格納されやすい順に、「必ず保持」、「LRUで管理」、「必ず廃棄」という値を取る。
「必ず保持」は、実行系ＳＱＬプール１０３に必ず保持（格納）されるという管理ルールである。
「LRUで管理」は、実行系ＳＱＬプール１０３に保持（格納）されるか否かは、他のＳＱＬ文との比較で決定される管理ルールである。ＬＲＵ（Least Recently Used）とは、最近最も使われなかったものが、破棄されるというルールである。
「必ず廃棄」は、実行系ＳＱＬプール１０３に必ず保持（格納）されないという管理ルールである。
なお、発行予測リスト１１３からプール管理ルール１１４の作り方は、例えば、次の通りである。
0.3以上の確率（高確率）であれば「必ず保持」とし、
0.1以上0.2以下の確率であれば「LRUで管理」とし、
0.1未満の確率であれば「必ず廃棄」とする。
管理ルールは、実行系ＳＱＬプール１０３にＳＱＬ文が格納されやすい順に、「必ず保持」、「LRUで管理」、「必ず廃棄」という値を取る。
「必ず保持」は、実行系ＳＱＬプール１０３に必ず保持（格納）されるという管理ルールである。
「LRUで管理」は、実行系ＳＱＬプール１０３に保持（格納）されるか否かは、他のＳＱＬ文との比較で決定される管理ルールである。ＬＲＵ（Least Recently Used）とは、最近最も使われなかったものが、破棄されるというルールである。
「必ず廃棄」は、実行系ＳＱＬプール１０３に必ず保持（格納）されないという管理ルールである。
なお、発行予測リスト１１３からプール管理ルール１１４の作り方は、例えば、次の通りである。
0.3以上の確率（高確率）であれば「必ず保持」とし、
0.1以上0.2以下の確率であれば「LRUで管理」とし、
0.1未満の確率であれば「必ず廃棄」とする。
表８は、時系列に依存せずに適用する、プール管理ルール１１４の一例を示す表である。表７と比較すると、ＳＱＬ文ごとの管理ルールが時系列で区切られていない点が異なる。
図２は、第１実施形態の処理を示すフローチャートである。
Ｓ１０１において、クライアント１は、前処理のためのＳＱＬを実行系サーバ２に送信する。
Ｓ２０１において、実行系前処理部１０２は、クライアント１から受信したＳＱＬの前処理結果を、実行系ＳＱＬプール１０３から取得する。
Ｓ２０２において、実行系前処理部１０２は、Ｓ２０１でＳＱＬの前処理結果が実行系ＳＱＬプール１０３に存在するか否かを判定する。Ｓ２０２の判定を満たすときにはＳ２０４へ、判定を満たさないときにはＳ２０３へ、それぞれ移行する。
Ｓ２０３において、実行系前処理部１０２は、クライアント１から受信したＳＱＬに対して前処理を行う。
Ｓ２０４において、実行系前処理部１０２は、クライアント１にＳ２０１またはＳ２０３で取得した前処理結果を送信する。
Ｓ１０２において、クライアント１は実行系前処理部１０２から前処理結果を受信する。
Ｓ２０１において、実行系前処理部１０２は、クライアント１から受信したＳＱＬの前処理結果を、実行系ＳＱＬプール１０３から取得する。
Ｓ２０２において、実行系前処理部１０２は、Ｓ２０１でＳＱＬの前処理結果が実行系ＳＱＬプール１０３に存在するか否かを判定する。Ｓ２０２の判定を満たすときにはＳ２０４へ、判定を満たさないときにはＳ２０３へ、それぞれ移行する。
Ｓ２０３において、実行系前処理部１０２は、クライアント１から受信したＳＱＬに対して前処理を行う。
Ｓ２０４において、実行系前処理部１０２は、クライアント１にＳ２０１またはＳ２０３で取得した前処理結果を送信する。
Ｓ１０２において、クライアント１は実行系前処理部１０２から前処理結果を受信する。
Ｓ２０５において、実行系前処理部１０２は、Ｓ２０４で送信した前処理結果を、プール管理ルール１１４に従い、実行系ＳＱＬプール１０３に格納または破棄することで、実行系ＳＱＬプール１０３を更新する。
なお、プール管理ルール１１４の初期値はＬＲＵであるのが一般的だが、本実施形態は、ＬＲＵに限定せず、ランダムでもＦＩＦＯでも適用可能である。
なお、プール管理ルール１１４の初期値はＬＲＵであるのが一般的だが、本実施形態は、ＬＲＵに限定せず、ランダムでもＦＩＦＯでも適用可能である。
Ｓ２０６において、実行系サーバ２は、Ｓ２０１で受信したＳＱＬと、その発行時刻とを対応づけて発行履歴データ１１１に追加し、その発行履歴データ１１１を分析予測部２２０に送信する。なお、Ｓ２０６の送信処理のタイミングは、性能劣化が少ないタイミングを見計らって送信することとしてもよい。性能劣化が少ないタイミングの一例として、実行系ＤＢ１０１および待機系ＤＢ２０１の同期処理のタイミングが挙げられる。
待機系サーバ３は、受信した発行履歴データ１１１を、自身の発行履歴データ２１１へと反映する。
待機系サーバ３は、受信した発行履歴データ１１１を、自身の発行履歴データ２１１へと反映する。
Ｓ３０１において、分析予測部２２０は、Ｓ２０６で反映された発行履歴データ２１１を分析し、発行確率遷移表２１２を作成し、その発行確率遷移表２１２から発行予測リスト２１３を作成する。以下、発行予測リスト２１３の作成方法について、時系列ごとの発行予測リスト２１３（表５）、および、時系列に依存しない発行予測リスト２１３（表６）それぞれについて、具体的に説明する。
まず、Ｓ３０１において、時系列ごとの発行確率遷移表２１２（表４）から発行予測リスト２１３（表５）は、次のようにして作成される。
以下に、予測演算の一例として、ＳＱＬ文「(1)SELECT * FROM T1」に対して、重回帰分析を使用した計算方法を説明する。
あるＳＱＬが将来実行される確率を従属変数Yとし、過去の実行確率を順番に独立変数X1、X2、X3、X4として、重回帰分析を行う。
過去の実行確率は、例えば、14時台から17時台までの確率を独立変数に代入して、X1=0.35、X2=0.3、X3=0.1、X4=0.05とする。そして、重回帰分析は、以下の式で示される。
Y=-0.0814814814814813+1.2037037037037X1-X2+3.15796771448929E-17X3+1.2037037037037X4
この計算式に過去の実行確率を代入すると、Y=0.1となりこのＳＱＬ文が18時台に実行される確率は0.1であることが分かる。
また、過去の実行確率「X1=0.3、X2=0.1、X3=0.05、X4=0.1」を代入すると、Y=0.3となり、19時台にSELECT * FROM T1が実行される確率は0.3であることが分かる。
つまり、４回分のＳＱＬ発行確率を用いて、将来実行されるＳＱＬ発行確率が予測できる。その他のＳＱＬにも同様に重回帰分析を適用することで、発行予測リスト２１３（表５）が作成できる。
以下に、予測演算の一例として、ＳＱＬ文「(1)SELECT * FROM T1」に対して、重回帰分析を使用した計算方法を説明する。
あるＳＱＬが将来実行される確率を従属変数Yとし、過去の実行確率を順番に独立変数X1、X2、X3、X4として、重回帰分析を行う。
過去の実行確率は、例えば、14時台から17時台までの確率を独立変数に代入して、X1=0.35、X2=0.3、X3=0.1、X4=0.05とする。そして、重回帰分析は、以下の式で示される。
Y=-0.0814814814814813+1.2037037037037X1-X2+3.15796771448929E-17X3+1.2037037037037X4
この計算式に過去の実行確率を代入すると、Y=0.1となりこのＳＱＬ文が18時台に実行される確率は0.1であることが分かる。
また、過去の実行確率「X1=0.3、X2=0.1、X3=0.05、X4=0.1」を代入すると、Y=0.3となり、19時台にSELECT * FROM T1が実行される確率は0.3であることが分かる。
つまり、４回分のＳＱＬ発行確率を用いて、将来実行されるＳＱＬ発行確率が予測できる。その他のＳＱＬにも同様に重回帰分析を適用することで、発行予測リスト２１３（表５）が作成できる。
一方、Ｓ３０１において、時系列に依存しない発行予測リスト２１３（表６）は、次のようにして作成される。
発行履歴データ２１１（表３）には、ＳＱＬ文ごとにその発行時刻が記述されている。そこで、発行履歴データ２１１のＳＱＬ文を種別ごと（ＩＤごと）に１つ選択する。選択したＳＱＬ文に該当するレコードを発行履歴データ２１１から検索し、検索されたレコード数を取得する。取得したレコード数を発行履歴データ２１１の全レコード数で除算することで、選択したＳＱＬ文の発行確率を求める。
発行履歴データ２１１（表３）には、ＳＱＬ文ごとにその発行時刻が記述されている。そこで、発行履歴データ２１１のＳＱＬ文を種別ごと（ＩＤごと）に１つ選択する。選択したＳＱＬ文に該当するレコードを発行履歴データ２１１から検索し、検索されたレコード数を取得する。取得したレコード数を発行履歴データ２１１の全レコード数で除算することで、選択したＳＱＬ文の発行確率を求める。
Ｓ２０７において、実行系サーバ２は、Ｓ３０１で作成した発行予測リスト２１３を受信し、発行予測リスト１１３に反映する。そして、実行系プール管理部１１０は、発行予測リスト１１３にもとづいてプール管理ルール１１４を変更する。また、変更方法としては、発行確率の高いＳＱＬの前処理結果を廃棄対象から外し、発行確率の低いＳＱＬの前処理結果を格納対象から外す変更方法が一例として挙げられるが、発行予測リスト２１３にもとづいて今後のＳＱＬプールのヒット率を上げるという条件さえを満たせば、この方法に限定しない。この変更により、データベース管理システムの処理性能が向上する。
Ｓ３０２において、待機系プール管理部２１０は、Ｓ３０１で作成した発行予測リスト２１３にもとづいて、プール管理ルール２１４を変更し、発行確率が高いＳＱＬ（高確率ＳＱＬ）を待機系前処理部２０２に渡す。プール管理ルール２１４の変更方法も、発行予測リスト２１３にもとづいて今後のＳＱＬプールのヒット率を上げるという条件さえを満たせば、特定の方法に限定しない。
Ｓ３０３において、待機系前処理部２０２は、受け取った高確率ＳＱＬの前処理結果が待機系ＳＱＬプール２０３に存在しない場合、高確率ＳＱＬの前処理を行う。
Ｓ３０４において、待機系ＳＱＬプール２０３は、高確率ＳＱＬの前処理結果をプール管理ルール２１４に従い、待機系ＳＱＬプール２０３に格納する。これにより、前処理結果が待機系ＳＱＬプール２０３にも存在することになり、障害時に実行系サーバ２から待機系サーバ３に役割を円滑に引き継ぐ際、引き継いだ待機系サーバ３が前処理を行う可能性が少なくなるため、データベース管理システムの処理性能が向上する。
以下、第２実施形態によるデータベース管理システムについて、図面を参照して説明する。
第２実施形態の構成は、第１実施形態の構成（図１参照）と同じである。
図３は、第２実施形態の処理を示すフローチャートである。第１実施形態の処理（図２）と比較すると、図３ではＳ２０８が追加されている。
Ｓ２０８において、実行系サーバ２は、Ｓ３０３で作成される高確率ＳＱＬの前処理結果を受信し、実行系ＳＱＬプール１０３に受信した前処理結果を格納する。これにより、受信によるオーバヘッドはあるものの、高確率ＳＱＬの前処理を実行系前処理部１０２が実行する（Ｓ２０３）ことを省略できるので、実行系サーバ２の処理負荷を軽減できる。
Ｓ２０８において、実行系サーバ２は、Ｓ３０３で作成される高確率ＳＱＬの前処理結果を受信し、実行系ＳＱＬプール１０３に受信した前処理結果を格納する。これにより、受信によるオーバヘッドはあるものの、高確率ＳＱＬの前処理を実行系前処理部１０２が実行する（Ｓ２０３）ことを省略できるので、実行系サーバ２の処理負荷を軽減できる。
以下、第３実施形態によるデータベース管理システムについて、図面を参照して説明する。
第３実施形態の構成は、第１実施形態の構成（図１参照）と同じである。
図４は、第３実施形態の処理を示すフローチャートである。第１実施形態の処理（図２）と比較すると、Ｓ２０３の処理がＳ２０９に変更され、変更され、Ｓ３０５の処理が追加されている。
Ｓ２０９において、実行系前処理部１０２は、待機系前処理部２０２に対して、Ｓ２０１で受信したＳＱＬを送信し、そのＳＱＬの前処理を依頼する。
Ｓ３０５において、待機系前処理部２０２は、Ｓ２０９で受信したＳＱＬの前処理を行い、その前処理結果を実行系前処理部１０２に送信する。これにより、送信受信のオーバヘッドがあるものの実行系サーバ２で前処理を行う必要がなくなる。
Ｓ２０９において、実行系前処理部１０２は、待機系前処理部２０２に対して、Ｓ２０１で受信したＳＱＬを送信し、そのＳＱＬの前処理を依頼する。
Ｓ３０５において、待機系前処理部２０２は、Ｓ２０９で受信したＳＱＬの前処理を行い、その前処理結果を実行系前処理部１０２に送信する。これにより、送信受信のオーバヘッドがあるものの実行系サーバ２で前処理を行う必要がなくなる。
以下、第４実施形態によるデータベース管理システムについて、図面を参照して説明する。
図５は、第４実施形態のデータベース管理システムを示す構成図である。第４実施形態の構成は、第１実施形態の構成（図１参照）と比較すると、実行待ちキュー１０４が追加されている。
実行待ちキュー１０４は、クライアント１からのＳＱＬ（Ｓ１０１で受信）を保持するキューである。実行系前処理部１０２は、実行待ちキュー１０４が保持するＳＱＬをＦＩＦＯ（First In, First Out）の順番で前処理を行う。
さらに、実行系サーバ２は、実行待ちキュー１０４内の処理待ちのＳＱＬのリストから、最近登録された方から１つ、もしくは、複数個のＳＱＬを待機系サーバ３に送信し、待機系前処理部２０２に対して前処理を依頼する。
実行待ちキュー１０４は、クライアント１からのＳＱＬ（Ｓ１０１で受信）を保持するキューである。実行系前処理部１０２は、実行待ちキュー１０４が保持するＳＱＬをＦＩＦＯ（First In, First Out）の順番で前処理を行う。
さらに、実行系サーバ２は、実行待ちキュー１０４内の処理待ちのＳＱＬのリストから、最近登録された方から１つ、もしくは、複数個のＳＱＬを待機系サーバ３に送信し、待機系前処理部２０２に対して前処理を依頼する。
図６は、第４実施形態の処理を示すフローチャートである。第１実施形態の処理（図２）と比較すると、Ｓ２０１の処理がＳ２１０に変更され、Ｓ３０６の処理が追加されている。
Ｓ２１０において、実行系サーバ２は、実行待ちキュー１０４に保持されているＳＱＬをＦＩＦＯの順に（キュー先頭のＳＱＬから順に）実行系前処理部１０２に渡す。また、実行系サーバ２は、実行待ちキュー１０４に最近登録された方から１つ、もしくは、複数個のＳＱＬ（キュー末尾のＳＱＬ）を待機系前処理部２０２に送信し、前処理を依頼する。
Ｓ３０６において、待機系前処理部２０２は、受信したＳＱＬに対して、待機系前処理部２０２が前処理を行う、または、待機系ＳＱＬプール２０３から前処理結果を読み取ることにより、前処理結果を取得し、その前処理結果を実行系サーバ２に返信する。
Ｓ２１０において、実行系サーバ２は、実行待ちキュー１０４に保持されているＳＱＬをＦＩＦＯの順に（キュー先頭のＳＱＬから順に）実行系前処理部１０２に渡す。また、実行系サーバ２は、実行待ちキュー１０４に最近登録された方から１つ、もしくは、複数個のＳＱＬ（キュー末尾のＳＱＬ）を待機系前処理部２０２に送信し、前処理を依頼する。
Ｓ３０６において、待機系前処理部２０２は、受信したＳＱＬに対して、待機系前処理部２０２が前処理を行う、または、待機系ＳＱＬプール２０３から前処理結果を読み取ることにより、前処理結果を取得し、その前処理結果を実行系サーバ２に返信する。
以上説明したように、本発明の各実施形態は、待機系サーバ３の分析予測部２２０が、クライアント１が発行した発行履歴データ１１１をもとに発行予測リスト２１３を作成し、実行系サーバ２の実行系ＳＱＬプール１０３に適用することを特徴とする。
これにより、待機系サーバ３の計算資源を有効活用することで、実行系サーバ２が予測演算によって止められることなく、プール管理ルール１１４の最適化を行い、実行系ＳＱＬプール１０３のキャッシュヒット率を高めることができる。
よって、データベース管理システム全体の処理性能を向上することができる。
これにより、待機系サーバ３の計算資源を有効活用することで、実行系サーバ２が予測演算によって止められることなく、プール管理ルール１１４の最適化を行い、実行系ＳＱＬプール１０３のキャッシュヒット率を高めることができる。
よって、データベース管理システム全体の処理性能を向上することができる。
さらに、各実施形態に特有の追加的効果を説明するため、図７〜図８を参照して、各実施形態の通信処理の一例を説明する。
図７（ａ）は、第１実施形態における通信処理を示すシーケンス図である。
実行系サーバ２は、クライアント１からＳＱＬが送信（Ｓ１０１）されると、そのＳＱＬの前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１のＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
実行系サーバ２は、クライアント１からＳＱＬが送信（Ｓ１０１）されると、そのＳＱＬの前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１のＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
第１実施形態によれば、実行系サーバ２と待機系サーバ３との間で前処理結果そのものの通信が行われないため、特に、「１つのＳＱＬあたりの前処理の計算量」が「実行系サーバ２が待機系サーバ３から１つの前処理結果を受信するオーバヘッド」よりも小さい状況において、高い処理性能を発揮することができる。
図７（ｂ）は、第２実施形態における通信処理を示すシーケンス図である。
実行系サーバ２は、クライアント１から第１ＳＱＬが送信（Ｓ１０１）されると、そのＳＱＬの前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１の第１ＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
さらに、実行系サーバ２は、高確率ＳＱＬである第２ＳＱＬの前処理結果（第２前処理結果）が送信（Ｓ３０３）されると、自身の実行系ＳＱＬプール１０３へと反映する。
その後、実行系サーバ２は、クライアント１から第２ＳＱＬが送信（Ｓ１０１）されると、実行系ＳＱＬプール１０３から第２前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、クライアント１から第１ＳＱＬが送信（Ｓ１０１）されると、そのＳＱＬの前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１の第１ＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
さらに、実行系サーバ２は、高確率ＳＱＬである第２ＳＱＬの前処理結果（第２前処理結果）が送信（Ｓ３０３）されると、自身の実行系ＳＱＬプール１０３へと反映する。
その後、実行系サーバ２は、クライアント１から第２ＳＱＬが送信（Ｓ１０１）されると、実行系ＳＱＬプール１０３から第２前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
第２実施形態によれば、実行系サーバ２が高確率ＳＱＬの前処理結果を待機系サーバ３から取得するため、特に、「１つのＳＱＬあたりの前処理の計算量」が「実行系サーバ２が待機系サーバ３から１つの前処理結果を受信するオーバヘッド」よりも大きい状況において、高い処理性能を発揮することができる。
図８（ａ）は、第３実施形態における通信処理を示すシーケンス図である。
実行系サーバ２は、クライアント１からＳＱＬが送信（Ｓ１０１）されると、そのＳＱＬの前処理を依頼し（Ｓ２０９）、その依頼結果としての前処理結果の送信（Ｓ３０５）を受ける。そして、実行系サーバ２は、受信した前処理結果を、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１のＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
実行系サーバ２は、クライアント１からＳＱＬが送信（Ｓ１０１）されると、そのＳＱＬの前処理を依頼し（Ｓ２０９）、その依頼結果としての前処理結果の送信（Ｓ３０５）を受ける。そして、実行系サーバ２は、受信した前処理結果を、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１のＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
第３実施形態によれば、実行系サーバ２がＳＱＬの前処理を待機系サーバ３に依頼するため、特に、「１つのＳＱＬあたりの前処理の計算量」が「ＳＱＬの依頼送信処理、およびその返信としての前処理結果の受信処理のオーバヘッド」よりも大きい状況において、高い処理性能を発揮することができる。
図８（ｂ）は、第４実施形態における通信処理を示すシーケンス図である。
実行系サーバ２は、クライアント１から第１ＳＱＬと、第２ＳＱＬとが送信（Ｓ１０１）されると、送信順に実行待ちキュー１０４に格納する。
実行系サーバ２は、実行待ちキュー１０４の末尾の第２ＳＱＬを読み取り、待機系サーバ３へと前処理を依頼し、その前処理結果である第２前処理結果の送信（Ｓ３０６）を受ける。
実行系サーバ２は、実行待ちキュー１０４の先頭の第１ＳＱＬを読み取り、その前処理結果である第１前処理結果を取得し、クライアント１に送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１の各ＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
その後、実行系サーバ２は、実行待ちキュー１０４において第２ＳＱＬが先頭に送り出されると、実行系ＳＱＬプール１０３から第２前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
実行系サーバ２は、クライアント１から第１ＳＱＬと、第２ＳＱＬとが送信（Ｓ１０１）されると、送信順に実行待ちキュー１０４に格納する。
実行系サーバ２は、実行待ちキュー１０４の末尾の第２ＳＱＬを読み取り、待機系サーバ３へと前処理を依頼し、その前処理結果である第２前処理結果の送信（Ｓ３０６）を受ける。
実行系サーバ２は、実行待ちキュー１０４の先頭の第１ＳＱＬを読み取り、その前処理結果である第１前処理結果を取得し、クライアント１に送信（Ｓ２０４）する。
実行系サーバ２は、Ｓ１０１の各ＳＱＬを反映した発行履歴データ１１１を待機系サーバ３に送信（Ｓ２０６）し、待機系サーバ３に作成させた発行予測リスト２１３が送信（Ｓ３０１）されると、自身の発行予測リスト１１３へと反映する。
その後、実行系サーバ２は、実行待ちキュー１０４において第２ＳＱＬが先頭に送り出されると、実行系ＳＱＬプール１０３から第２前処理結果を取得し、クライアント１へと送信（Ｓ２０４）する。
第４実施形態によれば、実行待ちキュー１０４に最近登録されたＳＱＬは待機系前処理部２０２で前処理を行い、その前処理結果を実行系ＳＱＬプール１０３に格納されても、まだ実行待ちキュー１０４にある可能性がある。その場合、実行系前処理部１０２で前処理しなくて済むため、処理性能は向上する。つまり、実行待ちキュー１０４内に処理待ちのＳＱＬが多く格納されている状況において、高い処理性能を発揮することができる。
なお、図７〜図８で説明した各通信処理の順番について、クライアントがＳＱＬを送信した後に、そのＳＱＬの前処理結果を受信するという順序さえ満たせば、他処理の順番は適宜変更してもよい。
さらに、ＳＱＬの送信回数と、ＳＱＬの前処理結果の受信回数とは、同じ回数としてもよいし、異なった回数としてもよい。
さらに、ＳＱＬの送信回数と、ＳＱＬの前処理結果の受信回数とは、同じ回数としてもよいし、異なった回数としてもよい。
１ クライアント
２ 実行系サーバ
３ 待機系サーバ
９ ネットワーク
２０ 通信インターフェース
９１ ＣＰＵ
９２ メモリ
１０１ 実行系ＤＢ
１０２ 実行系前処理部
１０３ 実行系ＳＱＬプール
１０４ 実行待ちキュー
１１０ 実行系プール管理部
１１１ 発行履歴データ
１１２ 発行確率遷移表
１１３ 発行予測リスト
１１４ プール管理ルール
１２０ 分析予測部
２０１ 待機系ＤＢ
２０２ 待機系前処理部
２０３ 待機系ＳＱＬプール
２０４ 実行待ちキュー
２１０ 待機系プール管理部
２１１ 発行履歴データ
２１２ 発行確率遷移表
２１３ 発行予測リスト
２１４ プール管理ルール
２２０ 分析予測部
２ 実行系サーバ
３ 待機系サーバ
９ ネットワーク
２０ 通信インターフェース
９１ ＣＰＵ
９２ メモリ
１０１ 実行系ＤＢ
１０２ 実行系前処理部
１０３ 実行系ＳＱＬプール
１０４ 実行待ちキュー
１１０ 実行系プール管理部
１１１ 発行履歴データ
１１２ 発行確率遷移表
１１３ 発行予測リスト
１１４ プール管理ルール
１２０ 分析予測部
２０１ 待機系ＤＢ
２０２ 待機系前処理部
２０３ 待機系ＳＱＬプール
２０４ 実行待ちキュー
２１０ 待機系プール管理部
２１１ 発行履歴データ
２１２ 発行確率遷移表
２１３ 発行予測リスト
２１４ プール管理ルール
２２０ 分析予測部
Claims (11)
- クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムによるデータベース管理方法であって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合その前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理方法。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムによるデータベース管理方法であって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合その前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果、および、前記待機系前処理部から受信した前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系ＳＱＬプールに送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系ＳＱＬプールに送信し、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理方法。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムによるデータベース管理方法であって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合、前記前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合、そのＳＱＬを前記待機系前処理部に送信し、前記待機系前処理部から受信した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記実行系前処理部から受信したＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系前処理部に送信し、前記実行系前処理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系前処理部に送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理方法。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムによるデータベース管理方法であって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、ＳＱＬ発行履歴保持部、および、ＳＱＬ実行待ちキューを有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記ＳＱＬ実行待ちキューからＳＱＬを取得し、そのＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合、前記前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合、そのＳＱＬに対して前処理を行い、前記前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記ＳＱＬ実行待ちキューは、前記クライアントが発行したＳＱＬを実行順に保持し、実行が最後の方から１つもしくは複数のＳＱＬを前記待機系前処理部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記ＳＱＬ実行待ちキューから受信したＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系ＳＱＬプールに送信し、前記ＳＱＬ実行待ちキューから受信したＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系ＳＱＬプールに送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理方法。 - 前記ＳＱＬ発行予測リストは、時系列、ならびに、時系列ごとに前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬを発行する確率を、保持することを特徴とする
請求項１ないし請求項４のいずれか１項に記載に記載のデータベース管理方法。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムであって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合その前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理システム。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムであって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合その前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果、および、前記待機系前処理部から受信した前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系ＳＱＬプールに送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系ＳＱＬプールに送信し、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理システム。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムであって、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合、前記前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合、そのＳＱＬを前記待機系前処理部に送信し、前記待機系前処理部から受信した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記実行系前処理部から受信したＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系前処理部に送信し、前記実行系前処理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系前処理部に送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理システム。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムを実現させるためのデータベース管理プログラムであって、
前記データベース管理プログラムは、前記実行系サーバおよび前記待機系サーバにそれぞれ読み取られ、実行されることで、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合その前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理プログラム。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムを実現させるためのデータベース管理プログラムであって、
前記データベース管理プログラムは、前記実行系サーバおよび前記待機系サーバにそれぞれ読み取られ、実行されることで、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合その前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果、および、前記待機系前処理部から受信した前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系ＳＱＬプールに送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系ＳＱＬプールに送信し、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理プログラム。 - クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときにその実行系サーバの処理を代行する待機系サーバとを組として冗長構成とするデータベース管理システムを実現させるためのデータベース管理プログラムであって、
前記データベース管理プログラムは、前記実行系サーバおよび前記待機系サーバにそれぞれ読み取られ、実行されることで、
前記実行系サーバは、実行系ＤＢ、実行系前処理部、実行系ＳＱＬプール、実行系ＳＱＬプール管理部、実行系ＳＱＬプール管理ルール、および、ＳＱＬ発行履歴保持部を有し、
前記待機系サーバは、待機系ＤＢ、待機系前処理部、待機系ＳＱＬプール、待機系ＳＱＬプール管理部、待機系ＳＱＬプール管理ルール、および、分析予測部を有し、
前記実行系前処理部は、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在する場合、前記前処理結果を前記クライアントに渡し、前記クライアントが発行したＳＱＬの前処理結果が前記実行系ＳＱＬプールに存在しない場合、そのＳＱＬを前記待機系前処理部に送信し、前記待機系前処理部から受信した前処理結果を前記クライアントに渡し、
前記実行系ＳＱＬプールは、前記実行系前処理部が前記ＳＱＬを前処理して生成する前処理結果を前記実行系ＳＱＬプール管理ルールに従い前記実行系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行い、
前記ＳＱＬ発行履歴保持部は、前記クライアントが発行したＳＱＬの履歴を保持し前記分析予測部に送信し、
前記分析予測部は、前記ＳＱＬ発行履歴保持部から受信したＳＱＬ発行履歴を分析し、前記クライアントが今後発行するＳＱＬ、および、前記クライアントがそのＳＱＬが発行する確率を予測し、その結果をＳＱＬ発行予測リストにまとめ、実行系ＳＱＬプール管理部、および、待機系ＳＱＬプール管理部に、前記ＳＱＬ発行予測リストを送信し、
前記実行系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記実行系ＳＱＬプール管理ルールを変更し、
前記待機系ＳＱＬプール管理部は、前記分析予測部から受信したＳＱＬ発行予測リストにもとづいて、前記待機系ＳＱＬプール管理ルールを変更し、前記クライアントが発行する確率が高いＳＱＬを前記待機系前処理部に渡し、
前記待機系前処理部は、前記実行系前処理部から受信したＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在する場合その前処理結果を前記実行系前処理部に送信し、前記実行系前処理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い生成した前処理結果を前記実行系前処理部に送信し、前記待機系ＳＱＬプール管理部から受け取ったＳＱＬの前処理結果が前記待機系ＳＱＬプールに存在しない場合そのＳＱＬに対して前処理を行い、
前記待機系ＳＱＬプールは、前記待機系前処理部が前記ＳＱＬを前処理して生成する前処理結果を、前記待機系ＳＱＬプール管理ルールに従い前記待機系ＳＱＬプール内に格納し、かつ、前記実行系ＳＱＬプール管理ルールに従い実行系ＳＱＬプール内から前処理結果の破棄を行うこと、を特徴とする
データベース管理プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008231402A JP2010066922A (ja) | 2008-09-09 | 2008-09-09 | データベース管理方法、データベース管理プログラム、および、データベース管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008231402A JP2010066922A (ja) | 2008-09-09 | 2008-09-09 | データベース管理方法、データベース管理プログラム、および、データベース管理システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2010066922A true JP2010066922A (ja) | 2010-03-25 |
Family
ID=42192469
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008231402A Withdrawn JP2010066922A (ja) | 2008-09-09 | 2008-09-09 | データベース管理方法、データベース管理プログラム、および、データベース管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2010066922A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2018526746A (ja) * | 2015-09-08 | 2018-09-13 | アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ | データベーストランザクションを最適化するための方法および装置 |
-
2008
- 2008-09-09 JP JP2008231402A patent/JP2010066922A/ja not_active Withdrawn
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2018526746A (ja) * | 2015-09-08 | 2018-09-13 | アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ | データベーストランザクションを最適化するための方法および装置 |
| US11500869B2 (en) | 2015-09-08 | 2022-11-15 | Alibaba Group Holding Limited | Method and apparatus for optimizing database transactions |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9350826B2 (en) | Pre-fetching data | |
| US9773011B2 (en) | On-demand caching in a WAN separated distributed file system or clustered file system cache | |
| US9141648B1 (en) | Management of database blocks | |
| US9798745B2 (en) | Methods, devices and systems for caching data items | |
| CN110609796B (zh) | 用于存储系统中预取的方法、设备和计算机程序产品 | |
| JP2010108073A (ja) | ストリームデータ処理方法、及びシステム | |
| WO2018120171A1 (zh) | 一种用于存储过程的执行方法、设备以及系统 | |
| US20150142845A1 (en) | Smart database caching | |
| US20170329740A1 (en) | Distributed client based cache for keys using demand fault invalidation | |
| US8006238B2 (en) | Workload partitioning in a parallel system with hetergeneous alignment constraints | |
| US11841876B2 (en) | Managing transaction size during database replication | |
| US11561796B2 (en) | Linked miss-to-miss instruction prefetcher | |
| US20180267831A1 (en) | Information processing apparatus, stage-out processing method and recording medium recording job management program | |
| US8566521B2 (en) | Implementing cache offloading | |
| JP6189266B2 (ja) | データ処理装置、データ処理方法及びデータ処理プログラム | |
| US10621163B2 (en) | Tracking and reusing function results | |
| JP2010066922A (ja) | データベース管理方法、データベース管理プログラム、および、データベース管理システム | |
| JP2010152435A (ja) | 情報処理装置及び情報処理方法及びプログラム | |
| CN115686769A (zh) | 根据cxl协议处理一致存储器事务的系统、装置和方法 | |
| US11379268B1 (en) | Affinity-based routing and execution for workflow service | |
| CN109298884B (zh) | 一种通用字符操作加速处理硬件装置及控制方法 | |
| US10747627B2 (en) | Method and technique of achieving extraordinarily high insert throughput | |
| JP4768054B2 (ja) | キャッシュ制御方法 | |
| US20240028519A1 (en) | Data processing method, electronic device and computer program product | |
| JP6323109B2 (ja) | 文書管理システム、キーバリューストア装置、文書管理方法、及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100303 |
|
| A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20110704 |