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

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

この項では、Oracle Enterprise Managerアプリケーションを使用する上で最適なパフォーマンスを得るための手法について説明します。また、大規模環境でのキャパシティ・プランニング、サイジング、Enterprise Managerのパフォーマンスの最大化にも役立ちます。

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

ルーチン・ハウスキーピングを続け、パフォーマンスのモニタリングを定期的に行うことで、将来的なサイジングの要件を正確に見積もるために必要なデータが得られます。Enterprise Manager Cloud Controlのバイタル・サインに対する適切なベースライン値を認識し、ベースラインに対して妥当な警告とクリティカルのしきい値を設定することで、Enterprise Managerによるモニターが可能になります。

サイジングは、Enterprise Managerのパフォーマンスを左右する重要な要素です。Enterprise Managerデプロイメントのサイズ設定が不十分であると、Enterprise Manager全体のメリットが損われてしまいます。Enterprise Manager Oracle Management Service (OMS)および管理リポジトリ層に必要なリソースは、モニター対象ターゲットの数に基づいて大きく変化します。Enterprise Managerインフラストラクチャのサイジングでは他にも考慮すべき点がたくさんありますが、次のガイドラインは、OMSおよび管理リポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。

この章の構成は、次のとおりです。

Enterprise Manager Cloud Controlのサイジング

Oracle Enterprise Managerは、可用性および拡張性に優れたデプロイメント・トポロジを備えています。この章では、Oracle Enterprise Managerデプロイメントの最初のキャパシティ・プランニングに役立つ、サイジングおよびチューニングの基本的な推奨事項について説明します。この章では、Oracle Enterprise Managerのコンポーネントおよびシステムの基本的な内容が理解されていることを前提としています。Oracle Enterprise Managerの詳細は、Oracle Enterprise Manager Cloud Control概要から取得できます。この情報はサイトのサイジングの起点となります。サイトごとに独自の特性があるので、必要に応じてモニターやチューニングを行う必要があります。

サイジングは、Enterprise Managerのパフォーマンスを左右する重要な要素です。Enterprise Managerデプロイメントのサイズ設定が不十分であると、ユーザーが苛立ちを感じ、Enterprise Manager全体のメリットが損われてしまいます。Enterprise ManagerのOMSおよびリポジトリ層に必要なリソースは、モニター対象ターゲットの数によって大きく異なります。Enterprise Managerインフラストラクチャのサイジングでは他にも考慮すべき点がたくさんありますが、次のガイドラインは、OMSおよびリポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。

サイジング・ガイドラインの概要

次の各項では、サイジング・ガイドラインの概要を説明します。

ハードウェア情報

この章で説明しているサイジング・ガイドラインは、次のハードウェアおよびオペレーティング・システムの組合せで仮想環境を実行し、取得したものです。

ハードウェア: Oracle X4-2
ハイパーバイザー: Linux Oracle Virtual Server (64ビット)
仮想マシンのオペレーティング・システム: Oracle Linux (64ビット)

仮想環境では、Oracle Virtual Server (OVS)ホストとそこで実行されている仮想マシンとの間にCPUの1対1マッピングが設定されていました。OVSサーバーには、メモリーをスワップせずにすべての仮想マシンをサポートできる十分なRAMが搭載されていました。

この情報は、Oracle Linux (64ビット)環境に基づいています。他のプラットフォームで実行する場合は、同様のハードウェア・パフォーマンスに基づいて、サイジング情報を換算する必要があります。換算にはシングル・スレッドのパフォーマンスを使用します。処理能力のベンチマーク上は総合的なマシン性能が同じであっても、24個の低速コアを持つマシンで実行する場合と12個の高速コアを持つマシンで実行する場合とでは等しくなりません。シングル・スレッドのパフォーマンスは、適正なEnterprises Managerユーザー・インタフェースのレスポンス時間を計る上で重要です。

サイジングの仕様

Oracle Enterprise Managerのサイジング・ガイドラインは、4つのサイズ(評価、小、中、大)に分かれています。表13-1に、各サイズの定義を示します。

表13-1 Oracle Enterprise Managerサイトのサイズ

サイズ	エージェント数	ターゲット数	同時ユーザー・セッション数
評価	< 10	< 100	<3
小	< 100	< 1000	<10
中	>= 100, < 1000	>= 1000, < 10,000	>= 10, < 25
大	>= 1000	>= 10,000	>= 25, <= 50*
特大	>= 5000	>=50,000	>=50, <=100

大規模なユーザー負荷については、「大規模な同時UI負荷」を参照してください。

評価の構成は本番環境には適していません。試行およびテスト環境のみに適しています。

「特大」はEnterprise Managerをインストールするときのオプションではありません。サイジングの基準に一致する場合は特大設定で環境を構成できます。

アップグレードされたインストールのサイジング

Enterprise Managerの以前のリリースからEnterprise Manager 13cにアップグレードする場合、SYSMANユーザーとして次の問合せを実行し、表1で使用するための管理エージェントおよびターゲット数を取得できます。

エージェント数: select count (*) from mgmt_targets where target_type = ‘oracle_emd'
ターゲット数: select count (*) from mgmt_targets where target_type = ‘oracle_emd'

最小ハードウェア要件

表13-2に、4つの構成の最小ハードウェア要件を示します。

表13-2 Oracle Enterprise Managerの最小ハードウェア要件

サイズ	OMSマシン数*	OMS当たりのコア数	OMS当たりのメモリー(GB)	OMS当たりの記憶域(GB)	データベース・マシン数*	データベース・マシン当たりのコア数	データベース・マシン当たりのメモリー(GB)
評価	1	2	10	24	-	-	-
小	1	4	10	24	1	4	7
中	2	6	12	24	2 (Oracle RAC)	6	10
大	2 4	12 6	24 12	24 24	2 (Oracle RAC) 2 (Oracle RAC)	12 12	18 18
特大	4	24	32	24	2 (Oracle RAC)	48	96

表13-3 Oracle Enterprise Managerの最小記憶域要件

サイズ	MGMT_TABLESPACE (GB)	MGMT_AD4J_TS (GB)	MGMT_ECM_DEPOT_TS (GB)	TEMP	ARCHIVE LOG AREA (GB)
評価	15	3	1	3	アーカイブ・ログ・オフ
小	100	10	1	12	25
中	300	30	4	20	100
大	400	50	8	40	150
特大	600	80	16	80	250

ネットワーク・トポロジに関する考慮事項

Enterprise Manager Cloud Controlをデプロイする際、各層間のネットワーク・パフォーマンスを第一に考慮する必要があります。Enterprise Manager Cloud Controlでは、各アプリケーション層間のネットワークの異常、障害および故障に対するトレランスが、エラー・トレランスおよびエラー・リカバリによって保証されています。特に管理エージェントは、Enterprise Manager全体のパフォーマンスに大きな影響を与えることなく、パフォーマンスや信頼性の低い、管理サービスへのネットワーク・リンクを処理できます。ネットワークの問題が原因で起こる1つの管理エージェント・データの遅延に関するかぎり、その影響はEnterprise Manager Cloud Controlのシステムワイドなレベルではほとんど気づかない程度のものです。

ただし、管理サービスと管理リポジトリの間のネットワーク待機時間については、わずかに増えるのみでその影響は大きくなります。Enterprise Manager Cloud Controlの実装では、管理サービスと管理リポジトリの間のネットワーク・リンクの品質が十分でない場合に、重大なパフォーマンス問題が発生することがわかっています。

