可用性構成を実現する
Db2データ共用機能
IBM ZのミドルウェアであるDb2 for z/OS（以下、Db2）は、高可用性が求められるミッション･クリティカルな業務を支えている。本稿ではその高可用性のなかで、とくに「障害からの回復」に注目し、Db2システムの障害発生時でも業務継続を可能にする「リテインド･ロックとオブジェクト制限状態を的確に解消する機能と運用」について解説する。
Db2で高可用性を実現するクラスタリング･システム構成は、z/OSのParallel Sysplex機能を利用した「Db2データ共用機能を使用した構成」となる。
Db2メンバーと呼ばれる複数のDb2サブシステムがデータ共用グループを構成し、データベースを共有する。各Db2メンバーで実行されるアプリケーションは、同じデータに対して参照･更新が可能であり、更新データやロックの情報はCF（Coupling Facility）を介して共有することでデータの整合性が保障される（図表1）。
データ共用機能を使用することで、特定のDb2メンバーが障害で異常終了しても、生存しているDb2メンバーから業務を継続的に実行することが可能となる。しかし障害によりリテインド･ロックが保持されているデータや、LPL（Logical Page List）などの制限状態となったデータに関しては、生存しているDb2メンバーからもアクセスできない状況が考えられる（図表2）。
リテインド･ロックや制限状態を発生させないためには、アプリケーション設計や表／索引設計で検討する必要があるが、完全に抑止するのは困難なので、発生時に迅速に対応できる手順を併せて確立しておくことが重要となる。
リテインド･ロックの
解消手順を確立する
リテインド･ロックとは、Db2メンバーが異常終了した場合でもデータの整合性を保証するための仕組みである。
データ共用機能では、ロックの情報はCFのロック･ストラクチャを介してDb2メンバー間で共有される。Db2メンバーが異常終了すると、そのメンバーが保持していたロックのうち、更新ロック（Xロック）情報がリテインド･ロックに変更され、生存系のDb2メンバーからのアクセスは制限される。トランザクションが完了していない可能性のあるデータに対して、コミットもしくはロールバックを実施するまで、他アプリケーションからのアクセスを防ぐためである。
リテインド･ロックを解放するには、異常終了したDb2メンバーを再始動させてトランザクションを完了させる必要がある。
Db2メンバー再始動の考慮ポイント
迅速なDb2メンバーの再始動が重要なので、手動ではなく、z/OSのARM（Automatic Restart Management）機能を利用して自動で再始動する。
再始動はノーマルモード（ノーマル･リスタート）、ライトモード（ライト･リスタート）のどちらで実施するかを適切に選択する必要がある。ライト･リスタートでは再始動処理で使用するメモリを最小限に抑え、新たなアプリケーションを受け付けず、Db2メンバーは自動的に停止する。
Db2メンバーの単体障害の場合は、稼働していたz/OSでDb2メンバーを再始動させて業務を再開できるので、ノーマル・リスタートを選択する。LPAR障害や筐体障害では、z/OSの再始動に処理時間を要するため、別のz/OSでDb2を再始動させる（図表3）。再始動後に業務を再開する場合は、Db2メンバー障害と同様にノーマル・リスタートを選択する。
ただし、業務を再開するにはCPU、メモリなどのシステム資源が追加で必要となること、またCICSやIMSなどトランザクションマネージャとの接続設定が必要になるなどの点を考慮する。このため、リテインド･ロック解放後はDb2メンバーを停止し、縮退運用を実施することも考えられる。その場合は、新たなアプリケーションを受け付けず自動停止するライト･リスタートが推奨される。
ライト･リスタート機能の概要
ライト･リスタートは、Db2メンバーをリテインド･ロックから解放するためだけに再始動させる場合に有用な機能である。処理のフローは、以下のようになる。
1 最小限のメモリ使用の状態でDb2メンバーを始動
2 データベースの回復、リテインド･ロックの解消を実施
3 LPLの自動回復を実施
4 自動的にDb2を停止
この機能を利用する場合は、Db2のSTART DB2コマンドのLIGHTオプションで指定する（図表4）。オプションは3種類あるが、Db2 11で提供されたCASTOUTオプションが推奨される。
Db2 10以前のライト･リスタートでは、行やページに対するリテインド･ロックは解消されるものの、SIX、IXモードのページセットP-LOCKのリテインド・ロックが解消されなかった。
そのため再始動後は、SQLによるアクセスは可能だが、ユーティリティが実行できなかった。これにより障害発生直後は、ライト･リスタートで行やページのリテインド･ロックを解消し、z/OS回復後にノーマル･リスタートを実施して、ページセットP-LOCKのリテインド･ロックを解放するといった煩雑な手順を採用するケースも見られた。
このような問題を解消すべく、Db2 11ですべてのリテインド･ロックを解放するCASTOUTオプションが提供されている。
オブジェクト制限状態の
解消手順を確立する
Db2メンバーが障害で異常終了すると、Db2は表スペースや索引などのオブジェクトを制限状態におく可能性がある。障害により発生しうる制限状態はGRECP、LPL、UTUT、RECOVER PENDINGである（図表5）。
制限状態におかれたオブジェクトは、生存系のDb2メンバーからのアクセスも制限される。一部の制限状態はDb2メンバー再始動で自動的に回復されるが、すべてに適用されるわけではないので、ユーザーが回復手順をあらかじめ準備し、迅速に対応することが重要となる。
とくにLPLは、索引リーフ･ページやスペース･マップ･ページといった複数のDb2メンバーから同一ページを更新するような状況で発生しやすく、アプリケーションへの影響も大きいので、回復手順の自動化が推奨される。
LPLの概要
LPLとは、データページが何らかの理由で整合性を保てず、ログからの回復が必要と判断される状態である。データ共用構成に限らないが、ディスク上のページをREAD／WRITEしようとした際にエラーが発生するとLPLになる。LPLとなったデータページへのアクセスはエラーとなる。START DATABASEコマンドを実行するなどしてログを適用すると回復する。
Db2メンバーの異常終了でLPLとなった場合、再始動時にAutomatic LPL、GRECP Recoveryと呼ばれる自動回復処理が実施される。しかし回復できなかったLPLは残存してしまうので、ユーザーが回復する仕組みを準備しておく。
制限状態の解消手順のポイント
異常終了したDb2メンバーを再始動させると、Db2がリテインド･ロック解放、LPLの自動回復、PL解消を実行する。これらの処理との競合を回避するために、制限状態の解消は再始動処理の完了後に実施する。
ライト･リスタートしたDb2メンバーは、新たなアプリケーション実行を受け付けない。つまり、制限状態解消のためのジョブも実行できないことになる。そこで、制限状態解消のジョブは生存系のDb2メンバーから実行する。
影響の大きいDb2カタログ／ディレクトリ･データベースへの対応を他のオブジェクトより優先する。
障害により発生する制限状態は図表5のとおりであるが、障害発生前に何らかの制限状態におかれていた可能性も考慮し、すべての制限状態を確認して対応することが推奨される。
これらのポイントを踏まえ、以下にオブジェクト制限状態解消の実装例を挙げる。
1 Db2カタログ／ディレクトリの制限状態の確認および回復
（1）以下のコマンドで確認する。
DISPLAY DB(DSNDB01,DSNDB06) SP(*) RESTRICT LIMIT(*)
（2）LPL／GRECP状態のオブジェクトに対して、以下のコマンドで回復させる。
START DB(xxx) SP(xxx) （区分表スペースの場合は PART(xxx) を追加）
（3）その他の制限状態を解消する。回復手順の依存関係に注意する（たとえばREBUILD PENDING解消のため、REBUILD INDEXユーティリティを実行する前に、STOP状態などユーティリティ実行不可の制限状態を解消するなど）。
（4）（1）を再実行して制限状態が解消されたことを確認する。
2 ユーザー用オブジェクト（データベース、表スペース、索引）の制限状態の確認および回復
（1）以下のコマンドで確認する。
DISPLAY DB(*) SP(*) RESTRICT LIMIT(*)
DISPLAY DB(*) RESTRICT LIMIT(*)
（2）LPL／GRECP状態のオブジェクトに対して、以下のコマンドで回復させる。
START DB(xxx) SP(xxx) （区分表スペースの場合は PART(xxx) を追加）
（3）その他の制限状態を解消する。 回復手順の依存関係に注意する（たとえばREBUILD PENDING解消のため、REBUILD INDEXユーティリティを実行する前に、STOP状態などユーティリティ実行不可の制限状態を解消するなど）。
（4） （1）を再実行して制限状態が解消されたことを確認する。
3 助言状態の確認
（1）以下のコマンドを実施し、助言状態のオブジェクトについて確認。必要に応じて対応する。
DISPLAY DB(*) SP(*) ADVISORY LIMIT(*)
DISPLAY DB(*) ADVISORY LIMIT(*)
＊
Db2システムに障害が発生した状況で業務を継続するには、データ共用機能を利用したクラスタリング･システム構成の採用とともに、リテインド･ロックの解放、オブジェクト制限状態の回復を迅速に実施することが重要である。本稿では、回復手順を確立するうえで考慮すべきポイントを解説した。
今後、高可用性が求められるDb2システム構成を設計する際の参考としていただければ幸いである。
著者｜長尾 肇子
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシー
第二テクノロジー
アドバイザリーITスペシャリスト
2002年からDb2 for z/OSの技術支援を担当。主にDb2 for z/OSシステムの構築プロジェクトやバージョンアップ･プロジェクト、Db2システム、アプリケーションパフォーマンス分析･チューニングに従事。
