RESTART DATABASE コマンドまたは 自動再始動可能構成パラメーター (autorestart) を使用して破損回復を実行すると、 データベースが矛盾 (つまり使用不能) 状態のままになるのを防ぐことができます。
この部分では、次の点について説明します。
データベース・コマンドおよびアプリケーションは、様々な理由で失敗します。 トランザクション障害 とは、不正なパラメーター、 制限の超過、またはデッドロックによるロールバックなどで引き起こされるデータベース・アクションの障害のことではありません。 むしろ、データベースまたはデータベース・マネージャーを異常終了させ、 データベースの回復処理を要求する重大なエラーまたは状態のことです。 たとえば、マシンの電源障害が含まれます (データベース・マネージャーとデータベース区画がダウンします)。 また、データベースをダウンさせる COMMIT/ROLLBACK 障害も含まれます。この障害が発生すると、 データベース・ログがいっぱいになったときに COMMIT/ROLLBACK レコードを書き出すための追加のログ・ファイルを割り振ることができないために、 データベースはダウンします。
データベースに対してアプリケーションまたはコマンドが実行されている間に、 停電したり、アプリケーションで障害が発生したりすると、 データベースのすべてのアクティビティーが即時停止してしまいます。 1 つまたは複数のアプリケーションまたはコマンドによってこのデータベースのデータに対する処理が開始されているかもしれませんが、 それらの処理は未完了です。 また、コミット済み作業単位には、ディスクにフラッシュされないものもあります。 それらの未完の作業単位があるため、 データベースは矛盾した状態または使用不能な状態になっています。
詳細については、次の項を参照してください。
考慮が必要なのは、障害発生時に未完了になっている作業単位をデータベース・マネージャーによって自動的にロールバックするかどうかという点だけです。 ロールバックする場合は、 自動再始動 (autorestart) 構成パラメーターを "ON" に設定し、 使用可能にしてください。 (これが省略時解釈です。) 自動再始動を使用可能にしていない場合、 データベース障害の発生時に RESTART DATABASE コマンドを発行できるようにしておく必要があります。
注: | 自動再始動を使用可能にしている場合、 データベース障害が発生すると、 再始動が開始されます。 再始動には時間がかかる場合がありますが、 データベースがハングしていたり、 応答していないわけではありません。 データベースが再始動を開始すると、 db2diag.log ファイルに記録されます。 いつでも現在の状況を把握していたい場合や、 データベースが応答していないかどうか心配しないで済むようにしたい場合は、 自動再始動を使用を使用不可にしてください。 |
autorestart データベース構成パラメーターを使って、 自動再始動を使用できます。 このパラメーターの省略時値は、自動再始動が"オン"です。 このパラメーターの詳細は、第 32 章, DB2 の構成を参照してください。
通常、障害データベース区画サーバーと、 同じトランザクションまたはアプリケーションを実行していた他のデータベース区画サーバーとの両方で、 データベース回復処理を実行する必要があります。 障害データベース区画サーバーで行われるデータベースの回復処理は、 破損回復 と呼ばれることがあります。 破損回復は、障害を引き起こした状態が訂正された (たとえば、 電源の再活動化) 後に、障害を引き起こしたデータベース区画サーバーで実行されます。 他の (活動状態のままの) データベース区画サーバーにおけるデータベース回復処理は、 障害が検出された直後に行われます。 データベース区画障害回復 と呼ばれることもあるこの回復処理では、 障害が発生したトランザクションまたはアプリケーションについて、 ユーザーが意識しなくても資源はクリーンアップされます。
詳細については、活動データベース区画サーバーにおける障害回復および 障害データベース区画サーバーにおけるトランザクション障害回復を参照してください。
以下に述べる 2 フェーズ・コミット・プロトコルは、 区分データベース・システムにおける破損回復の概要を説明するためのものです。 2 フェーズ・コミットの詳細については、2 フェーズ・コミット・プロセスについて を参照してください。
区分データベース環境では、 アプリケーションが実行依頼されているデータベース区画サーバーは調整プログラム・ノードで、 最初にアプリケーションの処理を実行するエージェントは調整エージェントです。 調整エージェントは他のデータベース区画サーバーに対し作業を分配し、 どのサーバーがトランザクションに関係するかを追跡します。 アプリケーションがトランザクションの COMMIT を出すと、 調整エージェントは 2 フェーズ・コミット・プロトコルを使用して トランザクションをコミットします。 最初のフェーズでは、調整プログラム・ノードはトランザクションに関係している他のすべてのデータベース区画サーバーに対し PREPARE 要求を配布します。 これを受け取ると、これらのサーバーは次のいずれかで応答します。
いずれかのサーバーが "NO" で応答すると、トランザクションはロールバックされます。 そうでない場合は、調整プログラム・ノードは 2 番目のフェーズを開始します。
2 番目のフェーズでは、調整プログラム・ノードは COMMIT ログ・レコードを書き出した後、 "YES" で応答したすべてのサーバーに対し COMMIT 要求を配布します。 他のすべてのデータベース区画サーバーがコミットを完了すると、 それらのサーバーは調整プログラム・ノードに対し COMMIT の肯定応答を送信します。 関係するすべてのサーバーからすべての COMMIT 肯定応答を調整エージェントが受け取ると、 トランザクションは完了します。 この時点で、調整エージェントは FORGET ログ・レコードを書き出します。
データベース区画サーバーが他のサーバーのダウンを検出すると、 障害データベース区画サーバーと関連するすべての作業は、次のように停止されます。
未確定トランザクションの解決に関する詳細な説明については、 2 フェーズ・コミット時の問題を回復するを参照してください。
障害サーバーに対し要求を送信しようとするプロセス (エージェントまたはデッドロック検出機能) には、 要求が送信できない旨のメッセージが送られます。
プロセッサーが再始動された時点で障害が発生しデータベース・マネージャーが異常終了したら、 RESTART オプションを指定して DB2START を出し、 データベース・マネージャーを再始動することができます。 プロセッサーを再始動できない場合は、DB2START を使用して、 別のプロセッサーでデータベース・マネージャーを再始動させることができます。 詳細については、コマンド解説書 および管理 API 解説書 でそれぞれ START DATABASE MANAGER コマンドおよび API について参照してください。
異常終了が発生すると、サーバー上のデータベース区画は矛盾状態になることがあります (使用不能になります)。 データベース区画を使用可能にするためには、 破損回復を実行してデータベース区画が矛盾のないようにする必要があります。 破損回復は、データベース区画サーバー上で次のように起動することができます。
破損回復ではアクティブ・ログ・ファイルに含まれるログ・レコードを再適用し、 完全に実行されたトランザクションの結果がすべてデータベースに反映されるようにします。 すべての変更項目が再適用されると、未確定のトランザクションを除き、 コミットされていないすべてのトランザクションがローカルにロールバックされます。 区分データベース環境では、2 種類の未確定トランザクションがあります。
破損回復では、以下に述べる処置のいずれかを実行することで、 すべての未確定トランザクションの解決を試みます。 実行されるアクションは、 データベース区画サーバーがアプリケーションの調整プログラム・ノードであったかどうかにより異なります。
破損回復ですべての未確定トランザクションが解決できない場合もあります (たとえば、 一部のデータベース区画サーバーが使用不能の場合)。 この場合、SQL 警告メッセージ SQL1061W が戻されます。 未確定トランザクションが、 ロックおよびアクティブ・ログ・スペースなどの資源を保留する点に注意してください。 アクティブ・ログ・スペースが未確定トランザクションにより使用されたままであるため、 データベースに対し変更を加えることができない場合があることもあります。 このため、破損回復後に未確定トランザクションが残っているかどうかを調べ、 未確定トランザクションを解決しなければならないすべてのデータベース区画サーバーを、 できるだけ早期に回復する必要があります。
未確定トランザクションの解決に必要な 1 つまたは複数のサーバーの回復が間に合わない場合に、 他のサーバーのデータベース区画にアクセスしなければならないときは、 発見的手法の決定を下すことで未確定トランザクションの解決を手作業で行うことができます。 LIST INDOUBT TRANSACTIONS コマンドを使用し、 サーバー上の未確定トランザクションの照会、コミット、 およびロールバックを行うことができます。 詳細については、コマンド解説書 および管理 API 解説書 でそれぞれ LIST INDOUBT TRANSACTIONS コマンドおよび API について参照してください。
注: | 分散トランザクション環境におけるトランザクションでは、
LIST INDOUBT TRANSACTIONS コマンドも使用されます。
2 種類の未確定トランザクションを区別するために、
LIST INDOUBT TRANSACTIONS が戻す出力の "originator" フィールドには以下のいずれかが表示されます。
|
分散環境の詳細については、 第 9 章, 分散データベースの設計および 第 10 章, トランザクション・マネージャーの設計を参照してください。
データベース区画サーバーに障害が発生すると、 アプリケーションは通常以下のいずれかの SQLCODE を受け取ります。 障害が発生したデータベース・マネージャーを検出する方法は、 受け取られた SQLCODE により異なります。
どのデータベース区画サーバーが失敗したかの判別は、2 つのステップで構成されます。 SQLCODE SQL1229N と関連する SQLCA には、 sqlerrd フィールドの 6 番目の配列位置にエラーを検出したサーバーのノード番号が入っています。 (サーバーについて書き出されるノード番号は、 db2nodes.cfg ファイルに含まれるノード番号に対応しています。) エラーを検出するデータベース区画サーバーでは、 障害サーバーのノード番号を示すメッセージが db2diag.log ファイルに書き込まれます。
注: | 複数の論理ノードが 1 つのプロセッサーで使用されている場合は、 1 つの論理ノードに障害が発生すると、 同じプロセッサー上の他の論理ノードにも障害が発生します。 |
通常、データベース区画サーバーの障害から回復するためには、次の操作を実行します。