管理サービスのホストとリポジトリのホストは、相互に近接した場所に配置します。理想的には、2つの間のラウンドトリップ・ネットワーク待機時間が1ミリ秒未満になるようにする必要があります。

ソフトウェア構成

次の各項では、評価、小規模、中規模、大規模の各構成について説明します。

評価構成

評価の構成は簡易インストール・オプションを選択してインストールする必要があります。インストールは適切な値を使用して構成する必要があります。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを1GBに設定する必要があります。

最小リポジトリ・データベース設定

表13-4に、評価の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-4 評価の構成の最小データベース設定

パラメータ	最小値
Processes	300
memory_target	1000 MB
REDOログ・ファイルのサイズ	50 MB
shared_pool_size	450 MB
session_cached_cursors	remove

小規模の構成

小規模の構成は、Oracle Enterprise Managerのインストーラによって要求される最小要件に基づきます。

最小OMS設定

追加設定は不要です。

最小データベース設定

表13-5に、推奨される最小データベース設定を示します。

表13-5 小規模サイトの最小データベース設定

パラメータ	最小値
processes	300
pga_aggregate_target*	1024 MB
sga_target*	3 GB
REDOログ・ファイルのサイズ	300 MB
shared_pool_size	600 MB
optimizer_adaptive_features	false

ノート:

*sga_targetおよびpga_aggregate_targetのかわりに、4GBのmemory_targetを使用できます。

中規模の構成

中規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを4096MBに設定する必要があります。

最小リポジトリ・データベース設定

表13-6に、中規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-6 中規模サイトの最小データベース設定

パラメータ	最小値
processes	600
pga_aggregate_target*	1280 MB
sga_target*	5 GB
REDOログ・ファイルのサイズ	600 MB
shared_pool_size	600 MB
optimizer_adaptive_features	false

ノート:

*sga_targetおよびpga_aggregate_targetのかわりに、6.25GBのmemory_targetを使用できます。

ノート:

プロセス数は、OMSノード*300に基づいて調整する必要があります。

大規模の構成

大規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。

最小OMS設定

表13-7に、大規模の構成で推奨される最小OMS設定を示します。

表13-7 大規模サイトの最小OMS設定

OMS数	ヒープ・サイズの最小値
2	8192 MB
4	4096 MB

最小リポジトリ・データベース設定

表13-8に、大規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-8 大規模サイトの最小データベース設定

パラメータ	最小値
processes	1000
pga_aggregate_target*	1536 MB
sga_target*	8 GB
REDOログ・ファイルのサイズ	1000 MB
shared_pool_size	600 MB
optimizer_adaptive_features	false

ノート:

*sga_targetおよびpga_aggregate_targetのかわりに、9.5GBのmemory_targetを使用できます。

特大構成

特大構成には、次の設定が必要です。

最小OMS設定

表13-9に、特大規模の構成で推奨される最小OMS設定を示します。

表13-9 特大規模サイトの最小OMS設定

OMS数	ヒープ・サイズの最小値
4	16384 MB

最小リポジトリ・データベース設定

表13-10に、特大規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-10 特大規模サイトの最小データベース設定

パラメータ	最小値
processes	2000
pga_aggregate_target*	6 GB
sga_target*	40 GB
REDOログ・ファイルのサイズ	2 GB
shared_pool_size	600 MB
optimizer_adaptive_features	false

ノート:

Pingアラート、ジョブ、ロールアップ、イベントおよび構成メトリック・ポスト・ロード・コールバック用のRACサービスを設定することをお薦めします。詳細は、ステップ4: チューニングによるボトルネックの排除を参照してください。

リポジトリ表領域のサイジング

表13-11は、管理リポジトリに必要な最小記憶域要件を示しています。

表13-11 管理リポジトリ記憶域の合計

-	最小表領域サイズ*
デプロイメント・サイズ	SYSTEM**	MGMT_TABLESPACE	MGMT_ECM_DEPOT_TS	MGMT_AD4J_TS	TEMP
小	600 MB	100 GB	1 GB	10 GB	12 GB
中	600 MB	300 GB	4 GB	30 GB	20 GB
大	600 MB	400 GB	8 GBよりも大きい	50 GB	40 GB
特大	600 MB	600 GB	16 GB	80 GB	80 GB

追加構成

Enterprise Managerのインストールでは、個々のシステム負荷が大きいと、追加のチューニング設定が必要になる場合があります。追加設定を次に示します。

大規模な同時UI負荷

OMSごとに50を超える同時ユーザーが予想される場合は、次の設定を表13-12のとおり修正する必要があります。

表13-12 大規模な同時UI負荷の追加設定

プロセス	パラメータ	値	設定対象
OMS	-Djbo.recyclethreshold	同時ユーザー数/OMS数	OMS別
OMS	-Djbo.ampool.maxavailablesize	同時ユーザー数/OMS数	OMS別
OMS	ヒープ・サイズ	50ユーザー増加するたびに4GB追加	OMS別
データベース	sga_target*	50ユーザー増加するたびに1GB追加	インスタンス別

ユーザー負荷が高くなるほど、必要なハードウェア容量が増加します。50同時ユーザーごとに、データベース・ホストとOMSホストの両方に2コアを追加します。

例: エージェント数1500、ターゲット数15,000、同時ユーザー数150のサイトでは、表13-13に示した設定変更が最小限必要です(2 OMSの大規模な構成に基づく)。

表13-13 2 OMS構成の大規模な同時UI負荷の追加設定の例

プロセス	パラメータ	値	計算
OMS	-Djbo.recyclethreshold	75 (OMSごとに設定)	150ユーザー/2 OMS
OMS	-Djbo.ampool.maxavailablesize	75 (OMSごとに設定)	150ユーザー/2 OMS
OMS	ヒープ・サイズ	12GB (OMSごとに設定)	8GB (標準的な大規模設定) + ((150ユーザー - 50大規模なユーザー負荷のデフォルト)/2 OMS)* (4GB/50ユーザー)
データベース	sga_target	10 GB	8GB (標準的な大規模設定) + (150ユーザー - 50大規模なユーザー負荷のデフォルト)* (1GB/50ユーザー)

表13-14に、追加ハードウェアの最小要件を示します。

表13-14 2 OMS構成の大規模な同時UI負荷の最小追加ハードウェアの例

層	パラメータ	値	計算
OMS	CPUコア数	32 (すべてのOMSホスト間の合計)	12コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) (2コア 2 OMS)/50ユーザー)
データベース	CPUコア数	32 (すべてのデータベース・ホスト間の合計)	12コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) (2コア 2 OMS/50ユーザー)

この構成を実行できるようにするには、各マシンの物理メモリーも増設する必要があります。

パラメータ-Djbo.recyclethreshold、-Djbo.ampool.maxavailablesizeおよびHeap Sizeの値は変更できます。これらの値はデフォルトでは次のように設定されています。

Djbo.recyclethresholdは50に設定されています。
Djbo.ampool.maxavailablesizeは50に設定されています。
Heap Sizeは-Xms1024m -Xmx1740mに設定されています。

これらのメモリー・パラメータを設定するには、次の場所にあるstartEMServer.shファイルを変更します。

gc_inst/user_projects/domains/GCDomain/bin

-Djbo.recyclethresholdおよび-Djbo.ampool.maxavailablesizeパラメータについては、次の最初のセクションを2つ目のセクションに追加できます。

JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.security.egd=file:///dev/./urandom -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugWebAppSecurity=true -Dweblogic.SSL.LoginTimeoutMillis=300000 -Dj
ps.auth.debug=true -Xbootclasspath/p:/u01/EM12/oms/sysman/jlib/diagpatch_bug11725986.jar -Djdkpatchlog=/u01/EM12/oms/sysman/log/diagpatch_bug11725986.log -Doracle.apm.home=/u01/EM12/oms/apm/ -DAPM_
HELP_FILENAME=oesohwconfig.xml -Djava.util.logging.config.file=/tmp/logging.txt"

リリース12.1.0.3以降の場合、第11.1.3.5項のChanging Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold (JAVA_EM_ARGS)のポイントを参照してください。

同じファイルで、次のセクションのヒープ・サイズ設定を変更できます。

USER_MEM_ARGS="-Xms1024m -Xmx1740m -XX:MaxPermSize=1024M -XX:-DoEscapeAnalysis -XX:+UseCodeCacheFlushing -XX:CompileThreshold=8000 -XX:PermSize=128m"

ノート:

Xms値を変更することはお薦めしません。

大規模なジョブ・システム負荷

ジョブ・システムに長期間バックログがある場合、またはバックログを速く処理する場合、次のパラメータにemctl set propertyコマンドを設定できます。

表13-15 大規模なジョブ・システムのバックログ設定

パラメータ	値
oracle.sysman.core.jobs.shortPoolSize	50
oracle.sysman.core.jobs.longPoolSize	24
oracle.sysman.core.jobs.longSystemPoolSize	20
oracle.sysman.core.jobs.systemPoolSize	50
oracle.sysman.core.conn.maxConnForJobWorkers	144*

ノート:

*この設定はOMSサーバーの144のデータベースに設定するプロセスの増加が必要な場合があります。

これらの設定は、より多くの負荷をサポートできる十分なデータベース・リソースがあることを前提としています。これらのパラメータは2 OMSノードのある大規模な構成で必要となる場合があります。

OMSプロパティの変更

次の項では、この章でお薦めするOMS設定の変更例を説明します。たとえばジョブ・バックログ増加時に、OMSプロパティ設定の変更が必要となる可能性があります。例で示す値は、使用している構成に適した値に置き換える必要があります。次の手順に従って、OMSプロパティを変更します。

ヒープ・サイズの変更

Memory Argsの次のプロパティ名の値は、デフォルト値を上書きするために設定できます。

OMS_HEAP_MIN
OMS_HEAP_MAX
OMS_PERMGEN_MIN
OMS_PERMGEN_MAX

次の表に、これらのパラメータとその説明、デフォルト値、使用時の推奨事項、ノート、警告または既知の問題を示します。

名前	説明	デフォルト	推奨事項	ノート、警告または問題
OMS_HEAP_MIN (-Xms)	–Xmsの変更は実際は必要ありません。インストール後のデフォルト値のままにする必要があります。大規模な設定が時間の経過とともに非常に大きくなった場合、ユーザーやシステム管理者は、–Xmxの値を増やすタイミングでこの値を増やす場合があります。	32/64ビット: 小規模: 256M 中規模: 256M 大規模: 256M IBM JVMの場合、appサイズにかかわらず、次の設定を使用します。 32ビット: 1024M 64ビット: 1740M	「デフォルト」の項と同じ。これらはインストール後のデフォルト値であるため、推奨される設定です。	該当なし
OMS_HEAP_MAX (-Xmx)	ターゲットはEnterprise Managerの初回インストール/設定後に追加されるため、古い世代で予期しないメモリー不足エラーが発生しないように、HEAPサイズを増やすことをお薦めします。	32ビット: 小/中/大規模: 1524M 64ビット: 小規模: 1740M 中規模: 4096M 大規模: 8192M IBM JVMの場合、appサイズにかかわらず、ヒープ・サイズに制限はありません。	「デフォルト」の項と同じ。これらはインストール後のデフォルト値であるため、推奨される設定です。	常にメモリーの使用量が多かったために一定の期間でスループットが低下した場合は、これらのすべてのパラメータを変更する必要があります。パラメータを操作しているユーザー(sysadminを推奨)は、制限事項/警告を把握しておく必要があります。
OMS_PERMGEN_MIN (-XX:PermSize)	–XXの変更: PermSizeは必須ではありません。インストール後のデフォルト値のままにする必要があります。	32/64ビット: 小規模: 128M 中規模: 128M 大規模: 128M IBM JVMの場合、appサイズにかかわらず、次の設定を使用します。 32ビット: 128M 64ビット: 128M	「デフォルト」の項と同じ。これらはインストール後のデフォルト値であるため、推奨される設定です。	該当なし
OMS_PERMGEN_MAX (-XX:MaxPermSize)	大規模構成では、OMSコンテナでのアクティビティが多すぎると、多数のクラスローダーおよびClassオブジェクトが作成され、PermGenが一杯になり、その結果メモリー不足エラーが発生します。	32ビット: 小/中/大規模: 612M 64ビット: 小規模: 612M 中規模: 768M 大規模: 768M IBM JVMの場合、appサイズにかかわらず、次の設定を使用します。 32ビット: 612M 64ビット: 612M	「デフォルト」の項と同じ。これらはインストール後のデフォルト値であるため、推奨される設定です。	該当なし

次の2つのどちらかのコマンドを使用して、前述のプロパティのいずれかの値を設定できます。

emctl set property –name EM_JAVA_MEM_ARGS –value <complete memory parameter>

また、次のような指定もできます。

emctl set property –name <property_name> -value <number_followed_by_G_or_M>

次に例を示します。

emctl set property –name OMS_PERMGEN_MAX –value 1024M

次のコマンドを使用して、プロパティ名を取得します。

emctl get property –name <property_name>

JBO Argsの次のプロパティ名の値は、デフォルト値を上書きするために設定できます。

JBO_MIN_POOL_SIZE - この制限を超えると、アクティブでない時間がjbo.ampool.maxinactiveageの値を超えるアプリケーション・モジュールはアプリケーション・プールでタイムアウトします。デフォルト値は1です。
JBO_POOL_TTL - アプリケーション・モジュール・インスタンスが存続するアプリケーション・モジュール・プールの時間を定義します。デフォルト値は-1です。
JBO_LAZY_LOAD - コンポーネントの遅延ロードの有無を指定します。デフォルト値はTRUE。
JBO_MAX_CURSORS - ビジネス・コンポーネントで開くことのできるカーソルの最大数です。カーソル数がこの数値に近づくと、フレームワークでは空のJDBC文がクリーンアップされます。デフォルト値は5です。
JBO_RECYC_THRESHOLD - アプリケーション・モジュール・プールで使用されるリサイクルしきい値。デフォルト値は50です。
JBO_MAX_POOL_SIZE - この制限を超えると、jbo.ampool.maxinactiveageの値に達していなくても、アクティブでない時間の最も長いアプリケーション・モジュールがアプリケーション・プールでタイムアウトします。デフォルト値は50です。

次の2つのどちらかのコマンドを使用して、前述のプロパティのいずれかの値を設定します。

emctl set property –name EM_JAVA_MEM_ARGS –value <complete memory parameter>

また、次のような指定もできます。

emctl set property –name <property_name> -value <property_value>

次に例を示します。

emctl set property –name JBO_MAX_POOL_SIZE –value 5

次のコマンドを使用して、プロパティ名を取得します。

emctl get property –name <property_name>

プロパティ値の変更後、各OMSで次のコマンドを使用してOMSを再起動する必要があります。

emctl stop oms -all
emctl start oms

shortPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.shortPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.shortPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name “oracle.sysman.core.jobs.shortPoolSize"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name “oracle.sysman.core.jobs.shortPoolSize"

プロパティ値の変更後、各OMSで「emctl stop oms -all; emctl start oms」を使用してOMSおよびノード・マネージャを再起動する必要があります。デフォルト値は25です。

longPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.longPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.longPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name “oracle.sysman.core.jobs.longPoolSize"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name “oracle.sysman.core.jobs.longPoolSize"

プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は12です。

longSystemPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.longSystemPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.longSystemPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name “oracle.sysman.core.jobs.longSystemPoolSize"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name “oracle.sysman.core.jobs.longSystemPoolSize"

プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は10です。

systemPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.systemPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.systemPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name “oracle.sysman.core.jobs.systemPoolSize"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name “oracle.sysman.core.jobs.systemPoolSize"

プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は25です。

maxConnForJobWorkersの変更

OMSプロパティ(oracle.sysman.core.conn.maxConnForJobWorkers)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.conn.maxConnForJobWorkers -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name “oracle.sysman.core.conn.maxConnForJobWorkers"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name “oracle.sysman.core.conn.maxConnForJobWorkers"

プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は25です。

Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold (JAVA_EM_ARGS)の変更

OMSプロパティ(Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name JAVA_EM_ARGS -value "-Djbo.ampool.maxavailablesize=500 -Djbo.recyclethreshold=500"

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name "JAVA_EM_ARGS"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name "JAVA_EM_ARGS"

プロパティ値の変更後、各OMSで「emctl stop oms -all; emctl start oms」を使用してOMSを再起動する必要があります。

omsAgentComm.ping.heartbeatPingRecorderThreadsの変更

OMSプロパティ(oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

emctl set property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads -value 5

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

emctl get property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

emctl delete property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。

データベース設定の変更

事前構成済のリポジトリ用にデータベース・テンプレートをダウンロードしている場合、適切なSQLスクリプトを実行してデータベース・パラメータを推奨設定に調整できます。次の表に実行する必要のあるスクリプトを示します。

表13-16 DB 18.3.0.0.0のデプロイメント・サイズ用スクリプト

サイズ	スクリプト
小	`<DB_HOME>/assistance/dbca/templates/set_repo_param_<Database Version>_Database_SQL_for_<EM Version>_Small_deployment.sql`
中	`<DB_HOME>/assistance/dbca/templates/set_repo_param_<Database Version>_Database_SQL_for_<EM Version>_Medium_deployment.sql`
大	`<DB_HOME>/assistance/dbca/templates/set_repo_param_<Database Version>_Database_SQL_for_<EM Version>_Large_deployment.sql`

表13-17 DB 12.1.0.2.0のデプロイメント・サイズ用スクリプト

デプロイメント・サイズ	スクリプト
小規模	`<DB_HOME>/assistance/dbca/templates/set_repo_param_<Database Version>_Database_SQL_for_<EM Version>_Small_deployment.sql`
中規模	`<DB_HOME>/assistance/dbca/templates/set_repo_param_<Database Version>_Database_SQL_for_<EM Version>_Medium_deployment.sql`
大規模	`<DB_HOME>/assistance/dbca/templates/set_repo_param_<Database Version>_Database_SQL_for_<EM Version>_Large_deployment.sql`

ノート:

前述のスクリプトがMEMORY_TARGET/ SGA_TARGET/ PGA_AGGREGATE_TARGETを調整しないようにするために、これらのパラメータは手動で変更する必要があります。

Enterprise Manager Cloud Controlのパフォーマンス最適化の方法

拡大/縮小時に容量を正確に予測するために必要なのは、各Enterprise Manager Cloud Controlデプロイメントからの実際のメトリック傾向情報です。この情報と大まかな初期ホスト・システム・サイズの設定、チューニングとメンテナンスの繰返しの実行を組み合せることが、Enterprise Manager Cloud Controlデプロイメントの容量を予測する最も効果的な方法になります。また、デプロイメントのパフォーマンスを最適に保つことにも役立ちます。

Enterprise Manager Cloud Controlのサイジング手法の実施ステップは、次のとおりです。

まだEnterprise Manager Cloud Controlをインストールしていない場合は、表13-1に示すように、大まかな初期ホスト構成を選択します。
定期的にサイトのバイタル・サインを評価します(後述)。
DBAおよびEnterprise Manager管理のルーチン・ハウスキーピングを使用してボトルネックを排除します。
チューニングを使用してボトルネックを排除します。
今後に向けた直線外挿を行うことにより、将来のサイジング要件を計画します。

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

ステップ1: 最初のプラットフォームのCloud Controlデプロイの選択

最初のプラットフォームの Cloud Controlデプロイの選択については、「サイジング・ガイドラインの概要」を参照してください。

ステップ2: サイトのバイタル・サインの定期的な評価

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

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

モジュール	メトリック	EMサイト1	EMサイト2
サイト	-	emsite1	emsite2
ターゲット数	データベース・ターゲット	192 (45は起動されていない)	1218 (634は起動されていない)
-	ホスト・ターゲット	833 (12は起動されていない)	1042 (236は起動されていない)
-	ターゲット合計	2580 (306は起動されていない)	12293 (6668は起動されていない)
全体的ステータス	過去10分間の全体的バックオフ・リクエスト	0	500
ジョブ統計	現在のジョブ・ステップbacklogJobをクリアする推定時間	0.1	7804
イベント統計	保留中のイベント数	2	4000
管理サービス・ホスト統計	平均のCPU割合(ホスト1)	9 (emhost01)	13 (emhost01)
-	平均のCPU割合(ホスト2)	6 (emhost02)	17 (emhost02)
-	平均のCPU割合(ホスト3)	該当なし	38 (em6003)
-	平均のCPU割合(ホスト4)	該当なし	12 (em6004)
-	ホスト当たりのコア数	2 X 2.8 (Xeon)	4 X 2.4 (Xeon)
-	ホスト当たりのメモリー(GB)	8	8
管理リポジトリ・ホスト統計	平均のCPU割合(ホスト1)	12 (db01rac)	64 (em6001rac)
-	平均のCPU割合(ホスト2)	14 (db02rac)	78 (em6002rac)
-	ホスト当たりのCPUコア数	4	8
-	メモリー・ターゲット(GB)	5.25	7.5
-	ホスト当たりのメモリー(GB)	8	16
-	管理リポジトリ・サイズの合計(GB)	56	98
-	Oracle 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は、バックオフ・リクエストがほとんどなく、極めて正常に動作しています。また、ジョブおよびイベントのバックログが極めて低くなっています。OMSホストと管理リポジトリ・サーバー・ホストのCPU使用率は両方とも低い値です。最も重要なのは、UIページのレスポンス時間が非常に優れていることです。つまり、サイト1では最小限の労力で多くの処理が行われています。構成、チューニングおよびメンテナンスが適切に行われたOracle Enterprise Manager Cloud Controlサイトは、このような状態になります。

これに対し、EMサイト2には問題があります。このサイトには、かなりの量のバックオフがあり、ジョブおよびイベントのバックログも相当あります。最も大きな問題は、ユーザー・インタフェース・ページのレスポンス時間です。サイト2にボトルネックが存在するのは明らかです。複数のボトルネックがある可能性があります。

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

前出の表に示された、Enterprise Manager Cloud Controlサイトが良好に動作しているときのバイタル・サイン値のベースラインを測定します。
これらのベースライン値に基づいて妥当なしきい値および通知を設定し、正常な値から大きく逸脱した場合には自動的に通知されるようにします。このとき、サイトのしきい値を何度か繰返して微調整する必要があることがあります。受け取る通知が多すぎても役に立ちません。
1日(最低でも1週間)に1回、グラフで7日間にわたるこれらの値の傾向を監視します。これにより、近い将来に起こりうる問題を発見し、将来のリソース要件の計画を立てることができます。

Enterprise Managerコンソールでモニターするもう1つの重要なバイタル・サインは、メトリックやイベントのインフローを表示する、自己モニタリングの「マネージャの管理」リポジトリ・ページです。受け取るメトリックおよびイベント・データの微調整は、Enterprise Manager全体の状態とパフォーマンスを維持するために不可欠です。

次のステップでは、自己モニタリング・ページのメトリックおよびイベント・データのインフロー傾向からは異常がわからないが、設定したベースラインしきい値の範囲にバイタル・サイン値が収まらない場合に何をすべきかというガイドラインを示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。

ステップ3: DBAおよびEnterprise Managerタスクを使用したボトルネックの排除

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

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

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

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

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

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

ハウスキーピングを実行していない(パフォーマンス問題の最大の原因)
ハードウェアまたはソフトウェアが適切に構成されていない
ハードウェア・リソースの枯渇

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

高いCPU使用率

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

Enterprise Managerホストのホームページの「プロセス」画面を使用して、CPUのしきい値を超えた管理サービス・ホストまたは管理リポジトリ・ホストで最も多くのCPUを消費しているプロセスを判別します。
Enterprise Managerが最も多くのCPUを消費していることが明確になった場合は、Enterprise Managerを使用して、最も多くのCPUを消費しているアクティビティを特定します。これは通常、管理サービスの処理のほとんどが実行される管理リポジトリ・ホスト上に存在します。管理リポジトリが過剰にリソースを使用していると考えられる場合、一般的に次の点を調べる必要があります。
1. Enterprise Managerリポジトリについて「上位の待機イベント」メトリックを確認します。
2. 管理リポジトリの「データベース・パフォーマンス」ページにリストされた「使用中のCPU」データベース・リソースをクリックして、管理リポジトリで最も多くCPUを使用しているSQLを調べます。
3. 管理リポジトリの「データベース・パフォーマンス」ページの「データベース・ロック」で、競合問題がないか確認します。
4. 管理リポジトリのデータベース上のSQLモニタリングに、リソースを消費するSQLがないか確認します。

パフォーマンスのボトルネックの兆候として最も多いのは、高いCPU使用率です。通常は、管理リポジトリが最も多くCPUを消費しており、管理リポジトリを重点的に調べる必要があります。ハードウェア・リソースの制約が特になく、適切に構成およびメンテナンスが行われた管理リポジトリ・ホスト・システムの場合、CPU使用率の合計は平均して約40%以下になります。OMSホスト・システムのCPU使用率の合計は、平均して約20%以下である必要があります。平均値がこのように比較的低い場合は、アクティビティの急な増加にも十分に対応できます。アクティビティの急な増加を許容することで、ページ・パフォーマンスを長期間にわたって安定させることができます。Enterprise Manager Cloud Controlサイトのインタフェース・ページのレスポンスが良好(約3秒)で、大きなバックログが存在しない場合、CPUの使用率が推奨値を超えていても、大幅な上昇傾向にあると考えられる場合を除き、対処する必要はありません。

管理リポジトリのCPU使用率が高い場合、その根本的な原因を突き止めるために、前述のステップ3.a、3b、3cおよび3.dを行うことをお薦めします。CPUは、常に最上位の待機イベントになります。I/Oパフォーマンスの低下を示すログ・ファイル同期待機イベントは、上位5件の待機として表示されないことが理想です。根本的な原因を突き止めるには、管理リポジトリの「パフォーマンス」ページから、処理で最も多くCPUを消費しているSQLを探します。このようにして明らかになったことをAWRレポートと関連付けます。この方法は、いくつかの実際のサイトで使用され、成功しています。

Intelベースのホスト上でEnterprise Managerを実行している場合は、Enterprise Manager Cloud Control管理サービスと管理リポジトリの両方が、デプロイ先のホスト上で有効になっているハイパースレッディング(HT)のメリットを得られます。HTはIntelプロセッサの特定の最新モデルの機能であり、一定量のCPU命令のパラレルな実行を可能にするものです。これによって、システム上で物理的に使用可能なCPUの数は倍増します。HTを使用した場合、HTが使用可能になっていない同じシステムに比べて、CPU処理能力が約1.5倍になることがテストで実証されています。これにより、大幅にシステム・パフォーマンスを向上させることができます。管理サービスと管理リポジトリはどちらも複数のプロセスを同時に実行することが多いため、HTを使用するメリットは非常に大きくなります。

ローダーのバイタル・サイン

ローダーのバイタル・サインは、すべてのEnterprise Managerエージェントからシステムに絶えず送り込まれるデータの正確な量を示します。ここで最も重要な項目は、「過去1時間に返信されたエージェント数」メトリックです。このメトリックは、各管理サービスの「すべてのメトリック」ページにあります。これは過去1時間にデータのロードを遅延するように指示されたエージェントの数です。ロードの遅延を指示されるエージェントがないことが理想ですが、ある程度の遅延ロードは正常です。この値がデプロイされたエージェント数の2パーセントを超え、増え続ける場合には、対処する必要があります。

複数OMS環境でバックオフ・リクエストがOMSに均等に分散していることを確認します。バックオフ・リクエストが特定のOMSに関連し、OMS上で均等になっていない場合、サーバー・ロード・バランサで設定されているロード・バランシング・アルゴリズムがラウンドロビンであることを確認します。1時間当たり数百件のペースで重要なチャネルに連続してバックオフがあり、データベースに十分な空き領域がある場合のみ、ローダー・スレッドを追加します。

ローダー・スレッドの数はデフォルトで常にOMSごとに20に設定されます。OMSにローダー・スレッドを追加すると、全体のホストCPU使用率が高くなります。この値は、サイトの必要性に応じて変更できます。

リポジトリに使用可能なリソースが十分にない場合、ローダー・スレッドを追加すると収穫逓減が起こります。ローダー・スレッドの追加時に、使用可能なリポジトリ・リソースがある場合には、「過去1時間に返信されたエージェント数」メトリックが減ります。改善が見られない場合には、他のチューニングまたはハウスキーピングの機会を探る必要があります。

ローダー・スレッドをさらに追加するには、次の構成パラメータを変更できます。

oracle.sysman.core.gcloader.max_recv_thread

デフォルト値は20です。これはOMSごとの設定です。

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

ロールアップ・プロセスは、Enterprise Manager Cloud Controlの集計メカニズムです。ロールアップの2つのバイタル・サインは、行/秒と実行時間の割合です。ロールアップでは大量のデータ行が処理されるため、管理リポジトリのバッファ・キャッシュ領域を最も多く消費する傾向があります。このため、ロールアップのバイタル・サインを調べることで、バッファ・キャッシュ・サイズの拡大により効果が得られるかどうかを判断できます。

ロールアップの行/秒は、1秒間に処理または集計されて格納された行の正確な数を示します。バッファ・キャッシュのサイズが適切で、I/Oの速度も妥当なサイトでは、通常この値は1秒当たり約2,000行(+/- 500)です。この値が一定期間下降傾向を示している場合、将来的に問題が発生する可能性がありますが、実行時間の割合が100未満であれば、そのサイトは問題ないと考えられます。

ロールアップの実行時間の割合が上昇傾向にある(またはベースラインを超えている)場合、管理リポジトリのバッファ・キャッシュをまだ最大値に設定していなければ、バッファ・キャッシュ設定値を大きくすると効果があることがあります。通常は、バッファ・キャッシュを大きくするメリットがある場合には、管理リポジトリ・ホストのリソース使用率およびスループットが全体的に向上します。ローダー統計は多少改善されます。ホストのCPU使用率は低下し、I/Oは減少します。改善が最も顕著なのは、ロールアップ統計です。ロールアップの行/秒と実行時間の割合の両方で明らかな改善が見られます。これらのバイタル・サインのいずれにも改善が見られない場合、バッファ・キャッシュを以前のサイズに戻してもかまいません。古いバッファ・キャッシュ・ヒット率は、誤解を招く場合があります。バッファ・キャッシュが非常に小さいためにEnterprise Manager Cloud Controlのパフォーマンスが低下している場合に、バッファ・キャッシュ・ヒット率の値が高くなることがテストで観察されています。バッファ・キャッシュを大きくしてもCloud Controlのパフォーマンスが改善されない場合もあります。通常、これはアプリケーションの他の場所でリソース制約や競合があるためです。「高いCPU使用率」の項に示されたステップを使用して、競合の場所を特定することを検討してください。また、Cloud Controlでは、データベース自体からバッファ・キャッシュのサイズ設定に関するアドバイスを提供します。これは、データベースの「メモリー・パラメータ」ページで使用可能です。

バッファ・キャッシュの拡大を検討する際には、オペレーティング・システムにEnterprise Manager Cloud Controlのパフォーマンスの改善に役立つメカニズムが存在する可能性があることに注意してください。たとえば、Red Hat Linuxで使用可能なlarge memoryオプションがその一例です。Linux OS Red Hat Advanced Server(tm) 2.1(RHAS)には、big pagesという機能があります。RHAS 2.1では、bigpagesは大きな共有メモリー・セグメントの事前割当てに使用できる起動パラメータです。この機能を大きな管理リポジトリSGAとあわせて使用することで、Cloud Controlアプリケーション全体のパフォーマンスを大幅に向上させることができます。Red Hat Enterprise Linux(tm) 3からは、big pages機能はhuge pagesと呼ばれる新機能にかわり、起動パラメータは必要なくなりました。

ロールアップ・プロセス

ロールアップの実行時間の割合が上昇傾向にある(またはベースラインを超えている)とき、バッファ・キャッシュがすでに最適に設定されているのに、多くのクラスタ待機イベントがAWRレポートで報告される場合、ロールアップ・データベース・サービスを構成し、単一インスタンスRACノードのみでロールアップ・サービスを実行するようにアフィニティを設定します。単一インスタンスRACノードが、大きなI/Oボリュームを処理できるようにサイズ設定されていることを確認します。

ロールアップ・データベース・サービスでは次の構成ステップを使用します。

データベース・サービス「rollup」を作成し、RACインスタンスの1つをプライマリ・インスタンスとして「-r」に設定します。
- srvctl add service -d <dbname>-s rollup -r <primary instance> -a <the other instances> -y automatic
- srvctl start service -d <dbname>-s rollup
  
  srvctl status service -d <dbname>
sysユーザーとしてDBMS_SCHEDULER.create_job_class (job_class_name => 'ROLLUP'、service => 'rollup')を実行します
GRANT EXECUTE ON sys.ROLLUP TO sysman;
sysmanユーザーとしてDBMS_SCHEDULER.SET_ATTRIBUTE (name => 'EM_ROLLUP_SCHED_JOB'、attribute => 'job_class'、value => 'ROLLUP')を実行します
sysmanユーザーとしてGC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS ('EM_ROLLUP_SCHED_JOB'、'ROLLUP')を実行します

ロールアップ・データベース・サービスを構成する他に、追加スレッドによるロードの増加をデータベースが処理できる場合は、ロールアップ・ワーカー・スレッドを追加します。自己モニタリングの「マネージャの管理」リポジトリ・ページにある「メトリック:・ロールアップ・パフォーマンス」チャートの構成オプションを使用して、追加のロールアップ・ワーカー・スレッドを構成します。

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

ジョブ、通知およびアラートは、Enterprise Manager Cloud Controlサイトの管理サービスの処理効率を示します。

ジョブ

リポジトリのスケジュール済ジョブ・ステップでバックログのサイズが増加するのは、リポジトリに十分なリソースがないことを意味します。ジョブ・ディスパッチャの処理時間(%)が高いのは、リポジトリのボトルネックを意味します。ジョブ・ディスパッチャの処理時間(%)が高くスループットが低いのは、処理のボトルネックを意味します。ジョブ・サブシステムは、ロックを使用してシーケンスを内部で管理するため、アプリケーション・ロック待機イベントおよびトランザクション・ロック待機イベントをリポジトリのAWRレポートで確認できます。ジョブ・システムが待機時間の5-8%を消費するのは正常ですが、その値が20-30%を超えるときわめて異常であり、トリアージする必要があります。AWRのジョブSQLにクラスタ待機が大量にある場合は、RACサービスを導入することでジョブ・システムを最適化できる可能性があります。ジョブのためにデータベース・サービスを作成し、最適なパフォーマンスのために2ノードRACインスタンスで実行するようにアフィニティを設定します。

次の構成ステップを使用して、ロールアップ・データベース・サービスを設定します。

データベース・サービスemjobを作成し、RACインスタンスのうち2つをプライマリ・インスタンスとして「-r」に設定します。

srvctl add service -d <dbname> -s emjob -r <primary instances> -a <the other instances> -y automatic

データベース・サービスを作成した後、srvctl start service コマンドを使用してサービスを再開する必要があります。
次のDBMS_SCHEDULERジョブを実行します。
- sysユーザーとして、DBMS_SCHEDULER.create_job_class (job_class_name => 'EMJOB'、service => 'emjob ')を実行します
- GRANT EXECUTE ON sys.EMJOB TO sysman;
- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE (name => ' EM_JOBS_STEP_SCHED '、attribute => 'job_class'、value => 'EMJOB')を実行します
- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE (name => ' EM_JOB_PURGE_POLICIES '、attribute => 'job_class'、value => 'EMJOB')を実行します
- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_JOBS_STEP_SCHED', 'EMJOB')を実行します
- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_JOB_PURGE_POLICIES', 'EMJOB')を実行します
- INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('EM_jobs_step_sched_job_class', 'EMJOB')
pingサービス名の接続文字列をemctlプロパティに設定します

oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor
- サンプル: emctl set property -name "company.sysman.core.jobs.conn.service" -value "$DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP$$HOST=xxx.example.com$$PORT=1521$\)\)$CONNECT_DATA=\(SERVICE_NAME=emjob$\)\)"

イベントおよび通知

バイタル・サインがベースラインしきい値を超えた場合は、自己モニタリングの「マネージャの管理」ページでバイタル・サインを確認します。メトリック・アラート・バックログ、メトリック収集エラー・バックログおよび通知バックログの急激な増大が続いていないかチャートでモニターします。イベント・バックログをチェックする際に重要なメトリックは、「合計保留イベント」と「処理されたイベント合計(過去1時間)」です。「合計保留イベント」が多くても、「Total Events Processed (Last Hour)」で十分な進捗が見られる場合は、一時的な上昇として無視できる可能性があります。ただし、両方のメトリックが着実に増加している場合、データベース・サービスを導入して単一インスタンスRACノードのみで実行するようにアフィニティを設定するとイベント・サブシステムにメリットがあります。

イベント・データベース・サービスのために次の構成ステップを使用します。

データベース・サービスeventを作成し、RACインスタンスの1つをプライマリ・インスタンスとして「-r」に設定します

srvctl add service -d <dbname>-s event -r <primary instance> -a <the the other instances> -y automatic
pingサービス名の接続文字列をemctlプロパティoracle.sysman.core.events.connectDescriptorに設定します

サンプル emctl set property -name "oracle.sysman.core.events.connectDescriptor" -value "$DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP$$HOST=xxx.example.com$$PORT=1521$\)\)$CONNECT_DATA=\(SERVICE_NAME=event$\)\)"

Pingアラート

Pingアラートのパフォーマンスは、ターゲットの可用性を判別するために重要です。バイタル・サインがベースラインしきい値を超え、AWRレポートに多数のクラスタ待機がある場合は、Pingのためにデータベース・サービスを導入し、単一インスタンスRACノードのみで実行するようにアフィニティを設定すると明らかなメリットがあります。

Pingsデータベース・サービスを定義するために次の構成ステップを使用します。

データベース・サービスpingを作成し、RACインスタンスの1つをプライマリ・インスタンスとして「-r」に設定します

srvctl add service -d <dbname>-s ping -r <primary instance> -a <the the other instances> -y automatic
次のDBMS_SCHEDULERジョブを実行します
- sysユーザーとして、DBMS_SCHEDULER.create_job_class ( job_class_name => 'PING'、service => 'ping')を実行します
- GRANT EXECUTE ON sys.PING TO sysman;
- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_PING_MARK_NODE_STATUS'、attribute => 'job_class'、value => 'PING')を実行します
- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_REPOS_SEV_EVAL'、attribute => 'job_class'、value => 'PING')を実行します
- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS ('EM_REPOS_SEV_EVAL'、'PING')を実行します
- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS ('EM_PING_MARK_NODE_STATUS'、'PING')を実行します
pingサービス名の接続文字列をemctlプロパティoracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptorに設定します

サンプル

emctl set property -name oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor" -value "$DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP$$HOST=xxx.example.com$$PORT=1521$\)\)$CONNECT_DATA=\(SERVICE_NAME=ping$\)\)

