JP4621273B2 - データ同期方法、データ同期プログラム、データベースサーバ装置、および、データベースシステム - Google Patents

Description

本発明は、データ同期方法、データ同期プログラム、データベースサーバ装置、および、データベースシステムの技術に関する。

サービス処理を動作させるサーバ装置は、計算機であるために障害が発生する可能性がある。そこで、実行系のサーバ装置と待機系のサーバ装置とをペアにして、障害許容性のある高信頼なシステムが、提案されている（特許文献１参照）。

特許文献１に開示されているシステムは、複数のサーバ装置をペアにして冗長化する冗長構成を採用する。冗長構成では、ペアを構成するサーバ装置間でそれぞれ管理しているデータ内容を、ペア相手に送信することにより、データ同期を実現する。そして、片方のサーバ装置に障害が発生したときには、もう片方のサーバ装置を活用することにより、障害対策を行う。
特開２００５−２５１０５５号公報

ＤＢＭＳ（Data Base Management System）を動作させるサーバ装置は、処理対象のデータが消失しないように、特に高度な信頼性が要求される。そのため、データベースを有するサーバ装置間を冗長構成とし、それらのサーバ装置間のデータ同期処理をあらかじめ行うことにより、片方のサーバ装置の故障によるデータ消失を抑制することができる。このようなデータベースの冗長構成は、サーバ装置内のメモリ内にデータを保持するインメモリデータベースの形態において、特に有効である。

一方、データベースの処理性能に対しても、さらなる向上が要求される。データベースの処理性能は、例えば、単位時間あたりに処理するトランザクションの数により、計測される。よって、データベースの処理性能を向上するためには、そのデータベースを実行するサーバ装置の計算機資源（リソース）の使用効率を高めることが重要である。例えば、ＣＰＵ負荷が前記したデータ同期処理によって過剰に高まってしまうと、新たなトランザクションを処理できずに、データベースの処理性能が低下してしまう。

サーバ装置による資源の使用率は、時間の経過により、変動する。使用率の変動は、例えば、以下の要因により発生する。これにより、サーバ装置の資源のうち、ＤＢＭＳが使用できる資源が少なくなり、データベースシステムの可用性が低下してしまう。
・特定のＤＢＭＳに対してトランザクションが一時的に集中した結果、その特定のＤＢＭＳを実行するサーバ装置の負荷が急上昇する場合。
・１台のサーバ装置が、複数のＤＢＭＳを同時に起動しているときに、所定のＤＢＭＳでは使用率が低いが、別のＤＢＭＳでは使用率が高い場合。
・１台のサーバ装置が、冗長構成における１つの実行系（高負荷）と、１つの待機系（低負荷）と、を同時に実行しているときに、障害発生に伴って待機系が実行系に切り替わることで、２つの実行系（高負荷）を実行することになった場合。
・サーバ装置を構成するハードウェアの障害により、障害が発生したハードウェアが使用不能となった結果、同じサーバ装置内の別のハードウェアの使用率が高くなる場合。

そこで、本発明は、前記した問題を解決し、データベースの信頼性を高めつつ、データベースの処理性能を向上することを、主な目的とする。

前記課題を解決するため、本発明は、クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときに前記実行系サーバの処理を代行する待機系サーバとを有し冗長構成とするデータベースシステムにおける前記実行系サーバが有する実行系ＤＢと、前記待機系サーバが有する待機系ＤＢとを、データ同期処理するデータ同期方法であって、
前記実行系サーバは、前記実行系ＤＢに加えて、資源利用状況テーブル、資源利用状況監視部、トランザクション制御部、反映方式決定部、評価係数テーブル、および、同期用データ送信部を有し、
前記待機系サーバは、前記待機系ＤＢに加えて、同期用データ適用部を有し、
前記トランザクション制御部は、データ内容を指定して更新させるための操作要求を前記クライアントから受信すると、受信した前記操作要求を処理するためのトランザクションを開始した後、前記受信した操作要求で指定される更新内容を、ＤＢログデータとして前記実行系ＤＢに反映するとともに、前記実行系ＤＢにアクセスするためのインデクスデータのうち、前記ＤＢログデータに対応するインデクスデータを、インデクスログデータとして、前記実行系ＤＢに反映し、
前記資源利用状況監視部は、前記データベースシステムを構成する各サーバにおける資源の使用率情報およびデータベースの動作状況情報のうちの少なくとも１つの情報を収集して前記資源利用状況テーブルに格納し、
前記評価係数テーブルには、前記資源利用状況テーブルに格納される収集値ごとの評価係数が予め格納されており、
前記反映方式決定部は、前記資源利用状況テーブルに格納されている収集値と、前記評価係数テーブルに格納されている収集値ごとの評価係数と、を重み付け合計することにより、反映方式ごとの評価値を計算し、その評価値が最小となる前記反映方式を決定し、
前記同期用データ送信部は、決定された前記反映方式に従って、前記実行系ＤＢに反映されたデータを、ＤＢ同期用データとして、冗長構成の相手となる前記待機系サーバに送信し、
前記同期用データ適用部は、トランザクションを決着させるための決着要求が前記クライアントから前記実行系サーバへと送信されると、決定された前記反映方式に従って、受信した前記ＤＢ同期用データを前記待機系ＤＢに反映すること、を特徴とする
データ同期方法。
ただし、前記反映方式は、以下の（ａ）または（ｂ）に示す前記ＤＢ同期用データの送信内容から１つを選択することにより定義する
（ａ）前記ＤＢログデータを送信内容とするが、前記インデクスログデータは送信せずに前記待機系サーバ側で別途作成させる
（ｂ）前記ＤＢログデータに加えて、前記インデクスログデータを送信内容とする
その他の手段は、後記する。

本発明によれば、データベースの信頼性を高めつつ、データベースの処理性能を向上することが可能になった。

以下に、本発明が適用されるデータベースシステムの一実施形態について、図面を参照して詳細に説明する。

図１は、データベースシステムのハードウェア構成を示す構成図である。データベースシステムは、クライアント１と、実行系サーバ２と、待機系サーバ３（待機系サーバ３ａ、待機系サーバ３ｂ、待機系サーバ３ｃ）と、がネットワーク９で接続されて構成される。なお、待機系サーバ３の台数は、１台でもよいし、複数台（図１では３台を例示）のクラスタリング構成でもよい。
ネットワーク９は、例えば、ＩＰ（Internet Protocol）ネットワークとして、または、各サーバ（実行系サーバ２および待機系サーバ３）がブレードサーバである場合には内部バスとして、構成される。

