JP2609625B2 - 複合サブシステム型分散データベースシステムの障害回復方法 - Google Patents

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、分散型データベースの制御方式に係り、特
に複数のデータベースと相互乗入れする場合に好適な複
合サブシステム型分散データベース制御方式に関する。

〔従来の技術〕

従来、分散データベースの回復，制御方式について
は、情報処理学会第33回（昭和61年後期）全国大会予稿
集第907頁から第908頁に述べられているように、各分散
サイトのダウンは他のサイトのダウンとせず、スレーブ
サイトのダウンはマスタサイトが検出し切離し、マスタ
サイトのダウンは、検出したスレーブサイトが他のスレ
ーブサイトへマスタサイトの異常を送信する。ここで、
リスタート時のことを考えて、データベースの更新処理
には、ジェフリー デー ウールマン著のプリンシプル
オブ データベースシステム コンピュータサイエン
スプレスの第340頁から第356頁（Jeffrey D.Ullman,“P
rinciples of Data Base"Computer Science Press PP34
0−356）において論じられている２フェーズプロトコル
を用いている。これにより、他サイトのデータベースと
同期して更新処理を行っている時に、分散サイトがダウ
ンしてもデータの矛盾がない様に回復する。

しかし、分散サイトのサイト内の分散データベースア
クセス部のダウンをローカルデータベースのダウンと分
離していないので１サイトのダウンは、分散アクセスも
ローカルアクセスもダウンとなっていた。

〔発明が解決しようとする問題点〕

上記従来技術は、分散サイト内の分散データベースア
クセス部とサイト内のローカルデータベースアクセス部
を分離して考えておらず、サイトのダウンは、常に分散
データベースアクセスのダウンとローカルデータベース
アクセスダウンとなっており、信頼性の面で問題があっ
た。

本発明の目的は、分散データベースのアクセスコント
ロールを、複合サブシステムのサブシステムとして構築
することにより、分散データベースアクセス部のダウン
時にもローカルデータベースのアクセスは継続できる様
にした複合サブシステム型分散データベース制御方式を
提供することにある。

〔問題点を解決するための手段〕

上記目的は、分散データベースをローカルデータベー
スと分離し、分散データベースの他サイトからの要求に
従い自サイトにトランザクションを発生させる部分を複
合サブシステム上のデータコミュニケーション型サブシ
ステムとし、トランザクションから発生する分散データ
ベース要求を受け付ける部分をデータベース型サブシス
テムと見なし、複合サブシステム型オンラインシステム
として構築することで、ローカルデータベースのダウン
も分散データベースアクセスダウンも単なるサブシステ
ムダウンとして扱うことで達成される。

〔作用〕

分散データベースアクセス部をサブシステムとするこ
とで、ローカルデータベースと別々のサブシステムとな
る。複合サブシステム型オンラインシステムでは、サブ
システムごとのリラン情報が分離できる様になってお
り、ある１つのサブシステムのダウン時に他サブシステ
ムを同時にダウンさせる必要のない構造になっており、
分散データアクセスサブシステムがダウンしても、複合
サブシステムのコントローラは、分散データベースアク
セスを必要とするトランザクションだけを閉塞し、その
他のローカルデータベースアクセスだけで完了できるト
ランザクションの処理を進めて行うので、分散データベ
ースアクセスダウンをローカルデータベースアクセスか
ら切離すことができ、共倒れとならないようにすること
ができる。

〔実施例〕

以下、本発明の一実施例を図面により詳細に説明す
る。

第１図は、本発明を実現する複合サブシステム型オン
ラインシステムの全体構成図を示す。

第１図において、複合サブシステム型オンラインシス
テムは、複数のサブシステムを制御する複合サブシステ
ムコントローラ１（以下コントローラと呼ぶ）と、その
配下にある２種類のサブシステム（フロントエンド型サ
ブシステム２及びバックエンド型サブシステム３）と、
各サブシステムごと及びコントローラ用のリカバリファ
イル４（以下RFと呼ぶ）と、全サブシステムのジャーナ
ルを格納するジャーナルファイル５（以下、JNLFと呼
ぶ）と、全サブシステムの資源状態を管理する資源管理
テーブル６と、トランザクションを管理するトランザク
ション管理テーブル７と、システムの状態を管理するシ
ステムステータステーブル８と、システムステータステ
ーブル８の外部記憶装置上の複写として存在するシステ
ムステータスファイル９（以下、SYSSFと呼ぶ）から成
る。

フロントエンド形サブシステム（以下FEと呼ぶ）は、
オンライン端末10を有し、業務処理の単位であるトラン
ザクションを発生させる。バックエンド型サブシステム
３（以下、BEと呼ぶ）は、データベース11を有し、FE2
の発生させたトランザクションによる要求に従ってデー
タベース11をアクセスする。

分散データベースシステムは、他プロセッサからのデ
ータベースアクセス要求を受け自プロセッサ内にトラン
ザクションを発生させて行うFE2の役割（以下分散サー
バと呼ぶ）と、トランザクションからの他プロセッサの
データベースアクセス要求を受付けるBE3の役割（以下
分散クライアントと呼ぶ）を合わせて持つサブシステム
として位置づけられる。従って、複合サブシステム型オ
ンラインシステムの一部に分散データベースを考えるこ
ともできる。

第２図に、リカバリファイル４の構成を示す。RF4
は、サブシステム毎とコントローラ１用が存在しサブシ
ステム又はシステム全体が障害になった際の回復用情報
を格納する外部記憶の総称であり、チェックポイントダ
ンプを格納するチェックポイントファイル410と、テー
ブル回復に使用するテーブルリカバリファイル420と、
トランザクション単位のジャーナルを退避するためのト
ランザクションリカバリファイル430から成る。以下、
チェックポイントファイルをCKPTFと呼び、テーブルリ
カバリファイルをTBLRFと呼び、トランザクションリカ
バリファイルをTRRFと呼ぶ。

第３図に資源管理テーブル６の構成を示す。資源管理
テーブル６は、各FE2ごとにキューイングされたトラン
ザクショノード610と、各BE3ごとにキューイングされた
資源ノード620と、トランザクションと資源の排他保持
または待ち状態を示す資源排他ノード630から成る。

