運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

富士通メインフレームの本質を見る~性能改善の現場 第7回 バックアップ・リカバリ運用は適切ですか?
2009年04月22日 13:00

  今でもメインフレームが使われている理由の一つにシステムの高信頼性があります。 実際、本体装置やディスク装置のハードウェア障害はほとんど耳にしたことがありません。 ところが、性能評価を行っているとデータベースの(AIMの)バックアップ・リカバリ運用の不備を目にすることがあります。 長年この運用で問題なかったかもしれませんが、重大なシステム障害を起こさなかったのは単に運が良かっただけかもしれません。

  リカバリ設計はSEの仕事と思われるかもしれませんが、お客様の業務に直結する問題です。 事例を紹介しますので、一度ご確認されてはいかがでしょうか。

7.1 重大な問題
  データベース(*1)のバックアップ(JXATDUMP)が全く実行されていないシステムがありました。 何かの勘違いかと思いお客様に確認をしたところ、その通りということでした。 色々と事情もあるようですが、社会的責任としてバックアップは取得して頂きたいと思います。

  上記は極端な例ですが、業務の追加などの影響で一部のデータベースのバックアップを取り忘れているシステムもありました。 このシステムではデータベースのリカバリ作業最中に問題が発覚したため、システム停止が数日間に及びました。

※ バックアップをもれなく取得しているか、今一度ご確認ください。

  *1 NDB、SymfoWARE/RDB、AIM/VSAM、AIM配下のデータセット

7.2 中程度の問題
  AIMがシステムの信頼性を担保できるのは堅牢なログ管理(ISMS)があるからです。履歴ログファイル(HLF)は最も重要なファイルの一つですが、システム導入時にログ環境が構築された後に見直しをされることはほとんどありません。

  HLFには主にデータベースの更新後データが格納されます。更新後データは、応用プログラムが更新した後のデータベースの内容を記録したデータで、フォワードリカバリまたはダウンリカバリのために使用します。

  しかし、下記のようにHLFデータを破棄する運用を行っているため、更新後データを取得しているにもかかわらず フォワードリカバリができない事例がありました。

    1. HLFを退避していない (VARY[ICOFF]コマンドを投入後、データベースのバックアップを取得しない)
    2. AIMをSISの初期化モードで起動する (その後、データベースのバックアップを取得しないまま運用する)
    3. 実際にリカバリをしたことがない (リカバリ手順書がない。メンテナンスされていない)
※ HLFのバックアップを取得しているかご確認ください。
※ リカバリテストの必要性について検討してください。

7.3 小程度の問題
  更新後データは、ジョブ空間内に用意されたタスクログバッファ (PEDで定義するLOG BUFFER)で管理され、HLFバッファにデータを転送した後、AIMがHLFへ書き込みます。

  更新されたデータベースの内容を保障する(トランザクションを保障する)ため、 HLFへの書き込みが完了しないとプログラムのトランザクションは終了しません。 これは、HLFへの書き込みが遅延するとシステムはスローダウンする可能性があると言い換えることもできます。

  実際には以下のような例があります。参考までにHLFの設計例も表6に示します。

    1. HLFへの書き込み処理が間に合わず、HLFバッファの枯渇が発生している (多量に発生しているときにはチューニングが必要)
    2. トランザクション内でHLFに多量のログデータが出力されている (JXAD82Iの警告メッセージが出力される)
※ PDL/PDAのR7レポート(ASYSレポート)でHLFバッファが不足していないか確認をしてください。
※ JXAD82Iで警告されたプログラムはログデータの出力が妥当か(プログラムミスでないか)確認をしてください。
表6 HLFの設計例
image13.PNG
*1 ×:HLFバッファ不足が大量に発生、△:時々発生、○:不足は起きていない
7.4 その他の留意事項
  HLFは通常2つ以上のファイルを循環使用します。運用上最も注意すべきことは、 バックアップを完了せずにファイルを使い切ってしまうことです。 せっかくHLFを3世代用意したのに、切り替わったファイルの1つ前のファイルを退避していたケースもありました。 このときHLFが交替できなくなり、HLFに書き込み要求をするプログラムは134-108で異常終了します。

  図15に実例を紹介します。この例ではプログラムのトランザクションキャンセル後のリトライが ループしたため、HLFが約5分で満杯になっています。HLFの退避(\ICOPY)はCPU使用率が100%のため 思うように進まず、3本全て使い切ってしまいました。
090422_1.png
図15 HLFの満杯例

  トランザクションキャンセルでなぜHLFを使うのか疑問に思われるかもしれません。 実は、HLFには内部統制の証跡ログなど用途で以下のデータを格納することがあります。

    • ユーザログデータ
    • AIM課金統計情報
    • ユーザ課金統計情報
    • 電文情報

  リスクをコントロールするために証跡ログを取得しているのに、システム障害のリスクを高めては意味がありません。

  2008年3月10日、東京証券取引所でデータベースのデッドロックが引き金となったシステム障害を 記憶されている方も多いかと思います。デッドロックのリトライ回数を無制限にしてもかまいませんが、 上記のような事象に対する対応も必要となることをご理解ください。

※ デッドロックやトランザクションキャンセルなどが頻繁に起きていないか、そのときの対応は適切か確認をしてください。
※ 気になっているが見過ごしているメッセージが出ていませんか。
※ 更新後データ以外でHLFを使用しているか把握してください。

以 上

運用研究レポート
富士通メインフレームの本質を見る~性能改善の現場

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

記事一覧へ
筆者紹介

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



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

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回にわたり掲載。

コメントを書く
コメントを書く

未ログイン: ログインする

コメント: ログイン(会員登録)すると、コメントを書き込むことができます。

  • 新着Q&A
  • 最新の回答

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

こちらは、システム管理者認定講座の認定試験の受験のみ希望される方の申込みページです。 システム管理者認定講座のアソシエイト(初級)、バチェラー(中級)、マスタ

個人情報保護方針
運営者につい て
利用規約
サイトマップ