なお、図１の各装置（クライアント１、実行系サーバ２、待機系サーバ３）は、それぞれ演算処理を行う際に用いられる記憶手段としてのメモリ９２（９２ａ，９２ｂ，９２ｃ）と、前記演算処理を行う演算処理装置と、ネットワーク９を介して他装置と通信を行う通信インターフェース２０（２０ａ，２０ｂ，２０ｃ）と、を少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理機能は、ＣＰＵ（Central Processing Unit）９１（９１ａ，９１ｂ，９１ｃ）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。

クライアント１は、実行系サーバ２に対して、実行系サーバ２が管理するデータベース（以下、ＤＢと略す）に対するアクセスを要求する。アクセス要求は、少なくとも以下の２種類の要求（操作要求、決着要求）に分類できる。なお、クライアント１と実行系サーバ２との要求のやりとりのために、トランザクションが開始される。

「操作要求」は、データベースに格納されているデータ内容への操作を要求するメッセージである。操作要求は、例えば、挿入（insert）、更新（update）、および、削除（delete）であり、これらの操作により、データ内容が書き換わる。１つのトランザクション内で、０回以上の操作要求が発生する。実行系サーバ２は、１回目の操作要求を受信したときに、その操作要求に関するトランザクションがまだ開始されていないときには、トランザクションを開始することとしてもよい。

「決着要求」は、操作要求により書き換わったデータ内容を、最終的にデータベースに対して確定するか否かを決着するためのメッセージである。決着要求は、書き換わったデータ内容を確定する「コミット要求」、または、書き換わったデータ内容を破棄する「ロールバック要求」に分類される。そして、決着要求に対してデータ内容を確定または破棄した後、トランザクションは終了する。

実行系サーバ２は、クライアント１に対してデータベース業務を提供する。具体的には、実行系サーバ２は、クライアント１からの要求（操作要求、決着要求）を受け、自身が管理するデータベースに対して、要求で指定されたデータ内容を反映する。
実行系サーバ２および待機系サーバ３は、障害対策としての冗長構成を採用する。待機系サーバ３は、実行系サーバ２に障害が発生したとき、実行系サーバ２の役割を代行することにより、障害が発生した実行系サーバ２の業務を引き継ぐ。
よって、実行系サーバ２および待機系サーバ３は、名称こそ異なるものの、同じサーバ装置が実行系サーバ２として動作する時間帯もあれば、待機系サーバ３として動作する時間帯もある。そのため、実行系サーバ２および待機系サーバ３は、同じ装置構成を採用している。

なお、障害時に実行系サーバ２から待機系サーバ３へと役割が円滑に引き継がれるため、実行系サーバ２のデータベースの内容と、待機系サーバ３のデータベースの内容と、は同じ内容に同一化（データ内容の同期処理）がなされる。
一方、実行系サーバ２のデータベースの内容はクライアント１からの操作要求を直接受信することにより随時更新されるのに対し、待機系サーバ３はクライアント１とは直接やりとりを行わないため、直接的に最新のデータベースの内容を知ることができない。そのため、待機系サーバ３は、データベースの更新内容を差分形式のログとして、間接的に実行系サーバ２から通知を受ける。

図２は、データベースシステムの各サーバ装置（実行系サーバ２、待機系サーバ３）の詳細を示す構成図である。
実行系サーバ２は、通信インターフェース２０ｂと、実行系ＤＢ１０ａと、資源利用状況監視部３２と、トランザクション制御部４０と、を有する。
待機系サーバ３は、通信インターフェース２０ｃと、ログデータ適用部１３と、待機系ＤＢ１０ｂと、を有する。
なお、各データベース（実行系ＤＢ１０ａ、待機系ＤＢ１０ｂ）は、各データベースが属するサーバ装置内の揮発性のメモリ装置（メモリ９２）にデータを格納するインメモリデータベースとしてもよいし、不揮発性のハードディスク装置にデータを格納するデータベースとしてもよい。
例えば、メモリ９２ｂは、実行系ＤＢ１０ａを格納し、メモリ９２ｃは、待機系ＤＢ１０ｂを格納する。
一方、ハードディスク装置を用いる場合には、共有ディスク（図示省略）により、データをやりとりすることができる。
さらに、実行系サーバ２の各処理部（資源利用状況監視部３２、トランザクション制御部４０）は、例えば、実行系サーバ２のＣＰＵ９１ｂがプログラムを実行することにより、実行系サーバ２のメモリ９２ｂ上に構成される。
同様に、待機系サーバ３のログデータ適用部１３は、例えば、待機系サーバ３のＣＰＵ９１ｃがプログラムを実行することにより、待機系サーバ３のメモリ９２ｃ上に構成される。

なお、図２において、実行系サーバ２および待機系サーバ３の構成要素は、互いに異なるように図示したが、両サーバ装置の役割は入れ替わるため、１台のサーバ装置内には、図２の実行系サーバ２内の構成要素、および、図２の待機系サーバ３内の構成要素の両方が、含まれている。
よって、例えば、図２の実行系サーバ２は、ログデータ適用部１３が含まれていることが図示されていないが、ログデータ適用部１３が実行系サーバ２としては使用されていないことにより、説明を簡潔にするために図示を省略している。

また、所定のサーバ装置が実行系サーバ２として動作している時間帯には、待機系サーバ３の構成要素は使用しないので、所定のサーバ装置が待機系サーバ３として動作するまでの間は、待機系サーバ３の構成要素を有さないこととしてもよい。そして、所定のサーバ装置が待機系サーバ３に切り替わるときに、待機系サーバ３の構成要素を備えるよう、待機系サーバ３の構成要素を実現するためのプログラムの実行などを行うこととしてもよい。

実行系サーバ２の通信インターフェース２０ｂは、ログデータ送信部２１と、ログデータ送信バッファ２２と、を有する。
待機系サーバ３の通信インターフェース２０ｃは、ログデータ受信部２３と、ログデータ受信バッファ２４と、を有する。
ログデータ送信バッファ２２は、送信対象のログデータ（実行系ＤＢログデータ１２ａ、実行系インデクスデータ１４ａ）が、実行系ＤＢ１０ａから読み取られ、送信までの間に一時的に格納される。
ログデータ送信部２１は、ログデータ送信バッファ２２に格納されている送信対象のログデータを、ログデータ受信部２３に対して送信する。
ログデータ受信部２３は、ログデータ送信部２１から受信したログデータを、ログデータ受信バッファ２４に格納する。
ログデータ受信バッファ２４は、受信したログデータを、ログデータ適用部１３が適用するまでの間、一時的に保管する。

