AS400 / IBM iの本番環境でSQL UPDATEやDELETEを行う時は、実行できることと、実行してよいことを分ける必要があります。WHERE条件のミス、対象ライブラリの間違い、締め後データの更新は、大きな事故につながります。
UPDATE前に止まる確認項目
| 確認 | 見る理由 |
|---|---|
| 環境 | 本番、テスト、開発を間違えていないか |
| ライブラリ | 対象ライブラリとライブラリリストを確認する |
| WHERE条件 | 対象件数をSELECTで先に確認する |
| バックアップ | 更新前データを戻せる形で残す |
| 承認 | 業務担当者と責任者の承認を取る |
実行前の声出し
- 本番環境であることを確認したか
- 対象件数は想定通りか
- 更新前データを保存したか
- 戻しSQLを用意したか
- 締め、EDI、請求、在庫への影響を確認したか
若手や外部担当者の本番事故防止は、AS400若手・外部エンジニアの本番事故を防ぐチェックリストも確認してください。
ここまでの要点
AS400本番SQL更新では、環境、ライブラリ、WHERE条件、バックアップ、戻し、承認を必ず確認します。UPDATE前に止まれる仕組みを作ることが、本番事故を減らします。
UPDATE前に、更新前データを戻せる材料があるか確認する
本番SQL更新で一番怖いのは、SQL文そのものより「間違えた時に戻す材料がない」状態で実行してしまうことです。UPDATE前には、承認者、対象ライブラリ、対象ファイル、WHERE条件、件数確認に加えて、更新前データをどう残すかまで確認します。締め後データや請求・在庫・会計に関わる更新では、実行前の状態に戻せるか、戻した後にリランできるかを先に決めておく必要があります。
ジャーナルが設定されているファイルなら、障害発生時に DSPJRN で更新前後の履歴を機械的に確認できます。DSPJRNをファイル出力すると、前半に制御用の情報、後半に実データが入るため、キー項目と更新前レコードを抽出して戻し材料を作れる場合があります。ただし、これは「何でも簡単に戻せる」という意味ではありません。業務影響、承認、バックアップ、後続処理、取引先連携まで含めて判断します。
| UPDATE前に確認すること | 確認する理由 | 関連ページ |
|---|---|---|
| ジャーナル有無 | 更新前後の履歴をDSPJRNで追えるかを見る | AS400ジャーナル確認手順 |
| 戻し方 | 戻す、作り直す、リランするのどれかを先に決める | AS400データ復旧 |
| 締め後修正 | 請求・在庫・会計を崩さない承認を取る | 締め後データ修正の承認 |
| 障害時初動 | 失敗時に影響範囲と連絡先をすぐ確認する | 本番障害の初動対応 |
本番SQL更新を3段階で管理する
本番SQL更新は、SQL文をレビューするだけでは不十分です。事前確認、実行、実行後確認を別の段階として扱い、それぞれに実行者と確認者を置きます。
| 段階 | 確認すること | 止める条件 |
|---|---|---|
| 1. 事前確認 | 同じWHERE条件のSELECT結果、対象キー、件数、環境、ライブラリ、バックアップ | 0件、想定外件数、対象不明、戻し材料なし |
| 2. 実行 | 実行者、承認者、開始時刻、更新範囲、コミット方針、オンライン処理やバッチとの競合 | 別処理が対象データを更新中、ロックや影響範囲が不明 |
| 3. 実行後確認 | 更新件数、代表キー、ジョブログ、後続バッチ、帳票、EDIや会計連携 | 件数不一致、後続エラー、戻し判断が必要 |
SELECTで件数が合っていても、更新中に別処理が動けば結果は変わります。締め処理、受注・出荷更新、在庫引当、EDI連携が動く時間帯を避け、実行可能な時間帯を業務担当者と決めます。
承認記録に残す項目
- 変更理由と申請番号
- 本番環境、対象ライブラリ、ファイル、キー項目
- 事前SELECTの件数と確認者
- 更新前データの保存場所と戻し方法
- 実行予定時刻、実行者、承認者、立会者
- 更新後に確認する件数、画面、帳票、後続処理
- 中止条件と、異常時の連絡先
生成AIへ確認を依頼する場合も、本番の接続情報、パスワード、顧客名、個人情報、実データは渡しません。匿名化した項目名、想定件数、処理の前後関係だけでレビューできる形にします。
関連するAS400確認ルート
本番SQL更新は、UPDATE文の正しさより、承認、対象件数、バックアップ、戻し方、締め後影響の確認が重要です。実行前に止まれるフローを作ります。
請求状態を一件修正する時の承認例
本番データを一件だけ直す場合でも、UPDATE文を先に作るのではなく、対象特定、退避、戻し、承認、事後照合をそろえます。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 対象確認 | 同じWHERE条件のSELECTでキー、現在値、対象件数を確認する | 一件の想定が複数件になっていないか止まって確認する |
| 安全策 | 修正前データ、実行文、戻し文、コミット方法、実施時間をレビューする | 実行者と承認者を分ける |
| 事後確認 | 更新件数、対象値、関連帳票、バッチ、外部連携を確認する | SQL成功だけで業務整合を判断しない |
緊急時でも、対象キー、理由、承認、実施者、時刻、修正前後を残します。やり直しが必要な場合に同じUPDATEを繰り返さず、現時点のデータを再取得して判断します。