トランザクションノード610は、トランザクションID
を格納してあるトランザクションID部611と次のトラン
ザクションノードへのリンク612と資源排他ノードへの
リンク613から成る。資源ノード620は、資源名の格納し
てある資源名部621と、資源排他ノードへのリンク622と
次の資源ノードへのリンク623から成る。資源排他ノー
ド630は、資源名部631と同一資源に対して待ちをなして
いる次の資源排他ノードへのリンク632と同一トランザ
クションが保持又は、待っている次の資源に対する資源
排他ノードへのリンク633とトランザクションID部634
と、該資源排他ノード情報がジャーナルとして取得され
ているか否かを示すフラグ635と、該資源排他ノード情
報は、資源を保持しているのか待っているのかを示すフ
ラグ636から成る。

あるトランザクションTR1が言RS1を保持している場
合、TR1とRS1に対応するトランザクションノード610と
資源ノード620からリンク613とリンク622にて結合され
る資源排他ノード630が存在し、排他保持か待ちかを示
すフラグ636がオンになる。さらに、該資源RS1を待つト
ランザクションTR2が存在する場合、TR1とRS1とリンク
されている資源排他ノードから次の資源排他ノードへの
リンク632が作成され、TR2との間にもリンク613が作成
される。TR2からリンクされる資源排他ノードでは、排
他保持か待ちを示すフラグ636がオフとなる。該資源管
理テーブル６を用いると、リンク632,633をたどること
により、特定のトランザクションの保持する資源一覧、
又は特定の資源を保持しているトランザクション名が得
られる。各排他ノード中には、ジャーナル上に排他ノー
ド情報が退避されたか否かを示すフラグ635を持つ。

資源管理テーブル６が、サブシステムを通してコント
ローラ１上に一本化されているので、サブシステムダウ
ン時は、排他情報が保持できるだけでなく、サブシステ
ムをまたがったデッドロックの検出が容易となる。

第４図にトランザクション管理テーブル７の構成を示
す。トランザクション管理テーブルには、各FE2がある
時点で発生している全トランザクションが登録される。

該テーブルには、トランザクションID701（該テーブ
ルのエントリ番号7011と同一エントリを使用するたびに
カウントアップする通番7012から成る）と、発生FE領域
702と、使用BE領域703と、トランザクションステータス
領域710と、トランザクションの回復に必要となるジャ
ーナルへのジャーナルポインタ720と、ジャーナルを格
納するTRRF430の最終ポインタ730と、資源管理テーブル
の排他ノード630へのポインタ740から成るエントリがト
ランザクション単位に存在する。トランザクションステ
ータス領域710には、チェックポイントダンプ取得時の
同期用ビットすなわち影響ビット711と実行監視ビット7
12及びトランザクションの凍結制御用のトランザクショ
ン凍結要フラグ713とロールバック回復を行う必要があ
ることを示すロールバック要フラグ714とトランザクシ
ョンが同期点を通過したか否かを示す同期点フラウグ71
5とトランザクションが凍結中であることを示す凍結フ
ラグ716とトランザクションが同期点準備を通過しかつ
同期点通過前であることを示す同期点準備通過フラグ71
7とからなる。

第５図にシステムステータステーブル８の構成を示
す。システムステータステーブルには、コントローラ１
の状態810と各サブシステムの状態820と、システムのチ
ェックポイント時点のジャーナル通番記録領域815から
成る。

該システムステータステーブルは更新の都度SYSSFへ
対応エントリを書き出しておき、SYSSFに複写を作って
おく。

本実施例で示す複合サブシステム形オンラインシステ
ムでは、障害発生時の回復のために、種々の情報を外部
記憶装置に出力しながら業務処理を進めて行く。回復す
べき資源（データ，情報の総称）は、大きく分けて、次
の２種類がある。

仮想記憶装置上のテーブルの様に、障害発生時には
消失してしまうタイプの揮発性資源 外部記憶装置上のデータベースの様に、障害発生時
にも、一般には障害発生時点の状態を保持したままとな
るタイプの不揮発性資源 障害発生時点で消失する揮発性資源を回復するために
は、定期的に該資源の複写を不揮発性の外部記憶装置に
作成しておく（該複写をチェックポイントダンプと呼
ぶ）。チェックポイントダンプ取得以降変更の都度変更
の差分情報をジャーナルとして取得しておき、チェック
ポイントダンプに該ジャーナル情報を重畳することで回
復が行える。このタイプのジャーナルを履歴型ジャーナ
ルと呼ぶ。

障害発生時点の状態が保持される不揮発性資源を回復
するには、変更の都度ジャーナルを取得する。回復時に
は、業務処理単位であるトランザクション毎に更新を完
結させるか、更新を無効にするかを判断し、変更都度取
得したジャーナルの変更後情報を重畳するか、変更前情
報を重畳するかで回復を行う。このタイプのジャーナル
をトランザクショ型ジャーナルと呼ぶ。

本実施例のシステムでは、障害回復に備えて、データ
ベース更新，テーブル更新に先立ってジャーナル出力を
行う。ジャーナル出力は、コントローラ配下の機能を用
いて、各サブシステムを統合して一つのJNLF5に行う。J
NLF5を統合することは、複合サブシステムを運転する際
の操作性向上に大きく寄与する。ジャーナル取得の方式
を以下に説明する。

ジャーナルは、データベース更新、テーブル更新前に
必ず取得する。これはジャーナル取得前に変更を行う
と、変更後、ジャーナル取得前に障害が発生した場合に
回復できなくなるからである。

トランザクションの終了に際して、該トランザクショ
ンの全ジャーナルを出力した後に、全ジャーナルが出力
済すなわち同期点を示すジャーナル（以下同期点ジャー
ナルと呼ぶ）を出力する。