構成メトリック・ポスト・ロード・コールバック

エージェントからOMSへの構成メトリックのアップロードは2ステップのプロセスです。

エージェントが構成メトリック・コレクションをOMSにアップロードし、OMSがEnterprise Managerリポジトリにアップロードを登録し、スナップショットを生成した後、アップロードされたペイロード(データ)を後で処理するためにローダー・ジョブ・キューと呼ばれるキューにフィードします。これにより、OMSのローダー・モジュールは構成メトリック・アップロードで必要な追加処理の負荷を軽減し、より多くのエージェントからのアップロードを処理してリソースを解放できます。
このキューからエントリを取得した後、データを処理してローダー・ジョブ・キューへの挿入順にリポジトリにデータを取り込むコールバックをコールする個別のモジュールがあります。このモジュールは、構成メトリック・ポスト・アップロード・コールバック・エグゼキュータ(またはローダージョブ)モジュールと呼ばれます。このモジュールにより、エンド・ユーザーは、データを処理するスレッドの数や、これらのスレッドがアクセス権を持つEnterprise ManagerリポジトリへのSQL接続の数、Enterprise ManagerリポジトリをホストするRACノードのいずれかに固定された専用のDBサービスを使用するかどうかを構成できます。

評価、小規模、中規模のEnterprise Managerサイトのサイズに関するデフォルト値は正常に機能します。大規模および特大規模の構成のデフォルト値はオーバーライドする必要がある場合があります。

