JPH0833859B2 - 複合サブシステム形オンラインシステム - Google Patents

複合サブシステム形オンラインシステム

Info

Publication number
JPH0833859B2
JPH0833859B2 JP62095103A JP9510387A JPH0833859B2 JP H0833859 B2 JPH0833859 B2 JP H0833859B2 JP 62095103 A JP62095103 A JP 62095103A JP 9510387 A JP9510387 A JP 9510387A JP H0833859 B2 JPH0833859 B2 JP H0833859B2
Authority
JP
Japan
Prior art keywords
transaction
journal
subsystem
recovery
resource
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
Application number
JP62095103A
Other languages
English (en)
Other versions
JPS63261437A (ja
Inventor
一夫 正井
哲 和歌山
章治 山本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP62095103A priority Critical patent/JPH0833859B2/ja
Priority to US07/184,075 priority patent/US5065311A/en
Publication of JPS63261437A publication Critical patent/JPS63261437A/ja
Priority to US07/701,816 priority patent/US5333314A/en
Publication of JPH0833859B2 publication Critical patent/JPH0833859B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Landscapes

  • Retry When Errors Occur (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、複合サブシステム形オンラインシステムの
障害回復に係り、特に各サブシステムが同期して立上が
ることが期待できないオンラインシステムに好適なリラ
ン方式に関する。
〔従来の技術〕 従来の単独オンラインシステムの障害回復方式は特開
昭54−114145号に記載のように、オージットファイル
(ジャーナルファイル)とチェックポイントファイル
(及び、場合によっては、ビフォアルックファイル)を
持ち、障害時に備えて、ジャーナル及びチェックポイン
ト情報を採取しておき、障害発生時点では、障害に応じ
てジャーナルとチェックポイント情報を用いて回復を行
っていた。ここで対象とするオンラインシステムは、1
個のデータコミュニケーション部と1個のデータベース
部を持つものに限られていた。
〔発明が解決しようとする問題点〕
上記従来技術は、複合サブシステム形オンラインシス
テムの障害回復については配慮されておらず、複合サブ
システム構成をとると、それぞれのサブシステムが独立
にジャーナルをとり、相互に無関係に回復することにな
る。これでは、複数のサブシステムにまたがる業務処理
(トランザクション)が発生すると、複数のサブシステ
ムの情報を同期して回復する必要があるにもかかわら
ず、同期しての回復ができないことになる。障害発生サ
ブシステムが立上がってから同期をとってトランザクシ
ョンの回復を行うことにすれば良いが、障害発生後なか
なか立上がらないサブシステムがあった場合、他のサブ
システムはいつまでも障害回復の完了しないトランザク
ションを残すことになる。このため、該トランザクショ
ンの回復に必要となるジャーナル情報がいつまでも必要
となる。このまま、オンラインを再開すると、回復でき
ないトランザクションの回復に必要なジャーナルは後か
ら発生するジャーナルに埋もれてしまい、障害発生サブ
システムが回復した後、膨大なジャーナルの中に埋もれ
たジャーナル情報を挿すことになる。従って、一部サブ
システム障害発生時にも、全サブシステムの運転を停止
させ、全サブシステム立上げ後、全トランザクションを
回復してからオンラインを開始する必要があるという問
題があった。
一部サブシステムが立上がらなくても、情報更新の同
期情報がわかる様に全サブシステムのジャーナルを一本
にまとめた場合、障害発生サブシステム以外の情報は回
復できるが、今度は、障害発生サブシステムが必要とす
るジャーナルが一本にまとめられたジャーナルの中に埋
もれることになりやはり膨大なジャーナルの中から必要
なジャーナルを挿すことになってしまうという問題が発
生する。
本発明の目的は、複合サブシステム形のオンラインに
おいて、一部サブシステムに障害が発生した場合、障害
発生サブシステム以外のサブシステムの運転を続行さ
せ、その後障害サブシステムが立上がってからの回復が
容易にできる様にすることにある。
〔問題点を解決するための手段〕
上記目的は、複合サブシステム形オンラインシステム
に回復時に必要とするジャーナルをトランザクションご
とに退避するジャーナル退避ファイルを設け、チェック
ポイント時点ごとに、該時点で動作中のトランザクショ
ンが出力したジャーナルをジャーナル退避ファイルに退
避するこにより達成する。
〔作用〕
各々のサブシステムが出力するジャーナルは、一ケ所
のジャーナルファイルにまとめて取得するまた、各ジャ
ーナルは、チェックポイント時点で動作中のトランザク
ションのために出力したジャーナルであれば、ジャーナ
ル退避ファイルへ格納する。ジャーナル退避ファイル
は、トランザクション単位に区割りされており、トラン
ザクションごとのジャーナルに整理して格納される。
一部サブシステムが障害となった時には、該サブシス
テムを使用した全トランザクションを回復する必要があ
る。障害となったサブシステムを使用しトランザクショ
ンが必要となるジャーナルを得るため、複合サブシステ
ム形オンラインシステムのコントローラはチェックポイ
ント時点以降のジャーナルを全て読み出し、ジャーナル
退避ファイルに必要なジャーナルを追加書きして行く。
この動作が終了した時点で、回復を必要とする各トラン
ザクションが必要とするジャーナルは、全てジャーナル
退避ファイルに集められたことになる。このジャーナル
退避ファイル中の情報を用いて、各トランザクションの
回復が行われるが、使用したサブシステムのうち動作中
のサブシステムに関する情報はすぐ回復できるが、立上
がっていないサブシステムの情報は遅れて回復されるこ
とになる。しかし、必要なジャーナルはすべてジャーナ
ル退避ファイルに集められているので、障害サブシステ
ムが遅れて立ち上がっても、その時点ですぐにトランザ
クションの回復ができる。
〔実施例〕
以下、本発明の一実施例を第1図から第18図により説
明する。
第1図は、本発明を実現する複合サブシステム形オン
ラインシステムの全体構成図を示す。
第1図において、複合サブシステム形オンラインシス
テムは、複数のサブシステムを制御する複合サブシステ
ムコントローラ1(以下単にコントローラと呼ぶ)と、
その配下にある2種類のサブシステム(フロントエンド
形サブシステム2及びバックエンド形サブシステム3)
と、各サブシステムごと及びコントローラ用のリカバリ
ファイル4(以下単にRFと呼ぶ)と、全サブシステムの
ジャーナルを格納するジャーナルファイル5(以下、JN
LFと呼ぶ)と、全サブシステムの資源状態を管理する資
源管理テーブル6と、トランザクションを管理するトラ
ンザクション管理テーブル7と、システムの状態を管理
するシステムステータステーブル8と、システムステー
タステーブルの外部記憶装置上の複写として存在するシ
ステムステータスファイル9(以下、SYSSFと呼ぶ)か
ら成る。
フロントエンド形サブシステム(以下FEと呼ぶ)は、
オンライン端末10を有し、業務処理の単位であるトラン
ザクションを発生させる。バックエンド形サブシステム
3(以下、BEと呼ぶ)は、データベース11を有し、FE2
の発生させたトランザクションによる要求に従ってデー
タベース11をアクセスする。
分散データベースシステムは、他プロセッサからのデ
ータベースアクセス要求を受け、自プロセツサ内にトラ
ンザクションを発生させて行うFEの役割(以下分散サー
バと呼ぶ)と、トランザクションからの他のプロセッサ
のデータベースアクセス要求を受付けるBEの役割(以下
分散クライアントと呼ぶ)を合わせて持つサブシステム
として位置づけられる。従って、複合サブシステム形オ
ンラインシステムの一部に分散データベースを考えるこ
とも可能である。
第2図に、リカバリファイル4の構成を示す。RF4
は、サブシステム毎とコントローラ1用が存在しサブシ
ステム又はシステム全体が障害となった際の回復用情報
を格納する外部記憶の総称であり、チェックポイントダ
ンプを格納するチェックポイントファイル410と、テー
ブル回復に使用するテーブルリカバリファイル420と、
トランザクション単位のジャーナルを退避するためのト
ランザクションリカバリファイル430から成る。以下、
チェックポイントファイルをCKPTFと呼び、テーブルリ
カバリファイルをTBLRFと呼び、トランザクションリカ
バリファイルをTRRFと呼ぶ。
第3図に資源管理テーブル6の構成を示す。資源管理
テーブル6は、各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がオフとなる。該資源管
理テーブル6を用いると、リンク632,633をたどること
により特定のトランザクションの保持する資源一覧、又
は特定の資源を保持しているトランザクション名が得ら
れる。各排他ノード中には、ジャーナル上に排他ノード
情報が退避されたか否かを示すフラグ635を持つ。
資源管理テーブル6が、サブシステムを通してコント
ローラ1上に一本化されているので、サブシステムダウ
ン時は、排他情報が保持できるだけでなく、サブシステ
ムをまたがったデッドロックの検出が容易となってい
る。
第4図にトランザクション管理テーブル7の構成を示
す。トランザクション管理テーブルには、各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とからなる。
第5図にシステムステータステーブル8の構成を示
す。システムステータステーブルには、コントローラ1
の状態810と各サブシステムの状態820と、システムのチ
ェックポイント時点のジャーナル通番記録領域815から
成る。
該システムステータステーブルは更新の都度SYSSFへ
対応エントリを書き出しておき、SYSSFに複写を作って
おく。
本実施例で示す複合サブシステム形オンラインシステ
ムでは、障害発生時の回復のために、種々の情報を外部
記憶装置に出力しながら業務処理を進めて行く。回復す
べき資源(データ,情報の総称)は、大きく分けて、次
の2種類がある。
(1)仮想記憶装置上のテーブルの様に、障害発生時に
は消失してしまうタイプの揮発性資源 (2)外部記憶装置上のデータベースの様に、障害発生
時にも、一般には障害発生時点の状態を保持したままと
なるタイプの不揮発性資源 障害発生時点で消失する揮発資源を回復するために
は、定期的に該資源の複写を不揮発性の外部記憶装置に
作成しておく(該複写をチェックポイントダンプと呼
ぶ)。チェックポイントダンプ取得以降変更の都度変更
の差分情報をジャーナルとして取得しておき、チェック
ポイントダンプに該ジャーナル情報を重畳することで回
復が行える。このタイプのジャーナルを履歴形ジャーナ
ルと呼ぶ。
障害発生時点の状態が保持される不揮発性資源を回復
するには、変更の都度ジャーナルを取得する。回復時に
は、業務処理単位であるトランザクション毎に更新を完
結させるか、更新を無効にするかを判断し、変更都度取
得したジャーナルの変更後情報を重畳するか、変更前情
報を重畳するかで回復を行う。このタイプのジャーナル
をトランザクション形ジャーナルと呼ぶ。
本実施例のシステムでは、障害回復に備えて、データ
ベース更新,テーブル更新に先立ってジャーナル出力を
行う。ジャーナル出力は、コントローラ配下の機能を用
いて、各サブシステムを統合して一つのJNLF5に行う。J
NLF5を統合することは、複合サブシステムを運転する際
の操作性向上に大きく寄与する。ジャーナル取得の方式
を以下に説明する。
ジャーナルは、データベース更新,テーブル更新前に
必ず取得する。ジャーナル取得前に変更を行うと、変更
後、ジャーナル取得前に障害が発生した場合に回復でき
なくなる。
トランザクションの終了に際して、該トランザクショ
ンの全ジャーナルを出力した後に、全ジャーナルが出力
済すなわち同期点を示すジャーナル(以下同期点ジャー
ナルと呼ぶ)を出力する。
該同期点ジャーナルがジャーナルとして存在するトラ
ンザクションでは、不揮発性資源の回復に必要となるす
べてのトランザクション形ジャーナルが存在するため、
該トランザクションの処理を完結させる方向の回復が行
える。それに対し、同期点ジャーナルが存在しないトラ
ンザクションでは、全ジャーナルが出力されている保証
はないが、変更前には必ずジャーナルを出力しているた
め、存在するジャーナルの変更前情報を用いて、該トラ
ンザクションを無効とする方向の回復が行える。
トランザクションが完結した後に、トランザクション
終了を示すジャーナルを取得する。該終了を示すジャー
ナルを終了ジャーナルと呼ぶ。該ジャーナルが出力され
た後は、トランザクション形ジャーナルによる回復は不
要となる。
分散データベースの場合には、一つのトランザクショ
ンが自システム内のデータベースと他プロセッサ内のデ
ータベースを更新するため、プロセッサ間にまたがって
データベース更新の同期が必要となる。分散データベー
スの場合のジャーナル取得の方式を以下に説明する。
トランザクションの終了に際して、まず分散クライア
ント側の全ジャーナルが出力される。この時点で分散ク
ライアント側から分散サーバ側に全ジャーナルの出力指
示(以下、これを同期点準備指示と呼ぶ)を行う。分散
サーバ側では該指示を受け全ジャーナルの出力後に同期
点準備が完了したことを示すジャーナル(以下、これを
同期点準備ジャーナルと呼ぶ)を出力する。該ジャーナ
ルの出力完了後、分散サーバは分散クライアントに同期
点準備の完了を報告する。分散クライアント側では、該
トランザクションの自システム内の全ジャーナルの出
力、及び要求を出した全ての他プロセッサの分散サーバ
から同期点準備完了報告を受けた後、同期点ジャーナル
を出力する。同期点ジャーナルの出力が完了した後、分
散クライアントは自システム内のデータベースの更新を
行い、分散サーバに対し該トランザクションが同期点に
達した旨の指示(以下、これを同期点指示と呼ぶ)を行
う。分散サーバは、同期点指示を受けると、まず同期点
ジャーナルを出力した後、バッファ上に残る該トランザ
クションのデータベース更新を完了さる。その後終了ジ
ャーナルを出力し、出力が完了後、分散クライアントに
トランザクション完了を報告する。分散クライアント側
では、自システム内のデータベースの更新、及び指示を
出した全ての分散サーバから完了報告を受けた後、終了
ジャーナルを出力する。
分散クライアント側では、同期点ジャーナルが存在す
れば、該トランザクションを有効とする方向の回復を行
い、なければ無効とする方向の回復を行うことができ
る。分散サーバ側では、同期点準備ジャーナルと同期点
ジャーナルが存在すれば、該トランザクションを有効と
する方向の回復を行い、同期点ジャーナル及び同期点準
備ジャーナルのいずれも存在しない場合には、該トラン
ザクションを無効とする方向の回復を行う。同期点準備
ジャーナルだけが存在する場合には、分期クライアント
側の同期点ジャーナルの有無を調べ、それに従えば回復
を行うことができる。
なお、該プロセッサ内で独自のジャーナルファイルを
持ちジャーナルを取得する従来形オンラインシステムを
複合サブシステム形オンラインシステムに接続し、該オ
ンラインシステム下で実行するトランザクションから、
複合サブシステム形オンラインのBEのデータベースを更
新する場合、該オンラインシステムを分散サーバと同様
の一つのFEとして扱い、前述のジャーナル取得方式を用
いることにより該オンラインシステム内のデータベース
更新と複合サブシステム形オンラインシステムのBEのデ
ータベース更新の同期をとった回復ができる。
本実施例では、回復すべきテーブルを定期的にチェッ
クポイントダンプとしてサブシステム毎に取得し、同時
点にてトランザクション形ジャーナルをTRRFに退避す
る。各情報取得の方式を以下に説明する。
第6図,第7図,第8図にチェックポイントダンプ取
得の概念と取得の流れ図を示す。
第6図に示すように、各サブシステム2,3は、定期的
に仮想記憶装置上のチェックポイント対象テーブル411
の内容をCKPTF410へ格納する。チェックポイントダンプ
格納中にCKPTF410に障害が発生しても回復が行える様に
CKPTF410は世代管理を行う。システムの障害発生後の回
復時には、最新世代のCKPTF410上の情報と、JNLF5に格
納されているチェックポイント時点以降の更新情報を重
畳して行くことにより、テーブルが回復できる。チェッ
クポイントダンプを定期的に取得することは、障害発生
後の回復時に必要となるジャーナル情報を限定すること
になり、回復時に入力するジャーナル量の削減と回復時
間の短縮化の効果がある。
チェックポイントダンプ取得は、各サブシステムで行
うが、この際、当該サブシステムを使用する業務処理を
停止させない。このため、更新中のテーブルをチェック
ポイントダンプとして取得する可能性がある。更新中の
テーブル情報をチェックポイントダンプに取得しても、
該更新に対応するジャーナルがチェックポイント時点以
降に取得されていれば、チェックポイントダンプ取得完
了後は、チェックポイント時点以前の履歴形ジャーナル
情報を必要としない。
テーブルの更新と対応するジャーナル取得が完了する
タイミング410eは、トランザクションごとにまちまちで
あり同期していない。またチェックポイントダンプ取得
にも有限の時間がかかる。このため、チェックポイント
ダンプは、第7図に示すようにチェックポイント時点41
0aとチェックポイントダンプ取得開始時点410b,取得終
了時点410c、及びチェックポイントダンプ有効時点410d
の4つの時点を分けて取得する。チェックポイントダン
プを取得する必要が発生すると、まずチェックポイント
時点410aの宣言を行う。該時点で更新中のテーブル情報
に対応するジャーナルは、チェックポイント時点410a以
前に取得されている可能性があるのでまだチェックポイ
ントダンプ取得を開始できない。そこで、チェックポイ
ント時点410aで更新中の処理がすべて更新処理を完了し
た時点まで待ち、完了後チェックポイントダンプ取得開
始を行う。チェックポイントダンプ取得が完了しても、
まだ更新に対応するジャーナルが出力されていない可能
性があるので、チェックポイントダンプ取得終了時点41
0cに更新中の処理に対応するジャーナルがすべて出力さ
れた時点まで待ち、出力完了後、チェックポイントダン
プ有効時点410dとする。チェックポイントダンプ有効時
点410dを経過する以前に障害が発生した場合には、当該
チェックポイントダンプは使用せず、一世代前のチェッ
クポイントダンプによる回復を行う。
本実施例では、第8図に示す流れに従ってチェックポ
イントダンプを取得する。まず、コントローラ1は、一
定のジャーナル出力件数に到達するとチェックポイント
ダンプ取得タスク412を起動する。起動されたタスク412
は、チェックポイント時点の宣言を行い、この時点での
ジャーナル通番をコントローラの管理する仮想記憶上に
チェックポイント時点ジャーナル通番815として記憶し
チェックポイント取得開始待ちとなる。チェックポイン
ト取得開始が可能となると、各サブシステムにチェック
ポイントダンプ取得指示を行う。各サブシステムは、チ
ェックポイントダンプ取得指示に従い、チェックポイン
トダンプを各サブシステムのCKPTF410に取得する。取得
が完了するとコントローラに取得完了報告を行う。コン
トローラは、各サブシステムの取得完了報告を確認した
後、チェックポイントダンプ有効化待ちとなる。チェッ
クポイントダンプ有効化か可能となると、当該CKPTF410
とSYSSF9に有効ビットを記録して、チェックポイントダ
ンプ取得を終了し、次の取得タイミングまで待ちとな
る。
ここで、チェックポイントダンプ取得開始待ちと、チ
ェックポイントダンプ有効化待ちは、同一の方式を用い
る。本方式を第9図を用いて説明する。
第8a図において、各トランザクションは、チェックポ
イント対象となっているテーブル更新を含む機能を使用
する際には、トランザクション管理テーブル7上の影響
フラグ711をオンにし、機能使用終了時に影響フラグ711
及び実行監視フラグ712をオフにする。本フラグ操作
は、処理ルーチンへ渡る際の共通ルーチンにて行う。な
お共通ルーチンを経由しない場合、各サブシステムの処
理で開始,終了を宣言する方式をとればよい。
第10図においてコントローラ内のチェックポイントダ
ンプ取得タスク412でチェックポイントダンプ開始待ち
又は、有効化待ちを開始するには、トランザクション管
理テーブル7上の全トランザクションについて影響フラ
グ711がオンであれば実行監視フラグ712をオンにする。
その後タイマで待ち、起動されるたびにすべての実行監
視フラグ712がオフになっているかどうかチェックす
る。すべての実行監視フラグ712がオフになれば、待ち
を開始する時点にテーブル更新を含む処理がすべて終了
した事になる。
チェックポイントダンプ出力時には、後述するジャー
ナルポインタ情報の退避や、資源管理テーブルの論理情
報の退避を行い、チェックポイント時点以前のジャーナ
ル情報や資源管理情報がなくても、回復ができるように
する。また、トランザクション管理テーブルは、チェッ
クポイントダンプ対象テーブルとなっており、回復がで
きる。資源管理テーブルの論理情報の退避は、第11図に
示す資源管理論理情報テーブル750という形式にして行
う。該論理情報テーブルは資源管理テーブル中の全資源
に対し、該資源を保持しているトランザクションのトラ
ンザクションID701を第3図に示す資源管理テーブル6
の資源ノード620から資源排他ノードへのリンク622をた
どることにより資源排他ノード630を求め資源名751とト
ランザクションID752をペアにして格納することで作成
する。この時出力すべきペアは、チェックポイント時点
以前に資源保持情報をジャーナルに出力したものであ
り、チェックポイント時点以降の資源保持情報は、後述
する様にジャーナルから回復する。
ジャーナルを外部記憶装置上のJNLF5に出力する際、
出力するバッファ上に存在する全てのトランザクション
形ジャーナルについて、第12図に示す形式のジャーナル
ポインタ720を作成しトランザクション管理テーブルの
該当トランザクションエントリに退避する。該ポインタ
720は、ジャーナルの通番721とJNLF5のファイル名722及
びファイルの先頭からの相対ブロック番号723から成
り、該ポインタを用いることにより、必要な時点に当該
トランザクションで出力したジャーナルを得ることがで
きる。障害発生時、コントローラ1がダウンしていなけ
れば、トランザクション回復時には、該ジャーナルポイ
ンタでダイレクトにジャーナルを得ることができる。
チェックポイントダンプ出力時には、チェックポイン
トダンプ有効時点410dの時点を存在するトランザクショ
ンに関して、有効化に先だち、ジャーナルポインタ720
を用いてジャーナルをJNLF5から読み出し、トランザク
ションリカバリファイル430へ退避しておく。退避すべ
きか否かは、トランザクションテーブル7中のジャーナ
ルポインタ720にあるジャーナル通番721を参照し、チェ
ックポイント時点410aのジャーナル通番815より以前の
番号であれば、退避を行い、以降であればチェックポイ
ント時点以降のJNLF5中に存在するジャーナルなので退
避しない。
本実施例では、トランザクションの開始に先立ち、各
トランザクションにTRRF430の一定領域を割り当てる。
退避を行う場合、一世代前のチェックポイント時点に
退避したTRRF430中の情報を行うことのないように、ト
ランザクションテーブル7中のTRRF最終ポインタ730か
ら追加書きを行う。ここでTRRF最終ポインタ730は、ト
ランザクション発生時に該トランザクションに割り当て
たTRRF中の領域の先頭を指し、以降ジャーナル退避を行
う都度更新して、常にTRRF中の該トランザクションに割
り当てた領域の最終を指すポインタである。
ジャーナル情報をTRRF430に退避することにより、チ
ェックポイントダンプ取得以降は、チェックポイント時
点以前から長期化しているトランザクションの回復にも
チェックポイント時点以前のジャーナルは不要となる。
TRRF430は、トランザクション単位のエントリに整理さ
れているので、トランザクション単位の回復時にも該TR
RF430とチェックポイント時点以降のジャーナルで回復
に必要なデータが容易にそろう。
さらに、トランザクション形ジャーナル出力時には、
資源保持情報も同時に出力する。これは、トランザクシ
ョン形ジャーナルを出力する際に、当該トランザクショ
ンの保有している資源を、資源管理テーブル6のトラン
ザクションノード610から資源排他ノード630をたどるこ
とにより求め、該資源保持情報を第11図に示す資源管理
論理情報のエントリと同様の形式でトランザクション形
ジャーナルに付加して出力することで行う。
障害発生後の回復時には、CKPTF410中のチェックポイ
ントダンプとして保持されていた資源管理論理情報テー
ブルとトランザクション形ジャーナルと共にJNLF5に出
力した資源保持情報から資源確保処理を返すことにより
資源管理テーブルが回復できる。このため、データベー
スを全面閉塞すなわち、データベースに対するアクセス
を全面禁止するのではなく限定した範囲(使用していた
部分だけ)を閉塞すれば済み、一部サブシステムがダウ
ンしていたり、一部トランザクションの決着がつかない
場合にも、オンラインシステムを立上げることができ
る。
複合サブシステム形オンラインシステム全体が障害と
なった時の回復を全面回復と呼び、特定のサブシステム
だけが障害となった際の回復をサブシステム回復と呼
ぶ。以下、複合サブシステム形オンラインシステムの全
面回復,サブシステム回復について説明する。
第1に、複合サブシステム形オンラインシステムの全
面回復の流れを第13図から第17図を用いて説明する。全
面回復では、まずコントローラ1の機能を回復する。そ
の後各サブシステムの回復を行うが一部のサブシステム
機能が回復できなくても当該機能を縮退したままシステ
ムを再開できる。コントローラ1の機能回復は、まずSY
SSF9からコントローラ用CKPTF410を決め、該CKPTF410か
らコントローラ内のトランザクション管理テーブル7を
回復する。又、資源管理論理情報テーブル750も回復す
る。なお、コントローラ用CKPTF410を読むことにより、
現在の最新チェックポイント時点のジャーナル通番及び
該ジャーナル通番のジャーナルに対するジャーナルポイ
ンタ815が決まる。
次に、第14図に示すように最新チェックポイント時点
のジャーナルポインタ815で指す位置からJNLF5を順に読
む。読み出されたジャーナルは、コントローラの出力し
た履歴形ジャーナルであれば、第15図の流れに従いトラ
ンザクション管理テーブル7や、資源管理論理情報テー
ブル750更新情報として使用し、各テーブルを障害発生
時点の状態に回復して行く。コントローラ以外が出力し
た履歴形ジャーナルは、出力サブシステムのTBLRF420へ
出力する。トランザクション形ジャーナルの場合は、ト
ランザクション管理テーブル7の該当するトランザクシ
ョンエントリのジャーナルポインタ720の領域にジャー
ナルポインタ形式で格納して行く。トランザクション管
理テーブル7の各トランザクションのエントリは、同期
点ジャーナルが見つかれば同期点通過ステータスを同期
点通過フラグ715をオンにすることで記録し終了ジャー
ナルが見つかれば、該エントリを削除する。
分散データベースの分散サーバ側のように同期点準備
ジャーナルが存在する場合、同期点準備ジャーナルが見
つかれば、まず同期点準備通過フラグ717をオンにする
ことで同期点準備状態であることを記録する。同期点ジ
ャーナルが見つかれば、同期点準備通過フラグ717をオ
フにし、同期点通過フラグ715をオンにする。終了ジャ
ーナルが見つかれば、該エントリを削除する。
ジャーナル読み込みが完了した時点では、各サブシス
テムの履歴形ジャーナルは、サブシステムごとのTBLRF4
20に分類されて出力されてある。トランザクション管理
テーブル7は、障害発生時点まで回復されており、障害
発生時点で存在したトランザクションだけが登録されて
ある。この時点でトランザクション管理テーブル7中の
全トランザクションの凍結要フラグをオンにしておく各
トランザクションごとのエントリは、ジャーナルポイン
タ720領域を含めて回復されてある。
資源管理論理情報についても、最新のチェックポイン
ト時点の状態と、それ以降の更新情報がすべてそろって
いる。ジャーナルの読み込みが完了すると、資源管理論
理情報をもとに、資源確保,解放操作をくり返すことに
よって資源管理テーブル6を回復する。さらに回復され
た資源管理テーブルの全排他ノード630について凍結状
態にする。凍結状態になった資源に対して新たに資源確
保を行うと、凍結状態のため、排他ノード630を作るこ
とをせずに、資源確保要求が失敗する。従って資源管理
テーブルを凍結状態にすることで、障害発生時に使用し
ていた資源を一時的に使用禁止状態にすることができ、
新たなトランザクションが発生しても、使用可能な資源
だけで動作できるならば、実行ができ使用不可の資源を
必要とするならばエラーとして扱われ長時間待つことが
ない。すなわち、資源管理テーブル6の回復と凍結が済
んだ時点でコントローラ1としての回復は終了する。こ
の時点で、システムレディのメッセージを出力するがま
だサブシステムが回復されていないので、複合サブシス
テム型オンラインシステム全体としては、動作を開始し
ない。
なお、資源の凍結は、後で述べる決着で失敗した時点
で始めて行う方法もある。この場合、同一資源にアクセ
スするトランザクションは待ちになるが、決着が終るま
で待つだけなので障害の影響を小さくできる。
次に、サブシステムの回復を始める。各サブシステム
は、コントローラ1の指示で並行して回復処理を行う。
各サブシステムの回復は、TBLRF420に格納されている履
歴形ジャーナルをもとに、サブシステム内の回復対象テ
ーブルを回復することで終る。この時点で、複合サブシ
ステム形オンラインシステムは動作を開始する。なお、
一部のサブシステムが回復に失敗した場合には該サブシ
ステムだけが縮退した状態となる。この時点でも、障害
発生時点で動作中のトランザクションは回復されていな
いが、これらのトランザクションはすべて凍結要となっ
ており、後で述べるトランザクションの凍結決着処理に
て回復する。新しく発生したトランザクションは、その
まま実行される。
各サブシステムへの回復指示を出した後、サブシステ
ムにおける回復と並行してコントローラ1では、トラン
ザクション管理テーブル7に存在する凍結要フラグがオ
ンとなっている全トランザクションがアクセスしていた
資源(一般にはデータベース)をすべて回復する。そこ
で、コントローラ1は、トランザクションの回復のため
の処理を開始する。これを凍結決着処理と呼ぶ。凍結決
着処理の流れを第16図に示す。
凍結決着処理では、まず、凍結要となっているトラン
ザクションの凍結処理を行う。ここで、トランザクショ
ンを凍結状態にするとは、該トランザクションを終了さ
せずに一時的に停止させることであり、このために回復
に必要な情報を保存する。
トランザクションの凍結処理では、第16図に示すよう
にトランザクション管理テーブル7のジャーナルポイン
タ720をもとに、該トランザクションのもとで出力した
ジャーナルをJNLF5から読み出す。読み出したジャーナ
ルは、チェックポイントダンプ出力時と同様に、トラン
ザクション管理テーブル7のTRRF最終ポインタ730の位
置から追加書きでTRRF430に書き込んで行く。該トラン
ザクションのジャーナルポインタ720に関して、すべて
のジャーナルをTRRF430へ退避した時点で、該トランザ
クションの凍結処理が完了し、凍結要フラグをオフと
し、凍結フラグをオンとする。トランザクションが凍結
されると、該トランザクションの回復に必要となるすべ
てのジャーナルがTRRF430中に格納されたことになる。
これは、最新のチェックポイント時点以前に出力された
該トランザクションのジャーナルは、チェックポイント
時点にTRRF430に退避済であり、チェックポイント時点
以降のジャーナルは、ジャーナルポインタ720を用いて
凍結処理でTRRF430に退避したためである。
凍結状態になったトランザクションすなわち、凍結フ
ラグがオンとなっているトランザクションは、コントロ
ーラ1が定期的にトランザクション管理テーブル7から
選択し、該トランザクションの保持する資源を回復す
る。資源の回復は、同期点ジャーナルの有無により決め
る。同期点がジャーナルが存在すれば、すなわち同期点
通過フラグ715がオンであれば、ジャーナルをもとに更
新を完結させる。これをロールフォワードと呼ぶ。同期
点ジャーナルが存在しなければ、すなわち同期点通過フ
ラグ715がオフであれば、トランザクションの更新を無
効とし、更新済の部分はジャーナルをもとに以前の状態
に戻す。これをロールバックと呼ぶ。ロールフォワード
とロールバック処理を合わせて資源の決着、またはトラ
ンザクションの決着と呼ぶ。
決着処理は、第16図に示す様に、まず、トランザクシ
ョン管理テーブル7中の凍結フラグ716がオンとなって
いるトランザクションを一つ選択し、該トランザクショ
ンの状態をトランザクション管理テーブル7中の同期点
通過フラグ715でチェックする。同期点を通過していれ
ば、ロールフォワード処理を行い、同期点通過以前であ
れば、ロールバック処理を行う。ロールフォワード,ロ
ールバックは、該トランザクションの使用BE3をトラン
ザクション管理テーブル7の使用BE703から決め、全使
用BEに対してロールフォワード,ロールバックを指示す
ることで行う。指示を行うには、事前にTRRF430を読
み、該トランザクションの該BEに関連するジャーナルを
テーブルとして仮想記憶上に作成し、該BEに引き渡す。
BE3は、BE自身の回復が済みBE機能が回復していれば、
渡されたジャーナルをもとに資源の決着を行う。回復が
済めば、凍結されていた該資源の排他ノードを解放し、
資源を解放し、凍結フラグ716をオフにする。BE自身の
回復が完了していない、若しくは回復できない場合は、
該トランザクションを凍結したままとする。従って、障
害回復のできないBEによって回復処理が終了しない場合
でも、回復できない範囲を該BEのデータベースを更新し
たトランザクション群だけに限定することができる。
一つのトランザクションで複数BEのデータベースを更
新した場合の決着処理を図17に示す。複数BEのデータベ
ースを更新した場合、TRRF430から入力したジャーナル
を渡すべきBE3が障害中であれば、該ジャーナルとばしT
RRF430中の残りのジャーナルについて処理を続ける。TR
RF430中のジャーナル終了後、BE3が障害中のためとばし
たジャーナルがあれば、該BE3を除き処理済となったBE3
についての部分的終了ジャーナルを出力し、決着済BEに
対応する資源を解放し、該トランザクションは凍結状態
のままにしておく。処理済となったBE3については、ト
ランザクション管理テーブル中の使用BEエントリーに処
理済であることを記録しておく。次に決着処理が実行さ
れる場合には、TRRF430から入力されたジャーナルが既
に処理済BE3のジャーナルであれば読みとばす。従っ
て、一つのトランザクションが複数BEのデータベースを
更新した場合の一部BEが障害中の回復処理では、該トラ
ンザクション全体ではなく、該トランザクションの障害
中BEについての回復が保留されるだけであり、回復可能
なBEについての回復処理を完了することによって、回復
できない範囲を最小限にすることができる。
分散データベースの分散サーバ側の場合、該サーブシ
ステムはFE2に相当し、同期点通過以前の状態が更に、
同期点準備状態と同期点準備以前の状態に分けられる。
同期点準備以前の状態であれば、ロールバック処理を行
い、同期点通過後の状態であれば、ロールフォワード処
理を行う。同期点準備状態の場合、分散データベースの
分散サーバから当該トランザクションを発生させた分散
クライアントに問い合わせを行い、分散クライアント側
の対応するトランザクションが同期点通過後であればロ
ールフォワード処理を行い、同期点通過以前であればロ
ールバック処理を行う。分散サーバから問い合わすべき
相手の分散クライアントとトランザクションの識別情報
は、分散サーバ側でのトランザクション発生時点にトラ
ンザクション管理テーブルの発生FEエントリ702に記録
しておく。
自システム内の分散データベースサブシステムが障害
中、又は他プロセッサ側が障害中の場合、同期点準備状
態のトランザクションのみが決着できずに残されるが、
他のトランザクションは、図16,図17の流れに従い決着
する。
一方分散データベースの分散クライアント側の場合該
サブシステムはBE3に相当する。図17の流れにおいて、
コントローラ1は、トランザクション管理テーブル中の
使用BEエントリ703に、分散クライアントが記録されて
いたならば、各BE3へのジャーナル渡し処理時に分散ク
ライアントに対し、ロールバック、又はロールフォワー
ドの指示を出す。分散クライアントは、該指示を分散サ
ーバ側に送る。分散サーバ側では、指示を受けたトラン
ザクションが同期点準備状態であれば、ロールフォワー
ド指示の場合の同期点通過状態にする。ロールバック指
示の場合は同期点準備以前状態にし、各々該当する決着
処理を行う。
なお、分散サーバ側のトランザクションから、更に他
プロセッサの分散データベースに対する要求が出された
場合には、該トランザクションの一つのBEとして該シス
テム上の分散クライアントを使用した場合に対応ずける
だけで同様に扱うことができる。
第2に、サブシステム障害の回復について、第18図を
用いて説明する。
複合サブシステム形オンラインシステムでは、サブシ
ステム内に障害が発生した場合には、該サブシステムだ
けを障害扱いとし、サブシステム回復を行う。サブシス
テム回復方式は、FE2とBE3で異なる。
FE2に障害が発生した時の回復では、該サブシステム
の機能の回復と該サブシステム下で生成した全トランザ
クションを回復する必要がある。サブシステムのみ障害
の場合、コントローラ1の持つトランザクション管理テ
ーブル7はそのまま仮想記憶装置上に存在するので、該
サブシステムの異常終了時に呼び出されるルーチンの中
で、トランザクション管理テーブル7の発生FE領域702
を参照して該サブシステムの発生させた全トランザクシ
ョンについて凍結要フラグ713をオンにしておく。ここ
で、障害となったFE2が発生させたトランザクション
は、トランザクション管理テーブル7中の発生トランザ
クション領域702を参照することで限定している。この
ため、該FEの障害は、該FEの発生させたトランザクショ
ンに限定でき、他FEの発生させたトランザクションに対
しては影響なく業務処理が遂行できる。サブシステムダ
ウンをコントローラが検出するとコントローラ1は、全
面ダウン時と同様に、JNLF5を最新チェックポイント時
点から順次読み出し、該障害発生サブシステムに関連す
る履歴形ジャーナルを該サブシステムのTBLRF420に格納
する。そし後、コントローラ1は該サブシステムを再起
動し、起動後該サブシステムに回復指示を出す。回復指
示を受けたサブシステムは、CKPTF410とTBLRF420をもと
に該サブシステムの機能回復を行う。
該サブシステムの機能回復と並行して、コントローラ
1は、トランザクション管理テーブル7の凍結要フラグ
713がオンの全トランザクションについて、全面回復時
と同様に第16図の流れに従いすべて凍結し、決着を行
う。資源管理テーブル6は、コントローラ1が管理して
いるため、サブシステム障害,回復時にも有効のままな
ので、障害発生FE2は、該サブシステム機能の回復が済
めば、コントローラ1のトランザクション凍結,決着を
待つことなく、新しいトランザクションの処理を開始で
きる。
BE3に障害が発生した時の回復では、該サブシステム
の機能回復と、該BEを使用していたトランザクションの
回復を行う必要がある。FE2障害時同様、トランザクシ
ョン管理テーブルは仮想記憶装置上に存在するので、該
BE3の異常終了時に呼び出されるルーチンの中で、トラ
ンザクション管理テーブル7の使用BE領域703領域を参
照して、該BEを使用していた全トランザクションについ
て、ロールバック要フラグ714をオンにしておく。ここ
で、障害発生となったBE3を使用したトランザクション
をトランザクション管理テーブル7の使用BE領域703で
限定しているため、該BEの障害は、該BEを実際に使用し
ているトランザクションに限定でき、他BEだけを使用し
ているトランザクションに対しては、影響なく業務処理
が遂行できる。
さらに、該BE3の管理していた資源は、該BE3の障害回
復が終了するまで解放できないので資源凍結を行う必要
がある。資源の凍結は、該BE2の異常終了時に呼び出さ
れるルーチンの中で資源管理テーブル6中の該BE3に継
がる全資源ノード630について行う。資源凍結は、障害
発生時には単に凍結要としておき、BE回復,トランザク
ション決着が一通り済むまで遅延させる方式も考えられ
る。これにより、同一資源を要求している他トランザク
ションはエラーリターンではなく、一時的に待ちを行
い、該資源を保持しているトランザクションが正常に決
着されれば、障害はなかったものとして処理が継続でき
ることになる。
サブシステムダウンをコントローラ1が検出すると、
コントローラ1は、FE2障害時と同様にJNLF5からTBLRF4
20を作成する。その後、コントローラ1は、該BE3を再
起動し、起動後、障害発生BE3に回復指示を行う。回復
指示を受けたBEは、CKPTF410とTBLRF420をもとに該BEの
機能回復を行う。ただし、BEの種類によっては、CKPTF4
10やTBLRF420を必要としない。この場合は、コントロー
ラ1は、JNLF5を読まずに単に回復指示を出し、該BEは
機能回復を行う。
該サブシステムの機能回復を待ち、コントローラ1
は、トランザクション管理テーブル7のロールバック要
フラグ714がオンの全トランザクションについて、全面
回復時と同様に第16図の流れに従いすべて凍結し、ロー
ルバック方向の決着を行う。
以上サブシステムの障害回復で示した様にトランザク
ション管理テーブル7の発生FE領域702及び使用BE領域7
03を用いてサブシステム障害の影響を特定のトランザク
ションに限定している。本機構のため、一部サブシステ
ム障害時でも他のサブシステムの処理は正常に遂行でき
ることとなり、複合サブシステム形オンラインシステム
の運転を続行できることになる。また、RF4を持つこと
で、障害となったサブシステムは、他サブシステムの処
理が先に進む事に影響されずに遅延しながらも回復し、
他サブシステムに影響することなく合流することができ
る。
第3に、業務処理プログラムに障害が発生し、実行中
のトランザクションが異常終了した場合には、異常終了
時に呼び出されるルーチンにて、該トランザクションの
凍結要フラグ713をオンにしておく。これにより、全面
グウン時と同時にコントローラ1が該トランザクション
の凍結,決着を行う。業務処理プログラムは、FE2によ
って再度起動されることで、機能を回復する。
【図面の簡単な説明】
第1図は複合サブシステム形オンラインシステムの全体
構成図、第2図はリカバリファイルの構成図、第3図は
資源管理テーブルの構成図、第4図はトランザクション
管理テーブルの構成図、第5図はシステムステータステ
ーブルの構成図、第6図はチェックポイントダンプ取得
の概念図、第7図はチェックポイントダンプ取得のタイ
ミング図、第8図はチェックポイントダンプ取得の流れ
図、第9図はチェックポイントダンプ有効化方式の流れ
図、第10図はチェックポイントダンプ取得における待ち
処理の流れ図、第11図は資源管理論理情報テーブルの構
成図、第12図はジャーナルポインタの概念及び構成図、
第13図は全面回復の流れ図、第14図はジャーナル回復の
流れ図、第15図はコントローラのジャーナル回復の流れ
図、第16図はトランザクション凍結/決着の流れ図、第
17図は一つのトランザクションが複数BE更新時の決着の
流れ図、第18図はサブシステム障害回復の流れ図であ
る。 1…複合サブシステムコントローラ、2…フロントエン
ドサブシステム、3…バックエンドサブシステム、4…
リカバリファイル、5…ジャーナルファイル、6…資源
管理テーブル、7…トランザクション管理テーブル、8
…システムステータステーブル、9…システムステータ
スファイル、10…オンライン端末、11…データベース、
410…チェックポイントファイル、411…チェックポイン
ト対象テーブル、410a…チェックポイント時点、410b…
チェックポイント取得開始、410c…チェックポイント取
得終了、410d…チェックポイント有効時点、410e…テー
ブル更新と対応するジャーナル取得が完了するタイミン
グ、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領域、810…システムの状態領域、8
15…チェックポイント時点のジャーナルポインタ領域、
820…サブシステムの状態領域、7011…エントリ番号、7
012…通番。

Claims (2)

    【特許請求の範囲】
  1. 【請求項1】複数のサブシステムで構成され、1トラン
    ザクションに対し、ジャーナル情報を取得しながら、複
    数のサブシステムが各々のサブシステムに対応する分散
    データベースを独立にアクセスする複合サブシステム形
    オンラインシステムであって、あるサブシステムに障害
    が発生した場合、当該障害サブシステムはすべてのトラ
    ンザクションを拒否する状態にし、オンラインシステム
    の運転を続行する手段と、当該障害サブシステム及び対
    応する分散データベースを前記ジャーナル情報を用いて
    自動的に回復する手段と、前記すべてのトランザクショ
    ンの拒否状態を解除して、前記オンラインシステムに復
    帰する手段とを具備することを特徴とする複合サブシス
    テム形オンラインシステム。
  2. 【請求項2】請求項1において、退避ファイルを設け、
    あるサブシステムに障害が発生した場合、前記ジャーナ
    ル情報から当該障害サブシステム及び対応する分散デー
    タベースの回復に必要な情報を抽出し、当該障害サブシ
    ステム及び関連トランザクションに対応する前記退避フ
    ァイルに退避する手段と、当該障害サブシステム及び対
    応する分散データベースを前記退避ファイルの情報に基
    づき回復する手段とを具備することを特徴とする複合サ
    ブシステム形オンラインシステム。
JP62095103A 1987-04-20 1987-04-20 複合サブシステム形オンラインシステム Expired - Lifetime JPH0833859B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP62095103A JPH0833859B2 (ja) 1987-04-20 1987-04-20 複合サブシステム形オンラインシステム
US07/184,075 US5065311A (en) 1987-04-20 1988-04-20 Distributed data base system of composite subsystem type, and method fault recovery for the system
US07/701,816 US5333314A (en) 1987-04-20 1991-05-17 Distributed data base system of composite subsystem type, and method of fault recovery for the system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP62095103A JPH0833859B2 (ja) 1987-04-20 1987-04-20 複合サブシステム形オンラインシステム

Publications (2)

Publication Number Publication Date
JPS63261437A JPS63261437A (ja) 1988-10-28
JPH0833859B2 true JPH0833859B2 (ja) 1996-03-29

Family

ID=14128536

Family Applications (1)

Application Number Title Priority Date Filing Date
JP62095103A Expired - Lifetime JPH0833859B2 (ja) 1987-04-20 1987-04-20 複合サブシステム形オンラインシステム

Country Status (1)

Country Link
JP (1) JPH0833859B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04230553A (ja) * 1991-01-07 1992-08-19 Nec Corp ファイル転送誤り回復方法
JP3425156B2 (ja) * 1991-06-26 2003-07-07 株式会社日立製作所 処理履歴管理方法および計算機システム
US7711712B2 (en) * 2007-03-12 2010-05-04 Hitachi, Ltd. System and method for managing consistency among volumes based on application information

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
「情報処理学会論文誌」Vol.26,No6(1985−11)P.1023−1032

Also Published As

Publication number Publication date
JPS63261437A (ja) 1988-10-28

Similar Documents

Publication Publication Date Title
US5065311A (en) Distributed data base system of composite subsystem type, and method fault recovery for the system
JP3790589B2 (ja) 分散データベーストランザクションのコミットメント方法
US9940067B2 (en) Performing a data write on a storage device
US7499954B2 (en) Consistent reintegration of a failed primary instance
US5778388A (en) Method of processing a synchronization point in a database management system to assure a database version using update logs from accumulated transactions
US7543181B2 (en) Recovery from failures within data processing systems
US5884328A (en) System and method for sychronizing a large database and its replica
JP2501152B2 (ja) アンドゥ―ログ使用の最大利用のための方法及び装置
JP2708386B2 (ja) 同時更新及び複写手順を通して重複データベースを回復させる方法及び装置
JPH07175700A (ja) データベース管理方式
US20050283504A1 (en) Disaster recovery system suitable for database system
JPS633341B2 (ja)
JPH08110895A (ja) 分散システムに使用されるノード装置及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法
CN110825763A (zh) 基于共享存储的MySQL数据库高可用系统及其高可用方法
Borr Robustness to Crash in a Distributed Database: A Non Shared-memory Multi-Processor Approach.
JP4095139B2 (ja) コンピュータシステムおよびファイル管理方法
JPH0833859B2 (ja) 複合サブシステム形オンラインシステム
JPH0827753B2 (ja) オンラインシステムのチェックポイントダンプ取得方法
JPH0816881B2 (ja) データベース更新方法
JP2569063B2 (ja) 複合サブシステム形オンラインシステムの障害回復方法
JP2609625B2 (ja) 複合サブシステム型分散データベースシステムの障害回復方法
JPH083810B2 (ja) 資源の共用排他制御方法
JP4139642B2 (ja) データベース管理方法およびシステム
JP2002082826A (ja) データベースシステム
JP3290182B2 (ja) 共用環境におけるデータ・セットのバックアップ方法及び装置

Legal Events

Date Code Title Description
EXPY Cancellation because of completion of term
FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080329

Year of fee payment: 12