AS400データ復旧|本番障害で戻す・リランする前に確認すること

AS400 / IBM i の現場でデータリカバリーが必要になるのは、ほとんどの場合、本番トラブル時です。

テスト環境であれば、データを入れ直す、作り直す、環境を戻すなどで済むこともあります。しかし本番環境はそうはいきません。業務で使われているデータがあり、処理を待っている人がいて、間違えれば影響が広がります。

だからこそ、データリカバリーは「急いで直す作業」ではなく、慎重に影響範囲を確認し、実施内容を整えたうえで実行する作業だと考えています。

この記事では、25年以上AS400の現場に関わってきた経験から、本番トラブル時のデータリカバリーで初心者に伝えたい確認ポイントをまとめます。

AS400のSQLステートメント入力画面例。SQLを入力して実行する画面
SQLで本番データを確認・修正する場合は、対象ライブラリ、対象ファイル、WHERE条件を必ず確認します。特に販売管理の本番リカバリーでは、実行前レビューと環境確認を省略しないことが重要です。

データリカバリーが必要になる場面

現場でデータリカバリーが必要になるのは、本番トラブル時が多いです。

たとえば、処理途中でエラーになった、バッチが想定外の状態で止まった、データの一部だけ更新されてしまった、後続処理と整合性が合わなくなった。こういう時に、データを正しい状態へ戻す、または業務が続けられる状態へ直す作業が必要になります。

テスト環境なら、データを作り直して再実行すれば済むことがあります。しかし本番では、実際の業務データを扱います。ここが一番大きな違いです。

リカバリー前に確認する順番

私が本番リカバリー前に意識している流れは、大きく分けると次の3つです。

  1. 影響範囲の確認
  2. 実施内容のお膳立て
  3. 実行

いきなり実行から入るのは危険です。まずは、何が起きていて、どのデータに影響していて、どこまで直す必要があるのかを確認します。

1. 影響範囲を確認する

最初に見るべきなのは、影響範囲です。

対象の処理だけなのか、後続処理にも影響しているのか。特定の店舗、特定の日付、特定の伝票、特定のファイルだけなのか。影響範囲が曖昧なまま修正すると、直したつもりで別の不整合を残してしまうことがあります。

確認すること理由
対象処理どのジョブ・プログラムで問題が起きたかを確認する
対象データどのファイル・レコードを直す必要があるかを確認する
対象期間日付や締め範囲を間違えないために確認する
後続処理すでに次の処理へ影響していないか確認する
業務影響誰が困っていて、どこを優先すべきかを整理する

この段階では、ジョブログ、処理結果、対象ファイル、件数確認、業務側からの情報を合わせて見ます。調査メモを残しておくと、後で説明するときにも役立ちます。

2. 実施内容のお膳立てをする

影響範囲が見えたら、次は実施内容を整えます。

ここでいうお膳立てとは、作業手順、確認SQL、実行コマンド、作業順番、確認方法をそろえることです。大げさな資料でなくても構いません。箇条書きで「何をするか」が見える状態にしておくことが大切です。

たとえば、次のような粒度です。

  • 対象ライブラリを確認する
  • 対象ファイルを確認する
  • 更新対象件数を確認する
  • リカバリーSQLまたはコマンドを確認する
  • 実行前の状態を残すか判断する
  • 確認済みのSQLまたはコマンドを実行する
  • 実行後の件数と業務状態を確認する

本番トラブル時は、完璧な手順書を作る時間がないこともあります。それでも、頭の中だけで進めるより、箇条書きで作業を見える化した方が安全です。

SQLで一番怖いのはライブラリ名の指定ミス

SQLでデータ修正をするとき、私が一番怖いと思うのはライブラリ名の指定ミスです。

AS400では、同じようなファイル名が複数のライブラリに存在することがあります。開発、検証、本番、退避用など、環境によってライブラリが分かれていることもあります。

そのため、SQLを実行する前には、対象ライブラリを必ず確認します。

SELECT COUNT(*)
  FROM TESTLIB.TESTFILE
 WHERE 処理日 = 20260524

上の例では、TESTLIB を明示しています。実際の本番作業でも、どのライブラリを見ているのか、どのライブラリを更新するのかを曖昧にしないことが重要です。

特に更新系SQLでは、実行前に対象件数を確認します。

SELECT *
  FROM TESTLIB.TESTFILE
 WHERE キー項目 = '確認対象'

更新対象が想定より多い、または少ない場合は、そこで止まるべきです。焦っているときほど、この確認を省略してはいけません。

バックアップをどう考えるか

更新前バックアップは、状況によって考え方が変わります。

最近の現場では、リカバリーリハーサルをしてから本番実行することも多く、その場合は手順と結果が確認済みであるため、必ずしも毎回バックアップを取らないケースもあります。

ただし、リハーサルをしていない場合や、影響範囲に不安が残る場合は、ファイルを丸ごとバックアップして安全に備えることがあります。

状況考え方
リハーサル済み手順・対象・結果が確認済みなら、その内容に沿って実行する
リハーサルなし可能なら対象ファイルを退避し、戻せる状態を作る
影響範囲が広い関係者と確認し、単独判断で進めない
対象件数が不明件数確認ができるまで更新しない

