(57)【特許請求の範囲】
【請求項１】
第１のデータを管理する第１の管理部と第２のデータを管理する第２の管理部とが前記第１のデータと前記第２のデータとを共用するデータべース管理方法において、
前記第１の管理部から前記第２のデータを参照する場合は、前記第１の管理部が前記第２のデータを参照し、前記第１の管理部から前記第２のデータを更新する場合は、前記第１の管理部から第２の管理部へ前記第２のデータを更新する更新要求を送り、前記第２の管理部が前記第２のデータを更新することを特徴とするデータベース管理方法。
【請求項２】
請求項１記載のデータベース管理方法において、前記第２の管理部から前記第２のデータを参照する場合は、前記第２の管理部が前記第２のデータを参照し、前記第２の管理部から前記第２のデータを更新する場合は、前記第２の管理部が前記第２のデータを更新することを特徴とするデータベース管理方法。
【請求項３】
請求項１記載のデータベース管理方法において、前記第１の管理部から前記第１のデータを参照する場合は、前記第１の管理部が前記第１のデータを参照し、前記第１の管理部から前記第１のデータを更新する場合は、前記第１の管理部が前記第１のデータを更新することを特徴とするデータベース管理方法。
【請求項４】
請求項３記載のデータベース管理方法において、前記第１の管理部は、前記第１のデータの更新ジャーナルを生成し、前記第２の管理部は、前記第２のデータの更新ジャーナルを生成することを特徴とするデータベース管理方法。
【請求項５】
請求項４記載のデータベース管理方法において、前記第１のデータの障害を検出した場合は前記第１の管理部で生成した更新ジャーナルを、前記第２のデータの障害を検出した場合は前記第２の管理部で生成した更新ジャーナルを参照して回復処理を行うことを特徴とするデータベース管理方法。
【請求項６】
第１のプロセッサと、データ領域を管理する第２のプロセッサとの間で前記データ領域を共用するデータベース管理方法において、データ参照要求を受けた第１のプロセッサは、前記データ領域を参照し、データ更新要求を受けた第１のプロセッサは、前記データ更新要求を前記第２のプロセッサへデータ更新要求を転送し、当該更新要求を受け取った前記第2のプロセッサが前記データ領域のデータを更新することを特徴とするデータベース管理方法。
【請求項７】
第１のデータを管理する第１の管理手段と第２のデータを管理する第２の管理手段とが前記第１のデータと前記第２のデータとを共用するデータベース管理システムにおいて、前記第１の管理手段は、入力した更新要求に従い前記第１のデータを更新する第１のデータ更新手段と、前記第２のデータの更新要求を前記第２の管理手段へ送る第１のデータ更新要求手段と、入力した参照要求に従い前記第１のデータ及び前記第２のデータを参照する第１のデータ参照手段とを備え、前記第２の管理手段は、入力した更新要求に従い前記第２のデータを更新する第２のデータ更新手段と、前記第１のデータの更新要求を前記第１の管理手段へ送る第２のデータ更新要求手段と、入力した参照要求に従い前記第１のデータ及び前記第２のデータを参照する第２のデータ参照手段とを備えたことを特徴とするデータベース管理システム。
【請求項８】
第１のデータを管理する第１の管理部と第２のデータを管理する第２の管理部とが前記第１のデータと前記第２のデータとを共用するデータベース管理システムにおいて、前記第１の管理部から前記第２のデータを参照する場合は、前記第１の管理部が前記第２のデータを参照し、前記第１の管理部から前記第２のデータを更新する場合は、前記第１の管理部から第２の管理部へ前記第２のデータを更新する更新要求を送り、前記第２の管理部が前記第２のデータを更新することを特徴とするデータベース管理システム。
【請求項９】
請求項８記載のデータベース管理システムにおいて、前記第２の管理部は、前記第２の管理部から前記第２のデータを参照する場合、前記第２のデータを参照し、前記第２の管理部から前記第２のデータを更新する場合、前記第２のデータを更新することを特徴とするデータベース管理システム。
【請求項１０】
請求項８記載のデータベース管理システムにおいて、前記第１の管理部は、前記第１のデータを参照する場合、前記第１のデータを参照し、前記第１の管理部から前記第１のデータを更新する場合、前記第１のデータを更新することを特徴とするデータベース管理システム。
【請求項１１】
請求項１０記載のデータベース管理システムにおいて、前記第１の管理部は、前記第１のデータの更新ジャーナルを生成し、前記第２の管理部は、前記第２のデータの更新ジャーナルを生成する手段を備えたことを特徴とするデータベース管理システム。
【請求項１２】
請求項１１記載のデータベース管理システムにおいて、前記第１のデータの障害を検出した場合は前記第１の管理部で生成した更新ジャーナルを、前記第２のデータの障害を検出した場合は前記第２の管理部で生成した更新ジャーナルを参照して回復処理を行う手段を備えたことを特徴とするデータベース管理システム。
【請求項１３】
第１のプロセッサと、データ領域を管理する第２のプロセッサとの間で前記データ領域を共用するデータベース管理装置において、データ参照要求を受けた第１のプロセッサは、前記データ領域を参照し、データ更新要求を受けた第１のプロセッサは、前記データ更新要求を前記第２のプロセッサへデータ更新要求を転送し、当該更新要求を受け取った前記第２のプロセッサが前記データ領域のデータを更新することを特徴とするデータベース管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
データベースを複数のデータベース管理部で共有する場合のデータベース管理技術である。
【０００２】
【従来の技術】
システム間でＤＢを共用する方式として、例えば特開昭６２−２０４３６０号公報に記載のように、共用ＤＢの排他制御のため、ＤＢ管理元をきめ、このロックマネジャと他システムとの間で排他情報をやりとりして排他の一元管理を行なう方法が知られている。
【０００３】
また、この方式では、ＤＢ障害時の回復情報であるジャーナルは、各システムで取得されておりＤＢ障害回復時、ジャーナルマージが必要であった。
【０００４】
【発明が解決しようとする課題】
従来のシステム間ＤＢ共用方式では、性能面、運用面で、下記の問題があった。（１）システム間共用ＤＢに対して、データ検索だけを行う場合でも、当該ＤＢに対する更新処理との排他制御を行うために、ＤＢ管理元システムに排他使用連絡を行う必要が有り、システム間でＤＢ共用しない場合に比べて、データ検索のオ一バヘッドが大きくなるため、大量のデータ検索には適していない。
（２）システム間共用ＤＢに対して、複数ＣＰＵからデータ更新を行う場合、ＤＢ更新ジャーナルは、ＤＢ更新要求元システムで取得されるため、ＤＢ障害回復時、複数システムのジャーナルをマージする必要が有る。
本発明の目的は、以上の問題を解決するシステム間データベース共用方式を提供することにある。
【０００５】
【課題を解決するための手段】
上記目的を達成するために、ＣＰＵ間のＤＢ共用方式として、
（１）データ検索オ一バヘッドの削減
ＣＰＵ間共用ＤＢに対して、データ検索しか行わない処理（トランザクション）については、アクセス対象のデータに対して、排他制御を行わず、データ検索要求元ＣＰＵから直接データアクセスを行う。
【０００６】
これにより、データ検索については、ＣＰＵ間で共用しないＤＢへのアクセスと同等の性能を実現できる。
【０００７】
データ検索時、他ＣＰＵからのデータ更新処理とのタイミングにより、検索データブロックの制御情報に矛盾を検知した場合は、次のいずれかの方法で処理する。（ａ）一定時間間隔で一定回数、データ検索を再指向し、タイミングによる同期ズレを救済する。（ｂ）当該データベース管理元ＣＰＵに検索要求を転送し、矛盾のない状態での検索をデータベース管理元ＣＰＵで実行する。
【０００８】
（２）ＤＢ障害回復用ジャーナルの一元化
ＤＢ障害回復には、ＤＢのバックアップ情報と、バックアップ取得時点以降のＤＢ更新ジャーナル情報が必要である。ＤＢ更新ジャーナルを１つのＣＰＵの下で一元化して取得するため、ＤＢ更新処理については、すべてＤＢ管理元ＣＰＵで実施する。即ち、ＤＢ管理元以外のＣＰＵから、ＣＰＵ間共用ＤＢを更新するときは、ＤＢ管理元ＣＰＵへＤＢ更新要求を送り、ＤＢ管理元ＣＰＵでＤＢ更新する方式とする。
【作用】
本発明のＣＰＵ間ＤＢ共用方式では、ＤＢ検索だけの処理（トランザクション）については、ＤＢ検索要求元ＣＰＵから、他ＣＰＵとの連絡なしに直接ＤＢアクセスができるので、非共用ＤＢへのアクセスと同等の検索性能が実現できる。
【０００９】
また、ＤＢ更新は、ＤＢ管理元ＣＰＵで一元化して行うので、複数のＣＰＵから同一ＤＢに対して更新要求があっても、同一ＤＢの更新ジャーナルは、当該ＤＢの管理元ＣＰＵで一元化して取得され、ＤＢ障害回復時のジャーナルマージが不要となり、ＤＢ障害などに関するＤＢシステム運用管理者の負担の大幅軽減が実現できる。
【００１０】
【発明の実施の形態】
以下、本発明の一実施例を図面により詳細に説明する。
第１図は、本発明の構成を示すブロック図である。
ＣＰＵａ１が共用ＤＢ３の管理元であるとき、ＣＰＵｂ２のユーザプログラム２２からのＤＢアクセス要求があった場合、検索については、ＣＰＵｂ２のＤＢアクセス部２１が直接ＤＢアクセスを行い、更新については、ＣＰＵｂ２のＤＢアクセス部２１からＣＰＵｂ２のＤＢ分散機能部２３、ＣＰＵａ１のＤＢ分散機能部１３を経由して、ＣＰＵａ１のＤＢアクセス部１１がＤＢアクセスを行う。
【００１１】
ＣＰＵａ１のユーザプログラム１２からのＤＢアクセス要求があると、検索、更新にかかわらず、ＣＰＵａ１のＤＢアクセス部１１がＤＢアクセスを行う。
【００１２】
アクセス対象のＤＢがＣＰＵａ１の管理するＤＢかＣＰＵｂ２の管理するＤＢかは、第６図に示すテーブルで管理し、それぞれのＤＢアクセス部で管理元を判別する。
【００１３】
以下、ＤＢ検索、更新の具体的な処理手順を説明する。
（１）ＤＢ検索の場合（第２図参照）
ＣＰＵｂ２のユーザプログラム２２から、ＣＰＵａ１の管理する共用ＤＢ３への検索要求が発行されると（２０１）、ＣＰＵｂ２のＤＢアクセス部２１で、当該ＤＢ３を直接アクセスする。ただし、ＣＰＵａ１側との排他制御を行わずにアクセスするので、ＣＰＵａ１側の更新処理とのタイミシグによっては、ＤＢのインデックス部とＤＢのデータ部の内容に不一致があるように見える場合がある。そこで、この微妙なタイミングを排他制御なしに対処するために、ＤＢのインデックス部とデータ部の内容に不一致がある場合（２０２）には、所定の時間間隔で所定回数、ＤＢインデックス、ＤＢデータのリードを再試行し（２０３）、タイミングズレによる不一致がなくなるのを待つ。
所定回数内でも矛盾がなくならない場合、恒久的データ破壊が起きていると判断し、リードエラ一として処理する（２０４）。
（２）ＤＢ更新の場合（第３図〜第５図参照）
ＣＰＵｂ２のユーザプログラム２２から、ＣＰＵａ１の管理する共用ＤＢ３を更新する場合について、３つの段階に分けて説明する。（ａ）更新のための検索要求
第３図に、ＣＰＵｂ２で共用ＤＢ３更新のための検索要求が発行された場合を示す。
【００１４】
ＣＰＵｂ２のＤＢアクセス部２１では、第６図のＤＢ所在管理テーブルを用いて、要求のあったＤＢが自ＣＰＵ管理のＤＢか否か判別し（３０１）、ＣＰＵａ１の管理するＤＢへの要求ならば、ＤＢ分散機能部２３を通じて、ＣＰＵａ１へＤＢアクセス要求を送信する（３０２）。ＣＰＵａ１では、ＣＰＵｂ２から送信され、ＤＢ分散機能部１３で受信した（３０３）ＤＢアクセス要求にもとづき、ＤＢ排他使用を宣言し（３０４）、ＤＢアクセスを行ない、ＤＢインデックス部、ＤＢデータ部を読み込む（３０５，３０６）。読み込んだ結果はＤＢ分散機能部１３を通じてＣＰＵｂ２ヘ送信する（３０７）。
【００１５】
ＣＰＵｂ２の管理するＤＢの場合は、ＣＰＵｂ２のアクセス部でＤＢアクセスを行なう（３０８〜３１０）。
【００１６】
（ｂ）更新要求
第４図に、ＣＰＵｂ２から共用ＤＢ３に対する更新要求が発行された場合を示す。
【００１７】
（ａ）の場合と同様、ＣＰＵｂ２のユーザプログラム２２から更新要求があると（４０１）、ＤＢアクセス部２１では、自ＣＰＵ管理のＤＢかを判断する（４０２）。自ＣＰＵ管理でない場合ＤＢ分散機能部を通じてＤＢ管理元ＣＰＵ、この場合ＣＰＵａ１ヘ、ＤＢアクセス要求を送信する（４０３）。ＣＰＵａ１では、ＤＢ分散機能部１３で更新要求を受信すると（４０４）、ＤＢアクセス部で同期点に達するまでＤＢ更新要求を退避し（４０５）、更新要求処理報告をＤＢ機能分散部を通じてＣＰＵｂ２に送信する（４０６）。（ｃ）コミット（ＣＯＭＭｌＴ）あるいはリ夕一ン
第５図に、ＣＰＵｂ２のユーザプログラム２２がコミットを発行したか、あるいは、リターンをして処理の同期点に達した場合を示す。
コミット要求の場合を説明する。（ａ）の場合と同様、ＣＰＵｂ２からＣＰＵａ１ヘ、ＤＢ分散機能部２３を通じて、まずコミット準備要求が送信される（５０２）。ＣＰＵａ１ではＤＢアクセス部でＤＢ更新要求と、ＤＢジャーナル取りだし（５０４，５０５）コミット準備完了報告をＣＰＵｂ２に送信する（５０６）。ＣＰＵｂ２のＤＢアクセス部は、コミット準備完了報告を受信すると、コミット要求を送信する（５０８）（２フェーズコミット）。コミット要求を受けるとＣＰＵａ１は、ＤＢアクセス部で共用ＤＢの実更新を行い（５０９〉、ＤＢ排他使用の宣言を解除して（５１０）、コミット完了報告をＣＰＵｂ２に行う（５１１）。この時、ＤＢ更新のジャーナルは、ＣＰＵａｌで取得されるため、当該ＤＢが障害になったときの回復処理では、ＣＰＵａ１のジャーナルのみを用いて回復が実行できる。
【００１８】
【発明の効果】
本発明によれば、ＣＰＵ間でＤＢ共用しても、ＤＢ検索性能は、非共用ＤＢへのアクセスと同等の性能を実現できる。
【００１９】
また、ＤＢ障害回復時、複数ＣＰＵのジャーナルをマージせずに簡易に回復運用を実施できる。
【図面の簡単な説明】
【図１】本発明の一実施例の構成図である。
【図２】本発明の一実施例の処理のフローチャートである。
【図３】本発明の一実施例の処理のフローチャートである。
【図４】本発明の一実施例の処理のフローチャートである。
【図５】本発明の一実施例の処理のフローチャートである。
【図６】本発明の一実施例の管理テーブルを示す図である。
【符号の説明】
１，２…ＣＰＵ、３…共用ＤＢ、１１，２１…ＤＢアクセス部、１２，２２…ユーザプログラム、１３，２３…ＤＢ分散機能部
【図１】
0003674598.tif 000002
【図２】
0003674598.tif 000003
【図３】
0003674598.tif 000004
【図４】
0003674598.tif 000005
【図５】
0003674598.tif 000006
【図６】
0003674598.tif 000007