今でもメインフレームが使われている理由の一つにシステムの高信頼性があります。 実際、本体装置やディスク装置のハードウェア障害はほとんど耳にしたことがありません。 ところが、性能評価を行っているとデータベースの（AIMの）バックアップ・リカバリ運用の不備を目にすることがあります。 長年この運用で問題なかったかもしれませんが、重大なシステム障害を起こさなかったのは単に運が良かっただけかもしれません。
リカバリ設計はSEの仕事と思われるかもしれませんが、お客様の業務に直結する問題です。 事例を紹介しますので、一度ご確認されてはいかがでしょうか。
- 目次
- ７．１ 重大な問題
- ７．２ 中程度の問題
- ７．３ 小程度の問題
- ７．４ その他の留意事項
７．１ 重大な問題
データベース(*1)のバックアップ（JXATDUMP）が全く実行されていないシステムがありました。 何かの勘違いかと思いお客様に確認をしたところ、その通りということでした。 色々と事情もあるようですが、社会的責任としてバックアップは取得して頂きたいと思います。
上記は極端な例ですが、業務の追加などの影響で一部のデータベースのバックアップを取り忘れているシステムもありました。 このシステムではデータベースのリカバリ作業最中に問題が発覚したため、システム停止が数日間に及びました。
※ バックアップをもれなく取得しているか、今一度ご確認ください。
*1 NDB、SymfoWARE/RDB、AIM/VSAM、AIM配下のデータセット
７．２ 中程度の問題
AIMがシステムの信頼性を担保できるのは堅牢なログ管理（ISMS）があるからです。履歴ログファイル（HLF）は最も重要なファイルの一つですが、システム導入時にログ環境が構築された後に見直しをされることはほとんどありません。
HLFには主にデータベースの更新後データが格納されます。更新後データは、応用プログラムが更新した後のデータベースの内容を記録したデータで、フォワードリカバリまたはダウンリカバリのために使用します。
しかし、下記のようにHLFデータを破棄する運用を行っているため、更新後データを取得しているにもかかわらず フォワードリカバリができない事例がありました。
HLFを退避していない （VARY[ICOFF]コマンドを投入後、データベースのバックアップを取得しない）
AIMをSISの初期化モードで起動する （その後、データベースのバックアップを取得しないまま運用する）
実際にリカバリをしたことがない （リカバリ手順書がない。メンテナンスされていない）
※ HLFのバックアップを取得しているかご確認ください。
※ リカバリテストの必要性について検討してください。
７．３ 小程度の問題
更新後データは、ジョブ空間内に用意されたタスクログバッファ （PEDで定義するLOG BUFFER）で管理され、HLFバッファにデータを転送した後、AIMがHLFへ書き込みます。
更新されたデータベースの内容を保障する（トランザクションを保障する）ため、 HLFへの書き込みが完了しないとプログラムのトランザクションは終了しません。 これは、HLFへの書き込みが遅延するとシステムはスローダウンする可能性があると言い換えることもできます。
実際には以下のような例があります。参考までにHLFの設計例も表６に示します。
HLFへの書き込み処理が間に合わず、HLFバッファの枯渇が発生している （多量に発生しているときにはチューニングが必要）
トランザクション内でHLFに多量のログデータが出力されている （JXAD82Iの警告メッセージが出力される）
※ PDL/PDAのR7レポート（ASYSレポート）でHLFバッファが不足していないか確認をしてください。
※ JXAD82Iで警告されたプログラムはログデータの出力が妥当か（プログラムミスでないか）確認をしてください。
表６ HLFの設計例
*1 ×：HLFバッファ不足が大量に発生、△：時々発生、○：不足は起きていない
７．４ その他の留意事項
HLFは通常2つ以上のファイルを循環使用します。運用上最も注意すべきことは、 バックアップを完了せずにファイルを使い切ってしまうことです。 せっかくHLFを3世代用意したのに、切り替わったファイルの１つ前のファイルを退避していたケースもありました。 このときHLFが交替できなくなり、HLFに書き込み要求をするプログラムは134-108で異常終了します。
図１５に実例を紹介します。この例ではプログラムのトランザクションキャンセル後のリトライが ループしたため、HLFが約5分で満杯になっています。HLFの退避（\ICOPY）はCPU使用率が100%のため 思うように進まず、3本全て使い切ってしまいました。
HLFは通常2つ以上のファイルを循環使用します。運用上最も注意すべきことは、 バックアップを完了せずにファイルを使い切ってしまうことです。 せっかくHLFを3世代用意したのに、切り替わったファイルの１つ前のファイルを退避していたケースもありました。 このときHLFが交替できなくなり、HLFに書き込み要求をするプログラムは134-108で異常終了します。
図１５に実例を紹介します。この例ではプログラムのトランザクションキャンセル後のリトライが ループしたため、HLFが約5分で満杯になっています。HLFの退避（\ICOPY）はCPU使用率が100%のため 思うように進まず、3本全て使い切ってしまいました。
以 上
コメント
投稿にはログインしてください