該同期点ジャーナルがジャーナルとして存在するトラ
ンザクションでは、不揮発性資源の回復に必要となるす
べてのトランザクション型ジャーナルが存在するため、
該トランザクションの処理を完結させる方向の回復が行
える。それに対し、同期点ジャーナルが存在しないトラ
ンザクションでは、全ジャーナルが出力されている保証
はないが、変更前には必ずジャーナルを出力しているた
め、存在するジャーナルの変更前情報を用いて、該トラ
ンザクションを無効とする方向の回復が行える。

トランザクションが完結した後に、トランザクション
終了を示すジャーナルを取得する。該終了を示すジャー
ナルを終了ジャーナルと呼ぶ。該ジャーナルが出力され
た後は、トランザクション型ジャーナルによる回復は不
要となる。

分散データベースの場合には、一つのトランザクショ
ンが自システム内のデータベースと他プロセッサ内のデ
ータベースを更新するため、プロセッサ間にまたがって
データベース更新の同期が必要となる。分散データベー
スの場合のジャーナル取得の方式を以下に説明する。

トランザクションの終了に際して、まず分散クライア
ント側の全ジャーナルが出力される。この時点で分散ク
ライアント側から分散サーバ側に全ジャーナルの出力指
示（以下、これを同期点準備指示と呼ぶ）を行う。分散
サーバ側では該指示を受け全ジャーナルの出力後に同期
点準備が完了したことを示すジャーナル（以下、これを
同期点準備ジャーナルと呼ぶ）を出力する。該ジャーナ
ルの出力完了後、分散サーバは分散クライアントに同期
点準備の完了を報告する。分散クライアント側では該ト
ランザクションの自システム内の全ジャーナルの出力、
及び要求を出した全ての他プロセッサの分散サーバから
同期点準備完了報告を受けた後、同期点ジャーナルを出
力する。同期点ジャーナルの出力が完了した後、分散ク
ライアントは自システム内のデータベースの更新を行
い、分散サーバに対し該トランザクションが同期点に達
した旨の指示（以下、これを同期点指示と呼ぶ）を行
う。分散サーバは、同期点指示を受けると、まず同期点
ジャーナルを出力した後、バッファ上に残る該トランザ
クションのデータベース更新を完了する。その後終了ジ
ャーナルを出力し、出力が完了後、分散クライアントに
トランザクション完了を報告する。分散クライアント側
では、自システム内のデータベースの更新、及び指示を
出した全ての分散サーバから完了報告を受けた後、終了
ジャーナルを出力する。

分散クライアント側では、同期点ジャーナルが存在す
れば、該トランザクションを有効とする方向の回復を行
い、なければ無効とする方向の回復を行うことができ
る。分散サーバ側では、同期点準備ジャーナルと同期点
ジャーナルが存在すれば、該トランザクションを有効と
する方向の回復を行い、同期点ジャーナル及び同期点準
備ジャーナルのいずれも存在しない場合には、該トラン
ザクションを無効とする方向の回復を行う。同期点準備
ジャーナルだけが存在する場合には、分散クライアント
側の同期点ジャーナルの有無を調べ、それに従えば回復
を行うことができる。

なお、該プロセッサ内で独自のジャーナルファイルを
持ちジャーナルを取得する従来形オンラインシステムを
複合サブシステム型オンラインシステムに接続し、該オ
ンラインシステム下で実行するトランザクションから、
複合サブシステム型オンラインBEのデータベースを更新
する場合、該オンラインシステムを分散サーバと同様の
一つのFEとして扱い、前述のジャーナル取得方式を用い
ることにより該オンラインシステム内のデータベース更
新と複合サブシステム型オンラインシステムのBEのデー
タベース更新の同期をとった回復ができる。

本実施例では、回復すべきテーブルを定期的にチェッ
クポイントダンプとしてサブシステム毎に取得し、同時
点にてトランザクション型ジャーナルをTRRFに退避す
る。各情報取得の方式を以下に説明する。

第６図，第７図，第８図にチェックポイントダンプ取
得の概念と取得処理の流れを示す。

第６図に示すように、各サブシステム2,3は、定期的
に仮想記憶装置上のチェックポイント対象テーブル411
の内容をCKPTF410へ格納する。チェックポイントダンプ
格納中にCKPTF410に障害が発生しても回復が行える様に
CKPTF410は世代管理を行う。システムの障害発生後の回
復時には、最新世代のCKPTF410上の情報と、JNLF5に格
納されているチェックポイント時点以降の更新情報を重
畳して行くことにより、テーブルが回復できる。チェッ
クポイントダンプを定期的に取得することは、障害発生
後の回復時に必要となるジャーナル情報を限定すること
になり、回復時に入力するジャーナル量の削減と回復時
間の短縮化の効果がある。

チェックポイントダンプ取得は、各サブシステムで行
うが、この際、当該サブシステムを使用する業務処理を
停止させない。このため、更新中のテーブルをチェック
ポイントダンプとして取得する可能性がある。更新中の
テーブル情報をチェックポイントダンプに取得しても、
該更新に対応するジャーナルがチェックポイント時点以
降に取得されていれば、チェックポイントダンプ取得完
了後は、チェックポイント時点以前の履歴型ジャーナル
情報を必要としない。

テーブルの更新と対応するジャーナル取得が完了する
タイミング410eは、トランザクションごとにまちまちで
あり同期していない。またチェックポイントダンプ取得
にも有限の時間がかかる。このため、チェックポイント
ダンプは、第７図に示すようにチェックポイント時点41
0aとチェックポイントダンプ取得開始時点410b,取得終
了時点410c、及びチェックポイントダンプ有効時点410d
の４つの時点を分けて取得する。チェックポイントダン
プを取得する必要が発生すると、まずチェックポイント
時点410aの宣言を行う。該時点で更新中のテーブル情報
に対応するジャーナルは、チェックポイント時点410a以
前に取得されている可能性があるのでまだチェックポイ
ントダンプ取得を開始できない。そこで、チェックポイ
ント時点410aで更新中の処理がすべて更新処理を完了し
た時点まで待ち、完了後チェックポイントダンプ取得開
始を行う。チェックポイントダンプ取得が完了しても、
まだ更新に対応するジャーナルが出力されていない可能
性があるので、チェックポイントダンプ取得終了時点41
0cに更新中の処理に対応するジャーナルがすべて出力さ
れた時点まで待ち、出力完了後、チェックポイントダン
プ有効時点410dとする。チェックポイントダンプ有効時
点410dを経過する以前に障害が発生した場合には、当該
チェックポイントダンプは使用せず、一世代前のチェッ
クポイントダンプによる回復を行う。

