Oracle 11g ADRに関する検証 その4

<Oracle 11g ADRに関する検証 その4>
ペンネーム: ミラニスタ

自動診断リポジトリ(ADR:Automatic Diagnostic Repository)の検証を行っ
ています。

▼ 前回のおさらい

前回は、クリティカル・エラーを故意(!?)に発生させ、ADRによってインシ
デントとして管理される様子を確認しました。
また、インシデント・パッケージング・サービス(IPS)によって、インシ
デントに紐付く診断データ(アラート・ログ、トレース・ファイル、ダンプ・
ファイル等)を Oracleサポートに送るための ZIPファイルにまとめるまでを
紹介しました。

▼ ADRのメリット

前回までの3回に亘るメルマガで、ADRのさわりを紹介してきましたが、い
かがだったでしょうか?

ADRの特徴として

1. 情報を一元管理することができる
2. 関連情報を紐付けて管理することができる

の2つを挙げましたが、これらが運用コストの削減にどのようにどのように結
びつくのかを考えてみたいと思います。

▲ 一元管理で何がうれしいのか

まず、前者ですが、弊社内で「アラート・ログとリスナー・ログが一箇所に
集まっているのがそんなにうれしいことなのか?」という率直な意見が出まし
た。

確かにそうとも言えるのですが、この連載の冒頭で RAC:Real Application
Clustersの障害試験に関するお話をしたことを思い出してください。

例えば、SE RACは ASMの使用が必須ですが、2ノード構成の場合 Oracleイン
スタンスと ASMインスタンスは各ノードごとに存在するため、合計4つのイン
スタンスそれぞれにアラート・ログが出力されることになります。

もし、各ノードのアラート・ログの出力先、つまり ADRベースをローカル・
ディスクではなく、NAS:Network Attached Storage 上に NFS: Network File
System で構築された共有ファイル・システムとすれば、全インスタンスの
ADRベースを一箇所に統合することができます。

そうすれば、あるノードで障害が発生したとしても、他の残存ノードから
ADRにアクセスして障害の調査を行うことができます。

もちろん、ネットワークやディスクの障害で、NFSの書き込みに問題が発生
する可能性は否定できませんが、そもそも ASMディスクを構築できるほどの信
頼性が NASにあれば、管理性の向上という点から ADRによる一元管理は大いに
メリットがあるのではないでしょうか。これはノード数が多くなればなるほど
有効になってきます。

従って、NAS上に RACを構築するようなケースにおいては、ADRベースの統合
化は特におすすめです。(ちなみに、ADRはファイル・ベースのリポジトリな
ので、ASM内には格納できません。)

○ RAC on NAS

近年 RACの共有ストレージに SAN:Storage Area Network ではなく NASを利
用するというケースを多く見かけるようになりました。
「NAS=遅い、SAN=速い」という偏見があったため、私は NASの導入には慎
重だったのですが、昨年実際の案件で NASが(ネットワークの帯域を十分確保
しておけば)パフォーマンス的に遜色のないことを見てからは、考えが変わり
ました。

▲ 関連情報の紐付けができてうれしいのか?

インシデントとなるクリティカル・エラーに遭遇したことがない。というよ
うな”幸運”なデータベース管理者にはあまりメリットが感じられないかもし
れませんが、逆に ORA-600や ORA-7445などがよく発生しているデータベース
のお守りをしているような方には朗報のはずです。

従来 Oracleサポートに必要な情報を送るためには、以下のような面倒な手
順が必要でした。

  1. クリティカル・エラー発生!!
  2. 監視インフラが、アラート・ログ中の「ORA-」で始まるメッセージを検
     知し通知する
  3. アラート・ログの格納場所を確認する
  4. アラート・ログの障害発生に関する部分を確認する
  5. 関連するトレース・ファイル等が出力されていないか確認する
  6. トレース・ファイル等を送付する

ADRを活用すると、以下のような手順で同じことを行うことができます。

  1. クリティカル・エラー発生!!
  2. 監視インフラが、アラート・ログ中の「Sweep Incident[xxxxx]: completed」
     を含むメッセージを検知し通知する(xxxxxxはインシデントID)
  3. ADRCIでインシデント一覧およびインシデント詳細情報の確認を行う
  4. ADRCIで論理インシデント・パッケージを作成する
  5. ADRCIで物理インシデント・パッケージを作成し、Oracleサポートに送付
     する

