～オラクルコンサルタントの Big 3（大竹、大野、大木）が語る～ データベース運用における Oracle Enterprise Manager 徹底活用への道 第１回　オラクル・コンサルタントが語る、Oracle Enterprise Manager （EM）基本機能講座

[著者紹介] 日本オラクル株式会社 コンサルティングサービス事業統括 クラウド・テクノロジーコンサルティング事業本部 大竹 ブライアン（おおたけ ブライアン）

日本オラクルに新卒で入社。以来主にOracle Databaseの運用・設計・移行に関わる業務に携わってきた。 Oracle Enterprise Manager(EM)と出会ってから早5年。 その素晴らしさと使いやすさを広く世に普及するため、日々EMと戯れている。

本記事では、Oracle Enterprise Manager （以下EM)で Oracle Database（以下DB）を運用する上で効率的なEMの活用方法やオラクルコンサルタントとしてオススメしている機能について説明します。そもそもEMとは何か、EMを一般的にはどう使えば良いのかについても解説します。なお、本記事で取り扱う EM の画面例やマニュアルの参照情報は、特に断りがない限り Oracle Enterprise Manager Cloud Control 13c Release 2 を対象とします。

EMって何？何故EMがいいの？

そもそもEMとはなんなのでしょうか。

一言で表現するとオラクル製品を含め、システム全体を見える化・監視するためのブラウザベースの管理ツールです。（EMのアーキテクチャについては後述します）

他社の監視製品でもオラクル製品の運用や監視はできるのに、なぜEMなのでしょうか。

1つ目の理由は、オラクル社が予め定義した「メトリック」と呼ばれる監視単位を用意しているという点です。予めオラクル社として監視すべき項目とその監視頻度がメトリックごとに定義されており、ユーザはどのプロセスを監視すべきか、どのオブジェクトを見るべきか、などを新たに考慮する必要がありません。これらメトリックの収集頻度などは必要に応じてカスタマイズすることも可能です。

メトリックは主に監視用途として使用されますが、一部キャパシティ・プランニングとしても使用できるのも強みとなります。メトリックの鮮度には3つのカテゴリ（表1を参照）が存在します。Rawメトリック・データとはエージェントが収集した生の情報でEMリポジトリに格納されます。また、そのデータを元に毎時および日次単位でサンプリングした結果もEMのリポジトリに格納されています。最新のデータを確認するとRawメトリック・データが参照されますが、過去データを参照する場合はサンプリングされたデータが使用されます。データの鮮度が重要な場合は、都度EMを確認することを推奨します。

Oracle® Enterprise Manager Cloud Control管理者ガイド 13c リリース2 E78869-01

20.2 管理リポジトリのデータ保持ポリシー

https://docs.oracle.com/cd/E83823_01/EMADM/GUID-A3CDCD1E-294D-4472-82A7-F2CD30D8D9BA.htm#GUID-A3CDCD1E-294D-4472-82A7-F2CD30D8D9BA （February 19, 2017, 14:30 UTC+9）

表1: メトリックのデフォルトのパージポリシー

図1: EM画面例 – メトリック値の履歴グラフ

2つ目の理由は、GUIを使ってグラフィカルに操作が出来るという点です。

EMを使わない場合、DBで遅延などの問題が発生した時にどう対処すれば良いでしょうか。

EMでは後述する機能によって、上記作業をワンクリックで行うことができ、今までデータベース管理者（以下DBA）がやっていた作業を簡単に視覚化することが出来るため、時間の大幅な削減が可能となります。

3つ目の理由は、DBだけでなく、Oracle WebLogic ServerなどのミドルウェアやOS、ストレージといった様々なレイヤの製品を一括で監視できるという点です。

EMではインストール後、すぐに管理・監視ができるよう標準的にDBやOSに関する監視の定義情報を持っています。しかしながら、実際にシステムの基盤を構築する場合、各製品のバージョンの組み合わせは様々となります。つまり、EMがリリースされた時点ではサポートされていなかったバージョンの製品が含まれる可能性も出て来るということです。そのため、EMにはプラグインと呼ばれるアーキテクチャの採用により管理対象や機能を拡張できるようになっており、これを使用することにより新製品やサードパーティ製品を管理・監視するための情報を追加することが可能です。これにより、ワンストップですべてのレイヤを監視することができます。

