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