ヘッダーをスキップ
Oracle Enterprise Manager管理
11gリリース1（11.1.0.1）
B61022-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

9 Enterprise Managerデプロイメントのサイジング

Oracle Enterprise Manager 11g Grid Controlには、1つのEnterprise Manager実装において何百ものユーザー、何千ものシステムとサービスの規模を拡大および縮小する機能があります。

この章では、Oracle Enterprise Managerアプリケーションを使用して最適なパフォーマンスを実現するための手法について説明します。また、大規模な環境における容量計画、Enterprise Managerパフォーマンスのサイジングおよび最大化に役立つ情報も提供します。ルーチン・ハウスキーピングを保守し、パフォーマンスを定期的に監視することで、将来的なサイジング要件の正確な予測に必要なデータを入手できます。Enterprise Manager Grid Controlのバイタル・サインを示す適切なベースライン値を理解し、ベースラインに対して警告およびクリティカルの妥当なしきい値を設定することにより、Enterprise Managerの自動的な監視が可能になります。

また、この章では、バックアップ、リカバリおよび障害時リカバリの実際的な方法と、Enterprise Managerの各層に対して実施できる様々な戦略についても説明します。

この章の内容は、次のとおりです。

Oracle Enterprise Manager Grid Controlのアーキテクチャの概要

Oracle Enterprise Manager 11g Grid Controlのアーキテクチャは、処理の分散および並列化という、アプリケーション・パフォーマンス・チューニングにおける2つの重要な概念を具現しています。Grid Controlの各コンポーネントは、この両方の概念を応用して構成できます。

Enterprise Manager Grid Controlには、次のコンポーネントが含まれます。

図9-1 Enterprise Managerアーキテクチャのコンポーネントの概要

Enterprise Managerアーキテクチャのコンポーネントの図
「図9-1 Enterprise Managerアーキテクチャのコンポーネントの概要」の説明

Grid Controlアーキテクチャの詳細は、Oracle Enterprise Manager 11gの次のドキュメントを参照してください。

Oracle Enterprise Manager 11gのドキュメントは、Oracle Technology Network（OTN）の次の場所から入手できます。

http://otn.oracle.com/documentation/oem.html

Enterprise Manager Grid Controlのサイジングおよびパフォーマンス最適化の方法

正確に容量を予測するためには、個々のEnterprise Manager Grid Controlデプロイからの実際のメトリック傾向情報が重要です。この情報を利用しながら、大まかな初期ホスト・システム・サイズを設定し、チューニングとメンテナンスを繰返し行うことで、Enterprise Manager Grid Controlデプロイの容量の正確な予測が可能になります。また、デプロイのパフォーマンスを常に最適レベルに保つうえでも、この情報が役立ちます。

Enterprise Manager Grid Controlのサイジング手法の実施手順は、次のとおりです。

  1. まだEnterprise Manager Grid Control 11gをインストールしていない場合は、表9-1に示すように、大まかな初期ホスト構成を選択します。

  2. 定期的にサイトのバイタル・サインを評価します（後述）。

  3. DBAおよびEnterprise Manager管理のルーチン・ハウスキーピングを使用してボトルネックを排除します。

  4. チューニングを使用してボトルネックを排除します。

  5. 今後に向けた直線外挿を行うことにより、将来のサイジング要件を計画します。

手順1は、各デプロイにつき1回行うのみで済みます。手順2、3および4は、Enterprise Manager Grid Controlサイトを拡大する計画があるかどうかにかかわらず、デプロイが存続しているかぎり定期的に行う必要があります。これらの手順は、Enterprise Manager Grid Controlサイトのサイズや処理負荷にかかわらず、効率的なEnterprise Manager Grid Controlサイトにとって不可欠です。手順5に進むには、手順2、3および4を完了しておく必要があります。これは非常に重要です。手順5が必要となるのは、監視対象ターゲットの数を増やしてデプロイ・サイズを拡大しようとする場合のみです。ただし、これらの傾向を定期的に評価することは、デプロイに行われた他の変更を評価するうえでも役立ちます。

手順1: 最初のプラットフォームのGrid Controlデプロイの選択

最初のプラットフォームにまだEnterprise Manager Grid Controlをインストールしていない場合、この手順で、実際のEnterprise Manager Grid Controlデプロイでの経験に基づく概数値を選択できます。Enterprise Manager Grid Controlをすでにインストールしてある場合は、手順2に進みます。 標準的なデプロイ・サイズとして、小、中、大の3つが定義されています。Enterprise Manager Grid Controlデプロイのサイズは、監視対象のシステム（またはターゲット）の数およびタイプによって大まかに決まります。この表はIntelベースのプラットフォームを示します。

表9-1 管理サーバー

デプロイ・サイズ ホスト ホスト当たりのCPU ホスト当たりのメモリー（GB）

小（監視対象ターゲット数が100）

1

1（3GHz）

4

中（監視対象ターゲット数が1,000）

1

2（3GHz）

4以上

大（監視対象ターゲット数が10,000）

2

2（3GHz）2

6以上

次の表は、他のプラットフォームとオペレーティング・システムに最低限必要なサイジング情報を示しています。

表9-2 他のプラットフォームのサイジング要件

