オラクルの統合運用管理ツール

DBだけじゃないの？ Oracle Enterprise Managerを使ってみた

2008/03/07

　基本機能が無償で使えるにもかかわらずあまり機能が知られていないのがOracle Databaseの統合管理ツール「Oracle Enterprise Manager」（OEM）。2月5日には最新版の「Release 4」を出荷したが、データベースだけでなく、アプリケーションも含めて統合管理し、さらには問題を修復できるなど管理対象と機能が拡大した。日本オラクルが「隠れたヒット商品」と呼ぶOEMを使ってみた。

　最新のRelease 4の特徴はトップダウンアプローチの採用だ。データベースだけでなく、ITシステムのすべてのレイヤを一元管理する考え。従来まではHTTPサーバ、アプリケーションサーバ、データベースサーバと個別に障害を確認し、対応する必要があったが、OEMでは上位レイヤから下位レイヤまで自動でチェックできるようにした。日本オラクルの製品戦略統括本部 Grid/EPM/BIビジネス推進本部担当マネジャー高橋輝匡氏は「闇雲に見るのではなく、確実に効率的に分析、チューニングができる」と説明する。ただ、このトップダウンアプローチが完全に機能するにはアプリケーションも含めてオラクル製品で統一されている必要がある。

　Oracle E-Business Suite（EBS）にユーザーがログインできなくなったというシナリオを設定し、実際にOEMを使ってみた。まずはOEMのトップから停止しているサービスをクリック。そうすると画面に想定される「失敗の原因」が表示される。この項目をクリックすることで障害分析の結果が見られる。

システム障害の原因を示す画面（クリックで拡大します、以下同）

　画面の下部にある「分析ステップ」ではOEMが実際に行った分析プロセスをたどることができる。オラクルのコンサルタントの手法を模して上位レイヤから下位レイヤに向けて順にコンポーネントを分析するようにした。今回のシナリオでは「データベース・インスタンス」に問題があることが分かった。さらにこの「ebs12 db」をクリックすると障害の原因をドリルダウンして調べることができる。リスナーが停止していることが判明し、OEMから開始し、障害を復旧させた。

分析ステップを表示。「×」のコンポーネントが障害原因になっている

　高橋氏によると軽微な障害ならOEMで復旧可能という。ハードウェアやOSなどオラクル製品以外が原因になっているとOEMでの復旧は難しい。また、オラクル以外の製品がシステムに含まれる場合でも、障害場所の特定までは可能という。

適切なデータベース・チューニング法を提案

　OEMにはデータベースの適切なチューニング方法を示すアドバイザ機能がある。アプリケーションのパフォーマンスが低下するとOEM上にアラートが表示。トップダウンアプローチによって問題がデータベースと特定された場合に、データベースの負荷をチェックできる。アドバイザ機能の集合体である「アドバイザ・セントラル」をクリックして、適切なチューニング法を選ぶ。試したシナリオではデータベース全体をチューニングする「SQLアクセス・アドバイザ」を選択した。データウェアハウスのパフォーマンスが低下していることが分かり、その改善策が示された。この改善策が適当と思った場合は「実装」ボタンをクリックするだけでチューニングがほぼ自動的に実行される。もちろんスケジュールの設定なども可能だ。

チューニングの結果。レスポンス時間が97.14％改善した

　今回はほかにJavaアプリケーションの障害を特定する機能やオラクル製品のパッチ適用を効率化する機能などを試した。限られたシナリオの中で、限られた機能しか試していないが、システムがオラクル製品中心であればOEMは有効な製品だろう。だが、他社製品やカスタムアプリケーションを組み合わせたシステムが一般的なことを考えると、まずはOEMが効果的に機能するようなシステム環境作りが大変かもしれない。

　オラクル自身が説明するようにハードウェアやジョブの管理は「JP1」などの既存の統合管理ツールを使い、オラクル製品はOEMを活用し、SNMPトラップなどで相互に連携させるというのが現実的だろう。高橋氏は「OEMは今後、すべてのオラクル製品の管理プラットフォームになる方向を目指している」と話した。Javaアプリケーションのチューニングなども可能にするという。