プラグインの概要については下記を参照ください。

Oracle® Enterprise Manager Cloud Control概要 13cリリース2 E78871-01

1 Oracle Enterprise Manager Cloud Control 13cの概要

https://docs.oracle.com/cd/E83823_01/EMCON/GUID-DC86504F-9F4E-4D5F-92AC-49E898384FB9.htm#GUID-DC86504F-9F4E-4D5F-92AC-49E898384FB9 （February 19, 2017, 14:30 UTC+9）

なお、EMには大きく分けて2つの種類があります。 1つはDatabase Express と呼ばれる、単一のデータベースを監視・管理するための製品で、もう1つはCloud Controlと呼ばれる複数のデータベースを監視・管理するための製品です。今回の記事ではCloud Control（EMCC）をベースに話をさせていただきます。

図2: EMの種類の解説

EMのコンポーネントを理解しよう

EMとしては大きく3つのコンポーネントがあり、それぞれ異なる役割を担っています。

コンポーネント1 ：Oracle Management Server （OMS） OMSはEMの管理サービスであり、Oracle WebLogic ServerにデプロイされたWebベースのJ2EEアプリケーションとなります。OMAと連携し、管理対象であるターゲットから情報収集を行い、OMRにそのデータを格納します。ユーザがブラウザ経由でEM操作を行う際にアクセスするコンポーネントとなります。

コンポーネント2 ：Oracle Management Agent （OMA） OMAはEMの管理エージェントであり、管理対象のホストにデプロイすることで、OMSからの命令を実行したり、ターゲットのステータスやパフォーマンス情報をOMSにHTTP/HTTPSでアップロードします。

コンポーネント3 ：Oracle Management Repository （OMR）

OMRはEMの管理リポジトリであり、OMAが収集した全ての情報が保存されるリポジトリDBとなります。OMSからブラウザのEM画面を操作する際、OMSはOMR内のSYSMANスキーマ内に格納されたデータを検索し、表示します。

図3: EMのコンポーネント関係図

DBA観点でEMを使ってみよう

EMを使用することで、DBAが今までターミナル（CUIベース）で実施していた業務をグラフィカルに操作することが出来ます。従って、DBAの経験が無いまたは少ない方でも経験者と同等の情報を確認することが出来るようになります。 以下にOracle Databaseの管理においてEMで使用できる主な機能について説明します。

表領域使用率の確認

EMからデータベースの各表領域の使用率を確認することが出来ます。使用率の他にも表領域の割当サイズ、使用済みサイズ、使用率といった運用管理に必要な項目が表示されます。

図4: EM画面例 – 表領域の状態確認

データファイルの追加

データベースを運用していく中で、データ増加により表領域使用率が上昇することが想定されます。そのような場合、データファイルの拡張またはデータファイルの追加を行う必要があります。従来どおりにCUIで対応することも可能ですが、EMを活用することもできるという点を覚えて貰えればと思います。

図5: EM画面例 – データファイル追加

パフォーマンス管理（トップ・アクティビティ）

データベースを運用していく中で、SQLの性能劣化やインスタンス障害といった問題はどうしても発生してしまいます。従来であればAWRやSTATSPACKといったデータベースの性能統計レポートの分析やv$session、Active Session History（ASH）といったセッション情報を出力し、分析する必要がありました。これらの情報は性能/障害分析を行うにあたり重要ではありますが、レポートを見たことが無い人はどうやって分析するのだろうか、と悩んでしまうかもしれません。

図6: EM画面例 – トップ・アクティビティ

性能劣化や障害が発生したときは、EMでトップ・アクティビティ画面を見ることをオススメします。トップ・アクティビティ画面ではASHを自動でグラフ化してくれるため、どういったSQLが実行され、それぞれどういった待機イベントで待機しているかがグラフィカルに表示されます。例えば上図の場合、緑色のグラフが19時40分頃から大きくなっていることが見えます。緑色はCPUの待機イベントであるため、CPU待機による遅延が発生していることがわかります。