DBサービスを構成し、リポジトリ・ノードに固定するには

srvctl add service -d <dbname>-s loaderjob -r <primary instance> -a <the the otherinstances> -y automatic

接続元としてDBサービスを構成するには

emctl set property -name "oracle.sysman.core.pbs.gcloader.connectDescriptor" -value 
"\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=loaderjob\)\)\)"

大規模

このモジュール用に作成されるスレッドの数を構成するには

emctl set property -name "oracle.sysman.core.pbs.gcloader.numThreads" -value 5

このモジュールのスレッドに使用可能なSQL接続の数を構成するには

emctl set property -name "oracle.sysman.core.gcloader.loaderjob.maxConnections" -value 5

特大

このモジュール用に作成されるスレッドの数を構成するには

emctl set property -name "oracle.sysman.core.pbs.gcloader.numThreads" -value 10

このモジュールのスレッドに使用可能なSQL接続の数を構成するには

emctl set property -name "oracle.sysman.core.gcloader.loaderjob.maxConnections" -value 10

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

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

管理リポジトリ・インスタンスからそのデータファイルへのディスクI/O
OMSと管理リポジトリの間のネットワークI/O
Oracle RACインターコネクト(ネットワーク) I/O (Oracle RACシステムの場合のみ)

これらのチャネルそれぞれについて、最大スループットおよび持続的スループットI/O機能を理解しておく必要があります。この情報および設定したベースライン値から、Cloud Controlで警告およびクリティカルのアラートの妥当なしきい値を導き出すことができます。しきい値を設定した後は、サイトでこれらのしきい値に近づいた場合に、自動的に通知されます。Cloud Controlのサイト管理者でも、サイトでこれらのI/Oチャネルが処理できる内容を知らなかったり、誤解していることがあります。このような場合、Enterprise Manager Cloud Controlがこれらのチャネルに過度な処理をさせることになり、それによってサイトのパフォーマンスは低下します。このような状況では、多くのバイタル・サインがその影響でよくない値を示します。

