10gリリース5（10.2.0.5.0）
B53907-01
 目次 |
 索引 |
| Oracle Enterprise Manager アドバンスト構成 10gリリース5（10.2.0.5.0） B53907-01 |
|
Oracle Enterprise Manager 10g Grid Controlには、1つのEnterprise Manager実装において何百ものユーザー、何千ものシステムとサービスの規模を拡大および縮小する機能があります。
この章では、Oracle Enterprise Managerアプリケーションを使用して最適なパフォーマンスを実現するための手法について説明します。また、大規模な環境における容量計画、Enterprise Managerパフォーマンスのサイジングおよび最大化に役立つ情報も提供します。ルーチン・ハウスキーピングを保守し、パフォーマンスを定期的に監視することで、将来的なサイジング要件の正確な予測に必要なデータを入手できます。Enterprise Manager Grid Controlのバイタルサインを示す適切なベースライン値を理解し、ベースラインに対して警告およびクリティカルの妥当なしきい値を設定することにより、Enterprise Managerの自動的な監視が可能になります。
また、この章では、バックアップ、リカバリおよび障害時リカバリの実際的な方法と、Enterprise Managerの各層に対して実施できる様々な戦略についても説明します。
この章では次の項について説明します。
Oracle Enterprise Manager 10g Grid Controlのアーキテクチャは、処理の分散および並列化という、アプリケーション・パフォーマンス・チューニングにおける2つの重要な概念を具現しています。Grid Controlの各コンポーネントは、この両方の概念を応用して構成できます。
Enterprise Manager Grid Controlには、次のコンポーネントが含まれます。
Grid Controlアーキテクチャの詳細は、Oracle Enterprise Manager 10gの次のドキュメントを参照してください。
Oracle Enterprise Manager 10gのドキュメントは、Oracle Technology Network（OTN）の次のサイトから入手できます。
http://otn.oracle.com/documentation/oem.html
正確に容量を予測するためには、個々のEnterprise Manager Grid Controlデプロイからの実際のメトリック傾向情報が重要です。この情報を利用しながら、大まかな初期ホスト・システム・サイズを設定し、チューニングとメンテナンスを繰返し行うことで、Enterprise Manager Grid Controlデプロイの容量の正確な予測が可能になります。また、デプロイのパフォーマンスを常に最適レベルに保つうえでも、この情報が役立ちます。
Enterprise Manager Grid Controlのサイジング手法の実施手順は、次のとおりです。
手順1は、各デプロイにつき1回行うのみで済みます。手順2、3および4は、Enterprise Manager Grid Controlサイトを拡大する計画があるかどうかにかかわらず、デプロイが存続しているかぎり定期的に行う必要があります。これらの手順は、Enterprise Manager Grid Controlサイトのサイズや処理負荷にかかわらず、効率的なEnterprise Manager Grid Controlサイトにとって不可欠です。手順5に進むには、手順2、3および4を完了しておく必要があります。これは非常に重要です。手順5が必要となるのは、監視対象ターゲットの数を増やしてデプロイ・サイズを拡大しようとする場合のみです。しかし、これらの傾向を定期的に評価することは、デプロイに行われた他の変更を評価するうえでも役立ちます。
最初のプラットフォームにまだEnterprise Manager Grid Controlをインストールしていない場合、この手順で、実際のEnterprise Manager Grid Controlデプロイでの経験に基づく概数値を選択できます。Enterprise Manager Grid Controlをすでにインストールしてある場合は、
手順2に進みます。標準的なデプロイ・サイズとして、小、中、大の3つが定義されています。Enterprise Manager Grid Controlデプロイのサイズは、監視対象のシステム（またはターゲット）の数およびタイプによって大まかに決まります。
| デプロイ・サイズ | ホスト | ホスト当たりのCPU |
ホスト当たりの メモリー（GB） |
|---|---|---|---|
|
小（監視対象ターゲット数が100） |
1 |
1（3GHz） |
2 |
|
中（監視対象ターゲット数が1,000） |
1 |
2（3GHz） |
2 |
|
大（監視対象ターゲット数が10,000） |
2 |
2（3GHz） |
2 |
| デプロイ・サイズ | ホスト | ホスト当たりのCPU | ホスト当たりのメモリー（GB） |
|---|---|---|---|
|
小 |
管理サーバーとホストを共有 |
管理サーバーとホストを共有 |
管理サーバーとホストを共有 |
|
中 |
1 |
2 |
4 |
|
大 |
2 |
4 |
6 |
前出の各表は、各デプロイ・サイズに対応する推定最小ハードウェア要件を示したものです。前述の大規模なデプロイで示したように、複数のホスト上で動作する管理サーバーは、処理を各サーバー間で分散します。
また、複数の管理サーバーをデプロイした場合、1つの管理サーバーに障害が発生したときは他のサーバーが操作を引き継ぐという基本的なフェイルオーバー機能が働きます。サーバー・ロード・バランサ（SLB）を使用すると、管理サーバー・ホストに障害が発生したときに、Enterprise Manager UIクライアントに対して透過的なフェイルオーバーが行われます。また、使用可能な管理サーバー間でリクエスト・ロードが分散されます。SLBはロード・バランシングのみを行うホスト・マシンです。フェイルオーバー機能を提供するために、SLBをクラスタ化できます。
管理リポジトリに対して複数のホストを使用する場合は、Oracle Real Application Clusters（RAC）の使用が前提になります。この場合、複数のホスト・システム上で同一のOracleデータベースをアクセス可能にすることができます。管理サーバーに必要な記憶域の他、管理リポジトリの記憶域も必要になることがあります。管理サーバーの記憶域は、管理ターゲットの数に大きな影響を受けません。このため、Enterprise Manager Grid Controlドキュメントで推奨されている数値で十分間に合います。
Enterprise Manager Grid Controlをデプロイする際、各層間のネットワーク・パフォーマンスを第一に考慮する必要があります。Enterprise Manager Grid Controlでは、各アプリケーション層間のネットワークの異常、障害および故障に対するトレランスが、エラー・トレランスおよびエラー・リカバリによって保証されています。特に管理エージェントは、Enterprise Manager全体のパフォーマンスに大きな影響を与えることなく、パフォーマンスや信頼性の低い、管理サービスへのネットワーク・リンクを処理できます。ネットワーク問題が原因で起こる1つの管理エージェント・データの遅延に関するかぎり、その影響はEnterprise Manager Grid Controlのシステムワイドなレベルではほとんど気づかない程度のものです。
しかし、管理サービスと管理リポジトリの間のネットワーク待機時間については、わずかに増えるだけでその影響は大きくなります。Enterprise Manager Grid Controlの実装では、管理サービスと管理リポジトリの間のネットワーク・リンクの品質が十分でない場合に、重大なパフォーマンス問題が発生することがわかっています。次の図に、Enterprise Managerのコンポーネントと、それらを接続するネットワーク・リンクのパフォーマンス要件を示します。これらは、より規模が大きい実際のEnterprise Manager Grid Controlデプロイおよびテストに基づいて決定された最小要件です。
図11-2から、Enterprise Manager Grid Controlコンポーネント間のネットワーク・リンクの帯域幅および待機時間の最小要件が、Enterprise Managerアプリケーションのパフォーマンスに大きく影響することがわかります。
これが、5つの中で最も重要な手順です。Enterprise Manager Grid Controlサイトのバイタルサインの傾向や大きな変動をある程度監視および理解しておかないと、サイトのパフォーマンスが重大なリスクに晒されることになります。監視対象ターゲットはそれぞれ、関連付けられた管理エージェントを介して、ロードおよび集計のためにデータを管理リポジトリに送信します。これは、他のエンタープライズ・アプリケーションと同レベルの管理およびメンテナンスを必要とする大量のアクティビティになります。
Enterprise Managerには、その状態を反映するバイタルサインがあります。これらのバイタルサインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。パフォーマンスが許容可能なときのバイタルサインの現実的なベースラインを設定する必要があります。ベースラインを設定した後は、Oracle Enterprise Manager Grid Controlの組込み機能を使用して、警告およびクリティカルのしきい値を設定できます。これにより、Enterprise Managerサイトに重大な変更があった場合は自動的に通知されます。次の表に、
2つのサイトにおけるEnterprise Manager Grid Controlのバイタルサインのポイント・イン・タイム・スナップショットを示します。
この2つのEnterprise Managerサイトのパフォーマンスは対極的です。
EMサイト1は、ローダーの行/秒/スレッドとロールアップの行/秒の値が大きく、非常に高いパフォーマンスで動作しています。また、ローダーおよびロールアップの実行時間の割合が非常に低くなっています。管理サーバー・ホストと管理リポジトリ・サーバー・ホストのCPU使用率は両方とも低い値です。特に重要なのは、UIページのレスポンス時間が非常に優れていることです。つまり、サイト1では最小限の労力で多くの処理が行われています。構成、チューニングおよびメンテナンスが適切に行われたOracle Enterprise Manager Grid Controlサイトは、このような状態になります。
これに対し、EMサイト2には問題があります。ローダーおよびロールアップでの行の処理効率がよくありません。最も大きな問題は、UIページのレスポンス時間です。サイト2にボトルネックが存在するのは明らかです。複数のボトルネックがある可能性があります。
これらのバイタルサインはすべて、Enterprise Managerインタフェースから取得できます。ほとんどの値は各ホストの「すべてのメトリック」ページか、または管理サーバーの「すべてのメトリック」ページに表示されます。警告およびクリティカルのアラートにしきい値を割り当て、これらのバイタルサインの傾向を一定期間観察することで、良好なパフォーマンスを維持し、将来のリソース要件を予測することができます。次のようにして、これらのバイタルサインの監視を計画してください。
次の手順で、バイタルサインの値が設定済しきい値の範囲にない場合に行う操作を示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。
Enterprise Manager Grid Controlサイトの動作を良好に保つために、ルーチン・ハウスキーピングが役立つことを覚えておくことが重要です。次に、ハウスキーピングのタスクとその適切な実行間隔を示します。
exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_RAW', null, .000001, false, 'for all indexed columns', null, 'global', true, null, null, null);
exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_1HOUR', null, .000001, false, 'for all indexed columns', null, 'global', true, null, null, null);
exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_1DAY', null, .000001, false, 'for all indexed columns', null, 'global', true, null, null, null);
Oracle Enterprise Managerにより、自動的にデータが切り捨てられ、デフォルトの保存時間よりも長く存在しているパーティションで使用されていた領域が再利用されます。Enterprise Managerでは管理サーバーの動作中にパーティションを削除できません。削除すると、多数のSQLカーソルが誤って無効化されるために、Enterprise Managerエラー・メッセージが発生することがあります。すべての管理サーバーを停止した状態で、次のコマンドを実行する必要があります。
Enterprise Manager Grid Controlアプリケーションのパフォーマンスのボトルネックの代表的な原因を次に（頻度の高い順に）示します。
バイタルサインが日常的に設定済しきい値の範囲外にある場合、または一定期間そのような傾向を示している場合は、2つの領域に対処する必要があります。まず、前述したすべてのハウスキーピングが最近行われていることを確認します。2番目に、Enterprise Manager Grid Controlアプリケーションのリソース使用率に注意する必要があります。前出の表に列記したバイタルサインは、Enterprise Manager Grid Controlのリソース使用率およびスループットのキー・ポイントを反映しています。次の各項で、重要なバイタルサインのいくつかを説明し、ベースライン値に基づいて設定されたしきい値を超えたバイタルサインに対処するために使用可能なオプションを示します。
サイトのパフォーマンスを評価するように求められ、高いCPU使用率に気づいた場合、どのリソースがどの場所で使用されているかを判断するために、いくつか手順を実行する必要があります。
パフォーマンスのボトルネックの兆候として最も多いのは、高いCPU使用率です。通常は、管理リポジトリが最も多くCPUを消費しており、管理リポジトリを重点的に調べる必要があります。ハードウェア・リソースの制約が特になく、適切に構成およびメンテナンスが行われた管理リポジトリ・ホスト・システムの場合、CPU使用率の合計は平均して約40%以下になります。管理サーバー・ホスト・システムのCPU使用率の合計は、平均して約20%以下である必要があります。平均値がこのように比較的低い場合は、アクティビティの急な増加にも十分に対応できます。アクティビティの急な増加を許容することで、ページ・パフォーマンスを長期間にわたって安定させることができます。Enterprise Manager Grid Controlサイトのインタフェース・ページのレスポンスが良好（約3秒）で、大きな（間断のない）ローダー・バックログが存在しない場合、CPUの使用率が推奨値を超えていても、それが大幅な上昇傾向の一部であると考えられる場合を除き、対処する必要はありません。
管理リポジトリのCPU使用率が高い場合、その根本的な原因を突き止めるために、前述の
手順3.bを行うことをお薦めします。これにより、管理リポジトリの「パフォーマンス」ページから、処理で最も多くCPUを消費しているSQLを突き止めることができます。この方法は、いくつかの実際のサイトで使用され、成功しています。
Intelベースのホスト上でEnterprise Managerを実行している場合は、Enterprise Manager Grid Control管理サービスと管理リポジトリの両方が、デプロイ先のホスト上で有効になっているハイパースレッディング（HT）のメリットを得られます。HTはIntelプロセッサの特定の最新モデルの機能であり、一定量のCPU命令のパラレルな実行を可能にするものです。これによって、システム上で物理的に使用可能なCPUの数は倍増します。HTを使用した場合、HTが使用可能になっていない同じシステムに比べて、CPU処理能力が約1.5倍になることがテストで実証されています。これにより、大幅にシステム・パフォーマンスを向上させることができます。管理サービスと管理リポジトリはどちらも複数のプロセスを同時に実行することが多いため、HTを使用するメリットは非常に大きくなります。
ローダーのバイタルサインは、すべてのEnterprise Managerエージェントからシステムに絶えず送り込まれるデータの正確な量を示します。ここで最も重要な項目は、実行時間の割合と行/秒/スレッドです。（ローダーの）実行時間の割合は、構成されているローダー・スレッドが受信データ・ボリュームの処理に対応しているかどうかを示します。この値が100%に近づくにつれて、ロード・プロセスが受信データ・ボリュームの処理に対応できていないことが明らかになります。この値が低いほど、ローダーの実行効率は高く、ローダーが管理サービス・ホストから必要とするリソースは少なくなります。管理サーバーにローダー・スレッドを追加すると、ローダーの実行時間の割合を減らすのに役立ちます。
行/秒/スレッドは、1秒当たりの各ローダー・スレッドのスループットの正確な測定値です。この数値が高いほど良好です。適切に構成およびメンテナンスされた小規模なEnterprise Manager Grid Controlサイトでは、行/秒/スレッドの値が1200に達する場合が観察されています。ローダー・スレッド数を増やしておらず、この数値が下降傾向にある場合、将来的に問題が起こる可能性があります。行/秒/スレッドの値の減少に対処するには、ローダー・スレッドを追加する方法があります。
管理サーバー構成ファイル内では、ローダー・スレッドの数はデフォルトで常に1に設定されます。管理サーバー1つにつき、最大10までのローダー・スレッドを持つことができます。多数の管理エージェントが構成されているEnterprise Manager Grid Controlサイトでは、管理サーバーにローダー・スレッドを追加すると、通常は全体のホストCPU使用率が2〜5%増加します。この値は、サイトの必要性に応じて変更できます。中規模および小規模の構成では、複数のローダー・スレッドが必要になることはほとんどありません。ローダー・スレッドを追加する際の簡単なガイドラインを次に示します。
（すべての管理サーバー全体での）最大合計ローダー・スレッド= 2×管理リポジトリ・ホストのCPUの数
ローダー・スレッドを追加する際には、収穫逓減が働きます。2つ目（またはそれ以上）のスレッドを追加すれば100%の能力が得られるわけではありません。ただし、プラスの効果もあります。ローダー・スレッドを追加すると、行/秒/スレッドは減少しますが、合計行/時間のスループットは増加します。合計行/時間の値に大きな改善が見られず、ローダー・ファイルのバックログ・サイズが拡大し続けている場合、ローダー・スレッドの数を増やしてもそのコストに見合わない可能性があります。この場合は、他のチューニングまたはハウスキーピングの機会を探る必要があります。
ローダー・スレッドを追加するには、次の構成パラメータを変更します。
em.loader.threadPoolSize=n
ここで、nは正の整数1〜10です。デフォルトは1で、1〜10以外の値を指定した場合、スレッド・プール・サイズはデフォルトの1に設定されます。このプロパティ・ファイルは、{ORACLE_HOME}/sysman/configディレクトリ内にあります。このパラメータを変更した場合、管理サービスを再起動して新しい値とともに再ロードすることが必要になります。
ロールアップ・プロセスは、Enterprise Manager Grid Controlの集計メカニズムです。1時間に1回、管理リポジトリ表MGMT_METRICS_RAWにロードされた新しいRAWデータがすべて処理され、平均値が計算されて、表MGMT_METRICS_1HOURおよび
MGMT_METRICS_1DAYに格納されます。ロールアップの2つのバイタルサインは、行/秒と実行時間の割合です。ロールアップでは大量のデータ行が処理されるため、管理リポジトリのバッファ・キャッシュ領域を最も多く消費する傾向があります。このため、ロールアップのバイタルサインを調べることで、バッファ・キャッシュ・サイズの拡大により効果が得られるかどうかを判断できます。
ロールアップの行/秒は、1秒間に処理、集計および格納されている行の正確な数を示します。バッファ・キャッシュのサイズが適切で、I/Oの速度も妥当なサイトでは、通常この値は1秒当たり約2,000行（+/- 500）になります。この値が一定期間の下降傾向を示している場合、将来的に問題が発生する可能性がありますが、実行時間の割合が100未満であれば、そのサイトは問題ないと考えられます。
ロールアップの実行時間の割合が上昇傾向にある（またはベースラインを超えている）場合、管理リポジトリのバッファ・キャッシュをまだ最大値に設定していなければ、バッファ・キャッシュ設定値を大きくすると効果があることがあります。通常は、バッファ・キャッシュを大きくするメリットがある場合には、管理リポジトリ・ホストのリソース使用率およびスループットが全体的に向上します。ローダー統計は少し改善されます。ホストのCPU使用率は低下し、I/Oは減少します。最も明らかに改善されるのは、ロールアップ統計です。ロールアップの行/秒と実行時間の割合のどちらにも顕著な改善があります。このいずれのバイタルサインにも改善が見られない場合は、バッファ・キャッシュを元のサイズに戻してもかまいません。古い「バッファ・キャッシュ・ヒット率」メトリックは、誤解を招く場合があります。バッファ・キャッシュが非常に小さいためにEnterprise Manager Grid Controlのパフォーマンスが低下している場合に、「バッファ・キャッシュ・ヒット率」の値が高くなることがテストで観察されています。バッファ・キャッシュを大きくしてもGrid Controlのパフォーマンスが改善されない場合もあります。通常、これはアプリケーションの他の場所でリソース制約や競合があるためです。高いCPU使用率のセクションに示された手順を使用して、競合の場所を特定することを検討してください。また、Grid Controlでは、データベースそのものからバッファ・キャッシュのサイズ設定に関するアドバイスを提供します。これは、データベースの「メモリー・パラメータ」ページで使用可能です。
バッファ・キャッシュの拡大を検討する際には、オペレーティング・システムにEnterprise Manager Grid Controlのパフォーマンスの改善に役立つメカニズムが存在する可能性があることに注意してください。たとえば、Red Hat Linuxで使用可能なlarge memoryオプションがその一例です。Linux OS Red Hat Advanced Server™ 2.1（RHAS）には、big pagesという機能があります。RHAS 2.1では、bigpagesは大きな共有メモリー・セグメントの事前割当てに使用できる起動パラメータです。この機能を大きな管理リポジトリSGAとあわせて使用することで、Grid Controlアプリケーション全体のパフォーマンスを大幅に向上させることができます。Red Hat Enterprise Linuxa 3からは、big pages機能はhuge pagesと呼ばれる新機能にかわり、起動パラメータは必要なくなりました。
収集クラスには、短期実行タスク（タスク・クラス0）および長期実行タスク（タスク・クラス1）の2種類があります。ワーカーには、収集を処理するタイミングに基づいてタスク・クラスが割り当てられます。デフォルトでは、ワーカーは短期実行タスクと長期実行のタスクごとに1つずつ作成されます。クラスごとのデフォルトのワーカー数は、
mgmt_task_Worker_counts表内に保管されています。
この数は、mgmt_collection.set_worker_count()プロシージャを使用して増減できます。
例1: mgmt_collection.set_worker_count(0,2)
この例では、短期実行タスクに対して収集数のデフォルト値が2に設定されます。
例2: mgmt_collection.set_worker_count(1,2)
この例では、長期実行タスクに対して収集数のデフォルト値が2に設定されます。
数の設定後、mgmt_collection.start_workers()を実行して収集を開始する必要があります。このコールによって、既存のワーカー（DBMSジョブ）が停止され、mgmt_task_Worker_counts表で指定されているデフォルト数に基づいて新しいワーカーが開始されます。
emd_maintenance.submit_em_dbms_jobs()がコールされると、収集ワーカーは正常に開始されます。
「管理サービスとリポジトリ」→「すべてのメトリック」→「リポジトリ収集パフォーマンス」からタスク・クラスごとの収集のバックログを確認し、このバックログに基づいてワーカーを設定できます。
mgmt_collection.run_workerを実行すると、収集ワーカーを現在のセッションと同期的に実行することもできます。
例: mgmt_collection.run_worker(0) ;
これにより、現在のセッションに含まれる保留中の短期実行タスクが処理され、保留中の収集がなくなると終了します。
ジョブ、通知およびアラートは、Enterprise Manager Grid Controlサイトの管理サービスの処理効率を示します。これらの値がよくない傾向を示している場合、通常はアプリケーションの他の場所に競合があります。これらの値の有効な使用方法は、複数の管理サーバーを使用して実行した場合のメリットを測定することです。各管理サーバーにはジョブ・ディスパッチャが1つずつあります。管理サーバーを追加しても、必ずしもこれらの値が改善されるわけではありません。一般に、アプリケーションにリソース競合問題が存在していなければ、管理サーバーを追加することでGrid Controlの全体のスループットが改善します。その改善の程度を測定するには、ジョブ、通知およびアラートのバイタルサインが役立ちます。
Enterprise Managerデプロイにおける様々なチャネルのI/Oスループットを監視することは、良好なパフォーマンスを実現するうえで不可欠です。少なくとも次の3つの異なるI/Oチャネルに対して、ベースラインおよびアラートのしきい値を定義する必要があります。
これらのチャネルそれぞれについて、最大スループットおよび持続的スループットI/O機能を理解しておく必要があります。この情報および設定したベースライン値から、Grid Controlでこれらのチャネルに対して警告およびクリティカルのアラートの妥当なしきい値を導き出すことができます。しきい値を設定した後は、サイトでこれらのしきい値に近づいた場合に、自動的に通知されます。Grid Controlのサイト管理者でも、サイトでこれらのI/Oチャネルが処理できる内容を知らなかったり、誤解していることがあります。このような場合、Enterprise Manager Grid Controlがこれらのチャネルに過度な処理をさせることになり、それによってサイトのパフォーマンスは低下します。このような状況では、多くのバイタルサインがその影響でよくない値を示します。
管理リポジトリが関連しているかどうかを調べるには、Grid Controlを使用して「データベース・パフォーマンス」ページを確認します。管理リポジトリの「パフォーマンス」ページで、最大消費時間を示す待機グラフをクリックします。このグラフから、実際に待機しているSQLコードまたはセッションにドリルダウンできます。これは、ボトルネックの原因となっている箇所を理解するために役立ちます。
確認するもう1つの領域は、バックアップや別のアプリケーション、複雑なSQL問合せや複数のデカルト積などを扱ってデータ・マイニングをしている社員がいる場合など、Enterprise Manager Grid Control以外のソースからの予期しないI/Oロードです。
リポジトリI/Oの合計に関連する問題は、2つの要因により発生します。1つ目は、定期的にハウスキーピングが行われていないことです。Grid Controlセグメントの一部が過度に断片化されるため、深刻なI/Oドレインが発生することがあります。2つ目に、適切にチューニングされていないSQL文がサイトのI/O帯域幅の大部分を消費している可能性もあります。Grid Controlの多くのバイタルサインの急な悪化は、ほとんどがこの2つの主要な問題によって起こります。また、ハウスキーピングが適切に行われていないために、管理リポジトリの割当てサイズが大幅に増加することもあります。
これを活用した重要な機能の1つが、非同期I/Oです。非同期I/Oを有効化すると、Grid Controlアプリケーションの全体のパフォーマンスが大幅に向上する可能性があります。Sun Solaris™およびLinuxオペレーティング・システムにはこの機能が搭載されていますが、デフォルトでは無効になっていることがあります。Microsoft Windows™オペレーティング・システムでは、デフォルトで非同期I/Oが使用されます。管理リポジトリ・ホストおよび管理サービス・ホストに対して、このオペレーティング・システム機能を有効化しておくことを強くお薦めします。
他のパフォーマンス低下はないが、Enterprise Managerのユーザー・インタフェース・ページが遅いことがあります。ページの遅れの一般的な原因は、Enterprise Managerハウスキーピングの領域が見落とされていることにあります。Enterprise Managerのページ・パフォーマンスの監視における最初の項目は、Enterprise Managerビーコンの使用です。これらの機能は、Enterprise Manager以外のWebアプリケーションに対しても有用です。
ビーコンは、軽量なページ・パフォーマンス監視ターゲットとなるように設計されています。管理エージェント上でビーコン・ターゲットを定義した後は、そのビーコンを使用してUIパフォーマンス・トランザクションを定義できます。これらのトランザクションは一連のUIページ・ヒットです。手動で1回ウォークスルーします。それ以降は、ビーコンは指定された間隔でUIトランザクションを自動的に繰り返します。ビーコン・トランザクションが実行されるたびに、Enterprise Managerはそのパフォーマンスを計算し、履歴目的で格納します。また、ページ・パフォーマンスが指定したしきい値を下回ったときにアラートを生成することもできます。
Enterprise Managerビーコンを構成する場合、まず、このプロセスで指定したホームページを監視する1つの事前定義済トランザクションから開始します。その後は、いくつでも必要な数のトランザクションを追加できます。ネットワーク上の異なるポイントから同じWebアプリケーションに対する追加のビーコンを設定して、WANの遅延がアプリケーション・パフォーマンスに与える影響を測定することもできます。Enterprise Manager Grid Controlにより監視されるすべてのWebアプリケーションに対して、これと同じ機能が使用可能です。
パフォーマンスが悪いUIページが示された後は、Enterprise Manager Grid Controlのページ・パフォーマンス監視の2つ目の項目に進みます。Grid Controlにおけるこのエンドツーエンド（E2E）監視機能は、ページの処理時間をその基本単位に分解できるように設計されています。これにより、ページ・パフォーマンスを高めるためにメンテナンスが必要となる時期を特定できます。Grid ControlにおけるE2E監視を使用すると、1つのページ・ヒットのクライアント側とサーバー側の両方の処理を分解できます。
「中間層パフォーマンス」セクションの次のページには、そのページの層別の処理時間が示されます。「処理時間ブレークダウン」という円グラフの最大の区分（上のJDBC時間）をクリックすると、SQLの詳細が表示されます。SQL文をクリックすると、そのSQL文の実行について一定期間のパフォーマンスが表示されます。
「JDBC」ページに、システムでページ時間の実行の大部分が消費されているSQLコールが表示されます。このSQLコールは、個別のDML文の場合もあれば、PL/SQLプロシージャ・コールの場合もあります。個別のSQL文の場合、その文によりアクセスされるセグメント（表およびその索引）を調べて、そのハウスキーピング（再作成および再編成）の必要の有無を判断する必要があります。PL/SQLプロシージャ・コールの場合は、管理リポジトリ内のプロシージャのソース・コードを参照して、そのコールによりアクセスされる表および関連する索引を特定する必要があるため、もう少し複雑になります。
セグメントを特定したら、管理サーバーを停止した状態で、必要な文の再作成および再編成を実行できます。これにより、ページ・パフォーマンスは大幅に向上します。オープン・アラート、システム・エラーおよびメトリック・エラーの数が多すぎる場合など、再作成と再編成のみではページ・パフォーマンスが改善されないこともあります。このようなコールを改善するには、（たとえば、クリーンアップや削除を行って）これらの問題の数を減らすしかありません。これらの数を減らした後は、セグメントの再作成および再編成を実行して、パフォーマンスを最適化する必要があります。これらのシナリオについては、11.2.3項で説明しています。最新状態が維持されていれば、UIページ・パフォーマンスをそれほど頻繁に分析する必要はありません。
将来の記憶域要件を決定することは、バイタルサイン傾向の有効利用の最もよい例です。Grid Controlには、「一定期間におけるターゲット合計数」および「一定期間における管理リポジトリ・サイズ」という2つのグラフが組み込まれています。将来の記憶域要件の予測には、これらのグラフを使用できます。
どちらのグラフも、管理サービスの「すべてのメトリック」ページで使用できます。この2つのグラフの間に相関関係があることは明らかです。両方の曲線に適用された直線は、ほぼ同じ増加率を表します。Enterprise Manager Grid Controlに監視対象のターゲットを追加した後、31日間は管理リポジトリの拡大が見られます。これは、ターゲットの管理リポジトリ領域を消費するデータのほとんどが、管理リポジトリで完全に表示されるようになるまで約31日かかるためです。次の1年間は、そのターゲットは少しずつ拡大を続けます。これは、最大レベルのデータ集計におけるデフォルトの最長データ保存時間が1年であるためです。最初の31日間に比べると、これはさほど重要ではありません。
ターゲットの追加を停止すると、グラフは約31日間横ばいになります。グラフが横ばいになると、追加したターゲット数と、管理リポジトリ内で使用される追加領域の大きさの間に相関関係が現れます。Enterprise Manager Grid Controlデプロイ・プロセスの早い段階からこれらの値を追跡することで、サイトの記憶容量を積極的に管理できます。この履歴は非常に重要なツールです。
CPU使用率とターゲット合計の間にも同様の種類の相関関係を作成して、それらの要件を判断することができます。CPU使用率の場合、ターゲットを追加すると、横ばい状態がより早く見られます。ターゲットの追加後は、直近の増加率を超えるほどCPUコストが一定期間にわたって大幅に増加することはなくなります。新規メトリックの追加または収集の増加にかかわらず、新しい監視を既存のターゲットに適用すると、たいていはCPU使用率が増加します。
Enterprise ManagerにはGrid Controlコンソールに対するポータブルなブラウザベースのインタフェースとOracle Application Serverのテクノロジが組み込まれていますが、それらは中間層の管理サービス・ツールとして機能します。このツールは、管理リポジトリおよび履歴データを管理するためのデータベース・サーバー・テクノロジを基盤としています。この項では、これらの高可用性に関するトピックへの実際的なアプローチと、Enterprise Managerの各層に対して実施できる様々な戦略について説明します。
Oracleデータベースの場合、バックアップに関するベスト・プラクティスは、標準的なデータベース・ツールを使用し、次のようにすることです。
この場合は、全体バックアップを作成した後、以降は毎回増分バックアップを作成します。増分の変更をロールアップしてベースラインを作成し、新しい全体バックアップ・ベースラインを作成します。
推奨バックアップ計画を使用すると、Grid Controlの機能を利用してバックアップを実行することもできます。バックアップ・ジョブは、Grid Controlジョブ・サブシステムにより、自動的にスケジューリングされます。バックアップの履歴はレビューで利用することができ、バックアップのステータスはデータベース・ターゲットのホーム・ページの「ジョブ・アクティビティ」セクションに表示されます。
このジョブとアーカイブおよびフラッシュバック・テクノロジを併用すると、管理リポジトリのいずれかの部分が失われた場合のリストア・ポイントが得られます。このバックアップ処理およびアーカイブ・ログとオンライン・ログにより、管理リポジトリを最後に完了したトランザクションまでリカバリすることができます。
アーカイブおよびフラッシュバック・テクノロジを有効にするには、「リカバリ設定」ページを使用し、次のものを有効にします。
データベースを停止し、管理サービスの全プロセスを再起動します。
データベースを停止し、管理サービスの全プロセスを再起動します。
Enterprise Managerを使用したバックアップの構成方法のサマリーについては、『Oracle Database 2日でデータベース管理者』を参照してください。
データベースの高可用性に関するベスト・プラクティスの付加情報については、『Oracle高可用性アーキテクチャおよびベスト・プラクティス』を参照してください。
バックアップ・ジョブの実行頻度は、Grid Control環境で生成されるデータの量と、リストアが必要な場合に耐えられる停止時間の長さに応じて設定できます。停止期間が短く、データベースのリストアによって品質保証契約を満たすことができない場合は、Real Application Clusters（RAC）やData Guardデータベースなど、管理リポジトリの可用性に関するその他の戦略を検討する必要があります。管理リポジトリのその他の高可用性オプションについては、Oracle Technology Network（OTN）のMaximum Availability Architecture（MAA）のページ（http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm）からアクセスできる『Configuring Enterprise Manager for High Availability』という論文を参照してください。
Oracleデータベースの場合、リカバリのベスト・プラクティスは用意しておく必要があります。状況によっては、管理リポジトリ、管理サービスおよび管理エージェントがGrid Controlにアクセスすることができないので、コマンドライン・インタフェースを使用してRMANコマンドを入力する必要があります。
管理リポジトリが影響を受けるような状況が発生すると、RMANに対する管理インタフェースをGrid Controlから得ることができなくなります。
RMANを使用したデータベース・リカバリの構文例を次に示します。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータベースのリカバリに関する情報を参照してください。
RMAN> STARTUP MOUNT; RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN;
管理リポジトリのリカバリを検討する際は、次の2つの場合を考える必要があります。
Enterprise Managerに関する特別な考慮事項はありません。データベースがリカバリされたら、データベースおよび管理サービス・プロセスを再起動します。その後、管理エージェントによって保留中のファイルが管理リポジトリにアップロードされます。
管理エージェントは、リセットされるまで管理リポジトリと正常に通信できません。次のステップを手動で実行する必要があります。
$AGENT_HOME/sysman/emdディレクトリからagntstmp.txtおよびlastupld.xmlファイルを削除します。
/stateおよび/uploadサブディレクトリに移動し、その中身をクリアします。
これらのステップは、管理エージェントごとに実行する必要があります。
不完全リカバリの場合、前述の手順を完了するまで、管理エージェントがデータをアップロードできないことがあります。また、このタイプのリカバリ後に管理エージェントが管理サービスと通信できない可能性があることは、インタフェースにすぐには示されません。この情報は、管理エージェントのログまたはコマンドラインの管理エージェント・ステータスから取得できます。不完全リカバリが必要な場合は、管理エージェントごとにこの手順を実行する必要があります。
管理サービスはステートレスであるため、バイナリ・ファイルおよび構成ファイルを可能なかぎり短時間内にリストアする必要があります。この場合、他に2つの方法があります。
高可用性の管理サービス・インストールの場合、ミラーリング・テクノロジを使用して/recvディレクトリが保護されていることを確認することをお薦めします。/recvディレクトリは、管理エージェントから受信したファイルの内容をデータベースの管理リポジトリに書き込む前に、管理サービスがそのファイルをステージングする際に使用されます。
管理エージェントは、そのXMLファイルを管理サービスに転送し終わると、XMLファイルのコピーを削除します。その場合、管理エージェントから送信されたメトリック・データは失われます。
管理エージェントのリカバリは、管理エージェントがステートレスでない点を除き、管理サービスのリカバリに類似しています。使用できる方法は2つあります。
ホスト名が変更されていない場合は、ディスクのバックアップとリストアで十分です。
管理サービスの場合と同様に、ミラーリング・テクノロジを使用して/stateおよび/uploadディレクトリを保護するようお薦めします。
ノード障害が発生した場合、RMANまたはOSコマンドを使用してデータベースをリストアできます。このプロセスを短時間で行うには、Data Guardを実装して、管理リポジトリを別のハードウェア・ノードにレプリケートします。
管理リポジトリを新しいホストにリストアする場合、データベースのバックアップをリストアし、新しい管理リポジトリ場所を指すように管理サービスごとにemoms.propertiesファイルを手動で変更します。また、各管理サービスのtargets.xmlファイルを更新し、新しい管理リポジトリの場所を反映させる必要もあります。リカバリの際にデータ損失が発生した場合は、「管理リポジトリのリカバリ」を参照してください。
1つの管理サービスに障害が発生した場合に、管理サービスから管理リポジトリへの再接続を短時間で行うには、透過的アプリケーション・フェイルオーバー（TAF）対応の接続文字列を使用して管理サービスを構成します。管理サービスは、emoms.propertiesファイル内でTAF接続文字列を使用して構成できます。このファイルでは、FAILOVER構文を使用して通信が自動的に別のノードにリダイレクトされます。次に例を示します。
EM= (description= (failover=on) (address_list= (failover=on) (address=(protocol=tcp)(port=1522)(host=EMPRIM1.us.oracle.com)) (address=(protocol=tcp)(port=1522)(host=EMPRIM2.us.oracle.com))) (address_list= (failover=on) (address=(protocol=tcp)(port=1522)(host=EMSEC1.us.oracle.com)) (address=(protocol=tcp)(port=1522)(host=EMSEC2.us.oracle.com))) (connect_data=(service_name=EMrep.us.oracle.com)))
障害時リカバリに使用するハードウェアに、管理サービスおよび管理エージェントをプリインストールします。こうすることで、Enterprise Managerバイナリ・ファイルのコピーをバックアップからリストアする手順と、管理サービスおよび管理エージェントの構成ファイルを変更する手順を省略できます。
実際の障害リカバリ時には、新しいホスト上で動作するすべてのターゲットが管理エージェントでクリーン検出されるように、管理エージェントを再インストールするほうが簡単です。
|
 Copyright © 2003, 2009 Oracle Corporation. All Rights Reserved. |
|