本実施例では、第８図に示す流れに従ってチェックポ
イントダンプを取得する。まず、コントローラ１は、一
定のジャーナル出力件数に到達するとチェックポイント
ダンプ取得タスク412を起動する（850）。起動されたタ
スク412は、チェックポイント時点の宣言を行い、この
時点でのジャーナル通番をコントローラの管理する仮想
記憶上にチェックポイント時点ジャーナル通番815とし
て記憶しチェックポイント取得開始待ちとなる（85
1）。チェックポイント取得開始が可能となると、各サ
ブシステムにチェックポイントダンプ取得指示を行う
（852）。各サブシステムは、チェックポイントダンプ
取得指示に従い、チェックポイントダンプを各サブシス
テムのCKPTF410に取得する（860,862）。取得が完了す
るとコントローラに取得完了報告を行う（864）。コン
トローラは、各サブシステムの取得完了報告を確認した
後、チェックポイントダンプ有効化待ちとなる（85
6）。チェックポイントダンプ有効化が可能となると、
当該CKPTF410とSYSSF9に有効ビットを記録して（85
8）、チェックポイントダンプ取得を終了し（859）、次
の取得タイミングまで待ちとなる。

ここで、チェックポイントダンプ取得開始待ちと、チ
ェックポイントダンプ有効化待ちは、同一の方式を用い
る。本方式を第９図を用いて説明する。

第９図において、各トランザクションは、チェックポ
イント対象となっているテーブル更新を含む機能を使用
する際には、トランザクション管理テーブル７上の影響
フラグ711をオンにし（914）、機能使用終了時に影響フ
ラグ711及び実行監視フラグ712をオフにする（922,92
4）。本フラグ操作は、処理ルーチンは渡る際の共通ル
ーチンにて行う。なお共通ルーチンを経由しない場合、
各サブシステムの処理で開始，終了を宣言する方式をと
ればよい。

第10図においてコントローラ内のチェックポイントダ
ンプ取得タスク412でチェックポイントダンプ開始待ち
又は、有効化待ちを開始するには、トランザクション管
理テーブル７上の全トランザクションについて（1010）
影響フラグ711がオンであれば（1015）実行監視フラグ7
12をオンにする（1020）。その後タイマで待ち（102
5）、起動されるたびにすべての実行監視フラグ712がオ
フになっているかどうかをチェックする（1030）。すべ
ての実行監視フラグ712がオフになれば、待つを開始す
る時点にテーブル更新を含む処理がすべて終了する（10
35）。

チェックポイントダンプ出力時には、後述するジャー
ナルポインタ情報の退避や、資源管理テーブルの論理情
報の退避を行い、チェックポイント時点以前のジャーナ
ル情報や資源管理情報がなくても、回復ができるように
する。また、トランザクション管理テーブルは、チェッ
クポイントダンプ対象テーブルとなっており、回復がで
きる。資源管理テーブルの論理情報の退避は、第11図に
示す資源管理論理情報テーブル750という形式にして行
う。該論理情報テーブルは資源管理テーブル中の全資源
に対し、該資源を保持しているトランザクションのトラ
ンザクションID701を第３図に示す資源管理テーブル６
の資源ノード620から資源排他ノードへのリンク622をた
どることにより資源排他ノード630を求め資源名751とト
ランザクションID752をペアにして格納することで作成
する。この時出力すべきペアは、チェックポイント時点
以前に資源保持情報をジャーナルに出力したものであ
り、チェックポイント時点以降の資源保護情報は、後述
する様にジャーナルから回復する。

ジャーナルを外部記憶装置上のJNLF5に出力する際、
出力するバッファ上に存在する全てのトランザクション
形ジャーナルについて、第12図に示す形式のジャーナル
ポインタ720を作成しトランザクション管理テーブルの
該当トランザクションエントリに退避する。該ポインタ
720は、ジャーナルの通番721とJNLF5のファイル名722及
びファイルの先頭からの相対ブロック番号723をから成
り、該ポインタを用いることにより、必要な時点に当該
トランザクションで出力したジャーナルを得ることがで
きる。障害発生時、コントローラ１がダウンしていなけ
れば、トランザクション回復時には、該ジャーナルポイ
ンタでダイレクトにジャーナルを得ることができる。

チェックポイントダンプ出力時には、チェックポイン
トダンプ有効時点410dの時点で存在するトランザクショ
ンに関して、有効化に先だち、ジャーナルポインタ720
を用いてジャーナルをJNLF5から読み出し、トランザク
ションリカバリファイル430へ退避しておく。退避すべ
きか否かは、トランザクションテーブル７中のジャーナ
ルポインタ720にあるジャーナル通番721を参照し、チェ
ックポイント時点410aのジャーナル通番815より以前の
番号であれば、退避を行い、以降であればチェックポイ
ント時点以降のJNLF5中に存在するジャーナルなので退
避しない。

本実施例では、トランザクションの開始に先立ち、各
トランザクションにTRRF430の一定領域を割り当てる。

退避を行う場合、一世代前のチェックポイント時点に
退避したTRRF430中の情報を失うことのないように、ト
ランザクションテーブル７中のTRRF最終ポインタ730か
ら追加書きを行う。ここでTRRF最終ポインタ730は、ト
ランザクション発生時に該トランザクションに割り当て
たTRRF中の領域の先頭を指し、以降ジャーナル退避を行
う都度更新して、常にTRRF中の該トランザクションに割
り当てた領域最終を指すポインタである。

ジャーナル情報をTRRF430に退避することにより、チ
ェックポイントダンプ取得以降は、チェックポイント時
点以前から長期化しているトランザクションの回復にも
チェックポイント時点以前のジャーナルは不要となる。
TRRF430は、トランザクション単位のエントリに整理さ
れているので、トランザクション単位の回復時にも該TR
RF430とチェックポイント時点以降のジャーナルで回復
に必要なデータが容易にそろう。