実行系サーバ２は、実行系ＤＢ１０ａを有し、待機系サーバ３は、待機系ＤＢ１０ｂを有する。実行系ＤＢ１０ａおよび待機系ＤＢ１０ｂは、トランザクション中のデータ同期処理の結果、トランザクションの終了後には互いに同じデータ内容を格納する。
まず、実行系ＤＢ１０ａは、実行系ＤＢデータ１１ａと、実行系ＤＢログデータ１２ａと、実行系インデクスデータ１４ａと、実行系インデクスログデータ１５ａと、を格納する。
同様に、待機系ＤＢ１０ｂは、待機系ＤＢデータ１１ｂと、待機系ＤＢログデータ１２ｂと、待機系インデクスデータ１４ｂと、待機系インデクスログデータ１５ｂと、を格納する。
つまり、実行系ＤＢデータ１１ａおよび待機系ＤＢデータ１１ｂ、実行系ＤＢログデータ１２ａおよび待機系ＤＢログデータ１２ｂ、実行系インデクスデータ１４ａおよび待機系インデクスデータ１４ｂ、実行系インデクスログデータ１５ａおよび待機系インデクスログデータ１５ｂは、それぞれ互いに対応し、トランザクションの終了後には互いに同じデータ内容となる。

表１は、実行系ＤＢデータ１１ａに対して、実行系ＤＢログデータ１２ａが反映される一例を示す。表１で示される３つの表は、上から順に、実行系ＤＢデータ１１ａ（ログデータ反映前）、実行系ＤＢログデータ１２ａ、実行系ＤＢデータ１１ａ（ログデータ反映後）である。

実行系ＤＢデータ１１ａ（ログデータ反映前、ログデータ反映後）は、行（レコード）ごとに、その行を特定するための行ＩＤと、その行を構成する行データと、を対応づけて構成する。行データは、１つ以上の列要素（表１では、列１から列ｎまでのｎ個の列要素）により構成される。

実行系ＤＢログデータ１２ａは、クライアント１からの操作要求による実行系ＤＢデータ１１ａの更新履歴を差分形式で示す。実行系ＤＢログデータ１２ａは、トランザクション通番と、操作種別と、行ＩＤと、行データと、を対応づけて構成する。これらの実行系ＤＢログデータ１２ａの各パラメータは、クライアント１からの操作要求から抽出される。
例えば、１行目のレコードは、トランザクション通番「１０」のトランザクションにおける操作要求「更新」により追加されたレコードであり、操作対象が行ＩＤ「１」であり、操作内容が行データ「Ａ２，Ｂ２，…，Ｃ２」への更新である。
なお、操作種別は、挿入（insert）、更新（update）、および、削除（delete）のいずれかであり、これらの操作により、データ内容が書き換わる。よって、実行系ＤＢログデータ１２ａの行データは、書き換わった後のデータ内容が記載されている。

実行系ＤＢデータ１１ａ（ログデータ反映後）は、トランザクションに対する決着要求の受信を契機に、実行系ＤＢデータ１１ａ（ログデータ反映前）に対して実行系ＤＢログデータ１２ａが反映された結果である。例えば、トランザクション通番「１０」への決着要求が受信されると、実行系ＤＢログデータ１２ａのレコードのうちのトランザクション通番が「１０」であるレコードが、反映される。その結果、例えば、実行系ＤＢデータ１１ａ（ログデータ反映後）の行ＩＤ「１」のレコードは、反映前の「Ａ，Ｂ，…，Ｃ」から反映後の「Ａ２，Ｂ２，…，Ｃ２」へと更新される。

表２は、実行系インデクスデータ１４ａに対して、実行系インデクスログデータ１５ａが反映される一例を示す。表２で示される３つの表は、上から順に、実行系インデクスデータ１４ａ（ログデータ反映前）、実行系インデクスログデータ１５ａ、実行系インデクスデータ１４ａ（ログデータ反映後）である。

実行系インデクスデータ１４ａ（ログデータ反映前、ログデータ反映後）は、行（レコード）ごとに、１つの行データのキー値と、１つ以上の行ＩＤと、を対応づけて構成する。
行データのキー値は、実行系ＤＢデータ１１ａの行データ中の列要素が取りうる値であり、実行系ＤＢデータ１１ａへの操作要求などのアクセス要求において、そのアクセス対象を特定するための検索キーである。
行ＩＤは、行データのキー値が存在する列要素を含む行をリストアップしたものである。
このように、実行系インデクスデータ１４ａを作成することにより、実行系ＤＢデータ１１ａへのアクセス効率が高まる。つまり、検索キーとして行データのキー値が指定されたときに、実際に実行系ＤＢデータ１１ａの行データを全探索する代わりに、実行系インデクスデータ１４ａを１回検索することにより、アクセス対象となる実行系ＤＢデータ１１ａの行ＩＤを高速で特定することができる。

実行系インデクスログデータ１５ａは、実行系インデクスデータ１４ａの更新履歴を差分形式で示す。なお、実行系インデクスデータ１４ａは、実行系ＤＢデータ１１ａを説明（要約）するものなので、実行系ＤＢデータ１１ａの更新に伴って更新される。
実行系インデクスログデータ１５ａは、トランザクション通番と、操作種別と、行ＩＤと、行データのキー値と、を対応づけて構成する。これらの実行系インデクスログデータ１５ａの各パラメータは、クライアント１からの操作要求から抽出される。
トランザクション通番は、操作要求を受け付けるトランザクションを特定する。
行ＩＤおよび行データのキー値は、実行系インデクスデータ１４ａへの更新内容を示す。
操作種別は、「追加」または「削除」のいずれかである。なお、操作要求と操作種別との対応関係は、操作要求「挿入」が操作種別「追加」に、操作要求「削除」が操作種別「削除」に、操作要求「更新」が操作種別「追加、削除」に、それぞれ対応する。例えば、１つの操作要求「ＡをＢに更新」は、１つの操作種別「Ａを削除」と、１つの操作種別「Ｂを追加」に分割される。
操作種別が「追加」である場合は、対応する「行ＩＤ」および「行データのキー値」は、実行系インデクスデータ１４ａに新規に追加された行に書き込まれる値、または、既存の行に上書きされる値である。
操作種別が「削除」である場合は、対応する「行ＩＤ」および「行データのキー値」は、実行系インデクスデータ１４ａから削除される行に記録されている値、または、既存の行における更新前の値である。

