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