さらに、トランザクション型ジャーナル出力時には、
資源保持情報も同時に出力する。これは、トランザクシ
ョン型ジャーナルを出力する際に、当該トランザクショ
ンの保有している資源を、資源管理テーブル６のトラン
ザクションノード610から資源排他ノード630をたどるこ
とにより求め、該資源保持情報を第11図に示す資源管理
論理情報のエントリと同様の形式でトランザクション型
ジャーナルに付加して出力することで行う。

障害発生後の回復時には、CKPTF410中のチェックポイ
ントダンプとして保持されていた資源管理論理情報テー
ブルとトランザクション型ジャーナルと共にJNLF5に出
力した資源保持情報から資源確保処理をくり返すことに
より資源管理テーブルが回復できる。

このため、データベースを全面閉塞すなわち、データ
ベースに対するアクセスを全面禁止するのではなく限定
した範囲（使用していた部分だけ）を閉塞すれば済み、
一部サブシステムがダウンしていたり、一部トランザク
ションの決着がつかない場合にも、オンラインシステム
を立上げることができる。

複合サブシステム型オンラインシステム全体が障害と
なった時の回復を全面回復と呼び、特定のサブシステム
だけが障害となった際の回復をサブシステム回復と呼
ぶ。以下、複合サブシステム型オンラインシステムの全
面回復，サブシステム回復について説明する。

第１に、複合サブシステム型オンラインシステムの全
面回復の流れを第13図から第17図を用いて説明する。全
面回復では、まずコントローラ１の機能を回復する。そ
の後各サブシステムの回復を行うが一部のサブシステム
機能が回復できなくても当該機能を縮退したままシステ
ムを再開できる。コントローラ１の機能回復は、まずSY
SSF9からコントローラ用CKPTF410を決め（1310）、該CK
PTF410からコントローラ内のトランザクション管理テー
ブル７と資源管理論理情報テーブル750を回復する（131
5）。なお、コントローラ用CKPTF410を読むことによ
り、現在の最新チェックポイント時点のジャーナル通番
及び該ジャーナル通番のジャーナルに対するジャーナル
ポインタ815が決まる（1320）。

次に、第14図に示すように最新チェックポイント時点
とジャーナルポインタ815で指す位置からJNLF5を順に読
む。読み出されたジャーナルは、コントローラ出力した
履歴形ジャーナルであれば、第15図の流れに従いトラン
ザクション管理テーブル７や、資源管理論理情報テーブ
ル750更新情報として使用し、各テーブルを障害発生時
点の状態に回復して行く。コントローラ以外が出力した
履歴形ジャーナルは、出力サブシステムのTBLRF420へ出
力する。トランザクション型ジャーナルの場合は、トラ
ンザクション管理テーブル７の該当するトランザクショ
ンエントリのジャーナルポインタ720の領域にジャーナ
ルポインタ形式で格納して行く。トランザクション管理
テーブル７の各トランザクションのエントリは、同期点
ジャーナルが見つかれば同期点通過ステータスを同期点
通過フラグ715をオンにすることで記録し終了ジャーナ
ルが見つかれば、該エントリを削除する。

分散データベースの分散サーバ側のように同期点準備
ジャーナルが存在する場合、同期点準備ジャーナルが見
つかれば、まず同期点準備通過フラグ717をオンにする
ことで、同期点準備状態であることを記録する。同期点
ジャーナルが見つかれば、同期点準備通過フラグ717を
オフにし、同期点通過フラグ715をオンにする。終了ジ
ャーナルが見つかれば、該エントリを削除する。

ジャーナル読み込みが完了した時点では、各サブシス
テムの履歴形ジャーナルは、サブシステムごとのTBLRF4
20で分類されて出力されてある。トランザクション管理
テーブル７は、障害発生時点まで回復されており、障害
発生時点で存在したトランザクションだけが登録されて
ある。この時点でトランザクション管理テーブル７中の
全トランザクションの凍結要フラグをオンにしておく各
トランザクションごとのエントリは、ジャーナルポイン
タ720領域を含めて回復されてある。

資源管理論理情報についても、最新のチェックポイン
ト時点の状態と、それ以降の更新情報がすべてそろって
いる。ジャーナルの読み込みが完了すると、資源管理論
理情報をもとに、資源確保，解放操作をくり返すとによ
って資源管理テーブル６を回復する。さらに回復された
資源管理テーブルの全排他ノード630について凍結状態
にする。凍結状態になった資源に対して新たに資源確保
を行うと、凍結状態のため、排他ノード630を作ること
をせずに、資源確保要求が失敗する。従って資源管理テ
ーブルを凍結状態にすることで、障害発生時に使用して
いた資源を一時的に使用禁止状態にすることができ、新
たなトランザクションが発生しても、使用可能な資源だ
けで動作できるならば、実行ができ使用不可の資源を必
要とするならばエラーとして扱われ長時間待つことがな
い。すなわち、資源管理テーブル６の回復と凍結が済ん
だ時点でコントローラ１としての回復は終了する。この
時点で、システムレディのメッセージを出力するがまだ
サブシステムが回復されていないので、複合サブシステ
ム型オンラインシステム全体としては、動作を開始しな
い。

なお、資源の凍結は、後で述べる決着で失敗した時点
で始めて行う方法もある。この場合、同一資源にアクセ
スするトランザクションは待ちになるが、決着が終るま
で待つだけなので障害の影響を小さくできる。

次に、サブシステムの回復を始める。各サブシステム
は、コントローラ１の指示で並行して回復処理を行う。
各サブシステムの回復は、TBLRF420に格納されている履
歴型ジャーナルをもとに、サブシステム内の回復対象テ
ーブルを回復することで終る。この時点で、複合サブシ
ステム型オンラインシステムは動作を開始する。なお、
一部のサブシステムが回復に失敗した場合に該サブシス
テムだけが縮退した状態となる。この時点でも、障害発
生時点で動作中のトランザクションは回復されていない
が、これらのトランザクションはすべて凍結要となって
おり、後で述べるトランザクションの凍結決着処理にて
回復する。新しく発生したトランザクションは、そのま
ま実行される。