表２では、例えば、実行系インデクスログデータ１５ａの１行目のレコード（「１０」、「削除」、「Ｂ」、「１」）は、トランザクション通番「１０」のトランザクションにおける操作要求により追加されたレコードであり、実行系インデクスデータ１４ａにおける行ＩＤ「１」と行データのキー値「Ｂ」との組み合わせ（実行系インデクスデータ１４ａの１行目）に対して、操作種別「削除」を実行する旨を示している。
よって、実行系インデクスデータ１４ａ（ログデータ反映前）に対して、実行系インデクスログデータ１５ａが適用されると、行データのキー値「Ｂ」を含む行の行ＩＤが、「１，１０，１２」から「１」が削除されることにより、「１０，１２」となる。

資源利用状況監視部３２は、自装置である実行系サーバ２と、その系切替相手となる待機系サーバ３と、の資源（リソース）の使用率や、データベースシステムの動作状況を監視する。資源とは、例えば、ＣＰＵ、メモリ、ネットワーク帯域などである。

表３に示す資源利用状況テーブル３１は、資源利用状況監視部３２による監視結果である資源の利用状況、および、データベースシステムの動作状況を格納する。
そのため、資源利用状況テーブル３１は、例えば、実行系サーバ２のＣＰＵ使用率Ｒ１、実行系サーバ２のメモリ使用率Ｒ２、待機系サーバ３のＣＰＵ使用率Ｒ３、待機系サーバ３のメモリ使用率Ｒ４、ログデータ受信部２３のバッファキュー長Ｒ５、および、クライアント１からの決着要求に対する応答時間Ｒ６を、対応づけて格納する。

トランザクション制御部４０は、自装置である実行系サーバ２と、クライアント１とのトランザクションに関する制御を実施する。具体的には、トランザクション制御部４０は、以下の処理を実行する。
・トランザクション通番の管理：トランザクション通番は、トランザクションを識別するための番号であり、トランザクションが終了する度に、インクリメント（１ずつ増加）される。なお、同一のトランザクション内において、複数回の操作要求を受け付けた場合、それらの操作要求により書き込まれるレコードのトランザクション通番は、全て同じである。さらに、実行系サーバ２と待機系サーバ３とで、同じトランザクション通番を使用する。
・操作要求の処理：クライアント１から操作要求を受け付けると、その操作要求で指定された「行ＩＤ、行データのキー値、操作種別」をもとに、実行系ＤＢログデータ１２ａおよび実行系インデクスログデータ１５ａを作成し、現在のトランザクション通番に対応づけて実行系ＤＢ１０ａへと書き込む。
・ログデータの反映処理：表１で示したように、実行系ＤＢデータ１１ａに対して実行系ＤＢログデータ１２ａを反映するとともに、表２で示したように、実行系インデクスデータ１４ａに対して実行系インデクスログデータ１５ａを反映する。
・ログデータの送信指示：送信対象のログデータ（実行系ＤＢログデータ１２ａだけの場合、または、実行系ＤＢログデータ１２ａとその実行系インデクスログデータ１５ａとの組の場合がある）を、ログデータ送信バッファ２２に書き込むことにより、送信対象のログデータの送信を指示する。
・決着要求の処理：クライアント１から決着要求を受け付けると、待機系サーバ３に対して、未送信である送信対象のログデータを全て送信するとともに、送信対象のログデータを待機系ＤＢ１０ｂに書き込む（つまり、データ内容の同期を行う）ように指示する。

さらに、本実施形態の特徴として、トランザクション制御部４０は、データ内容の同期を行うための反映方式が複数存在するときに、その中から１つの反映方式を決定するための仕組みを有する。

表４は、反映方式の定義を示すテーブルである。このテーブルでは、２通りの送信内容および２通りの送信契機の組み合わせにより、４通りの反映方式（１）〜（４）が提示されている。これらの４通りの反映方式は、実行系ＤＢデータ１１ａに対して行われた変更が、待機系ＤＢデータ１１ｂに対しても反映されることにより、実行系ＤＢ１０ａと待機系ＤＢ１０ｂとのデータの同期が実現できるという基本的な効果は共通しつつ、以下に示す性能的な特徴に違いがある。

送信契機に着目した効果は、次の通りである。
方式（１，２）は、決着要求の受信時にログデータを送信するため、決着要求を受信するまでは、実行系サーバ２のＣＰＵ使用率を低く抑えられる。
方式（３，４）は、操作要求の受信時にログデータを送信するため、実行系サーバ２において決着要求の受信前にデータベースの処理と送信処理とが並列処理され、トランザクション全体の応答時間を短くできる。

送信内容に着目した効果は、次の通りである。
方式（１，３）は、実行系ＤＢデータ１１ａと実行系インデクスログデータ１５ａとの組を送信するため、送信された待機系サーバ３は、待機系インデクスログデータ１５ｂを新規に作成する必要はなく、実行系インデクスログデータ１５ａを待機系インデクスログデータ１５ｂとしてコピーするだけで済む。その結果、待機系サーバ３のＣＰＵ使用率を低く抑えられる。
方式（２，４）は、実行系インデクスログデータ１５ａの送信を省略するため、ログデータ送信バッファ２２およびログデータ受信バッファ２４には実行系インデクスログデータ１５ａを格納せずに済む。その結果、バッファの容量を小さくできるので、両装置のメモリ使用率、および、実行系サーバ２のＣＰＵ使用率を低く抑えられる。
以上説明した２通りの送信契機と、２通りの送信内容との組み合わせにより、４通りの反映方式（１）〜（４）の定義テーブルが構成される。さらに、別の実施形態として、２通りの送信契機の反映方式を記載する定義テーブルを構成してもよいし、２通りの送信内容の反映方式を記載する定義テーブルを構成してもよい。

トランザクション制御部４０は、評価係数テーブル４１（表５上段）と、評価値テーブル４２（表５中段）と、反映方式決定部４３（表５下段）と、を有する。
評価係数テーブル４１は、資源利用状況テーブル３１の各列要素に対して乗算（重み付け）する評価係数を、反映方式ごとに格納する。よって、評価係数テーブル４１の各列要素の形式は、資源利用状況テーブル３１の各列要素の形式と同じである。評価係数は、値が高いほど該当資源を使用する、もしくは時間を要することを示す。
評価値テーブル４２は、資源利用状況テーブル３１と評価係数テーブル４１とを参照した反映方式決定部４３による評価値を、反映方式ごとに格納する。なお、評価値の値が小さいほど、反映方式として採用されやすい（換言すると、高評価である）。
反映方式決定部４３は、互いに対応する２つの列要素（資源利用状況テーブル３１の列要素と、評価係数テーブル４１の列要素）を乗算（重み付け演算）し、それらの演算結果の合計を計算することで、反映方式ごとの評価値を計算する。この重み付け合計の計算式は、表５に記載する。