プラットフォームおよびオペレーティング・システム 物理メモリー プロセッサ CPUプロセッサの数

Solaris Sparc 64 -- SunOS dscgaa03-3 5.10 Generic_137137-09 sun4v sparc SUNW、SPARC-Enterprise-T5220

12,288MB

SUNW、UltraSPARC-T2 - 1415 MHz

12

HP IA -- HP-IA 64 B.11.23 U ia64

8161MB

Intel(R) Itanium 2プロセッサ

4

Microsoft Windows NT-- Windows NT Windows Server 2003 Service Pack 2

4GB

AMD Opteron™ Processor 248

2

OMSホスト・ボックスでは、OPMNプロセス、管理サーバー・プロセス、ノード・マネージャ・プロセス、DBプロセスが実行しているため、最低限必要なメモリーはOMSホスト1台当たり4GBになります。

表9-3 管理リポジトリ

デプロイ・サイズ ホスト ホスト当たりのCPU ホスト当たりのメモリー（GB）

小

管理サーバーとホストを共有します。

管理サーバーとホストを共有します。

管理サーバーとホストを共有します。

中

1

2

4

大

2

4

6

表9-4 管理リポジトリ記憶域の合計

デプロイ・サイズ 最小表領域サイズ*
SYSTEM** MGMT_TABLESPACE MGMT_ECM_DEPOT_TS MGMT_AD4J_TS TEMP

*これらは厳密な最小値です。大まかなガイドラインとして考慮してください。MGMT_TABLESPACEの実際のサイズは、ターゲット・タイプの配布、ユーザーによるカスタマイズ、およびその他の要因によって、デプロイメントごとに大きく異なります。これらの表領域は、定義される際にAUTOEXTENDがデフォルトでONに設定されており、領域の制約の問題が緩和されます。RAWファイルシステムでは、領域の制約の問題を回避するために、最小サイズより大きいサイズを使用することをお薦めします。
**SYSTEM表領域およびTEMP表領域のサイズは、Enterprise Managerのみのリポジトリの最小サイズです。Enterprise Managerがその他のアプリケーションとリポジトリ・データベースを共有する場合は、ここに示した最小サイズでは小さすぎます。
注意: Enterprise Managerのバージョン11gでは、自動拡張ファイルとともにアラートを使用して表領域を監視することはできません。表領域の管理機能を強化する場合は、TABLESPACE FULLアラートの生成を設定できます。また、データベースの拡大を許可し、AUTOEXTEND機能を介してアラートが生成されないようにすることもできます。このため、TABLESPACE FULLアラートの管理機能を強化する場合は、自動拡張をオフにできます。

小

600MB

50GB

1GB

100MB

10GB

中

600MB

200GB

4GB

200MB

20GB

大

600MB

300GB

4GBよりも大きい

400MB

40GB

前出の各表は、各デプロイ・サイズに対応する推定最小ハードウェア要件を示したものです。前述の大規模なデプロイで示したように、複数のホスト上で動作する管理サーバーは、処理を各サーバー間で分散します。

また、複数の管理サーバーをデプロイした場合、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デプロイおよびテストに基づいて決定された最小要件です。

図9-2 Enterprise Managerコンポーネントに関連するネットワーク・リンク

図9-2は、周囲のテキストで説明されています。

図9-2から、Enterprise Manager Grid Controlコンポーネント間のネットワーク・リンクの帯域幅および待機時間の最小要件が、Enterprise Managerアプリケーションのパフォーマンスに大きく影響することがわかります。

手順2: サイトのバイタル・サインの定期的な評価

これが、5つの中で最も重要な手順です。Enterprise Manager Grid Controlサイトのバイタル・サインの傾向や大きな変動をある程度監視および理解しておかないと、サイトのパフォーマンスが重大なリスクに晒されることになります。監視対象ターゲットはそれぞれ、関連付けられた管理エージェントを介して、ロードおよび集計のためにデータを管理リポジトリに送信します。これは、他のエンタープライズ・アプリケーションと同レベルの管理およびメンテナンスを必要とする大量のアクティビティになります。

Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。パフォーマンスが許容可能なときのバイタル・サインの現実的なベースラインを設定する必要があります。ベースラインを設定した後は、Oracle Enterprise Manager Grid Controlの組込み機能を使用して、警告およびクリティカルのしきい値を設定できます。これにより、Enterprise Managerサイトに重大な変更があった場合は自動的に通知されます。次の表に、2つのサイトにおけるEnterprise Manager Grid Controlのバイタル・サインのポイント・イン・タイム・スナップショットを示します。

モジュール メトリック EMサイト1 EMサイト2
サイトURL
emsite1.acme.com emsite2.acme.com




ターゲットの数 データベース・ターゲット 192（45は起動されていない） 1218（634は起動されていない）

ホスト・ターゲット 833（12は起動されていない） 1042（236は起動されていない）





ターゲット合計 2580（306は起動されていない） 12293（6668は起動されていない）




ローダー統計 ローダー・スレッド 6 16

合計行/時間 1,692,000 2,736,000

行/時間/ロード/スレッド 282,000 171,000

行/秒/ロード/スレッド 475 187

実行時間の割合 15 44




ロールアップ統計 1秒当たりの行 2,267 417

