クラッシュ・リカバリー

データベースまたはデータベース・マネージャーに障害が発生すると、 データベースは不整合な状態のままとなる可能性があります。 障害発生時に 未完了であったトランザクションによる変更が、データベースの内容に含まれている 可能性があります。 また、障害前に完了したトランザクションによって 行われた変更で、まだディスクにフラッシュされていなかったものが、 データベースから失われている可能性もあります。 クラッシュ・リカバリー操作を実行して、 部分的にしか完了しなかったトランザクションをロールバックし、 メモリーにしか書き込まれていなかった完了トランザクションによる変更を ディスクに書き込む必要があります。

データベース・マネージャーにクラッシュ・リカバリーを自動的に実行させるには、 データベース構成パラメーター (autorestart) を ON に設定することによって、自動再始動を有効にします。 (これはデフォルト値です。) 自動再始動を動作したくない場合、 autorestart データベース構成パラメーターを「OFF」に設定してください。 結果として、データベース障害の発生時に RESTART DATABASE コマンドを発行する必要があります。 クラッシュが発生する前にデータベース入出力が中断された場合は、クラッシュ・リカバリーを続行するために、 RESTART DATABASE コマンドの WRITE RESUME オプションを指定する必要があります。

IBM® Db2 pureScale® Featureを使用する場合、注意すべきクラッシュ・リカバリーには、 メンバー・クラッシュ・リカバリー と グループ・クラッシュ・リカバリーの 2 つのタイプがあります。 メンバー・クラッシュ・リカバリーとは、 メンバー に障害が発生した後、単一の メンバー のログ・ストリームを使用してデータベースの一部をリカバリーするプロセスのことです。 メンバー・クラッシュ・リカバリー (通常、メンバー再始動の一部として自動的に開始される) はオンライン操作です。これは、他の メンバー が引き続きデータベースにアクセスできることを意味します。 複数の メンバー が同時に メンバー ・クラッシュ・リカバリーを行うことができます。 グループ・クラッシュ・リカバリーは、障害の後に複数のメンバーのログ・ストリームを使用してデータベースをリカバリーするプロセスです。これにより、実行可能な クラスター・キャッシング・ファシリティー がクラスター内に残りません。 グループ・クラッシュ・リカバリーも通常は自動的に開始され (グループ再始動の一環として)、 Db2 pureScale 環境の外部での Db2 クラッシュ・リカバリー操作の場合と同様に、進行中のデータベースにはアクセスできません。

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

クラッシュ・リカバリー中の接続を可能にするようにデータベースを構成した場合は、クラッシュ・リカバリーの進行中にデータベースに接続できる可能性があります。 ロールバックが進行中の表、索引、またはオブジェクトは、排他モードまたは超排他モードでロックされます。 詳しくは、 クラッシュ・リカバリーまたは HADR テークオーバーのバックワード・フェーズ中のデータベース・アクセス可能性を参照してください。