図３は、反映方式決定部４３が、反映方式を決定する処理を表すフローチャートである。

まず、以下に示す各変数の初期化を行う（Ｓ１１）。
変数「ｎ」は、反映方式の個数を示し、反映方式の番号の最大値（例えば、表４に示すように４通りなら、４）が代入される。
変数「ｊ」は、ループを１回実行する度に１ずつ加算されるループ制御用変数であり、現在計算している反映方式の番号を示し、初期値「１」が代入される。
変数「Ｅｊ」は、現在計算しているｊ番目の反映方式における評価値を示し、初期値に「０（まだ計算されていない旨を示す）が代入される。
変数「Ｅｋ」は、前回までに計算された変数「Ｅｊ」のうちの最も値の小さい変数「Ｅｊ」であり、初期値に充分大きい値（変数型が取りうる最大値）が代入される。これにより、１回目に計算される変数「Ｅｊ」の値は、確実に変数「Ｅｋ」の値を置き換える。
変数「ｋ」は、現時点で最も決定される可能性の高い反映方式の番号を示し、初期値に「０（反映方式がまだ決定されていない旨を示す）が代入される。

次に、反映方式ごとに評価値を計算するループ（Ｓ２１〜Ｓ２５）を実行する。このループは、１回のループで１つの反映方式を評価するものであり、ループ制御用変数「ｊ」の値を初期値「１」から開始し、ループを１回実行する度に１ずつ加算し、変数「ｎ」の値＋１になったときに、終了する。

ループ内において、まず、ｊ番目の反映方式における評価値を計算する（Ｓ２２）。具体的には、資源利用状況テーブル３１の各値と、評価係数テーブル４１の各値と、を重み付け合計することで、ｊ番目の反映方式における評価値を１つの評価値として集計する。その集計結果である評価値は、評価値テーブル４２に書き込まれるとともに、変数「Ｅｊ」に代入される。

次に、判定式「Ｅｊ＜Ｅｋ」により、今回計算した変数「Ｅｊ」が、前回までに計算された最小値「Ｅｋ」を下回るか否かを判定する（Ｓ２３）。もし、判定式を満たす場合（Ｓ２３，Ｙｅｓ）、最小値「Ｅｋ」に今回計算した変数「Ｅｊ」を代入するとともに、変数「ｋ」に変数「ｊ」の値（反映方式番号）を代入することで（Ｓ２４）、決定される可能性の高い反映方式の番号を更新する。以上、Ｓ２１〜Ｓ２５のループにより、最も評価値の低い反映方式の番号が、変数「ｋ」の値として計算される。

ループ外において、ループにより計算されたｋ番目の反映方式を、今回のトランザクションの処理における反映方式として決定する（Ｓ３１）。

表６は、図３に示すフローチャートの実行結果の一例を示す。下線のつけられた評価値をもつ反映方式が、採用される反映方式となる。

図４は、反映方式（１）を実行する処理を示すフローチャートである。この反映方式（１）は、Ｓ１１２で選択される。

まず、クライアント１は、１回目の操作要求を送信すると（Ｓ１０１）、実行系サーバ２のトランザクション制御部４０は、その操作要求を受信し、トランザクションを開始する（Ｓ１１１）。
反映方式決定部４３は、反映方式を決定する処理（図３参照）を呼び出すことで、操作要求の反映方式を決定する（Ｓ１１２）。
トランザクション制御部４０は、受信した１回目の操作要求で指定されたデータ内容をもとに、実行系ＤＢログデータ１２ａ、および、実行系インデクスログデータ１５ａを作成し、実行系ＤＢ１０ａに対して反映する（Ｓ１１３）。

次に、クライアント１は、２回目の操作要求を送信すると（Ｓ１０２）、実行系サーバ２のトランザクション制御部４０は、その操作要求を受信する（Ｓ１１４）。
トランザクション制御部４０は、受信した２回目の操作要求で指定されたデータ内容をもとに、実行系ＤＢログデータ１２ａ、および、実行系インデクスログデータ１５ａを作成し、実行系ＤＢ１０ａに対して反映する（Ｓ１１５）。

ここで、クライアント１は、決着要求を送信すると（Ｓ１０３）、実行系サーバ２のトランザクション制御部４０は、その操作要求を受信する（Ｓ１１６）。
ログデータ送信部２１は、２回分の操作要求で作成されたログデータ（実行系ＤＢログデータ１２ａ、および、実行系インデクスログデータ１５ａ）を、送信対象のログデータとして、ログデータ受信部２３に送信する（Ｓ１１７）。このように、決着要求を受信する前に複数回分の操作要求が発生したときには、１回分の操作要求のログデータを１回の送信処理として送信してもよいし、複数回分の操作要求のログデータを１回の送信処理にまとめて送信してもよい。

ログデータ受信部２３は、ログデータ送信部２１から送信されたログデータを受信して、ログデータ受信バッファ２４へ書き込む（Ｓ１３１）。ここで、ログデータ受信部２３は、Ｓ１３１で送信対象のログデータが全て正常に受信できたときには、送信元の実行系サーバ２に対して、正常受信完了の応答（ＡＣＫ）を送信することとしてもよい（図４の破線矢印に記載）。そして、実行系サーバ２は、送信後にＡＣＫが到着しないときには、エラーとなったログの内容を再送するなどのエラー対策を行う。

ログデータ適用部１３は、受信したログデータ（実行系ＤＢログデータ１２ａ）を、ログデータ受信バッファ２４から読み出し、待機系ＤＢ１０ｂ（待機系ＤＢログデータ１２ｂ）へ反映する（Ｓ１３２）。
ログデータ適用部１３は、受信したログデータ（実行系インデクスログデータ１５ａ）を、ログデータ受信バッファ２４から読み出し、待機系ＤＢ１０ｂ（待機系インデクスログデータ１５ｂ）へ反映する（Ｓ１３３）。