実行時間の割合 5 19




ジョブ統計 ジョブ・ディスパッチャ 2 4

ジョブ・ステップ/秒/ディスパッチャ 32 10




通知統計 1秒当たりの通知 8 1

実行時間の割合 1 13




アラート統計 1時間当たりのアラート 536 1,100




管理サービス・ホスト統計 平均のCPU割合（ホスト1） 9（emhost01） 13（emhost01）

平均のCPU割合（ホスト2） 6（emhost02） 17（emhost02）

平均のCPU割合（ホスト3） 該当なし 38（em6003）

平均のCPU割合（ホスト4） 該当なし 12（em6004）

ホスト当たりのCPU数 2 X 2.8（Xeon） 4 X 2.4（Xeon）

ホスト当たりのメモリー（GB） 6 6




管理リポジトリ・ホスト統計 平均のCPU割合（ホスト1） 12（db01rac） 32（em6001rac）

平均のCPU割合（ホスト2）


平均のCPU割合（ホスト3）


平均のCPU割合（ホスト4）


ホスト当たりのCPU数


バッファ・キャッシュ・サイズ（MB）


ホスト当たりのメモリー（GB） 6 12

管理リポジトリ・サイズの合計（GB） 56 98

RACインターコネクト・トラフィック（MB/秒） 1 4

管理サーバー・トラフィック（MB/秒） 4 4

管理リポジトリI/Oの合計（MB/秒） 6 27




1秒当たりのEnterprise Manager UIページのレスポンス ホームページ 3 6

すべてのホスト・ページ 3 30+

すべてのデータベース・ページ 6 30+

データベースのホームページ 2 2

ホストのホームページ 2 2

この2つのEnterprise Managerサイトのパフォーマンスは対極的です。

EMサイト1は、ローダーの行/秒/スレッドとロールアップの行/秒の値が大きく、非常に高いパフォーマンスで動作しています。また、ローダーおよびロールアップの実行時間の割合が非常に低くなっています。管理サーバー・ホストと管理リポジトリ・サーバー・ホストのCPU使用率は両方とも低い値です。特に重要なのは、UIページのレスポンス時間が非常に優れていることです。つまり、サイト1では最小限の労力で多くの処理が行われています。構成、チューニングおよびメンテナンスが適切に行われたOracle Enterprise Manager Grid Controlサイトは、このような状態になります。

これに対し、EMサイト2には問題があります。ローダーおよびロールアップでの行の処理効率がよくありません。最も大きな問題は、UIページのレスポンス時間です。サイト2にボトルネックが存在するのは明らかです。複数のボトルネックがある可能性があります。

次の表は、概要が示された構成で実行されたテストに基づく様々なモジュールのメトリック・ガイドラインを示しています。指定した環境で使用されるメトリックとテスト環境に基づき、情報とデータを外挿するための参照ポイントとして役立ちます。

表9-5 テスト環境に基づくモジュールのメトリックのガイドライン

モジュール メトリック 値 テスト環境

ローダー統計

ローダー・スレッド

10

OMS詳細


OMSホストの数 = 2
ホスト当たりのCPUの数 = 4 Intel Xeon
メモリー = 6GB

リポジトリ詳細


リポジトリ・ノードの数 = 2
ホスト当たりのCPUの数 = 4 Intel Xeon
メモリー = 6GB

EM詳細


共有受信ディレクトリ = Yes
エージェントの数 = 867
ホストの数 = 867
ターゲット合計 = 1803

メトリックは、2台のOMSが起動して各エージェントのアップロード・バックログ・ファイルが50MBになってから5時間収集されます。

合計行/時間

4,270,652

行/時間/ローダー・スレッド

427,065

行/秒/ローダー・スレッド

120

ロールアップ統計

1秒当たりの行

ジョブ統計

ジョブ・ディスパッチャ

1 x OMSの数

ジョブ・ステップ/秒/ディスパッチャ

通知統計

1秒当たりの通知

16

OMS詳細


OMSホストの数 = 1
ホスト当たりのCPUの数 = 4 Intel Xeon
メモリー = 6GB

リポジトリ詳細


リポジトリ・ノードの数 = 1
ホスト当たりのCPUの数 = 4 Intel Xeon
メモリー = 6GB

EM詳細


OMSの数 = 1
リポジトリ・ノードの数 = 1
エージェントの数 = 2474
ホストの数 = 2474
データベース・ターゲット合計 = 8361

アラート統計

1時間当たりのアラート

7200

OMS詳細


OMSホストの数 = 1
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

リポジトリ詳細


リポジトリ・ノードの数 = 1
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

EM詳細


OMSの数 = 1
リポジトリ・ノードの数 = 1
エージェントの数 = 2474
ホストの数 = 2474

データベース・ターゲット合計 = 8361

管理サービス・ホスト統計

平均のCPU割合（ホスト1）

31%

OMS詳細


OMSホストの数 = 2
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

リポジトリ詳細


リポジトリ・ノードの数 = 2
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

EM詳細

共有受信ディレクトリ = Yes


エージェントの数 = 867
ホストの数 = 867

ターゲット合計 = 1803

メトリックは、2台のOMSが起動して各エージェントのアップロード・バックログ・ファイルが50MBになってから5時間収集されます。