更にSQL文の種類（SELECT、DML、DDL） と待機イベントの割合も表示されるので、直感的にボトルネックとなっているデータベース待機の種類を把握特定することが出来ます。SQL ID またはセッションID を押下することで、SQLやセッション個別などのより詳細な情報も確認することが出来ます。

図7: EM画面例 – 上位SQLと上位セッションの一覧

パフォーマンス管理（AWRレポート出力）

従来と同じ方式で性能/障害分析を行う場合、EMからAWRレポートを出力させることが出来ます。出力させたAWRレポートはHTML形式でクライアント側に保存することも出来るので、後追いでの分析も可能です。

図8: EM画面例 – AWRレポート

下記の様に、異なる期間でのAWRレポートの比較もEMから行うことが可能です。

図9: EM画面例 – AWRの期間比較レポート

パフォーマンス管理（SQLモニタリング）

EMを使用したパフォーマンス分析を行うにあたり、オラクルコンサルタントとして良く使用するのがSQLモニタリングの機能となります。以下条件に当てはまるSQLが一覧で表示され、どれくらいのリソースを消費していたのかがひと目でわかります。

SQLモニタリングを使用するための前提条件

- 対象DBが11gR1以降

- 実行計画の行数が300行以下である

SQLモニタリングの対象となるSQL

- パラレルクエリを実行している

- I/O または CPUで5秒以上消費している

- MONITORヒント句を使ってSQLを実行している

明らかにボトルネックとなっていそうなSQLを見つけた後は、SQL ID を選択することによりリアルタイムでSQLの進捗度や実行計画のどの部分を実行しているかをグラフィカルに確認することが出来ます。筆者としてもこの機能は是非DBAの皆様に使って頂ければと考えます。

図10: EM画面例 – SQLモニタリング

SQLの検索

アプリ担当者から特定のSQLが急激に遅くなったので調査して欲しい、と言われても通常時はどのような実行計画だったのかを把握するのが困難な場合があります。AWRから該当SQLを探そうにも手元にレポートが無いとgrepで検索するのも一苦労です。そこでSQLの検索機能を使うことにより、キャッシュ上だけで無く、AWR内の情報から条件に合致したSQLを検索することも可能です。 ※ ただしキャッシュ上から情報がエイジアウトしている場合およびAWRレポートに載っていない場合は検索することが出来ません。

図11: EM画面例 – SQLの検索にて任意の文字列で検索

これまでに説明したEMのパフォーマンス関連の操作を行うためにはターゲットのデータベースに対してTuning Pack 及び Diagnostic Pack のライセンスが必要となります。 詳細については下記ガイドを参照ください。

Oracle® Enterprise Managerライセンス情報ユーザー・マニュアル 13cリリース2 E78874-01 https://docs.oracle.com/cd/E83823_01/OEMLI/toc.htm （February 19, 2017, 14:30 UTC+9）

EMの監視設定を理解しよう

EMのデフォルトの監視設定はオラクル社によって設定されています。問題が無ければデフォルトのまま運用してもいくのも良いのですが、現行の監視設定（頻度、しきい値など）を踏襲したい場合もあるかと思います。EMではそれぞれのメトリックに対してしきい値と収集スケジュールが設定されています。以下でそれぞれどのように操作するかを説明します。

しきい値の変更

メトリックのしきい値を変更したい場合は、各ターゲットの「メトリックと収集設定」の画面から変更することが可能です。警告とクリティカルのしきい値を使い分けることにより、アラート発生時の対応優先度を定義することが可能です。

図12: EM画面例 – メトリックと収集設定

収集頻度の変更

先ほどと同じ画面でそれぞれのメトリックの収集頻度も変更することが出来ます。収集頻度は秒単位で設定することも可能ですが、あまりにも短い頻度で収集するとターゲットおよびEMの各コンポーネントの負荷が上がってしまうため、収集頻度を変更する場合は負荷状況を確認しつつ設定することを推奨します。

