JP3674598B2 - データベース管理方法およびシステム - Google Patents
データベース管理方法およびシステム Download PDFInfo
- Publication number
- JP3674598B2 JP3674598B2 JP2002118771A JP2002118771A JP3674598B2 JP 3674598 B2 JP3674598 B2 JP 3674598B2 JP 2002118771 A JP2002118771 A JP 2002118771A JP 2002118771 A JP2002118771 A JP 2002118771A JP 3674598 B2 JP3674598 B2 JP 3674598B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- management unit
- management
- update
- database
- 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 - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
データベースを複数のデータベース管理部で共有する場合のデータベース管理技術である。
【０００２】
【従来の技術】
システム間でＤＢを共用する方式として、例えば特開昭６２−２０４３６０号公報に記載のように、共用ＤＢの排他制御のため、ＤＢ管理元をきめ、このロックマネジャと他システムとの間で排他情報をやりとりして排他の一元管理を行なう方法が知られている。
【０００３】
また、この方式では、ＤＢ障害時の回復情報であるジャーナルは、各システムで取得されておりＤＢ障害回復時、ジャーナルマージが必要であった。
【０００４】
【発明が解決しようとする課題】
従来のシステム間ＤＢ共用方式では、性能面、運用面で、下記の問題があった。（１）システム間共用ＤＢに対して、データ検索だけを行う場合でも、当該ＤＢに対する更新処理との排他制御を行うために、ＤＢ管理元システムに排他使用連絡を行う必要が有り、システム間でＤＢ共用しない場合に比べて、データ検索のオ一バヘッドが大きくなるため、大量のデータ検索には適していない。
（２）システム間共用ＤＢに対して、複数ＣＰＵからデータ更新を行う場合、ＤＢ更新ジャーナルは、ＤＢ更新要求元システムで取得されるため、ＤＢ障害回復時、複数システムのジャーナルをマージする必要が有る。
本発明の目的は、以上の問題を解決するシステム間データベース共用方式を提供することにある。
【０００５】
【課題を解決するための手段】
上記目的を達成するために、ＣＰＵ間のＤＢ共用方式として、
（１）データ検索オ一バヘッドの削減
ＣＰＵ間共用ＤＢに対して、データ検索しか行わない処理（トランザクション）については、アクセス対象のデータに対して、排他制御を行わず、データ検索要求元ＣＰＵから直接データアクセスを行う。
【０００６】
これにより、データ検索については、ＣＰＵ間で共用しないＤＢへのアクセスと同等の性能を実現できる。
【０００７】
データ検索時、他ＣＰＵからのデータ更新処理とのタイミングにより、検索データブロックの制御情報に矛盾を検知した場合は、次のいずれかの方法で処理する。（ａ）一定時間間隔で一定回数、データ検索を再指向し、タイミングによる同期ズレを救済する。（ｂ）当該データベース管理元ＣＰＵに検索要求を転送し、矛盾のない状態での検索をデータベース管理元ＣＰＵで実行する。
【０００８】
（２）ＤＢ障害回復用ジャーナルの一元化
ＤＢ障害回復には、ＤＢのバックアップ情報と、バックアップ取得時点以降のＤＢ更新ジャーナル情報が必要である。ＤＢ更新ジャーナルを１つのＣＰＵの下で一元化して取得するため、ＤＢ更新処理については、すべてＤＢ管理元ＣＰＵで実施する。即ち、ＤＢ管理元以外のＣＰＵから、ＣＰＵ間共用ＤＢを更新するときは、ＤＢ管理元ＣＰＵへＤＢ更新要求を送り、ＤＢ管理元ＣＰＵでＤＢ更新する方式とする。
【作用】
本発明のＣＰＵ間ＤＢ共用方式では、ＤＢ検索だけの処理（トランザクション）については、ＤＢ検索要求元ＣＰＵから、他ＣＰＵとの連絡なしに直接ＤＢアクセスができるので、非共用ＤＢへのアクセスと同等の検索性能が実現できる。
【０００９】
また、ＤＢ更新は、ＤＢ管理元ＣＰＵで一元化して行うので、複数のＣＰＵから同一ＤＢに対して更新要求があっても、同一ＤＢの更新ジャーナルは、当該ＤＢの管理元ＣＰＵで一元化して取得され、ＤＢ障害回復時のジャーナルマージが不要となり、ＤＢ障害などに関するＤＢシステム運用管理者の負担の大幅軽減が実現できる。
【００１０】
【発明の実施の形態】
以下、本発明の一実施例を図面により詳細に説明する。
第１図は、本発明の構成を示すブロック図である。
ＣＰＵａ１が共用ＤＢ３の管理元であるとき、ＣＰＵｂ２のユーザプログラム２２からのＤＢアクセス要求があった場合、検索については、ＣＰＵｂ２のＤＢアクセス部２１が直接ＤＢアクセスを行い、更新については、ＣＰＵｂ２のＤＢアクセス部２１からＣＰＵｂ２のＤＢ分散機能部２３、ＣＰＵａ１のＤＢ分散機能部１３を経由して、ＣＰＵａ１のＤＢアクセス部１１がＤＢアクセスを行う。
【００１１】
ＣＰＵａ１のユーザプログラム１２からのＤＢアクセス要求があると、検索、更新にかかわらず、ＣＰＵａ１のＤＢアクセス部１１がＤＢアクセスを行う。
【００１２】
アクセス対象のＤＢがＣＰＵａ１の管理するＤＢかＣＰＵｂ２の管理するＤＢかは、第６図に示すテーブルで管理し、それぞれのＤＢアクセス部で管理元を判別する。
【００１３】
以下、ＤＢ検索、更新の具体的な処理手順を説明する。
（１）ＤＢ検索の場合（第２図参照）
ＣＰＵｂ２のユーザプログラム２２から、ＣＰＵａ１の管理する共用ＤＢ３への検索要求が発行されると（２０１）、ＣＰＵｂ２のＤＢアクセス部２１で、当該ＤＢ３を直接アクセスする。ただし、ＣＰＵａ１側との排他制御を行わずにアクセスするので、ＣＰＵａ１側の更新処理とのタイミシグによっては、ＤＢのインデックス部とＤＢのデータ部の内容に不一致があるように見える場合がある。そこで、この微妙なタイミングを排他制御なしに対処するために、ＤＢのインデックス部とデータ部の内容に不一致がある場合（２０２）には、所定の時間間隔で所定回数、ＤＢインデックス、ＤＢデータのリードを再試行し（２０３）、タイミングズレによる不一致がなくなるのを待つ。
所定回数内でも矛盾がなくならない場合、恒久的データ破壊が起きていると判断し、リードエラ一として処理する（２０４）。
（２）ＤＢ更新の場合（第３図〜第５図参照）
ＣＰＵｂ２のユーザプログラム２２から、ＣＰＵａ１の管理する共用ＤＢ３を更新する場合について、３つの段階に分けて説明する。（ａ）更新のための検索要求
第３図に、ＣＰＵｂ２で共用ＤＢ３更新のための検索要求が発行された場合を示す。
【００１４】
ＣＰＵｂ２のＤＢアクセス部２１では、第６図のＤＢ所在管理テーブルを用いて、要求のあったＤＢが自ＣＰＵ管理のＤＢか否か判別し（３０１）、ＣＰＵａ１の管理するＤＢへの要求ならば、ＤＢ分散機能部２３を通じて、ＣＰＵａ１へＤＢアクセス要求を送信する（３０２）。ＣＰＵａ１では、ＣＰＵｂ２から送信され、ＤＢ分散機能部１３で受信した（３０３）ＤＢアクセス要求にもとづき、ＤＢ排他使用を宣言し（３０４）、ＤＢアクセスを行ない、ＤＢインデックス部、ＤＢデータ部を読み込む（３０５，３０６）。読み込んだ結果はＤＢ分散機能部１３を通じてＣＰＵｂ２ヘ送信する（３０７）。
【００１５】
ＣＰＵｂ２の管理するＤＢの場合は、ＣＰＵｂ２のアクセス部でＤＢアクセスを行なう（３０８〜３１０）。
【００１６】
（ｂ）更新要求
第４図に、ＣＰＵｂ２から共用ＤＢ３に対する更新要求が発行された場合を示す。
【００１７】
（ａ）の場合と同様、ＣＰＵｂ２のユーザプログラム２２から更新要求があると（４０１）、ＤＢアクセス部２１では、自ＣＰＵ管理のＤＢかを判断する（４０２）。自ＣＰＵ管理でない場合ＤＢ分散機能部を通じてＤＢ管理元ＣＰＵ、この場合ＣＰＵａ１ヘ、ＤＢアクセス要求を送信する（４０３）。ＣＰＵａ１では、ＤＢ分散機能部１３で更新要求を受信すると（４０４）、ＤＢアクセス部で同期点に達するまでＤＢ更新要求を退避し（４０５）、更新要求処理報告をＤＢ機能分散部を通じてＣＰＵｂ２に送信する（４０６）。（ｃ）コミット（ＣＯＭＭｌＴ）あるいはリ夕一ン
第５図に、ＣＰＵｂ２のユーザプログラム２２がコミットを発行したか、あるいは、リターンをして処理の同期点に達した場合を示す。
コミット要求の場合を説明する。（ａ）の場合と同様、ＣＰＵｂ２からＣＰＵａ１ヘ、ＤＢ分散機能部２３を通じて、まずコミット準備要求が送信される（５０２）。ＣＰＵａ１ではＤＢアクセス部でＤＢ更新要求と、ＤＢジャーナル取りだし（５０４，５０５）コミット準備完了報告をＣＰＵｂ２に送信する（５０６）。ＣＰＵｂ２のＤＢアクセス部は、コミット準備完了報告を受信すると、コミット要求を送信する（５０８）（２フェーズコミット）。コミット要求を受けるとＣＰＵａ１は、ＤＢアクセス部で共用ＤＢの実更新を行い（５０９〉、ＤＢ排他使用の宣言を解除して（５１０）、コミット完了報告をＣＰＵｂ２に行う（５１１）。この時、ＤＢ更新のジャーナルは、ＣＰＵａｌで取得されるため、当該ＤＢが障害になったときの回復処理では、ＣＰＵａ１のジャーナルのみを用いて回復が実行できる。
【００１８】
【発明の効果】
本発明によれば、ＣＰＵ間でＤＢ共用しても、ＤＢ検索性能は、非共用ＤＢへのアクセスと同等の性能を実現できる。
【００１９】
また、ＤＢ障害回復時、複数ＣＰＵのジャーナルをマージせずに簡易に回復運用を実施できる。
【図面の簡単な説明】
【図１】本発明の一実施例の構成図である。
【図２】本発明の一実施例の処理のフローチャートである。
【図３】本発明の一実施例の処理のフローチャートである。
【図４】本発明の一実施例の処理のフローチャートである。
【図５】本発明の一実施例の処理のフローチャートである。
【図６】本発明の一実施例の管理テーブルを示す図である。
【符号の説明】
１，２…ＣＰＵ、３…共用ＤＢ、１１，２１…ＤＢアクセス部、１２，２２…ユーザプログラム、１３，２３…ＤＢ分散機能部
【発明の属する技術分野】
データベースを複数のデータベース管理部で共有する場合のデータベース管理技術である。
【０００２】
【従来の技術】
システム間でＤＢを共用する方式として、例えば特開昭６２−２０４３６０号公報に記載のように、共用ＤＢの排他制御のため、ＤＢ管理元をきめ、このロックマネジャと他システムとの間で排他情報をやりとりして排他の一元管理を行なう方法が知られている。
【０００３】
また、この方式では、ＤＢ障害時の回復情報であるジャーナルは、各システムで取得されておりＤＢ障害回復時、ジャーナルマージが必要であった。
【０００４】
【発明が解決しようとする課題】
従来のシステム間ＤＢ共用方式では、性能面、運用面で、下記の問題があった。（１）システム間共用ＤＢに対して、データ検索だけを行う場合でも、当該ＤＢに対する更新処理との排他制御を行うために、ＤＢ管理元システムに排他使用連絡を行う必要が有り、システム間でＤＢ共用しない場合に比べて、データ検索のオ一バヘッドが大きくなるため、大量のデータ検索には適していない。
（２）システム間共用ＤＢに対して、複数ＣＰＵからデータ更新を行う場合、ＤＢ更新ジャーナルは、ＤＢ更新要求元システムで取得されるため、ＤＢ障害回復時、複数システムのジャーナルをマージする必要が有る。
本発明の目的は、以上の問題を解決するシステム間データベース共用方式を提供することにある。
【０００５】
【課題を解決するための手段】
上記目的を達成するために、ＣＰＵ間のＤＢ共用方式として、
（１）データ検索オ一バヘッドの削減
ＣＰＵ間共用ＤＢに対して、データ検索しか行わない処理（トランザクション）については、アクセス対象のデータに対して、排他制御を行わず、データ検索要求元ＣＰＵから直接データアクセスを行う。
【０００６】
これにより、データ検索については、ＣＰＵ間で共用しないＤＢへのアクセスと同等の性能を実現できる。
【０００７】
データ検索時、他ＣＰＵからのデータ更新処理とのタイミングにより、検索データブロックの制御情報に矛盾を検知した場合は、次のいずれかの方法で処理する。（ａ）一定時間間隔で一定回数、データ検索を再指向し、タイミングによる同期ズレを救済する。（ｂ）当該データベース管理元ＣＰＵに検索要求を転送し、矛盾のない状態での検索をデータベース管理元ＣＰＵで実行する。
【０００８】
（２）ＤＢ障害回復用ジャーナルの一元化
ＤＢ障害回復には、ＤＢのバックアップ情報と、バックアップ取得時点以降のＤＢ更新ジャーナル情報が必要である。ＤＢ更新ジャーナルを１つのＣＰＵの下で一元化して取得するため、ＤＢ更新処理については、すべてＤＢ管理元ＣＰＵで実施する。即ち、ＤＢ管理元以外のＣＰＵから、ＣＰＵ間共用ＤＢを更新するときは、ＤＢ管理元ＣＰＵへＤＢ更新要求を送り、ＤＢ管理元ＣＰＵでＤＢ更新する方式とする。
【作用】
本発明のＣＰＵ間ＤＢ共用方式では、ＤＢ検索だけの処理（トランザクション）については、ＤＢ検索要求元ＣＰＵから、他ＣＰＵとの連絡なしに直接ＤＢアクセスができるので、非共用ＤＢへのアクセスと同等の検索性能が実現できる。
【０００９】
また、ＤＢ更新は、ＤＢ管理元ＣＰＵで一元化して行うので、複数のＣＰＵから同一ＤＢに対して更新要求があっても、同一ＤＢの更新ジャーナルは、当該ＤＢの管理元ＣＰＵで一元化して取得され、ＤＢ障害回復時のジャーナルマージが不要となり、ＤＢ障害などに関するＤＢシステム運用管理者の負担の大幅軽減が実現できる。
【００１０】
【発明の実施の形態】
以下、本発明の一実施例を図面により詳細に説明する。
第１図は、本発明の構成を示すブロック図である。
ＣＰＵａ１が共用ＤＢ３の管理元であるとき、ＣＰＵｂ２のユーザプログラム２２からのＤＢアクセス要求があった場合、検索については、ＣＰＵｂ２のＤＢアクセス部２１が直接ＤＢアクセスを行い、更新については、ＣＰＵｂ２のＤＢアクセス部２１からＣＰＵｂ２のＤＢ分散機能部２３、ＣＰＵａ１のＤＢ分散機能部１３を経由して、ＣＰＵａ１のＤＢアクセス部１１がＤＢアクセスを行う。
【００１１】
ＣＰＵａ１のユーザプログラム１２からのＤＢアクセス要求があると、検索、更新にかかわらず、ＣＰＵａ１のＤＢアクセス部１１がＤＢアクセスを行う。
【００１２】
アクセス対象のＤＢがＣＰＵａ１の管理するＤＢかＣＰＵｂ２の管理するＤＢかは、第６図に示すテーブルで管理し、それぞれのＤＢアクセス部で管理元を判別する。
【００１３】
以下、ＤＢ検索、更新の具体的な処理手順を説明する。
（１）ＤＢ検索の場合（第２図参照）
ＣＰＵｂ２のユーザプログラム２２から、ＣＰＵａ１の管理する共用ＤＢ３への検索要求が発行されると（２０１）、ＣＰＵｂ２のＤＢアクセス部２１で、当該ＤＢ３を直接アクセスする。ただし、ＣＰＵａ１側との排他制御を行わずにアクセスするので、ＣＰＵａ１側の更新処理とのタイミシグによっては、ＤＢのインデックス部とＤＢのデータ部の内容に不一致があるように見える場合がある。そこで、この微妙なタイミングを排他制御なしに対処するために、ＤＢのインデックス部とデータ部の内容に不一致がある場合（２０２）には、所定の時間間隔で所定回数、ＤＢインデックス、ＤＢデータのリードを再試行し（２０３）、タイミングズレによる不一致がなくなるのを待つ。
所定回数内でも矛盾がなくならない場合、恒久的データ破壊が起きていると判断し、リードエラ一として処理する（２０４）。
（２）ＤＢ更新の場合（第３図〜第５図参照）
ＣＰＵｂ２のユーザプログラム２２から、ＣＰＵａ１の管理する共用ＤＢ３を更新する場合について、３つの段階に分けて説明する。（ａ）更新のための検索要求
第３図に、ＣＰＵｂ２で共用ＤＢ３更新のための検索要求が発行された場合を示す。
【００１４】
ＣＰＵｂ２のＤＢアクセス部２１では、第６図のＤＢ所在管理テーブルを用いて、要求のあったＤＢが自ＣＰＵ管理のＤＢか否か判別し（３０１）、ＣＰＵａ１の管理するＤＢへの要求ならば、ＤＢ分散機能部２３を通じて、ＣＰＵａ１へＤＢアクセス要求を送信する（３０２）。ＣＰＵａ１では、ＣＰＵｂ２から送信され、ＤＢ分散機能部１３で受信した（３０３）ＤＢアクセス要求にもとづき、ＤＢ排他使用を宣言し（３０４）、ＤＢアクセスを行ない、ＤＢインデックス部、ＤＢデータ部を読み込む（３０５，３０６）。読み込んだ結果はＤＢ分散機能部１３を通じてＣＰＵｂ２ヘ送信する（３０７）。
【００１５】
ＣＰＵｂ２の管理するＤＢの場合は、ＣＰＵｂ２のアクセス部でＤＢアクセスを行なう（３０８〜３１０）。
【００１６】
（ｂ）更新要求
第４図に、ＣＰＵｂ２から共用ＤＢ３に対する更新要求が発行された場合を示す。
【００１７】
（ａ）の場合と同様、ＣＰＵｂ２のユーザプログラム２２から更新要求があると（４０１）、ＤＢアクセス部２１では、自ＣＰＵ管理のＤＢかを判断する（４０２）。自ＣＰＵ管理でない場合ＤＢ分散機能部を通じてＤＢ管理元ＣＰＵ、この場合ＣＰＵａ１ヘ、ＤＢアクセス要求を送信する（４０３）。ＣＰＵａ１では、ＤＢ分散機能部１３で更新要求を受信すると（４０４）、ＤＢアクセス部で同期点に達するまでＤＢ更新要求を退避し（４０５）、更新要求処理報告をＤＢ機能分散部を通じてＣＰＵｂ２に送信する（４０６）。（ｃ）コミット（ＣＯＭＭｌＴ）あるいはリ夕一ン
第５図に、ＣＰＵｂ２のユーザプログラム２２がコミットを発行したか、あるいは、リターンをして処理の同期点に達した場合を示す。
コミット要求の場合を説明する。（ａ）の場合と同様、ＣＰＵｂ２からＣＰＵａ１ヘ、ＤＢ分散機能部２３を通じて、まずコミット準備要求が送信される（５０２）。ＣＰＵａ１ではＤＢアクセス部でＤＢ更新要求と、ＤＢジャーナル取りだし（５０４，５０５）コミット準備完了報告をＣＰＵｂ２に送信する（５０６）。ＣＰＵｂ２のＤＢアクセス部は、コミット準備完了報告を受信すると、コミット要求を送信する（５０８）（２フェーズコミット）。コミット要求を受けるとＣＰＵａ１は、ＤＢアクセス部で共用ＤＢの実更新を行い（５０９〉、ＤＢ排他使用の宣言を解除して（５１０）、コミット完了報告をＣＰＵｂ２に行う（５１１）。この時、ＤＢ更新のジャーナルは、ＣＰＵａｌで取得されるため、当該ＤＢが障害になったときの回復処理では、ＣＰＵａ１のジャーナルのみを用いて回復が実行できる。
【００１８】
【発明の効果】
本発明によれば、ＣＰＵ間でＤＢ共用しても、ＤＢ検索性能は、非共用ＤＢへのアクセスと同等の性能を実現できる。
【００１９】
また、ＤＢ障害回復時、複数ＣＰＵのジャーナルをマージせずに簡易に回復運用を実施できる。
【図面の簡単な説明】
【図１】本発明の一実施例の構成図である。
【図２】本発明の一実施例の処理のフローチャートである。
【図３】本発明の一実施例の処理のフローチャートである。
【図４】本発明の一実施例の処理のフローチャートである。
【図５】本発明の一実施例の処理のフローチャートである。
【図６】本発明の一実施例の管理テーブルを示す図である。
【符号の説明】
１，２…ＣＰＵ、３…共用ＤＢ、１１，２１…ＤＢアクセス部、１２，２２…ユーザプログラム、１３，２３…ＤＢ分散機能部
Claims (13)
- 第１のデータを管理する第１の管理部と第２のデータを管理する第２の管理部とが前記第１のデータと前記第２のデータとを共用するデータべース管理方法において、
前記第１の管理部から前記第２のデータを参照する場合は、前記第１の管理部が前記第２のデータを参照し、前記第１の管理部から前記第２のデータを更新する場合は、前記第１の管理部から第２の管理部へ前記第２のデータを更新する更新要求を送り、前記第２の管理部が前記第２のデータを更新することを特徴とするデータベース管理方法。 - 請求項１記載のデータベース管理方法において、前記第２の管理部から前記第２のデータを参照する場合は、前記第２の管理部が前記第２のデータを参照し、前記第２の管理部から前記第２のデータを更新する場合は、前記第２の管理部が前記第２のデータを更新することを特徴とするデータベース管理方法。
- 請求項１記載のデータベース管理方法において、前記第１の管理部から前記第１のデータを参照する場合は、前記第１の管理部が前記第１のデータを参照し、前記第１の管理部から前記第１のデータを更新する場合は、前記第１の管理部が前記第１のデータを更新することを特徴とするデータベース管理方法。
- 請求項３記載のデータベース管理方法において、前記第１の管理部は、前記第１のデータの更新ジャーナルを生成し、前記第２の管理部は、前記第２のデータの更新ジャーナルを生成することを特徴とするデータベース管理方法。
- 請求項４記載のデータベース管理方法において、前記第１のデータの障害を検出した場合は前記第１の管理部で生成した更新ジャーナルを、前記第２のデータの障害を検出した場合は前記第２の管理部で生成した更新ジャーナルを参照して回復処理を行うことを特徴とするデータベース管理方法。
- 第１のプロセッサと、データ領域を管理する第２のプロセッサとの間で前記データ領域を共用するデータベース管理方法において、データ参照要求を受けた第１のプロセッサは、前記データ領域を参照し、データ更新要求を受けた第１のプロセッサは、前記データ更新要求を前記第２のプロセッサへデータ更新要求を転送し、当該更新要求を受け取った前記第2のプロセッサが前記データ領域のデータを更新することを特徴とするデータベース管理方法。
- 第１のデータを管理する第１の管理手段と第２のデータを管理する第２の管理手段とが前記第１のデータと前記第２のデータとを共用するデータベース管理システムにおいて、前記第１の管理手段は、入力した更新要求に従い前記第１のデータを更新する第１のデータ更新手段と、前記第２のデータの更新要求を前記第２の管理手段へ送る第１のデータ更新要求手段と、入力した参照要求に従い前記第１のデータ及び前記第２のデータを参照する第１のデータ参照手段とを備え、前記第２の管理手段は、入力した更新要求に従い前記第２のデータを更新する第２のデータ更新手段と、前記第１のデータの更新要求を前記第１の管理手段へ送る第２のデータ更新要求手段と、入力した参照要求に従い前記第１のデータ及び前記第２のデータを参照する第２のデータ参照手段とを備えたことを特徴とするデータベース管理システム。
- 第１のデータを管理する第１の管理部と第２のデータを管理する第２の管理部とが前記第１のデータと前記第２のデータとを共用するデータベース管理システムにおいて、前記第１の管理部から前記第２のデータを参照する場合は、前記第１の管理部が前記第２のデータを参照し、前記第１の管理部から前記第２のデータを更新する場合は、前記第１の管理部から第２の管理部へ前記第２のデータを更新する更新要求を送り、前記第２の管理部が前記第２のデータを更新することを特徴とするデータベース管理システム。
- 請求項８記載のデータベース管理システムにおいて、前記第２の管理部は、前記第２の管理部から前記第２のデータを参照する場合、前記第２のデータを参照し、前記第２の管理部から前記第２のデータを更新する場合、前記第２のデータを更新することを特徴とするデータベース管理システム。
- 請求項８記載のデータベース管理システムにおいて、前記第１の管理部は、前記第１のデータを参照する場合、前記第１のデータを参照し、前記第１の管理部から前記第１のデータを更新する場合、前記第１のデータを更新することを特徴とするデータベース管理システム。
- 請求項１０記載のデータベース管理システムにおいて、前記第１の管理部は、前記第１のデータの更新ジャーナルを生成し、前記第２の管理部は、前記第２のデータの更新ジャーナルを生成する手段を備えたことを特徴とするデータベース管理システム。
- 請求項１１記載のデータベース管理システムにおいて、前記第１のデータの障害を検出した場合は前記第１の管理部で生成した更新ジャーナルを、前記第２のデータの障害を検出した場合は前記第２の管理部で生成した更新ジャーナルを参照して回復処理を行う手段を備えたことを特徴とするデータベース管理システム。
- 第１のプロセッサと、データ領域を管理する第２のプロセッサとの間で前記データ領域を共用するデータベース管理装置において、データ参照要求を受けた第１のプロセッサは、前記データ領域を参照し、データ更新要求を受けた第１のプロセッサは、前記データ更新要求を前記第２のプロセッサへデータ更新要求を転送し、当該更新要求を受け取った前記第２のプロセッサが前記データ領域のデータを更新することを特徴とするデータベース管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002118771A JP3674598B2 (ja) | 2002-04-22 | 2002-04-22 | データベース管理方法およびシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002118771A JP3674598B2 (ja) | 2002-04-22 | 2002-04-22 | データベース管理方法およびシステム |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20861799A Division JP3478187B2 (ja) | 1999-07-23 | 1999-07-23 | データベース管理方法及びシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003044341A JP2003044341A (ja) | 2003-02-14 |
| JP3674598B2 true JP3674598B2 (ja) | 2005-07-20 |
Family
ID=19194069
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002118771A Expired - Lifetime JP3674598B2 (ja) | 2002-04-22 | 2002-04-22 | データベース管理方法およびシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3674598B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006268134A (ja) * | 2005-03-22 | 2006-10-05 | Dainippon Printing Co Ltd | データベースシステム、サーバ、プログラム、及び、記録媒体 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS58115567A (ja) * | 1981-12-29 | 1983-07-09 | Fujitsu Ltd | デイスクボリユ−ム互換方式 |
| JP3478187B2 (ja) * | 1999-07-23 | 2003-12-15 | 株式会社日立製作所 | データベース管理方法及びシステム |
-
2002
- 2002-04-22 JP JP2002118771A patent/JP3674598B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003044341A (ja) | 2003-02-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3222125B2 (ja) | システム間データベース共用方式 | |
| US9779128B2 (en) | System and method for massively parallel processing database | |
| US10747745B2 (en) | Transaction execution commitment without updating of data row transaction status | |
| US10116766B2 (en) | Asynchronous and idempotent distributed lock interfaces | |
| JP3504763B2 (ja) | 分散システムに使用されるクライアント，サーバ及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法 | |
| US5065311A (en) | Distributed data base system of composite subsystem type, and method fault recovery for the system | |
| CN100449548C (zh) | 数据库同步方法及系统 | |
| EP0567999B1 (en) | Method and apparatus for executing a distributed transaction in a distributed database | |
| CN111506592B (zh) | 一种数据库的升级方法和装置 | |
| JP6028850B2 (ja) | データ多重化システム | |
| KR100450400B1 (ko) | 안전 기억 장치가 없는 환경을 위한 이중화 구조의 주 메모리 상주 데이터베이스 관리시스템 및 그 데이터 일치성 제어방법 | |
| JP2006012153A (ja) | 同時トランザクション（ｃｏｎｃｕｒｒｅｎｔｔｒａｎｓａｃｔｉｏｎｓ）とページ同期（ｐａｇｅｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ） | |
| US10191959B1 (en) | Versioned read-only snapshots of shared state in distributed computing environments | |
| US6212595B1 (en) | Computer program product for fencing a member of a group of processes in a distributed processing environment | |
| CN110297822B (zh) | 面向区块链的密钥管理方法、装置、设备及存储介质 | |
| Matri et al. | Týr: blob storage meets built-in transactions | |
| JP3674598B2 (ja) | データベース管理方法およびシステム | |
| Liu et al. | Dax: a widely distributed multitenant storage service for dbms hosting | |
| JP3478187B2 (ja) | データベース管理方法及びシステム | |
| Sciascia et al. | RAM-DUR: In-memory deferred update replication | |
| US10754710B1 (en) | Transactional watch mechanism | |
| JPH07114495A (ja) | 多重化ファイル管理方式 | |
| US6205510B1 (en) | Method for fencing a member of a group of processes in a distributed processing environment | |
| JP2581141B2 (ja) | ディレイド・ジャーナル・マージ方式 | |
| JP4286857B2 (ja) | ノード間共用ファイル制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040907 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041105 |
|
| 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: 20050405 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050418 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080513 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090513 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100513 Year of fee payment: 5 |
|
| EXPY | Cancellation because of completion of term | ||
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100513 Year of fee payment: 5 |