Oracle Enterprise Managerフレームワーク、ホストおよびサービス・メトリック・リファレンス・マニュアル 10gリリース4(10.2.0.4) E05921-01 |
|
![]() 戻る |
![]() 次へ |
OMSおよびリポジトリ・ターゲットは、Oracle Enterprise Managerの管理サービス(OMS)および管理リポジトリの監視に役立つメトリックを提供します。
このメトリック・カテゴリには、消去されたグループ・セキュリティの違反に関する情報が含まれます。
このメトリック・カテゴリには、消去されたターゲット・セキュリティの違反に関する情報が含まれます。
これは、通知システムがクリティカル状態と判断すると、範囲外通知を送信しようとする管理エージェント・メトリックです。
通知の問題が悪化しているかどうかを判断するには、特定の通知タイプでこのメトリックを「通知待機(Notifications Waiting)」と組み合せて使用します。通知待機数が平均配信時間とともに増加する場合、通知自体の数の問題ではなく、配信上の問題である可能性が高くなります。配信時間の問題は、ネットワーク問題やリソース制約に関連している可能性があります。
データソース
このメトリックのデータは、name=<method_name>||_TOTAL_DELIVERY_TIMEという条件に一致するmgmt_system_performance_logのエントリから取得されます。
ユーザーの処理
値が徐々に増加している場合、次のユーザー処理を実行します。
「エラー」ページで、通知配信によって記録されたエラーを調べます。
通知配信パスのリソース制約を調べます(ネットワーク・エラー、電子メール・サーバーの停止、SNMPサーバーの停止など)。
このメトリックは、メンバー・ターゲットにセキュリティ・ポリシーが定義されているすべてのターゲット・グループの消去された違反に関する情報を収集します。消去された違反の数は、違反が修正されると増加します。このメトリックにより、セキュリティ・ポリシー違反の修正率の傾向を把握できます。
データソース
このメトリックのデータは、mgmt_policies、mgmt_violationsおよびmgmt_flat_target_assocのエントリから取得されます。
ユーザーの処理
消去された違反の数が変化しないか、消去された違反が存在しない場合、セキュリティ・ポリシー違反を調べ、ポリシーの推奨するとおりに違反が修正されていることを確認します。
このメトリックは、セキュリティ・ポリシーが定義されているすべてのターゲットの消去された違反に関する情報を収集します。消去された違反の数は、違反が修正されると増加します。このメトリックにより、セキュリティ・ポリシー違反の修正率の傾向を把握できます。
データソース
このメトリックのデータは、mgmt_policies、mgmt_violationsおよびmgmt_flat_target_assocのエントリから取得されます。
ユーザーの処理
消去された違反の数が変化しないか、消去された違反が存在しない場合、セキュリティ・ポリシー違反を調べ、ポリシーの推奨するとおりに違反が修正されていることを確認します。
このメトリックは、スケジュールが無効なDBMSジョブにフラグを立てます。1時間より前または1年より後にスケジュールされると、スケジュールは無効とマークされます。スケジュールが無効な場合、そのジョブは深刻な状況になります。
データソース
管理リポジトリ内のuser_jobs.next_time表。
ユーザーの処理
ジョブ・スケジュールが無効な場合は、DBMSジョブを再起動します。次の手順を実行します。
表内の行から停止中のDBMSジョブ名をコピーします。次の例では、停止中のDBMSジョブ名はyourDBMSjobnameです。
リポジトリ所有者としてデータベースにログインします。
次のSQL文を発行します。
select dbms_jobname from mgmt_performance_names where display_name='yourDBMSjobname';
dbms_jobnameがmyjobの場合、次のSQL文を発行します。
select job from all_jobs where what='myjob' ;
jobidをコピーします。
次のDBMSジョブ・コマンドとパラメータを指定し、再起動できるようにジョブを中断状態にします。
dbms_job.broken(jobid,true
)
次のSQL文を使用して、ジョブが中断状態としてマークされたことを確認します。
select what, broken from all_jobs where broken='Y';
結果にジョブが表示されます。
DBMSジョブが中断状態としてマークされていることを確認したら、次のDBMSジョブ・コマンドとパラメータを使用して、ジョブを再起動します。
dbms_job.run(jobid)
最近1時間にジョブが実行中だった割合です。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
ユーザーの処理
このメトリックの値が50%より大きい場合は、ジョブに問題がある可能性があります。「システム・エラー」ページで、ジョブによってエラーがレポートされていないかを調べます。アラート・ログで、ジョブ関連のアラートを調べます。
停止状態は、dbms_jobの中断状態と同じです。上矢印の場合は、中断していません。
データソース
「中断」列は、管理リポジトリ内のall_users表から取得されます。
ユーザーの処理
DBMSジョブの失敗の原因を特定します。失敗の原因を特定し、修正したら、dbms_job.runコマンドを使用して、ジョブを再起動します。
DBMSジョブの失敗の原因を特定するには、次の手順を実行します(myjobを表示された停止ジョブの名前に置き換えます)。
表内の行から停止中のDBMSジョブ名をコピーします。次の例では、停止中のDBMSジョブ名はyourDBMSjobnameです。
リポジトリ所有者としてデータベースにログインします。
次のSQL文を発行します。
select dbms_jobname from mgmt_performance_names where display_name='yourDBMSjobname';
dbms_jobnameがmyjobの場合、次のSQL文を発行します。
select job from all_jobs where what='myjob';
戻されたジョブIDを使用して、アラート・ログおよびトレース・ファイルでこのジョブIDに対するORA-12012メッセージを探し、問題の特定および修正を試みます。
次のデータベース・コマンドを使用すると、ジョブを手動で再起動できます。
execute dbms_job.run (jobid);
ローダーの処理を待機中のファイル数。10分ごとにサンプリングされます。
データソース
このメトリックは、管理リポジトリでmgmt_oms_parameters表の次の問合せを使用して取得します。
SELECT value FROM mgmt_oms_parameters where name='loaderFileCount'
ユーザーの処理
ロードを保留中のファイル数が長期にわたって徐々に増加している場合は、次のいずれかのオプションを検討します。
バックグラウンド・スレッド数を増やします。
管理サービスを追加して、いくつかの管理エージェントが新しい管理サービスを指すようにします。
このメトリックは、メンバー・ターゲットおよび自己ターゲットに関連するポリシー・ルールの平均コンプライアンス・スコアを提供します。コンプライアンス・スコアの範囲は、0〜100%です。このメトリックは、6時間(360分)ごとに収集されます。
このメトリックは、グループがポリシー・ルールにどの程度準拠しているかを示します。
データソース
このメトリックのデータは、MGMT_POLICY_ASSOC_EVAL_SUMMのエントリから取得されます。
ユーザーの処理
値が徐々に増加している場合、次のユーザー処理を実行します。
「ポリシー違反」タブにあるグループのポリシー・ルール・データを調べ、メンバー・ターゲットおよび自己ターゲットのポリシー・ルールの各コンプライアンス・スコアを調べます。
コンプライアンス・スコアの低いポリシー・ルールを特定し、手動または自動修正処理により対応するポリシー・ルール違反を解決します。
このメトリックは、メンバー・ターゲットに定義されているセキュリティ・ポリシーに関して、すべてのターゲット・グループのコンプライアンスの傾向を収集します。セキュリティ・コンプライアンス・スコアは、ターゲットのセキュリティ準拠状態を示します。スコア100は完全に準拠していることを示し、スコア0はまったく準拠していないことを示します。
データソース
このメトリックのデータは、mgmt_policy_assoc_eval_summのエントリから取得されます。
ユーザーの処理
コンプライアンス・スコアが継続的に低下している場合、セキュリティ・ポリシー違反を調べ、ポリシーの推奨するとおりに違反が修正されていることを確認します。
このメトリックは、個々のメンバー・ターゲットおよび自己ターゲットに関連するすべてのポリシー・ルールの平均コンプライアンス・スコアを提供します。このメトリック・データは、メンバー・ターゲットごとにロールアップされるため、グループのメンバー・ターゲット全体にわたるコンプライアンス・スコアを取得できます。
これにより、コンプライアンス・スコアに問題のないグループ内ターゲットの数と問題のあるグループ内ターゲットの数に関する傾向データを参照できます。
このメトリックは、6時間(360分)ごとに収集されます。
データソース
評価されたポリシーのコンプライアンス・スコアは、mgmt_policy_assoc_eval_summ表から取得されます。
ユーザーの処理
平均コンプライアンス・スコアが低下している場合、「セキュリティ一覧」ページでセキュリティ・ポリシー違反を調べます。違反しているポリシーを特定し、その違反を修正します。違反とそのポリシーの詳細は、「ポリシー違反」ページで参照できます。
このメトリックは、グループのメンバー・ターゲットおよび自己ターゲットに関連するすべてのポリシー・ルールの合計違反数を提供します。違反数とともに、違反レベル(クリティカル、警告または情報)も示されます。このメトリックにより、グループ・ポリシー違反データの全体的な傾向を把握できます。このメトリックは、6時間(360分)ごとに収集されます。
データソース
このメトリックのデータは、MGMT_POLICY_ASSOC_EVAL_SUMMのエントリから取得されます。
ユーザーの処理
値が徐々に増加している場合、次のユーザー処理を実行します。
グループ・ターゲットおよびそのメンバー・ターゲットのポリシー違反を調べます。
クリティカル・レベルの違反を優先的に処理し、次に警告および情報レベルの違反を処理します。「ポリシー違反」タブ・ページで、ポリシー違反の原因となっているポリシー・ルールを調べます。
手動または自動修正処理により違反を解決します。
すべてのディスパッチャがビジーだったために、スケジュールの準備はできているがスケジュールできなかったジョブ・ステップの数。
この数が徐々に増加している場合は、ジョブ・スケジューラがワークロードに対応できていないことを示します。
ユーザーの処理
このメトリックは、予定されているスケジュール時間がすでに経過してしまったジョブ・ステップ(実行準備は整っているがまだ実行されていないジョブ・ステップ)の合計数を示します。この数値のグラフが長期にわたって徐々に増加している場合は、次のいずれかの処理を行う必要があります。
web.xmlファイルのem.jobs.shortPoolSize
、em.jobs.longPoolSize
およびem.jobs.systemPoolSize
プロパティを大きくします。web.xmlファイルは、様々なタイプのジョブ・ステップを処理するために割り当てるスレッド数を指定します。ショート・プール・サイズは、ロング・プール・サイズより大きくします。
プロパティ | デフォルト値 | 推奨値 | 説明 |
---|---|---|---|
em.jobs.shortPoolSize | 10 | 10 50 | 実行時間が15分未満のステップ |
em.jobs.longPoolSize | 8 | 8 - 30 | 実行時間が15分を超えるステップ |
em.jobs.systemPoolSize | 8 | 8 - 20 | 内部ジョブ(エージェントのpingなど) |
別のホスト上で新しい管理アービスを追加します。
ジョブ・ステップの内容を調べ、効率が上がるかどうかを確認します。
ジョブ・ディスパッチャは、必要に応じてジョブのスケジュールを設定します。定期的に起動して、ジョブを実行する必要があるかどうかを調べます。ジョブ・ディスパッチャがしきい値レベルを超えて実行している場合は、ジョブ・ロードの処理に問題があります。
データソース
管理リポジトリ内のmgmt_system_performance_log表の、最近1時間にジョブが実行された時間の合計を1時間で割り、100を掛けてパーセントで表します。
ローダーがファイルを取得しているディレクトリ。
データソース
このメトリックは、管理リポジトリでmgmt_oms_parameters表の次の問合せを使用して取得します。
SELECT value FROM mgmt_oms_parameters where name='loaderDirectory'
ユーザーの処理
ローダー・ディレクトリに領域がない場合は、エラー・ファイルを検索して問題を調査できます。
管理サービスのローダー名と管理サービス名との間をカンマで区切って構成される、一意のローダー名。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
これは、最近1時間にローダー・スレッドが処理したXMLテキストの行数です。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
ユーザーの処理
この数値が長期にわたって増加し続けている場合は、ユーザーは管理サービスを追加するか、この管理サービスに対するローダー・スレッド数を増やすことを検討します。ローダー・スレッド数を増やすには、emoms.propertiesファイルのem.loader.threadPoolSize
エントリを追加または変更します。スレッド数のデフォルトは2です。2〜10の間の値が一般的です。
これは、最近1時間にローダー・スレッドが処理したXMLテキストの1秒当たりの平均行数です。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
管理サービスが稼働中または停止中かどうかを表示します。
データソース
管理リポジトリ内のmgmt_oms_parameters表およびmgmt_failover_table表。
ユーザーの処理
管理サービスが停止している場合は、起動します。停止している管理サービスのみ削除できます。
このメトリックは、メンバー・ターゲットにセキュリティ・ポリシーが定義されているすべてのターゲット・グループで発生した新規違反に関する情報を収集します。新規違反の数は、新しい違反が発生すると増加し、違反が消去されると減少します。このメトリックにより、新規セキュリティ・ポリシー違反の発生率の傾向を把握できます。
データソース
このメトリックのデータは、mgmt_policies、mgmt_violationsのエントリから取得されます。
ユーザーの処理
新規違反の数が継続的に増加している場合、セキュリティ・ポリシー違反を調べ、ポリシーの推奨するとおりに違反が修正されていることを確認します。
このメトリックは、セキュリティ・ポリシーが定義されているすべてのターゲットで発生した新規違反に関する情報を収集します。新規違反の数は、新しい違反が発生すると増加し、違反が消去されると減少します。このメトリックにより、新規セキュリティ・ポリシー違反の発生率の傾向を把握できます。
データソース
このメトリックのデータは、mgmt_policies、mgmt_violationsのエントリから取得されます。
ユーザーの処理
新規違反の数が継続的に増加している場合、セキュリティ・ポリシー違反を調べ、ポリシーの推奨するとおりに違反が修正されていることを確認します。
最近1時間に通知の配信にかかった時間の平均。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
ユーザーの処理
平均配信時間が徐々に長くなっている場合は、指定した通知方法が有効であることを確認します。不必要または期限切れの通知ルールおよびスケジュールは削除します。
最近1時間に通知の配信を実行している割合です。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
ユーザーの処理
平均配信時間が徐々に長くなっている場合は、指定した通知方法が有効であることを確認します。不必要または期限切れの通知ルールおよびスケジュールは削除します。
通知DBMSジョブ(通知が必要かどうか決定するための重大度を処理)が稼働中なのか停止中なのかを表示します。
データソース
管理リポジトリ内のuser_jobs表。
ユーザーの処理
DBMSジョブの失敗の原因を特定します。失敗の原因を特定し、修正したら、dbms_job.runコマンドを使用して、ジョブを再起動します。
DBMSジョブの失敗の原因を特定するには、次の手順を実行します。
管理リポジトリの所有者としてデータベースにログインします。
次のSQL文を発行します。
select job from all_jobs where what like '%CHECK_FOR_SEVERITIES%';
戻されたジョブIDを使用して、アラート・ログおよびトレース・ファイルでこのジョブIDに対するORA-12012メッセージを探し、問題の特定および修正を試みます。
次のDBMSジョブ・コマンドとパラメータを発行します。
execute dbms_job.run (jobid);
最後の10分間に管理サービスによって配信された通知の合計数。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
ユーザーの処理
処理された通知の数が数日間増加し続けている場合は、管理サービスを追加することを検討します。
「通知メソッドのパフォーマンス(Notification Method Performance)」メトリックは、SNMP、EMAIL、OSCMD、PLSQL、RCAなどの各通知タイプのパフォーマンス・データを測定します。このメトリックは、該当するメソッド・タイプのキューに格納されている通知の数を示します。
データソース
このメトリックのデータは、name=<method_name>||_S_QUEUEDという条件に一致するmgmt_system_performance_logのエントリから取得されます。
ユーザーの処理
値が徐々に増加している場合、次のユーザー処理を実行します。
「エラー」ページで、通知配信によって記録されたエラーを調べます。
メソッドを使用して定義されている通知ルールの数を調べ、不必要なルールは削除して必要なルールのみが定義されているようにします。
通知に使用されているアドレスが正しいことを確認します。
リポジトリ内のアクティブなエージェントの数。この数が0の場合、Enterprise Managerではどの外部ターゲットも監視していません。予期しない状況である場合は、問題が発生している可能性があります。
データソース
mgmt_current_availability表でステータスが稼働中となっているエージェントの数。
ユーザーの処理
エージェントが1つも実行されていない場合、エージェントが停止した原因を特定し、必要に応じて修正した後に再起動します。エージェントの停止原因に関連する可能性のある情報は、エージェントの$ORACLE_HOME/sysman/logディレクトリ内のログ・ファイルに含まれます。
Enterprise Managerに対して定義されている管理者の数。
データソース
管理リポジトリ内のmgmt_created_users表。
管理リポジトリ内の重複したターゲットの数。
データソース
管理リポジトリ内のmgmt_duplicate_targets表。
ユーザーの処理
管理システムの概要ページで「重複したターゲット」リンクをクリックし、「重複したターゲット」ページに進みます。重複したターゲットに関係する問題がある場合は、管理システムの概要ページに「重複したターゲット」リンクが表示されるだけです。
競合する管理エージェントから重複したターゲットを削除して、競合を解決します。
Enterprise Managerに対して定義されているグループの数。
データソース
管理リポジトリ内のmgmt_targets表。
ユーザーの処理
「すべてのターゲット」ページの表示に問題がある場合は、ロール数およびグループ数を確認します。
Enterprise Managerに対して定義されているロールの数。
データソース
管理リポジトリ内のmgmt_roles表。
ユーザーの処理
「すべてのターゲット」ページの表示に問題がある場合は、ロール数およびグループ数を確認します。
Enterprise Managerに対して定義されているターゲットの数。
データソース
管理リポジトリ内のmgmt_targets表。
このメトリックは、最も古いローダー・ファイルがローダーによる処理を待機している時間を示します。これは、管理エージェントが情報を送信してからユーザーが情報を受け取るまでの遅れを示します。
データソース
このメトリックは、管理リポジトリでmgmt_oms_parameters表の次の問合せを使用して取得します。
SELECT value FROM mgmt_oms_parameters where name='loaderOldestFile'
ユーザーの処理
最も古いローダー・ファイルが極端に古い場合は、ローダーに問題があります。管理サービスを追加して、いくつかの管理エージェントが新しい管理サービスを指すようにします。
これは、現在管理リポジトリ表領域が使用している合計MB数です。
データソース
管理リポジトリ内のdba_data_files表。
エージェントが過去24時間以内に再起動された回数。
データソース
次のように導出されます。
(SELECT t.target_name, COUNT(*) down_count FROM mgmt_availability a, mgmt_targets t WHERE a.start_collection_timestamp = a.end_collection_timestamp AND a.target_guid = t.target_guid AND t.target_type = MGMT_GLOBAL.G_AGENT_TARGET_TYPE AND a.start_collection_timestamp > SYSDATE-1 GROUP BY t.target_name)
ユーザーの処理
この回数が多い場合、エージェント・ログを調べて、再起動を引き起こすシステム状態が存在しているかどうかを確認します。エージェントが再起動を繰り返す場合、再起動問題が発生しているエージェントのターゲットに「データをアップロードしないターゲット(Targets Not Uploading Data)」メトリックも設定できます。再起動問題は、システムのリソース制約や構成上の問題に原因がある可能性があります。
ジョブ・ディスパッチャが処理した1秒当たりのジョブ・ステップの数(10分ごとにサンプリングした最近1時間の平均)。
データソース
管理リポジトリ内のmgmt_job_execution表。
ターゲットが作成される割合。通常、ターゲットの追加率は、EMがインストールされた直後に最大となり、新規エージェントが追加されるたびに一時的に増加します。この割合が不自然に増加している場合、異常なエージェントまたは管理者アクティビティが存在しないかどうかを調べ、ターゲットが適切に稼働していることを確認します。また、不要なグループが作成されていないかどうかを調べます。
データソース
このメトリックは、mgmt_target表の現在のターゲット数(最新のサンプリングで取得されたターゲット数)から導出されます。
このメトリックは、各ターゲットのコンプライアンス・スコアを提供します。このメトリックは、特定のターゲットに関連する個々のポリシー・ルールのコンプライアンス・スコアに基づいて算出されます。コンプライアンス・スコアの範囲は、0〜100%です。これにより、関連するポリシー・ルールにターゲットがどの程度準拠しているかを判断できます。このメトリックは、6時間(360分)ごとに収集されます。
データソース
このメトリックのデータは、MGMT_POLICY_ASSOC_EVAL_SUMMのエントリから取得されます。
ユーザーの処理
値が徐々に減少している場合、次のユーザー処理を実行します。
「ポリシー違反」タブにあるターゲットのポリシー・ルール・データを調べ、ターゲットのポリシー・ルールの各コンプライアンス・スコアを調べます。
コンプライアンス・スコアの低いポリシー・ルールを特定し、手動または自動修正処理により対応するポリシー・ルール違反を解決します。
このメトリックは、ターゲットに定義されているセキュリティ・ポリシーに関して、すべてのターゲットのコンプライアンスの傾向を収集します。セキュリティ・コンプライアンス・スコアは、ターゲットのセキュリティ準拠状態を示します。スコア100は完全に準拠していることを示し、スコア0はまったく準拠していないことを示します。
データソース
このメトリックのデータは、mgmt_policy_assoc_eval_summのエントリから取得されます。
ユーザーの処理
コンプライアンス・スコアが継続的に低下している場合、セキュリティ・ポリシー違反を調べ、ポリシーの推奨するとおりに違反が修正されていることを確認します。
このメトリックは、各ターゲットに関連するすべてのポリシー・ルールの合計違反数を提供します。違反数とともに、違反レベル(クリティカル、警告または情報)も示されます。このメトリックは、6時間(360分)ごとに収集されます。
このメトリックにより、ターゲット・ポリシー違反データの全体的な傾向を把握できます。
データソース
このメトリックのデータは、MGMT_POLICY_ASSOC_EVAL_SUMMのエントリから取得されます。
ユーザーの処理
値が徐々に増加している場合、次のユーザー処理を実行します。
クリティカル・レベルの違反を優先的に処理し、次に警告および情報レベルの違反を処理します。「ポリシー違反」タブ・ページで、ポリシー違反の原因となっているポリシー・ルールを調べます。
手動または自動修正処理により違反を解決します。
配信された1秒当たりの通知数(最近1時間の平均)。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
このメトリックは、最近1時間のローダー・スレッドの実行時間を秒単位で表します。
データソース
管理リポジトリ内のmgmt_system_performance_log表。
ユーザーの処理
この数値が「ローダー・スループット(行/時間)(Loader Throughput (rows per hour))」メトリックとともに徐々に増加している場合は、「ローダー・スループット(行/時間)(Loader Throughput (rows per hour))」メトリックの「ユーザーの処理」で説明している処理を実行します。この数値は増加しているがローダー・スループットは増加していない場合は、プロセスによる高いCPU使用率、管理リポジトリ・データベースでのデッドロック、プロセッサ・メモリーの問題など、リソースの制約を調べます。
OMSおよびリポジトリ・ターゲットは、Oracle Enterprise Managerの管理サービス(OMS)および管理リポジトリの監視に役立つメトリックを提供します。
このメトリック・カテゴリには、リポジトリ収集のパフォーマンスに関する情報が含まれます。各データは、収集ワーカーと呼ばれるリポジトリ・データベース内のバックグラウンドDBMSジョブによって収集されます。リポジトリのメトリックは、長期実行と短期実行のメトリックに分類されます。これらはタスク・クラス(短期タスク・クラスと長期タスク・クラス)と呼ばれます。いくつかの収集ワーカー(デフォルトは1)は短期タスク・クラスを処理し、別のいくつかの収集ワーカー(デフォルトは1)は長期タスク・クラスを処理します。「リポジトリ収集パフォーマンス(Repository Collections Performance)」メトリックは、各タスク・クラスのリポジトリ・メトリック収集のパフォーマンス・データを測定します。このメトリックは、リポジトリ・メトリックの1つであるため、収集ワーカーによって収集されます。
このメトリック・カテゴリには、リポジトリ・ジョブ・ディスパッチャに関する情報が含まれます。
最近10分間に収集ワーカーが稼働していた合計時間を秒単位で表します。これは、リポジトリ収集サブシステムに対する負荷を示します。負荷が高い場合、収集の数が増加しているか、一部のメトリックで処理を完了するのに長い時間を要していると考えられます。このメトリックを「処理された収集(Collections Processed)」メトリックと関連付けて把握し、収集の数が増加しているか、メトリックの処理に長い時間を要しているかを判断する必要があります。
データソース
このメトリックのデータは、job_name=MGMT_COLLECTION.Collection Subsystemという条件を満たすmgmt_system_performanceログのエントリから取得されます。
最近10分間に処理された収集の合計数。
データソース
このメトリックのデータは、job_name=MGMT_COLLECTION.Collection Subsystemという条件を満たすmgmt_system_performanceログのエントリから取得されます。
このメトリックの収集時点で実行を待機していた収集の合計数。この値が増加している場合、収集ワーカーが不足しているため、その数を増やす必要があります。実行待機中の収集は、システム起動時の初期段階では多く存在する可能性がありますが、その後は0(ゼロ)に近づいていくのが普通です。
データソース
このメトリックのデータは、収集のすべてのリストを保持するmgmt_collection_tasks表のエントリから取得されます。
このページは、Enterprise Managerが稼働中かまたは停止中かを表示します。停止していた期間の履歴情報も含まれます。
このメトリックは、Enterprise Managerが稼働中かまたは停止中かを表示します。有効な電子メール・アドレスでoracle_emrepターゲットを監視するエージェントを構成している場合、Enterprise Managerが停止したときに電子メール通知を受信できます。
メトリック・サマリー
次の表は、メトリックの値が収集され、デフォルトのしきい値と比較される頻度を示しています。「通知前の発生の連続回数」列は、しきい値との比較の結果が連続して何回TRUEとなればアラートが生成されるかを示しています。
表3-1 メトリック・サマリー表
ターゲットのリリース | 評価および収集頻度 | アップロード頻度 | 演算子 | デフォルトの警告のしきい値 | デフォルトのクリティカルのしきい値 | 通知前の発生の連続回数 | アラート・テキスト |
---|---|---|---|---|---|---|---|
すべてのリリース |
5分ごと |
アップロードなし |
= |
定義なし |
0 |
1 |
<Message> |
データソース
sysman/admin/scripts/emrepresp.pl
ユーザーの処理
このメトリックは、次の項目を確認します。
管理リポジトリ・データベースが稼働していてアクセス可能かどうか。
管理リポジトリ・データベースが停止している場合は、起動します。「ユーザー名またはパスワードが無効です」というエラーが表示された場合、oracle_emrepターゲットの名前およびパスワードが、リポジトリ所有者の名前およびパスワードと同じであることを確認します。
1つ以上の管理サービスが実行中かどうか。
管理サービスが実行中でない場合は、開始します。
「リポジトリ・メトリック(Repository Metrics)」のDBMSジョブが実行中かどうか。
DBMSジョブが停止中であるか、無効なスケジュールが割り当てられている場合、「DBMSジョブの無効なスケジュール(DBMS Job Bad Schedule)」メトリックの「ユーザーの処理」で説明している処理を実行し、ジョブを再起動します。