オラクル社では一般的に運用する中で必要とされる監視項目をメトリックとして提供していますが、過去に発生した障害などに基づいた独自の監視項目が読者の環境にあるかもしれません。標準で提供されているメトリックの中で不足している項目があれば、メトリック拡張を作りましょう。

メトリック拡張

ユーザ自らSQLやOSスクリプトを登録して、メトリック（メトリック拡張）を作成することが出来ます。メトリック拡張の作成方法は本記事では割愛しますが、注意点として、収集したデータを格納するためのテーブル定義をユーザ自らが設計しなくてはいけません。単一列のみを取得するようなメトリックであれば特に注意点はありませんが、複数列を取得する場合は、必ず主キーとなる列を作成して下さい。主キーが無い場合、メトリック収集が出来ずエラーが出力され続け、想定通りに監視出来ない可能性があります。 もし主キーとなる列が作成出来ない場合は、以下例の様にSELECT文にrownumを使用することで一意の値が取得されるようになるのでオススメです。

  
SELECT rownum, pid, sid, rawtohex(laddr), name, gets FROM v$latchholder;
 
 

図13: EM画面例 – メトリック拡張の作成

モニタリング・テンプレート

複数の環境をEMで監視する場合、それぞれのターゲットでしきい値の変更、収集頻度の変更を行うのはとても煩雑です。モニタリング・テンプレート機能を使うことによって、メトリックの設定状況を「テンプレート化」して他の環境に適用することが出来ます。モニタリング・テンプレートの作成方法も本記事では割愛しますが、適用の際の注意点としてキー値（主キー）のあるメトリックの扱いに注意が必要です。

図14: EM画面例 – モニタリング・テンプレートの一覧

完全に同一なメトリック設定を適用する場合、「すべてのメトリック設定を置換する」を選択するか、「テンプレートとターゲットに共有のメトリックだけをオーバーライドします」を選択する必要があります。前者はすべてのメトリック設定を置き換えてしまうため、環境固有で設定すべきメトリック情報が上書きされてしまいます。例えば非Exadata環境のホストのモニタリング・テンプレートをExadata環境に設定すると、設定されるべきExadata固有のメトリックが設定されません。後者はテンプレートとターゲット間で共通しているメトリックだけの置換となるため、範囲を狭めることが出来ます。先ほどのExadataの例だと、共通しているホストのメトリックのみが置き換わるため、デフォルトで設定されているExadataのメトリックには影響がありません。

図15: EM画面例 – モニタリング・テンプレートの適用オプション

最後にメトリックのしきい値が超過した時にアラート通知を飛ばすための設定としてルール・セットとルールを設定します。

ルール・セット/ルール

ルール・セットとは、OMSで管理するターゲットに対応する1つ以上のルールをまとめた定義です。ルールとは、特定のイベント・問題・インシデントに対応するアクション定義であり、管理者へのアラート送信先や方法もルール内で定義します。管理者へのアラート通知は上記ルールに基づき、OMSを経由して各宛先アドレスへ送信されます。通知方法としてメール送信だけでなく、SNMPトラップやコマンドを指定することも可能です。

ルール・セットとルールの関係性は以下の通りです。

- 1つのルール・セットに複数のルールを設定することは可能 （1:n）

- 1つのルールを複数のルール・セットには設定できない （1:1）

1つのルール・セットですべてのターゲットに対する通知ルールを設定することができます。しかしターゲットによっては通知させたいメトリックが異なる場合やルール・セットをメンテナンスする際、すべてのターゲットに影響が出てしまいます。ルール・セットを分けることでターゲットごとに通知先が変更でき、かつメンテナンス性もあがるため、ターゲットごとにルール・セットを作成することを推奨します。

図16: ルールとルール・セットの関係性

最後に

本記事ではEMの基礎について解説させて頂きました。EMについての理解が深まったでしょうか。読者の皆様が今後EMを活用・運用して行く上でのきっかけなって頂ければ幸いです。