平均のCPU割合（ホスト2）

34%

ホスト当たりのCPU数

4（Xeon）

ホスト当たりのメモリー（GB）

6

管理リポジトリ・ホスト統計

平均のCPU割合（ホスト1）

32%

OMS詳細


OMSホストの数 = 2
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

リポジトリ詳細


リポジトリ・ノードの数 = 2
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

EM詳細

共有受信ディレクトリ = Yes


エージェントの数 = 867
ホストの数 = 867

ターゲット合計 = 1803

メトリックは、2台のOMSが起動して各エージェントのアップロード・バックログ・ファイルが50MBになってから5時間収集されます。

平均のCPU割合（ホスト2）

26%

ホスト当たりのCPU数

4

SGAターゲット

2GB

ホスト当たりのメモリー（GB）

6

管理リポジトリ・サイズの合計（GB）

94

RACインターコネクト・トラフィック（MB/秒）

1

管理サーバー・トラフィック（MB/秒）

管理リポジトリI/Oの合計（MB/秒）

1秒当たりのEnterprise Manager UIページのレスポンス

ホームページ

9.1秒

OMS詳細


OMSホストの数 = 1
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

リポジトリ詳細


リポジトリ・ノードの数 = 1
ホスト当たりのCPUの数 = 4 Intel Xeon

メモリー = 6 GB

EM詳細


OMSの数 = 1
リポジトリ・ノードの数 = 1
エージェントの数 = 2474
ホストの数 = 2474

データベース・ターゲット合計 = 8361

すべてのホスト・ページ

9.8秒

すべてのデータベース・ページ

5.7秒

データベースのホームページ

1.7秒

ホストのホームページ

< 1秒

これらのバイタル・サインはすべて、Enterprise Managerインタフェースから取得できます。ほとんどの値は各ホストの「すべてのメトリック」ページか、または管理サーバーの「すべてのメトリック」ページに表示されます。警告およびクリティカルのアラートにしきい値を割り当て、これらのバイタル・サインの傾向を一定期間観察することで、良好なパフォーマンスを維持し、将来のリソース要件を予測できます。次のようにして、これらのバイタル・サインの監視を計画してください。

  • 前出の表に示された、Enterprise Manager Grid Controlサイトが良好に動作しているときのバイタル・サイン値のベースラインを測定します。

  • これらのベースライン値に基づいて妥当なしきい値および通知を設定し、正常な値から大きく逸脱した場合には自動的に通知されるようにします。このとき、サイトのしきい値を何度か繰返して微調整する必要があることがあります。受け取る通知が多すぎても役に立ちません。

  • 1日（最低でも1週間）に1回、グラフで7日間にわたるこれらの値の傾向を監視します。これにより、近い将来に起こりうる問題を発見し、将来のリソース要件の計画を立てることができます。

次の手順で、バイタル・サインの値が設定済しきい値の範囲にない場合に行う操作を示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。

手順3: ハウスキーピングでのDBAおよびEnterprise Managerタスクを使用したボトルネックの排除

Enterprise Manager Grid Controlサイトの動作を良好に保つために、ルーチン・ハウスキーピングが役立つことを覚えておくことが重要です。次に、ハウスキーピングのタスクとその適切な実行間隔を示します。

週に1回のオンライン・タスク

管理リポジトリ内の3つの主要な表（MGMT_METRICS_RAW、MGMT_METRICS_1HOURおよびMGMT_METRICS_1DAY）を分析します。管理リポジトリがOracle 11gデータベース内にある場合、これらの表は毎週自動的に分析されるので、このタスクは省略できます。管理リポジトリがOracleリリース9のデータベース内にある場合は、次のコマンドが毎週必ず実行されるようにしてください。

  • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_RAW', null, .2, false, 'for all indexed columns', null, 'global', true, null, null, null);

  • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_1HOUR', null, .2, false, 'for all indexed columns', null, 'global', true, null, null, null);

  • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_1DAY', null, .2, false, 'for all indexed columns', null, 'global', true, null, null, null);

  • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_STRING_METRIC_HISTORY', null, .2, false, 'for all indexed columns', null, 'global', true, null, null, null);

月に1回のオフライン・タスク

Enterprise Manager管理者は、Enterprise Managerリポジトリのセグメントの状態に関する推奨事項として、データベース内蔵のセグメント・アドバイザを監視する必要があります。セグメント・アドバイザは、どのセグメントを再構築/再編成する必要があるかを管理者に知らせ、その実行のためのコマンドを提供します。

セグメント・アドバイザと、システム状態に関連する問題の詳細は、My Oracle Supportナレッジ・ベースのノート242736.1および314112.1を参照してください。

手順4: チューニングによるボトルネックの排除

Enterprise Manager Grid Controlアプリケーションのパフォーマンスのボトルネックの代表的な原因を次に（頻度の高い順に）示します。

  1. ハウスキーピングを実行していない（パフォーマンス問題の最大の原因）

  2. ハードウェアまたはソフトウェアが適切に構成されていない

  3. ハードウェア・リソースの枯渇