トランザクション制御部４０は、待機系サーバ３からのＡＣＫの到着を待ってから、受信した決着要求（Ｓ１１６）に対する応答を送信した後（Ｓ１１８）、トランザクションを終了する（Ｓ１１９）。クライアント１は、既に送信した決着要求（Ｓ１０３）への応答を、実行系サーバ２から受信する（Ｓ１０４）。

以上説明したように、図４に示す反映方式（１）では、決着要求の受信時を送信契機として、２種類のログデータ（実行系ＤＢログデータ１２ａ、および、実行系インデクスログデータ１５ａ）を送信することを特徴とする（Ｓ１１７参照）。

図５は、反映方式（２）を実行する処理を示すフローチャートである。この反映方式（２）は、Ｓ１１２で選択される。以下、図４の反映方式（１）と同じ処理には同じ符号を付け、処理の相違点に着目して、以下で説明する。

まず、２回分の操作要求の受信、および、そのデータ内容の反映は、図４と同じである（Ｓ１０１〜Ｓ１１６）。
次に、決着要求を受信すると（Ｓ１１６）、図４では２種類のログデータを送信対象としていたが（Ｓ１１７）、その代わりに、１種類のログデータ（実行系ＤＢログデータ１２ａ）を送信対象として送信する（Ｓ２１７）。待機系サーバ３は、受信した実行系ＤＢログデータ１２ａを、受信バッファへ書き込む（Ｓ２３１）。

そして、実行系ＤＢログデータ１２ａの反映処理は図４と図５とで同じであるが（Ｓ１３２）、図５においては実行系インデクスログデータ１５ａは送信されていないため、新たに、待機系ＤＢ１０ｂの待機系ＤＢデータ１１ｂおよび待機系ＤＢログデータ１２ｂから作成し、待機系ＤＢ１０ｂの待機系インデクスログデータ１５ｂに反映する（Ｓ２３３）。

以上説明したように、図５に示す反映方式（２）では、決着要求の受信時を送信契機として、１種類のログデータ（実行系ＤＢログデータ１２ａ）を送信することを特徴とする（Ｓ２１７参照）。

図６は、反映方式（３）を実行する処理を示すフローチャートである。この反映方式（３）は、Ｓ１１２で選択される。以下、図４の反映方式（１）と同じ処理には同じ符号を付け、処理の相違点に着目して、以下で説明する。

まず、１回目の操作要求を受信すると（Ｓ１０１）、その内容を実行系ＤＢ１０ａに反映するところまでは図４のＳ１１３と同じであるが、その後にその反映内容を示す２種類のログデータ（実行系ＤＢログデータ１２ａ、実行系インデクスログデータ１５ａ）を作成し、待機系サーバ３に送信する（Ｓ３１３）。
待機系サーバ３は、受信したログデータをログデータ受信バッファ２４へ書き込むが（Ｓ３４１）、この時点ではまだ待機系ＤＢ１０ｂへの反映は行わない。
同様に、２回目の操作要求に対する処理が行われる（Ｓ３１５，Ｓ３４２）。つまり、操作要求の発生回数分だけ、ログデータの送信処理が行われる。
なお、操作要求は複数回発生する可能性があるので、待機系サーバ３からの受信時（Ｓ３４１、Ｓ３４２）での受領確認（ＡＣＫ）は行わず、実行系サーバ２は、ログデータを送信した後（Ｓ３１３）、直ちに、次の操作要求を受信（Ｓ１１４）できるように処理を進めることが、望ましい。

そして、実行系サーバ２は、決着要求を受信すると（Ｓ１１６）、ログデータの送信は既に済んでいるので（Ｓ３４１，Ｓ３４２参照）、決着要求を受信した旨を通知する（Ｓ３１７）。待機系サーバ３は、その通知を受信する（Ｓ３４３）。なお、図４におけるＡＣＫの送信に対応する処理として、複数回のログデータの受信（Ｓ３４１，Ｓ３４２）が全て正常に受信できたときには、１回のＡＣＫの送信処理が行われる。
受信した２種類のログデータの反映処理（Ｓ３４４，Ｓ３４５）は、図４の処理（Ｓ１３２，Ｓ１３３）と同じ処理である。これは、送信契機が図４と図６とで異なっていても、送信内容が同じためである。

以上説明したように、図６に示す反映方式（３）では、操作要求の受信時を送信契機として、２種類のログデータ（実行系ＤＢログデータ１２ａ、および、実行系インデクスログデータ１５ａ）を送信することを特徴とする（Ｓ３１３，Ｓ３１５参照）。

図７は、反映方式（４）を実行する処理を示すフローチャートである。この反映方式（４）は、Ｓ１１２で選択される。以下、図６の反映方式（３）と同じ処理には同じ符号を付け、処理の相違点に着目して、以下で説明する。

まず、ログデータの送信契機は図６と図７とで同じであるが、その送信内容は、図７では１種類（実行系ＤＢログデータ１２ａ）であり、実行系インデクスログデータ１５ａの送信は行わない（Ｓ４１３，Ｓ４１５）。よって、待機系サーバ３は、実行系ＤＢログデータ１２ａのみをログデータ受信バッファ２４へ書き込む（Ｓ４４１，Ｓ４４２）。

次に、決着要求を受信した後の処理において、実行系ＤＢログデータ１２ａを待機系ＤＢログデータ１２ｂに反映する処理は、図６と図７とで同じである（Ｓ３４４）。
一方、実行系インデクスログデータ１５ａは送信されていないので、図５のＳ２３３と同様に、新規に作成して、待機系インデクスログデータ１５ｂへと反映する（Ｓ４４５）。

以上説明したように、図７に示す反映方式（４）では、操作要求の受信時を送信契機として、１種類のログデータ（実行系ＤＢログデータ１２ａ）を送信することを特徴とする（Ｓ４１３，Ｓ４１５参照）。

図８は、図４で説明した反映方式（１）を実行する処理を、図１で説明した待機系サーバ３のクラスタリング構成で実施するフローチャートである。

まず、実行系サーバ２は、２種類のログデータを送信する（Ｓ１１７）ときに、１回のマルチキャスト通信で各待機系サーバ３（待機系サーバ３ａ、待機系サーバ３ｂ、待機系サーバ３ｃ）に送信することが、望ましい。これにより、ネットワークの使用効率を高めつつ、輻輳を抑制することができる。

そして、実行系サーバ２は、受信した決着要求（Ｓ１１６）に対する応答を送信する（Ｓ１１８）条件として、Ｓ１１７での送信相手となる各待機系サーバ３から、個別にＡＣＫの到着を待ち、全てのＡＣＫ（図８では、３つのＡＣＫ）が到着されたこととしてもよい。

