クラッシュ・リカバリー

データベースに対するトランザクション (つまり作業単位) は、 予期しない割り込みを受けることがあります。 例えば、作業単位の一部となるすべての変更内容が完了しコミットされる前に、 障害が発生すると、データベースは矛盾した、または使用不能な状態のままになっています。 クラッシュ・リカバリー とは、 データベースを整合した使用可能な状態に戻すプロセスのことです。これは、未完了のトランザクションをロールバックし、 破損発生時にメモリーに残っていたコミット済みトランザクションを完了することによって行われます (図 1)。 データベースが整合性があり使用可能な状態の場合には、これは「整合点」にあることになります。

図 1. 作業単位のロールバック (クラッシュ・リカバリー)

障害発生時に未完了になっている作業単位をデータベース・マネージャーによって自動的にロールバックする場合は、 自動再始動 (autorestart ) データベース構成パラメーターを ON に設定し、 使用可能にしてください。 (これはデフォルト値です。) 自動再始動を動作したくない場合、 autorestart データベース構成パラメーターを「OFF」に設定してください。 結果として、データベース障害の発生時に RESTART DATABASE コマンドを発行する必要があります。 破損が発生する前にデータベース入出力が SUSPEND された場合には、クラッシュ・リカバリーが継続するように、RESTART DATABASE コマンドの WRITE RESUME オプションを指定する必要があります。 データベースが再始動操作を開始すると、管理通知ログに記録されます。

フォワード・リカバリーが使用可能になっている (つまり logarchmeth1 構成パラメーターが OFF にセットされていない) データベースで、 クラッシュ・リカバリーを実行する場合に、個別の表スペースが原因でクラッシュ・リカバリー時にエラーが発生すると、 その表スペースはオフラインになり、修復されるまでアクセスできなくなります。 クラッシュ・リカバリーは続行します。 クラッシュ・リカバリーが完了した時点で、データベースに入っている他の表スペースはアクセス可能であり、 データベースへの接続は確立できます。 しかしながら、オフラインになった表スペースがシステム・カタログを含む表スペースである場合には、 その表スペースは、いずれかの接続が許可される前に修復されなければなりません。