各サブシステムへの回復指示を出した後、サブシステ
ムにおける回復と並行してコントローラ１では、トラン
ザクション管理テーブル７に存在する凍結用フラグがオ
ンとなっている全トランザクションがアクセスしていた
資源（一般にはデータベース）をすべて回復する。そこ
で、コントローラ１は、トランザクションの回復のため
の処理を開始する。これを凍結決着処理と呼ぶ。凍結決
着処理の流れを第16図に示す。

凍結決着処理では、まず、凍結要となっているトラン
ザクションの凍結処理を行う（1610）。ここで、トラン
ザクションを凍結状態にするとは、該トランザクション
を終了させずに一時的に停止させることであり、このた
めに回復に必要な情報を保存する。

トランザクションの凍結処理では、第16図に示すよう
にトランザクション管理テーブル７のジャーナルポイン
タ720をもとに、該トランザクションのもとで出力した
ジャーナルをJNLF5から読み出す（1615）。読み出した
ジャーナルは、チェックポイントダンプ出力時と同様
に、トランザクション管理テーブル７のTRRF最終ポイン
タ730の位置から追加書きでTRRF430に書き込んで行く
（1620）。該トランザクションのジャーナルポインタ72
0に関して、すべてのジャーナルをTRRF430へ退避した時
点で（1625）、該トランザクションの凍結処理が完了
し、凍結要フラグをオフとし、凍結フラグをオンとする
（1630）。トランザクションが凍結されると、該トラン
ザクションの回復に必要となるすべてのジャーナルがTR
RF430中に格納されたことになる。これは、最新のチェ
ックポイント時点以前に出力された該トランザクション
のジャーナルは、チェックポイント時点にTRRF430に退
避済であり、チェックポイント時点以降のジャーナル
は、ジャーナルポインタ720を用いて凍結処理でTRRF430
に退避したためである。

凍結状態になったトランザクションすなわち、凍結フ
ラグがオンとなっているトランザクションは、コントロ
ーラ１が定期的にトランザクション管理テーブル７から
選択し、該トランザクションの保持する資源を回復す
る。資源の回復は、同期点ジャーナルの有無により決め
る。同期点ジャーナルが存在すれば、すなわち同期点通
過フラグ715がオンであれば、ジャーナルをもとに更新
を完結させる。これをロールフォワードと呼ぶ。同期点
ジャーナルが存在しなければ、すなわち同期点通過フラ
グ715がオフであれば、トランザクションでの更新を無
効とし、更新済の部分はジャーナルをもとに以前の状態
に戻す。これをロールバックと呼ぶ。ロールフォワード
とロールバック処理を合わせて資源の決着、またはトラ
ンザクションの決着と呼ぶ。

決着処理は、第16図に示す様に、まず、トランザクシ
ョン管理テーブル７中の凍結フラグ716がオンとなって
いるトランザクション一つ選択し（1635）、該トランザ
クションの状態をトランザクション管理テーブル７中の
同期点通過フラグ715でチェックする。同期点を通過し
ていれば、ロールフォワード処理を行い、同期点通過以
前であれば、ロールバック処理を行う。ロールフォワー
ド，ロールバックは、該トランザクションの使用BE3を
トランザクション管理テーブル７の使用BE703から決
め、全使用BEに対してロールフォワード，ロールバック
を指示することで行う。指示を行うには、事前にTRRF43
0を読み、該トランザクションの該BEに関連するジャー
ナルをテーブルとして仮想記憶上に作成し、該BEに引き
渡す（1640）。BE3は、BE自身の回復が済みBE機能が回
復していれば、渡されたジャーナルをもとに資源の決着
を行う（1645）。回復が済めば、凍結されていた該資源
の排他ノードを解放し、資源を解放し、凍結フラグ716
をオフにする（1660）。BE自身の回復が完了していな
い、若しくは回復できない場合は、該トランザクション
を凍結したままとする。従って、障害回復のできないBE
によって回復処理が終了しない場合でも、回復できない
範囲を該BEのデータベースを更新したトランザクション
群だけに限定することができる。

一つのトランザクションで複数BEのデータベースを更
新した場合の決着処理を第17図に示す。複合BEのデータ
ベースを更新した場合、TRRF430からジャーナルを入力
し（1720）、入力したジャーナルを渡すべきBE3が障害
中であれば（1725）、該ジャーナルをとばしTRRF430中
の残りのジャーナルについて処理を続ける。TRRF430中
のジャーナル終了後（1735）、BE3が障害中のためとば
したジャーナルがあれば、該BE3を除き処理済となったB
E3についての部分的終了ジャーナルを出力し（1745）、
決着済BEに対応する資源を解放し（1750）、該トランザ
クンションは凍結状態のままにしておく。処理済となっ
たBE3については、トランザクション管理テーブル中の
使用BEエントリーに処理済であることを記録しておく
（1765）。次に決着処理が実行される場合には、TRRF43
0から入力されたジャーナルが既に処理済BE3のジャーナ
ルであれば読みとばす。従って、一つのトランザクショ
ンが複数BEのデータベースを更新した場合の一部BEが障
害中の回復処理では、該トランザクション全体ではな
く、該トランザクションの障害中BEについての回復が保
留されるだけであり、回復可能なBEについての回復処理
を完了することによって、回復できない範囲を最小限に
することができる。

分散データベースの分散サーバ側の場合、該サブシス
テムはFE2に相当し、同期点通過以前の状態が更に、同
期点準備状態と同期点準備以前の状態に分けられる。同
期点準備以前の状態であれば、ロールバック処理を行
い、同期点通過後の状態であれば、ロールフォワード処
理を行う。同期点準備状態の場合、分散データベースの
分散サーバから当該トランザクションを発生させた分散
クライアントに問い合わせを行い、分散クライアント側
の対応するトランザクションが同期点通過後であればロ
ールフォワード処理を行い、同期点通過以前であればロ
ールバック処理を行う。分散サーバから問い合わすべき
相手の分散クライアントとトランザクションの識別情報
は、分散サーバ側でのトランザクション発生時点にトラ
ンザクション管理テーブルの発生FEエントリ702に記録
しておく。

