(57)【要約】【課題】データベース管理システムにおいて、データベースレプリケーション機能には、製品の提供する機能に潜在的な不備により、データ不整合が発生するリスクがある。【解決手段】データベースレプリケーション処理の前に同処理の有無を判断し、実行中の同処理が存在しないと判断するときにデータベースレプリケーション処理を実行し、データベースレプリケーション処理の前後でレコード件数を比較する。【選択図】図１
2013250590.tif 000002
【特許請求の範囲】
【請求項１】
マスタテーブルとレプリケーション用テーブルとを管理するデータベース管理部と、
前記マスタテーブルから前記レプリケーション用テーブルへのレプリケーションを制御するレプリケーション制御部と、
前記レプリケーション制御部へ処理を指示するジョブスケジューラ部とを備えるサーバ装置であって、
前記レプリケーション制御部は、前記ジョブスケジューラ部からコマンドを受信する場合、実行中の前記レプリケーションの有無を判断して実行中の前記レプリケーションが存在しないときに、前記レプリケーションを処理し、前記レプリケーションの処理の前に取得した前記マスタテーブルのレコード件数と前記レプリケーションの処理後に取得した前記レプリケーション用テーブルのレコード件数との比較をし、前記比較で一致のときに実行結果のコマンドを前記ジョブスケジューラ部に送信することを特徴とするサーバ装置。
【請求項２】
前記レプリケーション制御部は、前記比較で不一致のときに前記レプリケーションの処理回数を判定し、処理回数が１回のときには前記レプリケーションの再実行を処理し、前記レプリケーションの再処理の前に取得した前記マスタテーブルのレコード件数と前記再実行の後に取得した前記レプリケーション用テーブルのレコード件数との比較をし、前記比較で一致のときに正常終了通知のコマンドを前記ジョブスケジューラ部に送信することを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記レプリケーション制御部は、実行中の前記レプリケーションの有無を判断して、前記ジョブスケジューラ部から受信する他のコマンドに基づくレプリケーションが存在する場合には、一定時間待機した後に、実行中の前記レプリケーションの有無を判断することを特徴とする請求項１乃至２に記載のサーバ装置。
【請求項４】
前記レプリケーション制御部は、前記レプリケーションを実行するバッチプログラムをインストールされたものであることを特徴とする請求項１乃至２に記載のサーバ装置。
【請求項５】
前記レプリケーション制御部は、前記比較で不一致のときに前記レプリケーションの処理回数を判定し、処理回数が１回のときには前記レプリケーションの再実行を処理し、前記レプリケーションの再処理の前に取得した前記マスタテーブルのレコード件数と前記再実行の後に取得した前記レプリケーション用テーブルのレコード件数との比較をし、前記比較で不一致のときに異常終了通知のコマンドを前記ジョブスケジューラ部に送信することを特徴とする請求項１に記載のサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース上のレプリケーションの技術に関する。
【背景技術】
【０００２】
従来、データベース管理システム（database management system、DBMS）製品では、データベースレプリケーション機能の不良によるデータ不整合が発生するリスクがあった。信頼性を高めるためにはDBMS製品の提供するデータベースレプリケーション機能を使用せず、独自のデータベースレプリケーション機能を開発して導入する方式がある。しかし、信頼性をDBMS製品が提供する機能の範囲で許容するのであれば、独自開発は行わないことも可能である。
【０００３】
レプリケーション機能をコンピュータに搭載させる技術としては、例えば、マスタＤＢの複数の複製レプリカＤＢを作成するレプリケーション機能を搭載するコンピュータがレプリカＤＢを作成するための更新情報を配信する技術が存在する（特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2005-293323
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来の技術には以下の課題が存在した。
【０００６】
第一に、DBMS製品の機能ではなく、独自のデータベースレプリケーション機能を開発する場合、新たに設計・開発・試験の期間と費用が必要となる点である。しかし、独自のデータベースレプリケーション機能を開発せず、製品の提供する機能だけに頼る場合、製品の提供する機能に潜在的な不備により、データ不整合が発生するリスクがある。
【０００７】
第二に、独自にデータベースレプリケーション機能を開発する場合、独自開発したデータベースレプリケーション機能が同時実行された場合にレプリケーション元とレプリケーション先のデータが不整合になるリスクがある。
【課題を解決するための手段】
【０００８】
本発明によるサーバ装置は一例として、マスタテーブルとレプリケーション用テーブルとを管理するデータベース管理部と、前記マスタテーブルから前記レプリケーション用テーブルへのレプリケーションを制御するレプリケーション制御部と、前記レプリケーション制御部へ処理を指示するジョブスケジューラ部とを備えるサーバ装置であって、前記レプリケーション制御部は、前記ジョブスケジューラ部からコマンドを受信する場合、実行中の前記レプリケーションの有無を判断して実行中の前記レプリケーションが存在しないときに、前記レプリケーションを処理し、前記レプリケーションの処理の前に取得した前記マスタテーブルのレコード件数と前記レプリケーションの処理後に取得した前記レプリケーション用テーブルのレコード件数との比較をし、前記比較で一致のときに実行結果のコマンドを前記ジョブスケジューラ部に送信することを特徴とする。
【発明の効果】
【０００９】
データベースレプリケーション処理の多重実行を防ぐことが可能となる。また、仮にジョブスケジューラから複数のレプリケーションの実行を同期間に指令される場合にもレプリケーションによるデータ不整合の発生を防止することができる。
【図面の簡単な説明】
【００１０】
【図１】システム構成例の図
【図２】処理フロー例の図
【発明を実施するための形態】
【００１１】
以下に、図面を参照して、本発明の実施例について説明する。
【００１２】
図1にシステム構成例の図を示す。図１に記載している通り、本実施例はオペレーションシステム (OS)がインストールされたサーバ装置上にデータベース管理部、ジョブスケジューラ部を設け、レプリケーションを実行するバッチプログラムをインストールしたレプリケーション制御部の制御の下で動作する。また、本実施例はデータベース管理部が管理するデータベースに、マスタテーブル、およびレプリケーション用テーブルを作成する。
【００１３】
図2にジョブスケジューラ部とバッチプログラム(レプリケーション制御部)との処理のフローを示す。本実施例では、ジョブスケジューラ部から送信されるコマンドをトリガーとして、バッチプログラム(レプリケーション制御部)を実行することでバッチプログラム(レプリケーション制御部)でのレプリケーション処理を開始する（図２の１）。
【００１４】
バッチプログラムは、処理を実行する上で必要なパラメータを定義ファイルから読み込む（図２の２）。定義ファイルは例えばデータベースのインスタンス名称や接続ユーザ名/パスワード、マスタテーブル名称、レプリケーション先テーブル名称、ログファイル名称の情報を含む。
【００１５】
定義ファイルを読み込んだ後、バッチプログラムはレプリケーションの多重実行を防止するために、レプリケーションの実行状態(未実行 or 実行中)をチェックする前処理に入り（図２の３）、実行中のレプリケーションの有無を判断する（図２の４）。実行中のレプリケーションの有無については、バッチプログラム(レプリケーション制御部)のプロセスの存在有無にて実行中か判断する。
【００１６】
当該チェック処理でレプリケーションが先にジョブスケジューラ部から別途送信されたコマンドに応じてレプリケーション実行中のためチェック結果がＮＧとなる場合は、レプリケーションが実行中ではない状態になるまで一定時間待機する（図２の５）。
【００１７】
レプリケーションが実行中ではなくチェック結果がＯＫとなる場合、データベースのマスタテーブルからテーブルのレコード件数を取得する（図２の６）。
【００１８】
マスタテーブルからのテーブル件数取得後に、マスタテーブルからレプリケーション用テーブルに対してレプリケーションを実行する（図２の７）。
【００１９】
レプリケーション実行後にレプリケーション用テーブルのレコード件数を取得する（図２の８）。
【００２０】
レプリケーション用テーブルのレコード件数取得後に、先に取得したマスタテーブルのレコード件数とレプリケーション用テーブルのレコード件数とを比較する（図２の９）。  レコード件数比較後に、レコード件数が一致し比較結果ＯＫとなる場合は、バッチプログラムの実行結果(正常終了通知。例えば正常終了のリターンコード、標準出力ログ等。)をジョブスケジューラに対して送信するようコマンドを送信する（図２の１１、１２）。  レコード件数が一致せず比較結果ＮＧとなる場合は、レプリケーションを実行した回数を判定する(図２の１０)。
【００２１】
実行回数が1回である場合は、マスタテーブルのレコード件数取得からレコード件数比較までの処理を再実行する(図２の６、７、８，９)。実行回数が2回である場合は、バッチプログラムの実行結果(異常終了通知。例えば異常終了のリターンコード、標準出力ログ等。)をジョブスケジューラに対して送信するようコマンドを送信する（図２の１１、１２）。実行回数が２回である場合は、サーバ装置の状態に不備がある可能性があるため、レプリケーションの無限ループとならないように終了させる。
【図１】
2013250590.tif 000003
【図２】
2013250590.tif 000004