バイタル・サインが日常的に設定済しきい値の範囲外にある場合、または一定期間そのような傾向を示している場合は、2つの領域に対処する必要があります。まず、前述したすべてのハウスキーピングが最近行われていることを確認します。2番目に、Enterprise Manager Grid Controlアプリケーションのリソース使用率に注意する必要があります。前出の表に列記したバイタル・サインは、Enterprise Manager Grid Controlのリソース使用率およびスループットのキー・ポイントを反映しています。次の各項で、重要なバイタル・サインのいくつかを説明し、ベースライン値に基づいて設定されたしきい値を超えたバイタル・サインに対処するために使用可能なオプションを示します。

高いCPU使用率

サイトのパフォーマンスを評価するように求められ、高いCPU使用率に気づいた場合、どのリソースがどの場所で使用されているかを判断するために、いくつか手順を実行する必要があります。

  1. 管理サーバーは、通常はCPUをごくわずかしか消費しません。Enterprise Manager Grid ControlでのCPU使用率が高い場合、管理リポジトリ側の兆候として現れることがほとんどです。

  2. Enterprise Managerホストのホームページの「プロセス」画面を使用して、CPUのしきい値を超えた管理サービス・ホストまたは管理リポジトリ・ホストで最も多くのCPUを消費しているプロセスを判別します。

  3. Enterprise Managerが最も多くのCPUを消費していることが明確になった場合は、Enterprise Managerを使用して、最も多くのCPUを消費しているアクティビティを特定します。これは通常、管理サービスの処理のほとんどが実行される管理リポジトリ・ホスト上に存在します。管理サービスそのものがボトルネックの原因になっていることは、非常にまれです。管理リポジトリが過剰にリソースを使用していると考えられる場合、一般的に次の点を調べる必要があります。

    1. 管理リポジトリの「データベース・パフォーマンス」ページにリストされた「使用中のCPU」データベース・リソースをクリックして、管理リポジトリで最も多くCPUを使用しているSQLを調べます。

    2. 管理リポジトリの「データベース・パフォーマンス」ページの「データベース・ロック」で、競合問題がないか確認します。

パフォーマンスのボトルネックの兆候として最も多いのは、高い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%の能力が得られるわけではありません。ただし、プラスの効果もあります。ローダー・スレッドを追加すると、行/秒/スレッドは減少しますが、合計行/時間のスループットは増加します。合計行/時間の値に大きな改善が見られず、ローダー・ファイルのバックログ・サイズが拡大し続けている場合、ローダー・スレッドの数を増やしてもそのコストに見合ない可能性があります。この場合は、他のチューニングまたはハウスキーピングの機会を探る必要があります。

ローダー・スレッドを追加するには、次の構成パラメータを変更します。nは正の整数1〜10です。

em.loader.threadPoolSize=n

デフォルトは1で、1〜10以外の値を指定した場合、スレッド・プール・サイズはデフォルトの1に設定されます。このプロパティ・ファイルは、{ORACLE_HOME}/sysman/configディレクトリ内にあります。このパラメータを変更した場合、管理サービスを再起動して新しい値とともに再ロードすることが必要になります。

次の2つのパラメータは、エージェントからファイルを受信するレシーバ・モジュールに設定されます。

  1. em.loader.maxDataRecvThreads=n（デフォルトは75）

    nは正の整数で、デフォルト値は75です。これは、同時データ・ファイルの受信者スレッドの最大数を制限する場合に使用されます。そのため、ピーク時には75の受信者スレッドのみがファイルを受信し、その他のリクエストはサーバー・ビジー・エラーで拒否されます。これらの拒否されたリクエストは、デフォルトの再試行時間が経過するとエージェントによって再送信されます。

    この値の設定が高すぎると、OMSマシンと共有受信者ディレクトリ・ボックスへの負荷が高くなるため注意してください。値の設定が低すぎると、データ・ファイルの受信スループットは小さくなります。

  2. oracle.sysman.emRep.dbConn.maxConnForReceiver=n（デフォルトは25）

    nは正の整数で、デフォルト値は25です。これは、受信スレッドのリポジトリ・データベース接続の最大数を設定する場合に使用されます。Oracleでは、この値をem.loader.maxDataRecvThreadsと等しく設定することをお薦めします。各受信者スレッドは1つのDBセッションを取得し、DB接続を待機しないためです。

ロールアップのバイタル・サイン

ロールアップ・プロセスは、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 Linux™ 3からは、big pages機能はhuge pagesと呼ばれる新機能にかわり、起動パラメータは必要なくなりました。

ロールアップ・プロセス