自システム内の分散データベースサブシステムが障害
中、又は他プロセッサ側が障害中の場合、同期点準備状
態のトランザクションのみが決着できずに残されるが、
他のトランザクションは、第16図，第17図の流れに従い
決着する。

一方分散データベースの分散クライアント側の場合該
サブシステムはBE3に相当する。第17図の流れにおい
て、コントローラ１は、トランザクション管理テーブル
中の使用BEエントリ703に、分散クライアントが記録さ
れていたならば、各BE3へのジャーナル渡し処理時に分
散クライアントに対し、ロールバック、又はロールフォ
ワードの指示を出す。分散クライアントは、該指示を分
散サーバ側に送る。分散サーバ側では、指示を受けたト
ランザクションが同期点準備状態であれば、ロールフォ
ワード指示の場合は同期点通過状態にする。ロールバッ
ク指示の場合は同期点準備以前状態にし、各々該当する
決着処理を行う。

なお、分散サーバ側のトランザクショから、更に他プ
ロセッサの分散データベースに対する要求が出された場
合には、該トランザクションの一つのBEとして該システ
ム上の分散クライアントを使用した場合に対応づけるた
めだけで同様に扱うことができる。

第２に、サブシステム障害の回復について、第18図を
用いて説明する。

複合サブシステム型オンラインシステムでは、サブシ
ステム内に障害が発生した場合には、該サブシステムだ
けを障害扱いとし、サブシステム回復を行う。サブシス
テム回復方式は、FE2とBE3で異なる。

FE2に障害が発生した時の回復では、該サブシステム
の機能の回復と該サブシステム下で生成した全トランザ
クションを回復する必要がある。サブシステムのみ障害
の場合、コントローラ１の持つトランザクション管理テ
ーブル７はそのまま仮想記憶装置上に存在するので、該
サブシステムの異常終了時に呼び出されるルーチンの中
で、トランザクション管理テーブル７の発生FE領域702
を参照して該サブシステムの発生させた全トランザクシ
ョンについて凍結要フラグ713をオンにしておく。ここ
で、障害となったFE2が発生させたトランザクション
は、トランザクション管理テーブル７中の発生トランザ
クション領域702を参照することで限定している。この
ため、該FEの障害は、該FEの発生させたトランザクショ
ンに限定でき、他FEの発生させたトランザクションに対
しては影響なく業務処理が遂行できる。サブシステムダ
ウンをコントローラが検出するとコントローラ１は、全
面ダウン時と同様に、JNLF5を最新チェックポイント時
点から順次読み出し、該障害発生サブシステムに関連す
る履歴型ジャーナルを該サブシステムのTBLRF420に格納
する（1810）。その後、コントローラ１は該サブシステ
ムを再起動し、起動後該サブシステムに回復指示を出す
（1815）。回復指示を受けたサブシステムは、CKPTF410
とTBLRF420をもとに該サブシステムの機能回復を行う
（1860）。

該サブシステムの機能回復と並行して、コントローラ
１は、トランザクション管理テーブル７の凍結要フラグ
713がオンの全トランザクションについて、全面回復時
と同様に第16図の流れに従いすべて凍結し、決着を行う
（1820）。資源管理テーブル６は、コントローラ１が管
理しているため、サブシステム障害，回復時にも有効の
ままなので、障害発生FE2は、該サブシステム機能の回
復が済めば、コントローラ１のトランザクション凍結，
決着を待つことなく、新しいトランザクションの処理を
開始できる。

BE3の障害が発生した時の回復では、該サブシステム
の機能回復と、該BEを使用していたトランザクションの
回復を行う。FE2障害時同様、トランザクション管理テ
ーブルは仮想記憶装置上に存在するので、該BE3の異常
終了時に呼び出されるルーチンの中で、トランザクショ
ン管理テーブル７の使用BE領域703領域を参照して、該B
Eを使用していた全トランザクションについて、ロール
バック要フラグ714をオンにしておく。ここで、障害発
生となったBE3を使用したトランザクションとトランザ
クション管理テーブル７の使用BE領域703で限定してい
るため、該BEの障害は、該BEを実際に使用しているトラ
ンザクションに限定でき、他BEだけを使用しているトラ
ンザクションに対しては、影響なく業務処理が遂行でき
る。

さらに、該BE3の管理していた資源は、該BE3の障害回
復が終了するまで解放できないので資源凍結を行う（18
40）。資源の凍結は、該BE2の異常終了時に呼び出され
るルーチンの中で資源管理テーブル６中の該BE3に継が
る全資源ノード630について行う。資源凍結は、障害発
生時には単に凍結要としておき、BE回復，トランザクシ
ョン決着が一通り済むまで遅延させる方式でもよい。こ
れにより、同一資源を要求している他トランザクション
はエラーリターンではなく、一時的に待ちを行い、該資
源を保持しているトランザクションが正常に決着されれ
ば、障害はなかったものとして処理が継続できる。

サブシステムダウンをコントローラ１が検出すると、
コントローラ１は、FE2障害時と同様にJNLF5からTBLRF4
20を作成する。その後コントローラ１は、該BE3を再起
動し、起動後、障害発生BE3に回復指示を行う。回復指
示を受けたBEは、CKPTF410とTBLRF420をもとに該BEの機
能回復を行う。ただし、BEの種類によっては、CKPTF410
やTBLRF420を必要としない。この場合は、コントローラ
１はJNLF5を読まずに単に回復指示を出し、該BEは機能
回復を行う。

該サブシステムの機能回復を待ち、コントローラ１
は、トランザクション管理テーブル７のロールバック要
フラグ714がオンの全トランザクションについて、全面
回復時と同様に第16図の流れに従いすべて凍結し、ロー
ルバック方向の決着を行う。