一見ステップ数が一つ減っただけのように見えますが、各ステップの作業負
荷は非常に軽くなります。大量のログ情報の中から必要な情報を探す。あるい
はディレクトリを移動して必要なファイルを取得する。というような Oracle
の知識に依存するような作業は大幅に減りました。

最近、24時間365日の運用を3交代シフトのエンジニアで行っているというお
客様から、Oracleの専門教育を受けていないエンジニアでも、障害発生時に的
確かつ迅速な対応ができるためにはどうしたらいいだろうか?というご相談を
受けました。
つまり、障害発生時に正しい判断を行うための Oracleに関する教育を対象
エンジニア全員に施すのは難しいが、定型的な手順で必要な処置を行うことが
できないだろうか?という主旨のお問合せでした。

アラート・ログにどのようなメッセージが出力されて、どのようなトレース・
ファイル等が出力されるのかということを体系的に理解し、円滑な運用に結び
つけるためには、ある程度の Oracleに関する教育が必要ですが、現実的には
エンジニアの養成が難しいケースが多いように思われます。

クリティカル・エラーのような予測が困難な障害に対して、Oracleサポート
に的確な情報を送るまでを、Oracleの知識が十分でないエンジニアでも ADRを
使って定型的な手順で実施できるならば、運用の質は向上し、コスト削減も期
待できるのではないでしょうか?

▼ Performance Insight ではこうなっている!

ADRからは少し脱線しますが、弊社製品である「Performance Insight(PI)」
のお話(宣伝)をさせていただきます。

▲ データの格納場所

PIのホーム(インストール)ディレクトリは、IST_HOMEという環境変数で設
定されます。例えば ORACLE_HOMEの下に insightというディレクトリを作成す
れば、IST_HOME=$ORACLE_HOME/insight になります。

評価レポートやパフォーマンス・データはデフォルトで $IST_HOME/usrに格
納されますが、このディレクトリは IST_USR_HOMEという環境変数で自由に変
更することができるため、各ノードに共有マウントさせた NFS領域に統合化す
るようなことを簡単に実現することができます。

IST_USR_HOME は以下のようなディレクトリ構造になっています。

$IST_USR_HOME/(hostname1)/(SID1)/report
                                /episode
                                ........
                         /(SID2)/report
                                /episode
                                ........
             /(hostname2)/(SID3)/report
                                /episode
                                ........
                         /(SID4)/report
                                /episode
                                ........

▲ ログ等の集約

PIで何か問題が発生した。という場合、弊社サポートから「コレクトログを
取得してください。」というようなお願いをする場合があります。

例:

  $ istctl collectlog
           ^^^^^^^^^^
  xx:xx:xx log collecting....
  Start Archiving...
  ./bin/prod_info
  ./tmp/console.200806xx.log
  ./install/InitRegistry.log
  ./install/confctl.log
  (中略)
  ./tmp/sc01_err_ps.log
  Compressing...
  
  Collect support data is finished.
  Please send file[/home/ora102d/insight/tmp/PI-SUP.xxxxx.200806xx.tar.bz2] to support.
  xx:xx:xx log collected.

コレクトログ機能は、必要なログ等の情報(collectlogの後に引数をつけて
制御することができます。)を一つに集約し、より圧縮率の高い bzip2を利用
して圧縮します。

弊社サポートではお客様からftp等で送っていただいたコレクトログの結果
を展開・解析し、原因を究明すると共に、迅速な問題解決を図っています。

ちなみに、この機能は、弊社のコンサルタントがお客様環境から、評価レ
ポートやパフォーマンス・データを持ち帰って診断を行う際にも活用してい
ます。

▼ おわりに

PIがコレクトログ機能を実装して何年も経つのですが、お客様からの情報収
集がかなり円滑になったという実感があります。
ADRについて調べたとき、Oracleサポートへの情報伝達がよりスムーズにな
り、問題解決が早くなるという期待感を持ちました。
今まで新機能と言えば、パフォーマンスや多様性といった明らかに目に見え
る改良を見てきました。しかし「障害診断インフラストラクチャ」の考え方は
従来にないが、健全な運用を実現するために必要な機能と言えるのではないで
しょうか。

ADRに関する検証はこれで終わりです。来週から「不可視索引」についての
検証が始まります。

ユーロ2008開幕!!イタリアがオランダに0-3の惨敗!ショックです。

恵比寿より