このドキュメントでは、データベースのリカバリと再スタートの設計概念について説明します。 リカバリと再スタートの設計を適切に行うことはシステム設計の重要な部分です。特にデータベース環境では重要です。 Adabas はリカバリおよび再スタートの両機能を備えていますが、これらの機能は別々に考慮しなければなりません。
このドキュメントでは、次のトピックについて説明します。
データベースのリカバリは、最優先されなければなりません。データベーストランザクションが失敗した場合またはトランザクションをキャンセルしなければならない場合は、トランザクションの実効性がなくなるように、データベースをトランザクション開始以前の状態に復元しなければなりません。
標準の Adabas システムは、データベースの保全性を保証するために、トランザクションロジック（ET ロジックと呼ぶ）、拡張チェックポイント／ロギング機能、およびトランザクションを戻すバックアウト処理を備えています。
システム障害後のデータベースの再スタートは、障害が発生する以前にセーブされていたレベルから障害が発生したステップまでの再構築を意味します。また、可能であれば中断したオペレーションを正常に終了し、通常のデータベースオペレーションを継続させることです。 Adabas には、データベースをリカバリするためのリカバリジョブストリームを再構築するリカバリエイドがあります。
リカバリ機能は、当然の機能として特に明示されないことがよくあります。 つまり、何が起こってもシステムがリカバリを行い再スタートできると皆が仮定しています。 しかし、システムのいろいろなユーザーが必要とするリカバリレベルについて決定すべき事柄が存在します。 リカバリ機能は、DBA がイニシアティブをとり、必要な事柄を設定すべき分野です。 まず、システムの各潜在ユーザーにリカバリ／再スタート要求について質問する必要があります。 考慮する必要がある最も重要な点としては次のものがあります。
システムなしに、どの位の期間ユーザーが管理できるか。
どの位長く、各フェーズの遅延が許容されるか。
どんな手作業で、ユーザーが入出力チェックを行い、どの位の時間が必要か。
リカバリ／再スタートが発生した場合、データ保全性が維持されていることを確認するためにどのような手順を行う必要があるか。
一旦、リカバリ／再スタートが必要だと認められたら、DBA はこれら要求を満たすのに必要な方法の計画に進むことができます。 ここで述べる手法は上記を行うための基本的な手引として使えるはずです。
システム内のさまざまなユーザーがデータを共有するレベルや程度について決定します。
システムに対するリカバリパラメータを設定します。 このパラメータとしては、予測／実際のブレークダウン率、平均の遅れと影響を受ける項目、およびセキュリティや監査に使用する項目を含みます。
システム内に監査処理を含む場合は、これに関する決定を含みます。
リカバリ設計の要点をまとめたアウトラインを準備します。 このアウトライン内には次の情報を含むようにします。
整合性チェックに関する計画。 データの整合性チェックは、できるだけシステムへのデータ入力時に近い時点で行う必要があります。 レコード入力時と別にデータを中間で更新すると、リカバリはより難しくコスト高になります。
データベースや選択ファイルのダンプ（バックアップコピー）。
ユーザーチェックポイントと Adabas チェックポイント。
ET ロジック、排他ファイル制御、ET データの使用。
監査手順。
リカバリ／再スタートに必要なすべてのリソースが必要なときに使用できるかどうかが判断できるようオペレーション担当者とも相談する必要があります。
最終的なリカバリ設計はドキュメント化し、ユーザー、オペレーション担当者、その他システムに関連する人々に知らせ、再確認しなければなりません。
大体のリカバリ要件が決まったら、次にリカバリ／再スタートを行うための関連機能（Adabas 機能も Adabas 以外の機能も）を選択します。 以下に、リカバリ／再スタートに関連する Adabas 機能について説明します。
大部分のオンライン更新システムや多くのバッチ更新プログラムでは、次のような特性の入力トランザクションストリームを処理します。
トランザクションにより、プログラムが検索、追加、更新、削除を行うレコードの数は少数です。 例えば、注文入力プログラムでは、各注文に対して顧客レコードと製品レコードを検索し、データベースにその注文と注文項目データを追加し、製品レコードの注文フィールドの量を更新します。
プログラムは、トランザクション開始から終了までに使用するレコードの排他制御が必要ですが、トランザクションが完了したら、レコードを解放し、他ユーザーが更新したり削除したりできるようにします。
トランザクションが未完了の状態になってはなりません。すなわち、2 レコードを更新する場合は、2 レコードを両方とも更新するか、いずれも更新されないかのどちらかでなければなりません。
Adabas ET コマンドを使用すると、次のことが可能です。
完了したトランザクションによる追加、更新、削除処理がすべてデータベースに適用されるようになります。
全体的または部分的なシステム障害により中断されたトランザクションについては、すべての更新処理をデータベースから取り除かれます。
プログラムで Adabas システムファイルに 2000 バイト以下のユーザー定義再スタートデータ（ET データ）を格納できます。 この ET データは、Adabas の OP または RE コマンドで再スタート時に取り出すことができます。 このため、プログラムや TP 端末ユーザーはどこから再開するかを判断できます。
トランザクション処理中にホールド状態にあった全レコードを解放します。
Adabas CL コマンドでユーザーの最新 ET データを更新できます（例えばユーザー定義のジョブ完了フラグの設定）。 詳細については、「ユーザー再スタートデータ」を参照してください。
Adabas の OP コマンドを使用して、ユーザー再スタート後、または新規ユーザー／Adabas セッション開始時、ET データを読むことができます。 OP コマンドには、ユーザー ID が必要です。このユーザー ID を基に、Adabas はユーザー ET データを格納します。また、ET データを読み込むためのコマンドオプションも必要です。
現在または指定のユーザーの ET データの読み込み、例えばオンライン更新操作の監視時には RE コマンドも使用できます。
自動バックアウトルーチンは、すべての Adabas セッションの開始時に起動されます。 セッションが異常終了した場合、オートバックルーチンによって、中断されたすべてのトランザクションによる処理が、最新の ET までデータベースから削除されます。 個々のトランザクションが中断された場合は、トランザクションが行った更新をすべてデータベースから自動的に除きます。 また、アプリケーションプログラムでも Adabas の BT コマンドを使用して現在のトランザクションの処理をバックアウトするように指定できます。
トランザクションリカバリ機能はデータベースの内容を回復するだけです。 TP メッセージシーケンスの回復、非 Adabas ファイルの再ポジショニング、あるいはユーザープログラムステータスの退避は行いません。
特定ユーザーのトランザクションによる処理だけをバックアウトすることはできません。このユーザーが追加または更新したレコードに対して別ユーザーがトランザクションを実行した可能性があるからです。
次の理由から、ある種のプログラムでは ET コマンドの使用は効果的ではありません。
各トランザクションの実行中、プログラムが多数のレコードをホールドしなければならない場合。 このことは、デッドロックの可能性を増加させ（Adabas では 2 ユーザーの一方のトランザクションをバックアウトすることでデッドロックを自動的に解消しますが、大量のトランザクションを再処理しなければならなくなります）、Adabas ホールドキューをかなり大きくとる必要があります。
複合検索により見つかるレコードが多く長いリストをプログラムで処理する場合、このリストの途中から再スタートするのは困難です。
上記のようなプログラムでは、必要に応じて Adabas チェックポイントコマンド（C1）を使用して、プログラムが更新中である 1 つ以上のファイルのリストア可能地点を設定できます。
ユーザーは 1 つ以上の Adabas ファイルの排他更新制御を要求できます。 OP コマンドで排他制御を要求し、他ユーザーがファイルを現在更新中でなければ、排他制御を行えます。 あるユーザーに排他制御が与えられると、他ユーザーはそのファイルを読み込むことはできますが、更新することはできません。 論理順処理か、あるいは検索の結果、一連の多数のレコードを読んだり更新したりするプログラムでは、他ユーザーからの更新を防ぐために排他制御を使用できます。 こうすれば、各レコードをホールド状態にする必要がなくなります。
排他制御ユーザーは ET コマンドを使用しても使用しなくてもかまいません。 ET コマンドを使用しないときは、C1 コマンドを発行し、チェックポイントを取得することができます。
システムまたはプログラム障害の場合、排他制御下で更新中のファイル（群）は、ADARES ユーティリティの BACKOUT 機能を使用してリストアできます。 このユーティリティは自動的に呼ばれるのではなく、入力として Adabas データプロテクションログが必要です。 ユーザーが ET コマンドを使用していれば、この処理は不要です（「トランザクションリカバリ」参照）。
排他ファイル制御には、次のような制限があります。
最終チェックポイントへのリカバリは自動的には行われず、障害が起きたときのデータプロテクションログがリカバリ処理に必要です。 ただし、ユーザーが ET コマンドを発行したときは、これは適用されません。
システム障害後の再スタート状態で、Adabas は、システム中断時排他制御の下で更新されていたファイルを他ユーザーが更新するのをチェックせず、また回避もしません。
Adabas の ET および CL コマンドでは、オプションとして Adabas システムファイルに 2000 バイトまでのユーザーデータを格納できます。 ユーザーごとにユーザーデータを 1 レコード保持します。 ユーザーが新規にユーザーデータを書き読むたびに、このレコードは書き換えられます。 OP コマンドでユーザー ID を指定したときだけ、セッション間でデータが保持されます。
ユーザーデータの第 1 の目的は、プログラムが自身で再スタートが可能となり、リカバリ手順が適切に行われたかをチェックできることです。 ユーザーデータとして有効な情報タイプは、次のものです。
プログラムの実行日時および最終更新時刻。 これにより、プログラムは端末ユーザー、コンソールオペレータまたはプリンタに適切なメッセージを送ることができ、ユーザーやオペレータはリカバリ／再スタート処理が正しく行われたかをチェックできます。 特に、知らずに夜中に重大な障害が起きた場合、端末ユーザーはどの業務から再実行すべきかがわかります。
入力データ収集日
バッチ番号。 端末から再入力しなければならない業務が何であるかを管理者は把握できます。
識別データ。 このデータを使用して、再スタート位置をプログラムで判別できます。 例えば、論理順スキャンを行うプログラムでは再開するキー値が必要です。
トランザクション番号／入力レコード位置。 これにより、端末ユーザーやバッチプログラムが開始位置を決める労力を最小にできます。 各トランザクションに Adabas はトランザクションシーケンス番号を返すが、次の理由からユーザーもシーケンス番号を保持したい場合があります。
再スタート後、Adabas シーケンス番号がリセットされるとき。
各トランザクションの処理内容が複雑で、Adabas トランザクションシーケンス番号と次の入力レコードやドキュメントの位置との関係が単純ではないとき。
入力エラーによりプログラムがトランザクションをバックアウトするとき。トランザクションを直ちに再入力するか（単純なキーイングミスなど）、または後で修正するために拒否するか（入力ドキュメントやレコードの基本的なエラーが発生した場合）を Adabas は判断できません。
その他の記述データや中間データ。例えば、繰越しトータル、レポートのページ番号や見出し、実行統計など。
ジョブ／バッチ完了フラグ。 すべての処理が完了後でオペレータやユーザーに知らされる前にシステムがダウンする場合もあります。 この場合、オペレータがプログラムを再スタートしても、プログラムでは入力の終りまで実行せずに、このフラグをチェックできます。 同様なことが端末から入力したドキュメントのバッチに対しても適用されます。
最終のジョブ／プログラム名。 いくつかのプログラムが一定の順序でデータベースを更新しなければならないとき、同一のユーザー ID を使用し、順序が正しく保たれているかをチェックするためにユーザーデータを使用できます。
OP コマンドまたは RE コマンドを使用して自分のユーザーデータを読み込むことができます。 別ユーザーのユーザーデータは、RE コマンドを使用し、別ユーザーの ID を指定して読み込むことができます。 全ユーザーのユーザーデータは、コマンドオプション付きで RE コマンドを使用すれば論理順に読み取ることができます。この場合にはユーザー ID を指定してはなりません。