以上サブシステムの障害回復で示した様にトランザク
ション管理テーブル７の発生FE領域702及び使用BE領域7
03を用いてサブシステム障害の影響を特定のトランザク
ションに限定している。本機構のため、一部サブシステ
ム障害時でも他のサブシステムの処理は正常に遂行でき
ることとなり、複合サブシステム型オンラインシステム
の運転を続行できる。また、RF4を持つことで、障害と
なったサブシステムは、他サブシステムの処理が先に進
む事に影響されずに遅延しながらも回復し、他サブシス
テムに影響することなく合流することができる。

第３に、業務処理プログラムに障害が発生し、実行中
のトランザクションが異常終了した場合には、異常終了
時に呼び出されるルーチンにて、該トランザクションの
凍結要フラグ713をオンにしておく。これにより、全面
グウン時と同様にコントローラ１が該トランザクション
の凍結，決着を行う。業務処理プログラムは、FE2によ
って再度起動されることで、機能を回復する。

〔発明の効果〕

以上の説明から明らかなように、本発明によれば、分
数データベースのために、新しい制御機構を設けること
なく、複合サブシステム型オンラインシステムの一サブ
システムとして分散データベースアクセス機能を構築す
るだけで、分散データベースのダウンをローカルデータ
ベースのダウンと分離することができ、信頼性向上が図
れるという効果がある。

本方式によれば、複合サブシステムコントローラのダ
ウン確率を0.01％，各サブシステムのダウン確率を0.05
％と仮定し、分散アクセスを必要とするトランザクショ
ンの割合を５％として試算すると、トランザクションの
実行できない確率は、従来の0.1％から0.06％と40％削
減できる。

【図面の簡単な説明】

第１図は複合サブシステム型オンラインシステムの全体
構成を示すブロック図、第２図はリカバリファイルの構
成図、第３図は資源管理テーブルの構成図、第４図はト
ランザクション管理テーブルの構成図、第５図はシステ
ムステータステーブルの構成図、第６図はチェックポイ
ントダンプ取得の概念図、第７図はチェックポイントダ
ンプ取得のタイミングチャート、第８図はチェックポイ
ントダンプ取得処理のフローチャート、第９図はチェッ
クポイントダンプの有効化方式のフローチャート、第10
図はチェックポイントダンプ取得における待ち処理のフ
ローチャート、第11図は資源管理論理情報テーブルの構
成図、第12図はジャーナルポインタの構成図、第13図は
全面回復処理のフローチャート、第14図はジャーナル回
復処理のフローチャート、第15図はコントローラのジャ
ーナル回復処理のフローチャート、第16図はトランザク
ション凍結／決着処理のフローチャート、第17図は一つ
のトランザクションが複数BE更新時の決着処理のフロー
チャート、第18図はサブシステム障害回復処理のフロー
チャートである。 １……複合サブシステムコントローラ、 ２……フロントエンドサブシステム、 ３……バックエンドサブシステム、 ４……リカバリファイル、 ５……ジャーナルファイル、 ６……資源管理テーブル、 ７……トランザクション管理テーブル、 ８……システムステータステーブル、 ９……システムステータスファイル、 10……オンライン端末、 11……データベース、 410……チェックポイントファイル、 411……チェックポイント対象テーブル、 412……チェックポイントダンプ取得タスク、 420……テーブルリカバリファイル、 430……トランザクションリカバリファイル、 610……トランザクションノード、 611……トランザクションID部、 612……次トランザクションノードへのリンク、 613……資源排他ノードへのリンク、 620……資源ノード、621……資源名部、 622……資源排他ノードへのリンク、 623……次資源ノードへのリンク、 630……資源排他ノード、 631……資源名部、 632……同一資源に対して待ちをしている次資源排他ノ
ードへのリンク、 633……同一トランザクションが保持又は待っている次
の資源排他ノードへのリンク、 634……トランザクションID部、 635……本資源排他ノード情報がジャーナルとして取得
されているか否かを示すフラグ、 636……本資源排他ノード情報は資源を保持しているの
か、待っているのかを示すフラグ、 701……トランザクションID領域、 702……発生フロントエンドサブシステム領域、 703……使用バックエンドサブシステム領域、 710……ステータスフラグ領域、 711……影響フラグ、712……実行監視フラグ、 713……凍結要フラグ、 714……ロールバック要フラグ、 715……同期点通過フラグ、 716……凍結フラグ、 717……同期点準備通過フラグ、 720……ジャーナルポインタ領域、 721……ジャーナル通番、 722……ジャーナルファイル名、 723……相対ブロック番号、 730……TRRF最終ポインタ領域、 740……資源管理テーブルへのポインタ、 750……資源管理論理情報テーブル、 751……資源名領域、 752……トランザクションID領域、 7011……エントリ番号、 7012……通番、810……システムの状態領域、 815……チェックポイント時点のジャーナルポインタ領
域、 820……サブシステムの状態領域。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 山本 章治 神奈川県横浜市戸塚区戸塚町5030番地 株式会社日立製作所ソフトウェア工場内 (56)参考文献 情報処理学会論文誌Ｖｏｌ．26 Ｎ ｏ．６（1985−11），Ｐ．1023〜1032

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】複数プロセッサの各々に、サブシステム単
   位に自律して実行、回復する能力を持つデータベースサ
   ブシステムと、データコミュニケーションサブシステム
   と、これらのサブシステムを統合制御するコントローラ
   とから構成される複合サブシステム型オンラインシステ
   ムを相互に通信経路で接続されて成る複合サブシステム
   型分散データベースシステムにおいて、前記複合サブシ
   ステム型オンラインシステムの一サブシステムとして分
   散データベースのアクセス機構を前記複合サブシステム
   型オンラインシステムの直下に存在する少なくとも１つ
   の前記データベースサブシステムと同一のコントローラ
   下に設け、前記分散データベースのリモートアクセス用
   サブシステムが分散先の分散データベースに関する回復
   情報を保存しておき、リモートデータベースが障害とな
   っている間も前記分散データベースのアクセス機構によ
   り前記コントローラ直下のデータベースサブシステムの
   回復を独立して自律的に実行することを特徴とする複合
   サブシステム型分散データベースシステムの障害回復方
   法。