富士通メインフレームの本質を見る~性能改善の現場

第7回 バックアップ・リカバリ運用は適切ですか?

概要

SEが何ヶ月も調査しているはずなのに一向に解決しない性能問題。ギブアップ寸前の問題の相談を受け、解決に導いていくプロセスを現場の視点で紹介します。性能改善の現場ではメインフレームの本質が見えてきます。

  今でもメインフレームが使われている理由の一つにシステムの高信頼性があります。 実際、本体装置やディスク装置のハードウェア障害はほとんど耳にしたことがありません。 ところが、性能評価を行っているとデータベースの(AIMの)バックアップ・リカバリ運用の不備を目にすることがあります。 長年この運用で問題なかったかもしれませんが、重大なシステム障害を起こさなかったのは単に運が良かっただけかもしれません。
 
  リカバリ設計はSEの仕事と思われるかもしれませんが、お客様の業務に直結する問題です。 事例を紹介しますので、一度ご確認されてはいかがでしょうか。
 
目次
7.1 重大な問題
7.2 中程度の問題
7.3 小程度の問題
7.4 その他の留意事項

7.1 重大な問題

  データベース(*1)のバックアップ(JXATDUMP)が全く実行されていないシステムがありました。 何かの勘違いかと思いお客様に確認をしたところ、その通りということでした。 色々と事情もあるようですが、社会的責任としてバックアップは取得して頂きたいと思います。
 
  上記は極端な例ですが、業務の追加などの影響で一部のデータベースのバックアップを取り忘れているシステムもありました。 このシステムではデータベースのリカバリ作業最中に問題が発覚したため、システム停止が数日間に及びました。
※ バックアップをもれなく取得しているか、今一度ご確認ください。
  *1 NDB、SymfoWARE/RDB、AIM/VSAM、AIM配下のデータセット
 

7.2 中程度の問題

 AIMがシステムの信頼性を担保できるのは堅牢なログ管理(ISMS)があるからです。履歴ログファイル(HLF)は最も重要なファイルの一つですが、システム導入時にログ環境が構築された後に見直しをされることはほとんどありません。
 
  HLFには主にデータベースの更新後データが格納されます。更新後データは、応用プログラムが更新した後のデータベースの内容を記録したデータで、フォワードリカバリまたはダウンリカバリのために使用します。
 
  しかし、下記のようにHLFデータを破棄する運用を行っているため、更新後データを取得しているにもかかわらず フォワードリカバリができない事例がありました。
 

HLFを退避していない (VARY[ICOFF]コマンドを投入後、データベースのバックアップを取得しない)
AIMをSISの初期化モードで起動する (その後、データベースのバックアップを取得しないまま運用する)
実際にリカバリをしたことがない (リカバリ手順書がない。メンテナンスされていない)

※ HLFのバックアップを取得しているかご確認ください。
※ リカバリテストの必要性について検討してください。
 

7.3 小程度の問題

  更新後データは、ジョブ空間内に用意されたタスクログバッファ (PEDで定義するLOG BUFFER)で管理され、HLFバッファにデータを転送した後、AIMがHLFへ書き込みます。
 
  更新されたデータベースの内容を保障する(トランザクションを保障する)ため、 HLFへの書き込みが完了しないとプログラムのトランザクションは終了しません。 これは、HLFへの書き込みが遅延するとシステムはスローダウンする可能性があると言い換えることもできます。
 
  実際には以下のような例があります。参考までにHLFの設計例も表6に示します。
 

HLFへの書き込み処理が間に合わず、HLFバッファの枯渇が発生している (多量に発生しているときにはチューニングが必要)
トランザクション内でHLFに多量のログデータが出力されている (JXAD82Iの警告メッセージが出力される)

※ PDL/PDAのR7レポート(ASYSレポート)でHLFバッファが不足していないか確認をしてください。
※ JXAD82Iで警告されたプログラムはログデータの出力が妥当か(プログラムミスでないか)確認をしてください。
表6 HLFの設計例
*1 ×:HLFバッファ不足が大量に発生、△:時々発生、○:不足は起きていない
 

7.4 その他の留意事項

  HLFは通常2つ以上のファイルを循環使用します。運用上最も注意すべきことは、 バックアップを完了せずにファイルを使い切ってしまうことです。 せっかくHLFを3世代用意したのに、切り替わったファイルの1つ前のファイルを退避していたケースもありました。 このときHLFが交替できなくなり、HLFに書き込み要求をするプログラムは134-108で異常終了します。
 
  図15に実例を紹介します。この例ではプログラムのトランザクションキャンセル後のリトライが ループしたため、HLFが約5分で満杯になっています。HLFの退避(\ICOPY)はCPU使用率が100%のため 思うように進まず、3本全て使い切ってしまいました。
  HLFは通常2つ以上のファイルを循環使用します。運用上最も注意すべきことは、 バックアップを完了せずにファイルを使い切ってしまうことです。 せっかくHLFを3世代用意したのに、切り替わったファイルの1つ前のファイルを退避していたケースもありました。 このときHLFが交替できなくなり、HLFに書き込み要求をするプログラムは134-108で異常終了します。
 
  図15に実例を紹介します。この例ではプログラムのトランザクションキャンセル後のリトライが ループしたため、HLFが約5分で満杯になっています。HLFの退避(\ICOPY)はCPU使用率が100%のため 思うように進まず、3本全て使い切ってしまいました。
以 上

連載一覧

コメント

筆者紹介

有賀 光浩(ありが みつひろ)

株式会社アイビスインターナショナル 代表取締役

1963年生まれ。1985年富士通株式会社入社。1992年~2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。

2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。

技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。

当サイトには、同名シリーズ「富士通メインフレームの本質を見る~IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る~CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る~性能改善の現場」を7回、「富士通メインフレームの本質を見る~2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る~2008年度の最新トピックス」を2回にわたり掲載。

バックナンバー