以上説明した本実施形態では、実行系サーバ２と待機系サーバ３との間のデータ同期処理（反映方式）を複数備えるとともに、実行系サーバ２の資源および待機系サーバ３の資源の利用状況に応じて、最適な反映方式を決定することを、特徴とする。
これにより、システム稼動中の負荷の変動や、ハードウェア障害、システム構成変更が発生して資源の使用率が変動しても、余裕のある資源を優先して利用する反映方式が選択される。よって、実行系サーバ２および待機系サーバ３の双方を含めたデータベースシステム全体で、高信頼性および可用性を高めることができる。

本発明の一実施形態に関するデータベースシステムのハードウェア構成を示す構成図である。 本発明の一実施形態に関するデータベースシステムの各サーバ装置の詳細を示す構成図である。 本発明の一実施形態に関する反映方式を決定する処理を示すフローチャートである。 本発明の一実施形態に関する反映方式（１）を実行する処理を示すフローチャートである。 本発明の一実施形態に関する反映方式（２）を実行する処理を示すフローチャートである。 本発明の一実施形態に関する反映方式（３）を実行する処理を示すフローチャートである。 本発明の一実施形態に関する反映方式（４）を実行する処理を示すフローチャートである。 本発明の一実施形態に関する反映方式（１）を実行する処理を、待機系サーバのクラスタリング構成で実施する処理を示すフローチャートである。

符号の説明

１ クライアント
２ 実行系サーバ
３ 待機系サーバ
３ｂ 待機系サーバ
３ｃ 待機系サーバ
９ ネットワーク
１０ａ 実行系ＤＢ
１０ｂ 待機系ＤＢ
１１ａ 実行系ＤＢデータ
１１ｂ 待機系ＤＢデータ
１２ａ 実行系ＤＢログデータ
１２ｂ 待機系ＤＢログデータ
１３ ログデータ適用部
１４ａ 実行系インデクスデータ
１４ｂ 待機系インデクスデータ
１５ａ 実行系インデクスログデータ
１５ｂ 待機系インデクスログデータ
２０ 通信インターフェース
２１ ログデータ送信部
２２ ログデータ送信バッファ
２３ ログデータ受信部
２４ ログデータ受信バッファ
３１ 資源利用状況テーブル
３２ 資源利用状況監視部
４０ トランザクション制御部
４１ 評価係数テーブル
４２ 評価値テーブル
４３ 反映方式決定部
９１ ＣＰＵ
９２ メモリ

Claims (11)

1. クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときに前記実行系サーバの処理を代行する待機系サーバとを有し冗長構成とするデータベースシステムにおける前記実行系サーバが有する実行系ＤＢと、前記待機系サーバが有する待機系ＤＢとを、データ同期処理するデータ同期方法であって、
   前記実行系サーバは、前記実行系ＤＢに加えて、資源利用状況テーブル、資源利用状況監視部、トランザクション制御部、反映方式決定部、評価係数テーブル、および、同期用データ送信部を有し、
   前記待機系サーバは、前記待機系ＤＢに加えて、同期用データ適用部を有し、
   前記トランザクション制御部は、データ内容を指定して更新させるための操作要求を前記クライアントから受信すると、受信した前記操作要求を処理するためのトランザクションを開始した後、前記受信した操作要求で指定される更新内容を、ＤＢログデータとして前記実行系ＤＢに反映するとともに、前記実行系ＤＢにアクセスするためのインデクスデータのうち、前記ＤＢログデータに対応するインデクスデータを、インデクスログデータとして、前記実行系ＤＢに反映し、
   前記資源利用状況監視部は、前記データベースシステムを構成する各サーバにおける資源の使用率情報およびデータベースの動作状況情報のうちの少なくとも１つの情報を収集して前記資源利用状況テーブルに格納し、
   前記評価係数テーブルには、前記資源利用状況テーブルに格納される収集値ごとの評価係数が予め格納されており、
   前記反映方式決定部は、前記資源利用状況テーブルに格納されている収集値と、前記評価係数テーブルに格納されている収集値ごとの評価係数と、を重み付け合計することにより、反映方式ごとの評価値を計算し、その評価値が最小となる前記反映方式を決定し、
   前記同期用データ送信部は、決定された前記反映方式に従って、前記実行系ＤＢに反映されたデータを、ＤＢ同期用データとして、冗長構成の相手となる前記待機系サーバに送信し、
   前記同期用データ適用部は、トランザクションを決着させるための決着要求が前記クライアントから前記実行系サーバへと送信されると、決定された前記反映方式に従って、受信した前記ＤＢ同期用データを前記待機系ＤＢに反映すること、を特徴とする
   データ同期方法。
   ただし、前記反映方式は、以下の（ａ）または（ｂ）に示す前記ＤＢ同期用データの送信内容から１つを選択することにより定義する
   （ａ）前記ＤＢログデータを送信内容とするが、前記インデクスログデータは送信せずに前記待機系サーバ側で別途作成させる
   （ｂ）前記ＤＢログデータに加えて、前記インデクスログデータを送信内容とする
2. 前記反映方式決定部は、前記ＤＢ同期用データの送信契機を前記操作要求の受信時とする前記反映方式、および、前記ＤＢ同期用データの送信契機を前記決着要求の受信時とする前記反映方式のうち、いずれか１つの反映方式を前記評価値をもとに決定することを特徴とする
   請求項１に記載のデータ同期方法。
3. 前記実行系サーバは、前記実行系ＤＢにおいて格納するデータをメモリに格納し、
   前記待機系サーバは、前記待機系ＤＢにおいて格納するデータをメモリに格納することを特徴とする
   請求項１または請求項２に記載のデータ同期方法。
4. 前記待機系サーバは、データベースシステム内に複数台配置され、
   前記同期用データ送信部は、決定された前記反映方式に従って、前記ＤＢ同期用データを冗長構成の相手となる複数台の前記待機系サーバに対してマルチキャスト通信で送信することを特徴とする
   請求項１ないし請求項３のいずれか１項に記載のデータ同期方法。