ロールアップ・プロセスでは、参加するインスタンスのロールアップのコンセプトが導入されています。ロールアップ処理は、参加するすべてのインスタンス間で分散されます。参加するEMROLLUPグループに候補インスタンスを追加するには、パラメータinstance_groupsをインスタンス・レベルで次のように設定する必要があります。

  • ノード1の場合、instance_groupパラメータにEMROLLUP_1を追加します。

    ノード2の場合、instance_groupパラメータにEMROLLUP_2を追加します。

  • PQおよびPWパラレル処理モードを導入しています。

    • PQはパラレル問合せ/パラレルdmlモードです。このモードでは、各参加インスタンスに、指定された並列度を利用する1つのワーカーが設定されています。

    • PWはパラレル・ワーカー・モードです。このモードでは、各参加インスタンスに、指定されたパラレル・レベルに等しい数のワーカー・ジョブがあります。

  • すべての参加RACインスタンスのワークロードを次のように分散します。

    • 各参加インスタンスには、同じ数のターゲットが割り当てられます。参加インスタンス数が（n）でワークロードの合計が（tl）の場合、各インスタンスには（tl/n）が割り当てられます。

    • 参加インスタンスの各ワーカーには、該当インスタンスのワークロードの同じ数のターゲットが割り当てられます。インスタンス当たりのターゲット数が（il）でワーカー数が（w）の場合、各ワーカーには（il/w）が割り当てられます。

    • 負荷はワーカーごとにバッチに分割され、ロールアップSQLの実行回数を制御します。バッチ当たりの行数は、ワーカーに割り当てられた行の総数をバッチ回数で除算したものになります。

ロールアップ処理時のガイドラインとして次の推奨事項を使用します。

  • パラレル・ワーカー（PW）・モードを使用し、参加するEMROLLUP_xxインスタンス・グループを利用します。

  • パラレル・ワーカー・モードの使用をお薦めします。

  • より多くのワーカー間で作業を分割すると、収穫逓減ルールが適用されるまでパフォーマンスとスケーラビリティが向上します。これは、各RACモードで使用可能なCPUの数によって異なります。このテスト・ケースでは、10のワーカーによる実行が最適な構成であり、レスポンス時間、マシンのCPUおよびIO使用率を調整します。

  • 適切なバッチ・サイズを設定することが重要です（推奨は10）。バッチ回数10回が最適な実行であり、メインSQL（EMD_1HOUR_ROLLUPと呼ばれる）の実行回数と、各実行に必要なソート領域が調整されます。

  • バッチ回数を10に設定して開始してください。バッチ回数はデータ分散に基づいて変更できます。

前述の推奨事項によって次の結果が得られます。（前述の再設計されたコードで）マルチインスタンス・パラレル・ワーカー（8 PW）・モードを使用すると、2つの参加RACインスタンスの利用時にパフォーマンスは9〜13倍改善されます。

MGMT_METRICS_1HOURのロールアップ行数（百万単位） 時間（分） ワーカー バッチ・サイズ
29.5 30 8 1
9.4 5 8 10
** テスト全体では、15779の明確なTARGET_GUIDがありました。

**テストによって、MGMT_METRICS_1HOURで“29.5百万”の新しいロールアップ行が生成されました。

実行** 行/ワーカー バッチ/ワーカー 行/バッチ 時間（分）
8PW/1インスタンス 3945 3945 1 40
8PW/2インスタンス 1973 1973 1 30

ジョブ、通知およびアラートのバイタル・サイン

ジョブ、通知およびアラートは、Enterprise Manager Grid Controlサイトの管理サービスの処理効率を示します。これらの値がよくない傾向を示している場合、通常はアプリケーションの他の場所に競合があります。これらの値の有効な使用方法は、複数の管理サーバーを使用して実行した場合のメリットを測定することです。各管理サーバーにはジョブ・ディスパッチャが1つずつあります。管理サーバーを追加しても、必ずしもこれらの値が改善されるわけではありません。一般に、アプリケーションにリソース競合問題が存在していなければ、管理サーバーを追加することでGrid Controlの全体のスループットが改善します。その改善の程度を測定するには、ジョブ、通知およびアラートのバイタル・サインが役立ちます。

I/Oのバイタル・サイン

Enterprise Managerデプロイにおける様々なチャネルのI/Oスループットを監視することは、良好なパフォーマンスを実現するうえで不可欠です。少なくとも次の3つの異なるI/Oチャネルに対して、ベースラインおよびアラートのしきい値を定義する必要があります。

  • 管理リポジトリ・インスタンスからそのデータファイルへのディスクI/O

  • 管理サーバーと管理リポジトリの間のネットワークI/O

  • RACインターコネクト（ネットワーク）I/O（RACシステムの場合のみ）

これらのチャネルそれぞれについて、最大スループットおよび持続的スループット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が使用されます。管理リポジトリ・ホストおよび管理サービス・ホストに対して、このオペレーティング・システム機能を有効化しておくことをお薦めします。

自動ストレージ管理（ASM）は、Enterprise Manager Grid Controlリポジトリ・データベースの記憶域にお薦めです。

Oracle Enterprise Managerの「パフォーマンス」ページ

他のパフォーマンス低下はないが、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プロシージャ・コールの場合は、管理リポジトリ内のプロシージャのソース・コードを参照して、そのコールによりアクセスされる表および関連する索引を特定する必要があるため、もう少し複雑になります。

セグメントを特定した後、管理サーバーを停止した状態で、必要な文の再作成および再編成を実行できます。これにより、ページ・パフォーマンスは大幅に向上します。オープン・アラート、システム・エラーおよびメトリック・エラーの数が多すぎる場合など、再作成と再編成のみではページ・パフォーマンスが改善されないこともあります。このようなコールを改善するには、（たとえば、クリーンアップや削除を行って）これらの問題の数を減らすしかありません。これらの数を減らした後は、セグメントの再作成および再編成を実行して、パフォーマンスを最適化する必要があります。これらのシナリオについては、「手順3: ハウスキーピングでのDBAおよびEnterprise Managerタスクを使用したボトルネックの排除」で説明しています。最新状態が維持されていれば、UIページ・パフォーマンスをそれほど頻繁に分析する必要はありません。