管理リポジトリが関連しているかどうかを調べるには、Cloud Controlを使用して「データベース・パフォーマンス」ページを確認します。管理リポジトリの「パフォーマンス」ページで、最大消費時間を示す待機グラフをクリックします。このグラフから、実際に待機しているSQLコードまたはセッションにドリルダウンできます。これは、ボトルネックの原因となっている箇所を理解するために役立ちます。

確認するもう1つの領域は、バックアップや別のアプリケーション、複雑なSQL問合せや複数のデカルト積などを使用してデータ・マイニングをしている社員がいる場合など、Enterprise Manager Cloud Control以外のソースからの予期しないI/Oロードです。

リポジトリI/Oの合計に関連する問題は、2つの要因により発生します。1つ目は、定期的にハウスキーピングが行われていないことです。Cloud Controlセグメントの一部が過度に断片化されるため、深刻なI/Oドレインが発生することがあります。2つ目に、適切にチューニングされていないSQL文がサイトのI/O帯域幅の大部分を消費している可能性もあります。Cloud Controlの多くのバイタル・サインの急な悪化は、ほとんどがこの2つの主要な問題によって起こります。また、ハウスキーピングが適切に行われていないために、管理リポジトリの割当てサイズが大幅に増加することもあります。

これを活用した重要な機能の1つが、非同期I/Oです。非同期I/Oを有効化すると、Cloud Controlアプリケーションの全体のパフォーマンスが大幅に向上する可能性があります。Sun Solaris(tm)およびLinuxオペレーティング・システムにはこの機能が搭載されていますが、デフォルトでは無効になっていることがあります。Microsoft Windows(tm)オペレーティング・システムでは、デフォルトで非同期I/Oが使用されます。管理リポジトリ・ホストおよび管理サービス・ホストに対して、このオペレーティング・システム機能を有効化しておくことをお薦めします。