5. 請求項１ないし請求項４のいずれか１項に記載のデータ同期方法を、コンピュータである前記実行系サーバおよび前記待機系サーバにそれぞれ実行させるためのデータ同期プログラム。
6. クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときに前記実行系サーバの処理を代行する待機系サーバとを有し冗長構成とするデータベースシステムにおける前記実行系サーバが有する実行系ＤＢと、前記待機系サーバが有する待機系ＤＢとを、データ同期処理するためのデータベースサーバ装置であって、
   前記実行系サーバは、前記実行系ＤＢに加えて、資源利用状況テーブル、資源利用状況監視部、トランザクション制御部、反映方式決定部、評価係数テーブル、および、同期用データ送信部を有し、
   前記待機系サーバは、前記待機系ＤＢに加えて、同期用データ適用部を有し、
   前記トランザクション制御部は、データ内容を指定して更新させるための操作要求を前記クライアントから受信すると、受信した前記操作要求を処理するためのトランザクションを開始した後、前記受信した操作要求で指定される更新内容を、ＤＢログデータとして前記実行系ＤＢに反映するとともに、前記実行系ＤＢにアクセスするためのインデクスデータのうち、前記ＤＢログデータに対応するインデクスデータを、インデクスログデータとして、前記実行系ＤＢに反映し、
   前記資源利用状況監視部は、前記データベースシステムを構成する各サーバにおける資源の使用率情報およびデータベースの動作状況情報のうちの少なくとも１つの情報を収集して前記資源利用状況テーブルに格納し、
   前記評価係数テーブルには、前記資源利用状況テーブルに格納される収集値ごとの評価係数が予め格納されており、
   前記反映方式決定部は、前記資源利用状況テーブルに格納されている収集値と、前記評価係数テーブルに格納されている収集値ごとの評価係数と、を重み付け合計することにより、反映方式ごとの評価値を計算し、その評価値が最小となる前記反映方式を決定し、
   前記同期用データ送信部は、決定された前記反映方式に従って、前記実行系ＤＢに反映されたデータを、ＤＢ同期用データとして、冗長構成の相手となる前記待機系サーバに送信し、
   前記同期用データ適用部は、トランザクションを決着させるための決着要求が前記クライアントから前記実行系サーバへと送信されると、決定された前記反映方式に従って、受信した前記ＤＢ同期用データを前記待機系ＤＢに反映すること、を特徴とする
   データベースサーバ装置。
   ただし、前記反映方式は、以下の（ａ）または（ｂ）に示す前記ＤＢ同期用データの送信内容から１つを選択することにより定義する
   （ａ）前記ＤＢログデータを送信内容とするが、前記インデクスログデータは送信せずに前記待機系サーバ側で別途作成させる
   （ｂ）前記ＤＢログデータに加えて、前記インデクスログデータを送信内容とする
7. 前記反映方式決定部は、前記ＤＢ同期用データの送信契機を前記操作要求の受信時とする前記反映方式、および、前記ＤＢ同期用データの送信契機を前記決着要求の受信時とする前記反映方式のうち、いずれか１つの反映方式を前記評価値をもとに決定することを特徴とする
   請求項６に記載のデータベースサーバ装置。
8. クライアントからの要求に従ってデータを更新する実行系サーバと、前記実行系サーバに障害が発生したときに前記実行系サーバの処理を代行する待機系サーバとを有し冗長構成とし、データベースシステムにおける前記実行系サーバが有する実行系ＤＢと、前記待機系サーバが有する待機系ＤＢとを、データ同期処理するデータベースシステムであって、
   前記実行系サーバは、前記実行系ＤＢに加えて、資源利用状況テーブル、資源利用状況監視部、トランザクション制御部、反映方式決定部、評価係数テーブル、および、同期用データ送信部を有し、
   前記待機系サーバは、前記待機系ＤＢに加えて、同期用データ適用部を有し、
   前記トランザクション制御部は、データ内容を指定して更新させるための操作要求を前記クライアントから受信すると、受信した前記操作要求を処理するためのトランザクションを開始した後、前記受信した操作要求で指定される更新内容を、ＤＢログデータとして前記実行系ＤＢに反映するとともに、前記実行系ＤＢにアクセスするためのインデクスデータのうち、前記ＤＢログデータに対応するインデクスデータを、インデクスログデータとして、前記実行系ＤＢに反映し、
   前記資源利用状況監視部は、前記データベースシステムを構成する各サーバにおける資源の使用率情報およびデータベースの動作状況情報のうちの少なくとも１つの情報を収集して前記資源利用状況テーブルに格納し、
   前記評価係数テーブルには、前記資源利用状況テーブルに格納される収集値ごとの評価係数が予め格納されており、
   前記反映方式決定部は、前記資源利用状況テーブルに格納されている収集値と、前記評価係数テーブルに格納されている収集値ごとの評価係数と、を重み付け合計することにより、反映方式ごとの評価値を計算し、その評価値が最小となる前記反映方式を決定し、
   前記同期用データ送信部は、決定された前記反映方式に従って、前記実行系ＤＢに反映されたデータを、ＤＢ同期用データとして、冗長構成の相手となる前記待機系サーバに送信し、
   前記同期用データ適用部は、トランザクションを決着させるための決着要求が前記クライアントから前記実行系サーバへと送信されると、決定された前記反映方式に従って、受信した前記ＤＢ同期用データを前記待機系ＤＢに反映すること、を特徴とする
   データベースシステム。
   ただし、前記反映方式は、以下の（ａ）または（ｂ）に示す前記ＤＢ同期用データの送信内容から１つを選択することにより定義する
   （ａ）前記ＤＢログデータを送信内容とするが、前記インデクスログデータは送信せずに前記待機系サーバ側で別途作成させる
   （ｂ）前記ＤＢログデータに加えて、前記インデクスログデータを送信内容とする
9. 前記反映方式決定部は、前記ＤＢ同期用データの送信契機を前記操作要求の受信時とする前記反映方式、および、前記ＤＢ同期用データの送信契機を前記決着要求の受信時とする前記反映方式のうち、いずれか１つの反映方式を前記評価値をもとに決定することを特徴とする
   請求項８に記載のデータベースシステム。
10. 前記実行系サーバは、前記実行系ＤＢにおいて格納するデータをメモリに格納し、
    前記待機系サーバは、前記待機系ＤＢにおいて格納するデータをメモリに格納することを特徴とする
    請求項８または請求項９に記載のデータベースシステム。
11. 前記待機系サーバは、前記データベースシステム内に複数台配置され、
    前記同期用データ送信部は、決定された前記反映方式に従って、前記ＤＢ同期用データを冗長構成の相手となる複数台の前記待機系サーバに対してマルチキャスト通信で送信することを特徴とする
    請求項８ないし請求項１０のいずれか１項に記載のデータベースシステム。

Images