手順5: サイジング要件を計画するための将来的な直線外挿

将来の記憶域要件を決定することは、バイタル・サイン傾向の有効利用の最もよい例です。Grid Controlには、一定期間におけるターゲット合計数および一定期間における管理リポジトリ・サイズという2つのグラフが組み込まれています。将来の記憶域要件の予測には、これらのグラフを使用できます。

どちらのグラフも、管理サービスの「すべてのメトリック」ページで使用できます。この2つのグラフの間に相関関係があることは明らかです。両方の曲線に適用された直線は、ほぼ同じ増加率を表します。Enterprise Manager Grid Controlに監視対象のターゲットを追加した後、31日間は管理リポジトリの拡大が見られます。これは、ターゲットの管理リポジトリ領域を消費するデータのほとんどが、管理リポジトリで完全に表示されるようになるまで約31日かかるためです。次の1年間は、そのターゲットは少しずつ拡大を続けます。これは、最大レベルのデータ集計におけるデフォルトの最長データ保存時間が1年であるためです。最初の31日間に比べると、これはさほど重要ではありません。

ターゲットの追加を停止すると、グラフは約31日間横ばいになります。グラフが横ばいになると、追加したターゲット数と、管理リポジトリ内で使用される追加領域の大きさの間に相関関係が現れます。Enterprise Manager Grid Controlデプロイ・プロセスの早い段階からこれらの値を追跡することで、サイトの記憶容量を積極的に管理できます。この履歴は非常に重要なツールです。

CPU使用率とターゲット合計の間にも同様の種類の相関関係を作成して、それらの要件を判断できます。CPU使用率の場合、ターゲットを追加すると、横ばい状態がより早く見られます。ターゲットの追加後は、直近の増加率を超えるほどCPUコストが一定期間にわたって大幅に増加することはなくなります。新規メトリックの追加または収集の増加にかかわらず、新しい監視を既存のターゲットに適用すると、たいていはCPU使用率が増加します。

Oracle Enterprise Managerのバックアップ、リカバリおよび障害時リカバリの考慮事項

Enterprise ManagerにはGrid Controlコンソールに対するポータブルなブラウザベースのインタフェースとOracle Application Serverのテクノロジが組み込まれていますが、それらは中間層の管理サービス・ツールとして機能します。このツールは、管理リポジトリおよび履歴データを管理するためのデータベース・サーバー・テクノロジを基盤としています。この項では、これらの高可用性に関するトピックへの実際的なアプローチと、Enterprise Managerの各層に対して実施できる様々な戦略について説明します。

バックアップのベスト・プラクティス

Oracleデータベースの場合、バックアップに関するベスト・プラクティスは、標準的なデータベース・ツールを使用し、次のようにすることです。

  1. データベースをアーカイブログ・モードにします。

  2. Grid Controlを使用して利用可能な推奨バックアップ計画オプションを使用して、定期的なオンライン・バックアップを実行します。この場合はRecovery Manager（RMAN）を使用します。

この場合は、全体バックアップを作成した後、以降は毎回増分バックアップを作成します。増分の変更をロールアップしてベースラインを作成し、新しい全体バックアップ・ベースラインを作成します。

推奨バックアップ計画を使用すると、Grid Controlの機能を利用してバックアップを実行することもできます。バックアップ・ジョブは、Grid Controlジョブ・サブシステムにより、自動的にスケジューリングされます。バックアップの履歴はレビューで利用でき、バックアップのステータスはデータベース・ターゲットのホーム・ページの「ジョブ・アクティビティ」セクションに表示されます。

このジョブとアーカイブおよびフラッシュバック・テクノロジを併用すると、管理リポジトリのいずれかの部分が失われた場合のリストア・ポイントが得られます。このバックアップ処理およびアーカイブ・ログとオンライン・ログにより、管理リポジトリを最後に完了したトランザクションまでリカバリすることができます。

アーカイブおよびフラッシュバック・テクノロジを有効にするには、「リカバリ設定」ページを使用し、次のものを有効にします。

  1. アーカイブ・ログ

    データベースを停止し、管理サービスの全プロセスを再起動します。

  2. データベースのフラッシュバック

    データベースを停止し、管理サービスの全プロセスを再起動します。

  3. ブロック変更トラッキング機能によるバックアップ処理の高速化

Enterprise Managerを使用したバックアップの構成方法のサマリーは、『Oracle Database 2日でデータベース管理者』を参照してください。

データベースの高可用性に関するベスト・プラクティスの付加情報については、Oracle Database高可用性のアーキテクチャおよびベスト・プラクティスを参照してください。