Enterprise Manager Cloud Controlリポジトリ・データベースのストレージには、自動ストレージ管理(ASM)をお薦めします。

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

他のパフォーマンス低下はないが、Enterprise Managerのユーザー・インタフェース・ページが遅いことがあります。ページの遅れの一般的な原因は、Enterprise Managerハウスキーピングの領域が見落とされていることにあります。Enterprise Managerのページ・パフォーマンスのモニタリングにおける最初の項目は、Enterprise Managerビーコンの使用です。これらの機能は、Enterprise Manager以外のWebアプリケーションに対しても有用です。

ビーコンは、軽量なページ・パフォーマンス・モニタリング・ターゲットとなるように設計されています。管理エージェント上でビーコン・ターゲットを定義した後は、そのビーコンを使用してUIパフォーマンス・トランザクションを定義できます。これらのトランザクションは、手動で一度実行する一連のUIページ・ヒットです。それ以降は、ビーコンは指定された間隔でUIトランザクションを自動的に繰り返します。ビーコン・トランザクションが実行されるたびに、Enterprise Managerはそのパフォーマンスを計算し、履歴目的で格納します。また、ページ・パフォーマンスが指定したしきい値を下回ったときにアラートを生成することもできます。

Enterprise Managerビーコンを構成する場合、まず、このプロセスで指定したホームページをモニターする1つの事前定義済トランザクションから開始します。その後は、いくつでも必要な数のトランザクションを追加できます。ネットワーク上の異なるポイントから同じWebアプリケーションに対する追加のビーコンを設定して、WANの遅延がアプリケーション・パフォーマンスに与える影響を測定することもできます。Enterprise Manager Cloud ControlによりモニターされるすべてのWebアプリケーションに対して、これと同じ機能が使用可能です。

パフォーマンスが悪いUIページが示された後は、Enterprise Manager Cloud Controlのページ・パフォーマンス・モニタリングの2つ目の項目に進みます。Cloud Controlにおけるこのエンドツーエンド(E2E)モニタリング機能は、ページの処理時間をその基本単位に分解できるように設計されています。これにより、ページ・パフォーマンスを高めるためにメンテナンスが必要となる時期を特定できます。Cloud ControlにおけるE2Eモニタリングを使用すると、1つのページ・ヒットのクライアント側とサーバー側の両方の処理を分解できます。

「中間層パフォーマンス」セクションの次のページには、そのページの層別の処理時間が示されます。「処理時間ブレークダウン」という円グラフの最大の区分(上のJDBC時間)をクリックすると、SQLの詳細が表示されます。SQL文をクリックすると、そのSQL文の実行について一定期間のパフォーマンスが表示されます。

「JDBC」ページに、システムでページ時間の実行の大部分が消費されているSQLコールが表示されます。このSQLコールは、個別のDML文の場合もあれば、PL/SQLプロシージャ・コールの場合もあります。個別のSQL文の場合、その文によりアクセスされるセグメント(表およびその索引)を調べて、そのハウスキーピング(再作成および再編成)の必要の有無を判断する必要があります。PL/SQLプロシージャ・コールの場合は、管理リポジトリ内のプロシージャのソース・コードを参照して、そのコールによりアクセスされる表および関連する索引を特定する必要があるため、もう少し複雑になります。

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

Enterprise ManagerコンソールからSQLプロシージャのパフォーマンスをモニタリングする場合の新機能の詳細は、Enterprise Managerの管理ガイドのEnterprise Managerの保守に関する章を参照してください。

中間層OMSサーバーの最適な数の決定

中間層OMSサーバーの最適な数を決定することは、重要なタスクです。追加のOMSインスタンスの導入について、根拠のある、理にかなった、納得できる決定を下すには、様々な点を考慮する必要があります。モニター対象ターゲットの数は最初に検討する項目の1つですが、決定に及ぼす影響は、通常大きくありません。

このタスクの一環として、次の点について検討し、確認する必要があります。

使用されるジョブの自動化とスケジューリングのボリューム
コンソールで同時に作業する管理者の数
エージェントとOMSサーバーとの間のネットワーク帯域幅とチャネルの堅牢性
トリガーされる違反と通知の数
OMSサーバーが使用するIOシステムの速度と安定性

情報に基づいた決定をするには、各カテゴリを詳細に調べることが重要です。単にOMSサーバーを追加したり、同一ホストにCPUやメモリーを増設しても、パフォーマンスの向上に変化が見られない場合があります。現在稼働しているOMSインスタンスを使用して、現在のOMSのパフォーマンスについて実際の統計を収集し、現在または今後のデプロイメントに必要なOMSサーバーの数を計算します。Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間モニターする必要があります。

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

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

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

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

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

問合せの結果に関する予防措置を使用したパフォーマンスの向上

「すべてのターゲット」ページでは、問合せから返される行の数を制限して、大量のデータによってパフォーマンスが低下したり、OMS内のリソースが過度に消費されることを防ぐ予防措置がEnterprise Managerによってとられています。デフォルトでは、制限は2000に設定されていますが、Enterprise Manager管理者は次のコマンドを使用して制限を変更できます。

emctl set property -name oracle.sysman.core.uifwk.maxRows -value 2000

値に0を指定すると、予防措置が解除され、すべての行がフェッチされます。新しい値はただちに有効になり、OMSの再起動は必要ありません。値が0未満の場合、デフォルト値(2000)がかわりに使用されます。制限がないことを指示する方法は、値を0に設定することのみです。

問合せから返される結果が多すぎ、この制限が有効な場合、次のメッセージが結果表の下に表示されます。

「検索結果のこの表は、2000ターゲットに制限されています。「検索の絞込み」または「ターゲット名の検索」を使用して、結果を絞り込んでください。この制限を変更する方法は、チューニング・ガイドを参照してください。」

同様の動作(とメッセージ)は、Enterprise Manager内の他の大きな表にも当てはまります。同一のOMSプロパティ(oracle.sysman.core.uifwk.maxRows)でそれらすべての最大限度を一度に制御できます。これは、以前のリリースのEnterprise Managerの動作と一致し(かつ、既存のプロパティを再利用し)ます。

Fusion Middlewareのモニタリングに対するサイジングの要件の概要

Fusion Middlewareターゲットは、他のEnterprise Managerターゲットと似ています。したがって、Enterprise Managerターゲットに当てはまるリポジトリまたはサイジングのガイドラインは、Fusion Middlewareターゲットにも当てはまります。

Fusion Middleware検出での懸案事項の1つは、検出、作成およびモニターされるターゲットが多すぎる場合があるということです。これによって、OMSインスタンス、リポジトリおよびターゲットの負荷が増します。ターゲットが非常に多い場合、ターゲットの検出後、ターゲットとそのメトリックをすべて確認することをお薦めします。

ユーザーは、要件に基づいて、モニターするターゲットとメトリック、およびターゲットのモニターに必要な頻度を最終決定します。

検出後、Fusion Middleware/ADP/JVMDモニタリングを一定期間(数日、可能であれば数週間)実行し、データベースのサイズとオペレーティング・システムのファイルシステムの増加(ADPの場合、ADPマネージャは最低10GBのディスク領域が必要)のモニターを、増加が一定になるまで続けます。その後、これらの様々な機能に関連付けられている様々なパラメータを詳細に調整できます。

バージョン12cのEnterprise Managerでは、ADPとJVMDの両方でEnterprise Managerリポジトリがリポジトリとして使用されます。データは、MGMT_AD4J_TS表領域に格納されます。