Oracle 11g ADRに関する検証 その４
＜Oracle 11g ADRに関する検証 その４＞
ペンネーム： ミラニスタ
自動診断リポジトリ（ADR:Automatic Diagnostic Repository)の検証を行っ
ています。
▼ 前回のおさらい
前回は、クリティカル・エラーを故意(!?)に発生させ、ADRによってインシ
デントとして管理される様子を確認しました。
また、インシデント・パッケージング・サービス（IPS）によって、インシ
デントに紐付く診断データ（アラート・ログ、トレース・ファイル、ダンプ・
ファイル等）を Oracleサポートに送るための ZIPファイルにまとめるまでを
紹介しました。
▼ ADRのメリット
前回までの３回に亘るメルマガで、ADRのさわりを紹介してきましたが、い
かがだったでしょうか？
ADRの特徴として
1. 情報を一元管理することができる
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の惨敗！ショックです。
恵比寿より