バックアップ・ジョブの実行頻度は、Grid Control環境で生成されるデータの量と、リストアが必要な場合に耐えられる停止時間の長さに応じて設定できます。停止期間が短く、データベースのリストアによって品質保証契約を満たすことができない場合は、Real Application Cluster（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に関する特別な考慮事項はありません。データベースがリカバリされたら、データベースおよび管理サービス・プロセスを再起動します。その後、管理エージェントによって保留中のファイルが管理リポジトリにアップロードされます。

  • 特定時点における不完全リカバリのみが可能な場合

    管理エージェントは、リセットされるまで管理リポジトリと正常に通信できません。次のステップを手動で実行する必要があります。

    1. 管理エージェントを停止します。

    2. $AGENT_HOME/sysman/emdディレクトリからagntstmp.txtおよびlastupld.xmlファイルを削除します。

    3. /stateおよび/uploadサブディレクトリに移動し、その中身をクリアします。

    4. 管理エージェントを再起動します。

    これらのステップは、管理エージェントごとに実行する必要があります。

不完全リカバリの場合、前述の手順を完了するまで、管理エージェントがデータをアップロードできないことがあります。また、このタイプのリカバリ後に管理エージェントが管理サービスと通信できない可能性があることは、インタフェースにすぐには示されません。この情報は、管理エージェントのログまたはコマンドラインの管理エージェント・ステータスから取得できます。不完全リカバリが必要な場合は、管理エージェントごとにこの手順を実行する必要があります。

Oracle Management Serviceのリカバリ

管理サービスはステートレスであるため、バイナリ・ファイルおよび構成ファイルを可能なかぎり短時間内にリストアする必要があります。この場合、他に2つの方法があります。

  • ソフトウェア・ディレクトリ構造全体をバックアップします。管理サービスの障害が発生した場合は、ソフトウェア・ディレクトリ構造を同じディレクトリ・パスにリストアできます。同時に、この管理サービスのインストールに関連付けられている管理エージェントもバックアップします。管理サービスのリストアが必要な場合は、この管理エージェントをリストアする必要があります。

  • オリジナルのメディアから再インストールします。

高可用性の管理サービス・インストールの場合、ミラーリング・テクノロジを使用して/recvディレクトリが保護されていることを確認することをお薦めします。/recvディレクトリは、管理エージェントから受信したファイルの内容をデータベースの管理リポジトリに書き込む前に、管理サービスがそのファイルをステージングする際に使用されます。

管理エージェントは、そのXMLファイルを管理サービスに転送し終わると、XMLファイルのコピーを削除します。その場合、管理エージェントから送信されたメトリック・データは失われます。

Oracle Management Agentのリカバリ

管理エージェントのリカバリは、管理エージェントがステートレスでない点を除き、管理サービスのリカバリに類似しています。使用できる方法は2つあります。

  • ホスト名が変更されている場合、SLBを使用して接続を管理しているのであれば、SLB内の接続プールを変更して旧ホスト名を削除し、新しいホスト名を追加する必要があります。SLBを使用している場合、旧OMSホストを指していた各エージェントは、そのemd.propertiesファイルを変更し、新しいOMSホスト名を指す必要があります。この手順は、旧マシンがクラッシュしたために新ホスト上で新しいOMSを立ち上げる必要がある場合に使用できます。

    ホスト名が変更されていない場合は、ディスクのバックアップとリストアで十分です。

    1. /sysman/emdディレクトリからagntstmp.txtおよびlastupld.xmlファイルを削除します。

    2. 管理エージェントを再起動する前に、/stateおよび/uploadサブディレクトリから全エントリをクリアします。

    3. 管理エージェントを起動します。このステップにより、ホスト上のターゲットが強制的に再検出されます。

  • オリジナルのメディアから管理エージェントを再インストールします。

管理サービスの場合と同様に、ミラーリング・テクノロジを使用して/stateおよび/uploadディレクトリを保護することをお薦めします。

非共有ファイルシステムから共有ファイルシステムへの切換え時のデータ損失およびダウン・タイムの防止

非共有ファイルシステムから共有ファイルシステムへの切換え時にデータ損失およびダウン・タイムを防ぐには、各OMSをローリング形式で共有ファイルシステムに切り換え、受信ディレクトリにバックログがないようにします。データ損失を防ぐには、OMSごとに次の手順を行います。

  1. OMSでhttpサーバーを停止します。

  2. 既存のバックログの処理を待機します。既存のバックログが処理されたかどうかを判断するには、引き続きローダー受信ディレクトリを監視します。受信ディレクトリ内のすべてのファイルがアップロードされるまで待機します。

  3. emctl config oms loader -shared yes -dir <sharedfs>を実行します。バックログがある場合、このコマンドによりバックログのクリアが求められます。

  4. OMSを停止します。

障害時リカバリ（DR）のベスト・プラクティス

ノード障害が発生した場合、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)))

Oracle Management Service

障害時リカバリに使用するハードウェアに、管理サービスおよび管理エージェントをプリインストールします。これにより、Enterprise Managerバイナリ・ファイルのコピーをバックアップからリストアする手順と、管理サービスおよび管理エージェントの構成ファイルを変更する手順を省略できます。


注意:

ホスト名の依存関係が存在するため、障害発生時に既存のバックアップから管理サービスおよび管理エージェントのバイナリを新しいホストにリストアしないでください。必ず、フレッシュ・インストールを行ってください。

管理エージェント

実際の障害リカバリ時には、新しいホスト上で動作するすべてのターゲットが管理エージェントでクリーン検出されるように、管理エージェントを再インストールするほうが簡単です。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引