AS400 / IBM i の障害の中で、いちばん記憶に残っているものを一つ挙げるなら、電源装置が壊れた時の復旧です。止まった原因そのものは単純でした。本当に苦しんだのは、その後のアクセスパスの再作成です。バックアップは取れていたのに、戻した後に一日使い物にならなくなりました。ここでは実際の流れと、同じことを起こさないために今すぐ確認できることを書きます。
第一報は「月曜日に出社したらASが起動していない」
連絡はこの一言でした。月曜の朝です。週末の間に何かが起きていて、誰も気づいていなかったことになります。
この時点で分かっているのは「起動していない」だけです。OSの問題なのか、ハードなのか、電源なのか、まだ何も切り分けられていません。第一報がこの粒度で来るのは珍しいことではありません。だからこそ、現地で実物を見るまで原因を決めつけないことが大事になります。
現地で電源が入らない。ここは自分の領域ではないと切り分けた
現地に行って電源を入れても、電源が入りませんでした。画面が出ないのではなく、電源そのものが入らない状態です。
ここで判断したのは、これはアプリケーション側の人間が手を出す話ではない、ということです。インフラ担当の会社へ連絡しました。
焦っている時ほど、自分の守備範囲の外に手を伸ばしたくなります。ですが電源が入らない筐体に対して、アプリ側でできることは何もありません。早く専門に渡すことが、結果としていちばん早いという場面です。
原因は電源装置の故障。電源は戻ったが、ディスクが無事ではなかった
原因は電源装置の故障でした。交換して電源が復旧すると、AS400自体は動作しました。
ところが、当時の対応では、電源断後にディスクのミラーリングにも問題があると分かり、そのまま使える状態ではありませんでした。これはこの障害で把握した状況であり、電源断で必ずミラーリングが壊れるという意味ではありません。電源が戻ってシステムが起動したことと、業務が再開できることは別だ、というのがここではっきりします。
ここでバックアップテープからのデータ復元に進みます。バックアップは取れていました。この時点では、あとは戻すだけだと思っていました。
テープから戻した後に、本当の問題が出た
悪いことに、そのプロジェクトはテープへのバックアップでアクセスパスの保管を行っていませんでした。
アクセスパスが保管されていないと、データを復元した後にシステムがアクセスパスを作り直しに行きます。復元自体は終わっているのに、そこから延々とアクセスパスの再作成が走ります。
結果として、AS400が重くて使い物になりませんでした。画面は出る、ログインもできる、でも業務を流せる速度ではない、という状態です。
月曜は復旧に徹し、火曜に2日分を入力してもらった
途中で、月曜のうちに業務を再開させるのは無理だと判断しました。中途半端に動かして、遅い環境で入力させて、それが原因で別の事故を起こすほうが怖いからです。
月曜は復旧に徹しました。そして火曜日に、月曜日の分と火曜日の分をまとめてデータ入力してもらう形で復旧しました。
障害対応というと技術的にどう直すかに目が行きますが、実際には「今日は動かさない」と決めることも復旧作業の一部です。この判断は現場のエンジニアだけでは決められません。業務側と話して決めることになります。
アクセスパスとは何で、なぜ復元後に時間がかかるのか
アクセスパスは、プログラムが処理するために、1つ以上のデータベースファイルのレコードがどういう順序で並んでいるかを示すものです。論理ファイルが持っている並び順だと考えると分かりやすいと思います。
論理ファイルのアクセスパスを保管する指定は、保管コマンドのACCPTHと、*SYSVAL指定時のQSAVACCPTHで確認します。ただし、*YESなら必ず保存・復元できるわけではありません。基になる物理ファイルを同じ保管操作で含めること、アクセスパスが有効であることなどの条件があります。物理ファイル自身のキーや制約に関わるアクセスパスには別の扱いもあります。IBM公式の保存条件と実際の保管ログを照合してください。
| 指定 | 意味 |
|---|---|
| ACCPTH(*SYSVAL) | システム値 QSAVACCPTH の設定に従う |
| ACCPTH(*YES) | 保存条件を満たす論理ファイルのアクセスパスを保管対象にする（システム値は使わない） |
| ACCPTH(*NO) | 論理ファイルのアクセスパスを保管対象にしない（物理ファイル自身のキー等は別扱い） |
| QSAVACCPTH = 1 | *SYSVAL指定時に、保存条件を満たす論理ファイルのアクセスパスを保管対象にする |
| QSAVACCPTH = 0 | *SYSVAL指定時に、論理ファイルのアクセスパスを保管対象にしない |
ACCPTH は SAVLIB、SAVOBJ、SAVCHGOBJ、SAVRSTLIB、SAVRSTOBJ、SAVRSTCHG で指定できます。
ここが分かれ目です。アクセスパスを保管すると、保管の時間と使うメディアの量は増えます。保存・復元の条件を満たせば、再作成するアクセスパスを減らし、復旧時間を短縮できます。どの程度短くなるかは、自社のデータ量と復元テストで確認します。
バックアップの窓が足りない現場では、時間を削るために保管を切ることがあります。その判断自体が常に間違いだとは言いません。ただし、そこで削った時間は、復旧する日にまとめて返ってきます。しかも返ってくるのは、いちばん余裕がない日です。
「保管する設定にしてある」だけでは保管されない
ここは見落としやすいところです。IBMの公式ドキュメントでは、アクセスパスが実際に保管されるのは次の条件を満たす場合だけだとされています。
- 基礎となる物理ファイルがデータを含み、同じ保管コマンドで同時に保存されること
- 保管の時点で、アクセスパスが無効になっていない、壊れていないこと
- 基礎となる物理ファイル同士が同じライブラリーにあり、対象論理ファイルがMAINT(*IMMED)またはMAINT(*DLY)であること
「同じライブラリー」は、基礎となる物理ファイル同士についての条件です。物理ファイルと論理ファイルが別ライブラリーでも、アクセスパスを保存できる場合があります。ただし、保存されたアクセスパスを復元できるかは別の条件です。保存できたことだけで再作成が不要とは判断せず、復元の順番・範囲とログを確認します。IBMの別ライブラリーを含む保管例も参照してください。
もう一つ、ACCPTH は論理ファイルというオブジェクトそのものを保管するパラメーターではありません。あくまでアクセスパスを保管するかどうかを制御するだけです。ここを取り違えると、バックアップの中身の理解がずれます。物理ファイルと論理ファイルの関係はAS400の物理ファイルと論理ファイルの違いにまとめています。
自分の環境が今どうなっているかを確認する
障害が起きてから調べるのでは遅い項目です。今日確認できます。
| 確認したいこと | 方法 | 見るところ |
|---|---|---|
| システム値の設定 | DSPSYSVAL SYSVAL(QSAVACCPTH) | *SYSVAL指定時の選択。対象ファイルと保存条件も照合する |
| バックアップ処理の指定 | バックアップのCLソースを見る | SAVLIB / SAVOBJ の ACCPTH の指定 |
| 今、無効なアクセスパスがあるか | EDTRBDAP | 現在のジョブから見えるASPの範囲を確認する。空の一覧だけで全IASPも正常とは判断しない |
| 再作成のタイミング | DSPFD で対象ファイルを見る | Access Path Recovery が *IPL・*AFTIPL・*NO のどれか。*NO では無効なパスを次回オープン時に再作成するため、業務再開時への影響も確認する |
EDTRBDAPを入力して一覧を表示するだけでは再作成は始まりません。ただし、画面で順序などを変更すると再作成を開始できます。調査中は変更しないでください。IASPの確認には対象ASPグループがジョブの名前空間に含まれる必要があります。空の一覧を全環境の正常証明とせず、対象範囲と復旧状況を管理者と照合します。IBM公式のEDTRBDAP説明を参照してください。
なお、GO SAVE のオプション21で全体バックアップを取っている場合、その中で動く SAVLIB は既定で ACCPTH(*YES) です。IBMが公開している手順にも、これを *NO に変更する方法として案内されています。オプション21の内容はAS400 GO SAVE・オプション21の確認ポイントで整理しています。
この事例から持ち帰ってほしいこと
- 電源が入らない時点でアプリ側の仕事ではない。早く専門に渡すほうが早い
- システムが起動したことと、業務が再開できることは別物
- バックアップが取れていることと、業務が使える状態まで戻せることも別物
- アクセスパスの保管を切ると、削った時間は復旧の日にまとめて返ってくる
- 復旧に徹する日を作る判断も、立派な障害対応
一番言いたいのは3つ目です。バックアップが取れているかどうかと、そこから業務を再開できるかどうかは、確認している内容が違います。戻せることまで確認して、初めてバックアップを確認したと言えます。
実際に戻すところまで試したことがあるかどうかで、障害の日の景色は変わります。確認の観点はAS400バックアップ確認チェックリストにまとめています。実際に戻す判断をする場面ではAS400データ復旧とAS400の復元系コマンドの注意点も合わせて見てください。
この種の本番対応をどれだけ経験してきたかは運営者のAS400実務経験にまとめています。データリカバリーの経験についても書いています。
参考：IBM公式ドキュメント（ACCPTH / QSAVACCPTH / EDTRBDAP）
本記事で扱った ACCPTH パラメーター、システム値 QSAVACCPTH、EDTRBDAP の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。
