AS400 / IBM i の現場でデータリカバリーが必要になるのは、ほとんどの場合、本番トラブル時です。
テスト環境であれば、データを入れ直す、作り直す、環境を戻すなどで済むこともあります。しかし本番環境はそうはいきません。業務で使われているデータがあり、処理を待っている人がいて、間違えれば影響が広がります。
だからこそ、データリカバリーは「急いで直す作業」ではなく、慎重に影響範囲を確認し、実施内容を整えたうえで実行する作業だと考えています。
この記事では、25年以上AS400の現場に関わってきた経験から、本番トラブル時のデータリカバリーで初心者に伝えたい確認ポイントをまとめます。
データリカバリーが必要になる場面
現場でデータリカバリーが必要になるのは、本番トラブル時が多いです。
たとえば、処理途中でエラーになった、バッチが想定外の状態で止まった、データの一部だけ更新されてしまった、後続処理と整合性が合わなくなった。こういう時に、データを正しい状態へ戻す、または業務が続けられる状態へ直す作業が必要になります。
テスト環境なら、データを作り直して再実行すれば済むことがあります。しかし本番では、実際の業務データを扱います。ここが一番大きな違いです。
リカバリー前に確認する順番
私が本番リカバリー前に意識している流れは、大きく分けると次の3つです。
- 影響範囲の確認
- 実施内容のお膳立て
- 実行
いきなり実行から入るのは危険です。まずは、何が起きていて、どのデータに影響していて、どこまで直す必要があるのかを確認します。
1. 影響範囲を確認する
最初に見るべきなのは、影響範囲です。
対象の処理だけなのか、後続処理にも影響しているのか。特定の店舗、特定の日付、特定の伝票、特定のファイルだけなのか。影響範囲が曖昧なまま修正すると、直したつもりで別の不整合を残してしまうことがあります。
| 確認すること | 理由 |
|---|---|
| 対象処理 | どのジョブ・プログラムで問題が起きたかを確認する |
| 対象データ | どのファイル・レコードを直す必要があるかを確認する |
| 対象期間 | 日付や締め範囲を間違えないために確認する |
| 後続処理 | すでに次の処理へ影響していないか確認する |
| 業務影響 | 誰が困っていて、どこを優先すべきかを整理する |
この段階では、ジョブログ、処理結果、対象ファイル、件数確認、業務側からの情報を合わせて見ます。調査メモを残しておくと、後で説明するときにも役立ちます。
2. 実施内容のお膳立てをする
影響範囲が見えたら、次は実施内容を整えます。
ここでいうお膳立てとは、作業手順、確認SQL、実行コマンド、作業順番、確認方法をそろえることです。大げさな資料でなくても構いません。箇条書きで「何をするか」が見える状態にしておくことが大切です。
たとえば、次のような粒度です。
- 対象ライブラリを確認する
- 対象ファイルを確認する
- 更新対象件数を確認する
- リカバリーSQLまたはコマンドを確認する
- 実行前の状態を残すか判断する
- 確認済みのSQLまたはコマンドを実行する
- 実行後の件数と業務状態を確認する
本番トラブル時は、完璧な手順書を作る時間がないこともあります。それでも、頭の中だけで進めるより、箇条書きで作業を見える化した方が安全です。
一番怖いのはデータをいじる時。中でもライブラリ名の指定ミス
本番作業で一番怖いのは、データをいじる時です。参照調査にも負荷や機密情報の扱いへの注意は必要ですが、更新・削除はデータ自体を変えるため、復元材料がなければ戻せないことがあります。そのデータ更新の中で、私が最も事故になりやすいと感じるのがライブラリ名の指定ミスです。
AS400では、同じようなファイル名が複数のライブラリに存在することがあります。開発、検証、本番、退避用など、環境によってライブラリが分かれていることもあります。
そのため、SQLを実行する前には、対象ライブラリを必ず確認します。
SELECT COUNT(*)
FROM TESTLIB.TESTFILE
WHERE 処理日 = 20260524上の例では、TESTLIB を明示しています。実際の本番作業でも、どのライブラリを見ているのか、どのライブラリを更新するのかを曖昧にしないことが重要です。
特に更新系SQLでは、実行前に対象件数を確認します。
SELECT *
FROM TESTLIB.TESTFILE
WHERE キー項目 = '確認対象'更新対象が想定より多い、または少ない場合は、そこで止まるべきです。焦っているときほど、この確認を省略してはいけません。
バックアップをどう考えるか
更新前バックアップは、状況によって考え方が変わります。
リカバリーのリハーサルは、手順と期待結果を検証するために有効です。ただし、実施済みであることは今回の本番作業を戻せる証明にはなりません。今回の対象・時点に合う退避、バックアップ、必要なジャーナル記録、復旧手順がそろっているかを実行前に確認します。
作業直前の退避を省く運用がある場合も、別の有効な復旧点、復旧可能な範囲、失われる更新、承認者を明確にします。リハーサルの有無だけで退避不要と判断せず、根拠がなければ本番実行を止めます。
| 状況 | 考え方 |
|---|---|
| リハーサル済み | 今回の本番対象・復旧点・退避・承認条件も照合し、変更があれば再検証する |
| リハーサルなし | 可能なら対象ファイルを退避し、戻せる状態を作る |
| 影響範囲が広い | 関係者と確認し、単独判断で進めない |
| 対象件数が不明 | 件数確認ができるまで更新しない |
大事なのは、バックアップを取るか取らないかを感覚で決めないことです。リハーサルの有無、影響範囲、戻し手順、作業時間、業務影響を見て判断します。
作業手順書は箇条書きでもよい
本番トラブル時の作業手順書は、状況によって書く内容が変わります。そのため、一概に「必ずこの形式」とは言えません。
ただ、最低限、やることリストとして箇条書きにしておくと安全です。
- 何を確認するか
- どのライブラリを見るか
- どのファイルを対象にするか
- どの条件で対象データを絞るか
- どの順番で実行するか
- 実行後に何を確認するか
手順が文章として残っていれば、メンバーや上司にレビューしてもらいやすくなります。作業後の振り返りにも使えます。
レビューでは全部を見る
レビューしてもらうときに、ここだけ見ればよいというものはありません。確認項目を一つずつ点検します。
ライブラリ名、ファイル名、対象条件、件数、実行順、実行後確認、戻し方。どれか一つでも間違えると、本番では大きな問題になります。
特に初心者のうちは、自分だけで判断しない方が安全です。自分では正しいと思っていても、経験者が見ると危ない点に気づくことがあります。
ヒヤッとする場面は毎回ある
本番データを触る作業では、ヒヤッとする場面は毎回あります。
対象件数が想定より多い、ジョブの状態が想定と違う、業務側の説明とデータの状態が合わない、実行直前に別の処理が動いていることに気づく。こういうことは珍しくありません。
だからこそ、怖がりすぎる必要はありませんが、軽く見てもいけません。本番データリカバリーは、毎回慎重に進める作業です。
販売管理のリカバリーは一概に言えないからこそ怖い
販売管理システムでデータリカバリーが必要になる場面は、受注、出荷、在庫引当、売上、請求、店舗連携、物流連携などさまざまです。だから最初から「このファイルだけ直せばよい」と決め打ちしない方が安全です。
| 確認すること | 現場での見方 |
|---|---|
| 対象ファイル | 本当に修正すべきファイルか。同名ファイルや別ライブラリを見ていないか。 |
| リカバリー方法 | SQLで直すのか、バックアップから戻すのか、再処理するのかを決める。 |
| 後続処理 | 売上、請求、在庫、EDI、帳票に影響しないかを見る。 |
| 戻し方 | 失敗した時に元に戻せるか。戻せない作業ならさらに慎重にする。 |
リストア・リカバリー・ロールフォワードを混同しない
本番復旧では言葉が混ざると危険です。リストアは保存済みデータを戻す作業、リカバリーは業務を続けられる状態へ戻す全体作業、ロールフォワードはバックアップ後の更新履歴を適用して時点を近づける考え方です。
対象ファイルが障害時点にジャーナル処理され、対象期間のレシーバーが残っていれば、DSPJRNで記録を調べられます。更新前の値には更新前イメージが必要です。記録形式と当時のファイル定義を照合し、復旧材料として使えるか検証します。APYJRNCHGやRMVJRNCHGは別の更新操作なので、対象範囲・コミット境界・途中更新・後続連携を確認し、レビューと承認なしに実行しません。