大事なのは、バックアップを取るか取らないかを感覚で決めないことです。リハーサルの有無、影響範囲、戻し手順、作業時間、業務影響を見て判断します。

作業手順書は箇条書きでもよい

本番トラブル時の作業手順書は、状況によって書く内容が変わります。そのため、一概に「必ずこの形式」とは言えません。

ただ、最低限、やることリストとして箇条書きにしておくと安全です。

  • 何を確認するか
  • どのライブラリを見るか
  • どのファイルを対象にするか
  • どの条件で対象データを絞るか
  • どの順番で実行するか
  • 実行後に何を確認するか

手順が文章として残っていれば、メンバーや上司にレビューしてもらいやすくなります。作業後の振り返りにも使えます。

レビューでは全部を見る

レビューしてもらうときに、ここだけ見ればよいというものはありません。確認項目を一つずつ点検します。

ライブラリ名、ファイル名、対象条件、件数、実行順、実行後確認、戻し方。どれか一つでも間違えると、本番では大きな問題になります。

特に初心者のうちは、自分だけで判断しない方が安全です。自分では正しいと思っていても、経験者が見ると危ない点に気づくことがあります。

ヒヤッとする場面は毎回ある

本番データを触る作業では、ヒヤッとする場面は毎回あります。

対象件数が想定より多い、ジョブの状態が想定と違う、業務側の説明とデータの状態が合わない、実行直前に別の処理が動いていることに気づく。こういうことは珍しくありません。

だからこそ、怖がりすぎる必要はありませんが、軽く見てもいけません。本番データリカバリーは、毎回慎重に進める作業です。

本番データリカバリー前のチェックリスト

データリカバリーは、戻せるかだけでなく、誰が承認したか、どの時点へ戻すか、戻した後に業務を続けられるかまで見る作業です。焦ってSQLやコマンドを実行する前に、最低限ここを確認します。

  • 本番・検証・開発のどの環境で作業するかを明示したか
  • 対象ライブラリ、ファイル、メンバー、キー条件を書いたか
  • 同じ条件でSELECTして、更新対象件数と内容を確認したか
  • 戻し先の時点、バックアップ、ジャーナル、更新前データを確認したか
  • 後続処理、帳票、EDI、締め処理、在庫、売上、請求への影響を見たか
  • 実行手順と戻し手順を第三者にレビューしてもらったか
  • 実行後に何を見れば成功と判断できるかを決めたか

販売管理のリカバリーは一概に言えないからこそ怖い

販売管理システムでデータリカバリーが必要になる場面は、受注、出荷、在庫引当、売上、請求、店舗連携、物流連携などさまざまです。だから最初から「このファイルだけ直せばよい」と決め打ちしない方が安全です。

確認すること現場での見方
対象ファイル本当に修正すべきファイルか。同名ファイルや別ライブラリを見ていないか。
リカバリー方法SQLで直すのか、バックアップから戻すのか、再処理するのかを決める。
後続処理売上、請求、在庫、EDI、帳票に影響しないかを見る。
戻し方失敗した時に元に戻せるか。戻せない作業ならさらに慎重にする。

SQL修正で一番怖いのはライブラリ名

SQLでデータを修正する時に一番怖いのは、ライブラリ名の指定ミスです。AS400 / IBM i では同じファイル名が複数のライブラリに存在することがあります。ファイル名だけ合っていても、ライブラリが違えば別のデータを触ることになります。

-- 悪い例: ライブラリが曖昧
UPDATE TESTFILE
   SET STATUS = '9'
 WHERE ORDERNO = '123456';

-- 確認しやすい例: ライブラリを明記
UPDATE TESTLIB.TESTFILE
   SET STATUS = '9'
 WHERE ORDERNO = '123456';

実行前には、同じ条件で SELECT COUNT(*) と明細確認を行います。対象件数が想定と違うなら、その時点で止める判断が必要です。

レビューしてもらうのは作業手順そのもの

リカバリー作業をレビューしてもらう時は、SQL文だけでなく、作業手順そのものを見てもらいます。作業者、対象環境、対象ライブラリ、確認SQL、実行SQL、戻し方、実行後確認までを箇条書きにします。

本番対応で信用されるのは、腕だけで突っ走る人ではなく、手順を作り、レビューを受け、対象ファイルとライブラリ名を確認してから実行できる人です。

リストア・リカバリー・ロールフォワードを混同しない

本番復旧では言葉が混ざると危険です。リストアは保存済みデータを戻す作業、リカバリーは業務を続けられる状態へ戻す全体作業、ロールフォワードはバックアップ後の更新履歴を適用して時点を近づける考え方です。

ジャーナルを設定している場合は、DSPJRNで更新前後、順序番号、対象ファイル、キー、後続処理を確認できます。更新前レコードを抽出して実行前の状態に戻し、リランする判断につながることがあります。ただし、APYJRNCHGやRMVJRNCHGのようなコマンドは、必ず事前確認とレビューを行ってから検討します。

復旧前に確認する次の入口