AS400 / IBM i の保守では、QueryやSQLで本番データを確認する場面がよくあります。便利な一方で、抽出条件を間違える、更新SQLを誤って実行する、個人情報を含むCSVを外へ出すなど、事故につながる操作でもあります。ここでは、調査担当者が安全に確認するための順番を整理します。
調査前の確認
| 確認 | 見るもの | 判断 |
|---|---|---|
| 目的 | 何を確認したいか | 件数確認か、明細確認か、原因調査か |
| 対象ファイル | ライブラリ、物理ファイル、論理ファイル | 本当に見るべきファイルか |
| 抽出条件 | 日付、コード、状態区分 | 条件漏れで大量抽出しないか |
| 権限 | 参照権限、更新権限、共用ID | 不要な更新権限で作業していないか |
| 持ち出し | CSV、Excel、メール | 個人情報や取引情報が含まれないか |
SELECTでも安心しすぎない
SELECTだけなら安全に見えますが、抽出範囲が大きすぎると性能影響が出ることがあります。締め処理中や夜間バッチ中に重いSQLを流すと、業務側では「AS400が遅い」と見えることもあります。まず件数確認、次に限定条件、最後に必要な項目だけを見る流れが安全です。
更新SQLは手順と承認を分ける
本番データを更新するSQLは、調査用SQLとは別物として扱います。実行前のバックアップ、対象件数、WHERE条件、戻し手順、承認者、実行ログを残します。1件だけの修正でも、後続処理や帳票に影響する可能性があります。
データ抽出の依頼は AS400データ抽出依頼の確認手順、SQL7008などDB2 for iの確認は SQL7008とDB2 for iの確認、権限面は AS400権限・監査チェックリスト にまとめています。
Codexへ渡す前に匿名化する
SQLの相談でCodexを使う時は、実データ、顧客名、取引先名、個人情報を入れないことが前提です。テーブル名や項目名も必要に応じて仮名にし、目的、条件、確認したい観点だけを渡すと安全です。
調査から更新へ進める時の分岐
QueryやSQLで原因が見えても、すぐUPDATEへ進めるとは限りません。参照だけで終わる調査、更新前データを残して承認を取る作業、ジャーナルや戻し手順まで必要な作業を分けます。
| 状態 | 次に見ること | 確認先 |
|---|---|---|
| SELECTで原因だけ確認する | 抽出条件、対象件数、権限 | データ抽出依頼・権限確認 |
| UPDATEが必要に見える | 更新前データ、承認者、戻し手順 | 本番データ修正チェックリスト |
| 誤更新の疑いがある | 時刻、ジョブ、ユーザー、DSPJRN | ジャーナル・コミットメント制御 |
| 在庫や締めへ影響する | 業務日付、後続処理、帳票 | 在庫差異の調べ方 |
更新作業へ進む場合は AS400本番データ修正チェックリスト、ジャーナルやCOMMIT/ROLLBACKの確認は AS400ジャーナル・コミットメント制御の確認手順、在庫数量への影響は AS400在庫差異の調べ方 を合わせて確認します。
Query・SQLは便利ですが、本番では「見るだけ」を徹底します
AS400 / IBM i の調査では、QueryやSQLでデータを直接確認したくなる場面が多くあります。特に在庫差異、売上計上、請求締め、出荷確定、EDI送受信後の確認では、ファイルの中身を早く見られることが復旧時間を左右します。ただし、本番環境で更新SQLを混ぜると、原因調査のはずが二次障害になります。
現場では、まず参照専用ユーザー、実行環境、対象ライブラリ、締め前後のタイミング、抽出条件、証跡の残し方を確認します。若手や外部エンジニアには、SELECTだけを許可し、UPDATE・DELETE・INSERTは承認手順を通す形にしておくと安全です。Codexを使う場合も、SQLの意味を説明させる、抽出条件をレビューする、テストデータで確認する用途に限定し、本番更新の自動実行には使いません。
- AS400コマンド逆引きで、DSPFFD・DSPPFM・WRKOBJなど周辺確認を行う
- トラブル逆引きで、業務影響から調査順を決める
誤UPDATEに気づいたらDSPJRNで更新前後を確認する
QueryやSQLの調査で一番怖いのは、確認のつもりが更新になってしまうことです。もし誤UPDATEや条件誤りに気づいたら、同じ画面で手修正を重ねる前に、対象時刻、ユーザー、ジョブ、対象ファイル、WHERE条件、更新件数を記録します。ジャーナル対象ファイルであれば、DSPJRNで更新前後の履歴を確認できる場合があります。
- まず追加更新を止め、対象範囲を広げない
- 対象キー、更新時刻、ジョブ、ユーザー、実行SQLを残す
- DSPJRNで更新前・更新後の差分を確認する
- 更新前レコードを復元材料にできるか確認する
- 戻し後にリラン、帳票、EDI、締め処理へ影響しないか確認する
詳しい確認順は、AS400ジャーナル確認手順｜DSPJRNで更新前後と戻し判断を見るで整理しています。SQL事故では、技術的に戻せるかだけでなく、業務上戻してよいかを同時に判断します。
Query・SQL確認の次に決めること
Query・SQLで本番データを確認した後は、結果を見て終わりにせず、抽出として渡すのか、影響調査へ進むのか、更新SQLを検討するのかを分けます。ここを曖昧にすると、見るだけの調査がいつの間にか本番修正に変わりやすくなります。
| 次の判断 | 確認する記事 |
|---|---|
| CSVや一覧で安全に渡したい | AS400データ抽出ガイド |
| ACS SQLの基本を確認したい | ACS SQL / IBM i SQL Servicesの基本 |
| ファイル定義や桁数を確認したい | DSPFFD / DSPPFMの確認手順 |
| 更新SQLに進む可能性がある | 本番データ修正前の承認チェック |
抽出条件やSELECT結果の妥当性に不安がある場合は、対象ライブラリ、対象ファイル、WHERE条件、件数、利用目的を整理してからお問い合わせで相談できます。実データや個人情報は送らず、マスキングした条件で共有してください。
SQLで調べた内容を、保守判断と研修に残す
AS400 / IBM i でQueryやSQLを使って本番データを確認するときは、調査結果だけで終わらせず、誰が見ても再確認できる形に残しておくことが大切です。どのファイルを見たか、どの条件で抽出したか、更新系SQLを避けたかを記録しておくと、保守会社への相談や社内引き継ぎがしやすくなります。
Codexを使う場合も、実データや機密情報をそのまま貼るのではなく、項目名、抽出条件、ジョブログ、エラー内容を整理する補助として使うのが安全です。現場担当者がSQL調査の観点を説明できるようにしておくと、障害時の確認時間を減らせます。
Query・SQLの確認は、抽出依頼の受け方まで標準化する
AS400のデータ確認では、SQLやQueryの書き方だけでなく、「誰の依頼で、何の目的で、どの範囲を、どの権限で見るか」を最初に揃えることが大切です。本番データを読む作業は便利な反面、条件ミス、桁違い、文字コード、個人情報、CSV出力後の扱いで事故が起きやすい領域です。
社内向けに教育するなら、SELECT文のサンプルよりも、対象ライブラリ、対象ファイル、WHERE条件、件数確認、出力先、保存期間、再利用可否をセットで確認する型を作ります。Codexを使う場合も、実データを渡すのではなく、項目名を伏せた構造や確認観点を整理する使い方が安全です。
テスト機で動いたSQLが本番機でエラーになる時に見るところ
運営者が実際に遭遇したのは、テスト機では問題なく動いていたSQLが、本番機ではSQLエラーになるという事象です。SQLの版なのかOSの版なのか、その時は特定できませんでした。同じように「こちらの機械では通るのに」で止まってしまう人は多いと思います。
見落としやすいのは、OSリリースが同じでも、Db2 for i のグループPTFレベルが違えば使えるSQLの機能が変わることです。SQLの関数やサポートされる構文は、リリース単位だけでなくグループPTFの適用レベルでも増えていきます。「両方とも7.4だから同じはず」と考えると、ここで足をすくわれます。
2台の差を先に確定させる
SQL文を書き換える前に、まず2台の環境差を数字で押さえます。エラー文だけを見て構文を直し始めると、原因が環境差だった場合に遠回りになります。
DSPPTF DSPSFWRSC WRKPTFGRP
| 確認 | 使うもの | 見る内容 |
|---|---|---|
| OSリリース | DSPPTF の画面上部、または DSPSFWRSC | テスト機と本番機で同じリリースか |
| グループPTFレベル | WRKPTFGRP | Db2 for i のグループPTFのレベル番号が2台で違わないか |
| SQLエラーの中身 | SQLCODE と SQLSTATE | 構文エラーなのか、機能が存在しないのかを分ける |
| 実行経路 | ACS、ODBC/JDBC、組み込みSQLのどれか | 経路によって既定値や制限が違う場合がある |
2台のリリースとグループPTFレベルが違っていれば、その時点で「環境差の可能性が高い」と切り分けられます。同じであれば、権限、ライブラリ、スキーマ、データ型など別の線を追うことになります。
避けたい進め方
- 本番で通らないからといって、原因を確かめないままSQLを場当たり的に書き換える
- テスト機だけで検証を終わらせ、本番機で初めて実行する
- 「動いたからよし」で、なぜ本番で落ちたのかを記録に残さない
現実には、テスト機と本番機のリリースやPTFレベルが完全に揃っていない現場はあります。揃えられないのであれば、揃っていない前提で、本番機と同じ条件で確認できる場を用意するほうが安全です。少なくとも、2台のリリースとグループPTFレベルは作業前に控えておきます。
Db2 for i にどの機能がどのレベルで追加されたかは、IBMが公開しているDb2 for i – Technology Updatesで確認できます。自分の環境で使える機能かどうかを、記憶や他社の事例ではなくここで突き合わせてください。
なお「自分の環境では動くのに、他の環境では落ちる」という形の障害は、SQLに限りません。コンパイル時のライブラリリスト違いでも同じことが起きます。切り分けの考え方はAS400ライブラリリスト違いによる障害の調べ方にまとめています。
参考：IBM公式ドキュメント（DSPJRN）
本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。