自分でやらかした話を書きます。QRYで抽出結果をファイルに書き出している最中に、ディスク使用率が95%を超えました。レコードが無限ループのように生成され続けるQRYを、自分で作ってしまったからです。ここでは、なぜ95%という数字が危ないのか、設定によっては何が起きうるのか、そして同じことをやらないために何を見ればいいのかを整理します。
やったことは単純です
QRYでデータを抽出して、結果をファイルに書き出そうとしました。よくある作業です。
ところが、そのQRYが想定と桁違いのレコードを生成し続けました。出力先のファイルがどんどん膨らんで、ディスク使用率が95%を超えました。
正直に書くと、どうやってそのQRYを作ってしまったのかは覚えていません。ただ、結果として何が起きたかと、そこから何を学ぶべきかははっきりしています。
95%は、たまたまの数字ではありません
後から知ったことですが、95%はIBM i が既定で警告を出す線そのものです。
システム値 QSTGLOWLMT（システム・ディスク・プールの最大使用率）の既定値は95%です。ここに到達すると、QSTGLOWACN（最大使用率に達した時の動作）で指定された動作が実行されます。
QSTGLOWACN の既定は「システム・オペレーターとシステム・メッセージ待ち行列にメッセージを送る」で、その時に送られるのが CPI099C です。つまり95%を超えた時点で、QSYSOPRにメッセージが出ています。
ここで一つ、読み違えやすい落とし穴があります
QSTGLOWLMT を5250の画面で見ると、「95」ではなく「5.00」と表示されます。
IBM Navigator for i では「使用率の上限を何%にするか」を指定しますが、文字ベースのインターフェースでは「空けておく割合」を指定する形になっているためです。IBMの公式ドキュメントにも、Navigator で95%と指定した場合、文字ベースでの QSTGLOWLMT の値は 5.00 になる、と明記されています。
| 見ている場所 | 表示 | 意味 |
|---|---|---|
| IBM Navigator for i | 95% | 使用率の上限が95% |
| DSPSYSVAL SYSVAL(QSTGLOWLMT) | 5.00 | 5%を空けておく（＝上限95%） |
「5.00と出ているから、5%で警告が出るのか」と読むと逆になります。確認する時はここを間違えないでください。
設定次第では、システムごと落ちていました
ここが、後から知って一番ぞっとしたところです。QSTGLOWACN に指定できる動作は、メッセージを送るだけではありません。
| 指定 | 上限に達した時の動作 |
|---|---|
| *MSG（既定） | CPI099C をシステム・オペレーターとシステム・メッセージ待ち行列へ送る |
| *CRITMSG | 重大メッセージを受け取る指定のユーザーへ CPI099B を送る（サインオン中のユーザーのみ） |
| *REGFAC | 登録された出口プログラムを呼び出すジョブを投入する |
| *ENDSYS | システムを制限状態まで終了させる |
| *PWRDWNSYS | システムを即時に電源断して再始動する |
既定が *MSG なので、多くの環境ではメッセージが出るだけです。ですが *ENDSYS や *PWRDWNSYS が指定されている環境で同じことをやれば、私のQRY一本でシステムが止まっていたことになります。
さらに、これらの動作が指定されている状態で上限に達すると、制限状態の間はサブシステムを開始できなくなります。復旧の難易度も上がるということです。
ディスクは自分だけのものではありません。データを抽出するだけの作業が、全員を止めうる——これがこの事故のいちばんの学びです。
なぜ抽出でレコードが爆発するのか
私の場合の作り方は覚えていません。ただ、抽出でレコード数が想定を超える理由は、だいたい決まっています。
いちばん多いのが、複数のファイルを結合した時に、結合の条件が足りていないケースです。結合条件が不足すると、片方の全レコードにもう片方の全レコードが総当たりで組み合わさります。件数は足し算ではなく掛け算になります。
1万件と1万件を条件なしで組み合わせれば1億件です。元のファイルがどちらも小さくても、出力は現実的でない大きさになります。画面上は「2つのファイルを指定しただけ」に見えるので、実行するまで気づきません。
これはQRYに限った話ではありません。SQLでも同じことが起きます。ツールの問題ではなく、結合の条件を書いたつもりで書けていないという問題です。
同じことをやらないために
抽出でファイルに書き出す前に、これだけはやるようになりました。
- 先に件数を数える。ファイルへ書き出す前に、同じ条件で何件になるかを確認する
- 結合しているなら、結合の条件が全部指定できているかを目で追う
- 元のファイルの件数と、出力の想定件数の桁を比べる。桁が合わなければ条件を疑う
- 画面表示で少し流してみて、想定通りの中身かを見てから書き出す
- 書き出し先のライブラリーと、既存ファイルを置き換えるのか追加するのかを確認する
要は、いきなりファイルに書かないということです。件数さえ先に見ていれば、この事故は起きませんでした。抽出の手順はAS400データ抽出ガイドとAS400 QUERY/400・WRKQRY・RUNQRYの確認ポイントにまとめています。
もし今、同じ状況になったら何を見るか
まず何が起きてどういう状態かを確認します。慌てて手を動かすと、別の事故を作ります。
| 見ること | 方法 | 確認する内容 |
|---|---|---|
| 今の使用率 | WRKSYSSTS | システムASPの容量と使用率 |
| ディスクごとの状況 | WRKDSKSTS | 各ディスク装置の状態と使用状況 |
| 原因のジョブ | WRKACTJOB | まだ動いているか、誰のジョブか |
| 警告が出ているか | QSYSOPR のメッセージ | CPI099C が出ていないか |
| 環境の設定 | DSPSYSVAL SYSVAL(QSTGLOWLMT) / (QSTGLOWACN) | 上限と、達した時の動作 |
WRKSYSSTS では、システムASPの総容量と現在の使用率が確認できます。日常的にここを見る習慣があると、異常な増え方に早く気づけます。確認の観点はAS400 WRKSYSSTSとASP使用率の確認ポイントにまとめています。
膨らんだ出力ファイルを消す時も、消す前に対象が本当にそれかを確認します。名前が似ているだけの別のファイルを消すほうが、よほど重い事故になります。
この失敗から持ち帰ってほしいこと
- 抽出はファイルに書く前に件数を数える。それだけで防げる
- ディスクは共有資源。自分の作業が全員に届く
- 95%はIBMが既定で警告を出す線。超えている時点で普通ではない
- QSTGLOWLMT は画面上「空けておく割合」で表示される。読み違えない
- QSTGLOWACN の指定次第では、システムが止まる設定もありうる
データを見るだけの作業は、本番を変更する作業に比べて軽く扱われがちです。読むだけなら壊れない、という感覚があるからだと思います。
ですが抽出結果をファイルに書き出す時点で、それは書き込み作業です。容量を使い、他の人に影響します。この事故で私が学んだのはそこでした。
こうした失敗を含めて、どういう現場を経験してきたかは運営者のAS400実務経験に書いています。
参考：IBM公式ドキュメント（QSTGLOWLMT / QSTGLOWACN / WRKSYSSTS）
本記事で扱ったシステム値 QSTGLOWLMT、QSTGLOWACN、および WRKSYSSTS、WRKDSKSTS の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。
