プライマリ・コンテンツに移動
Oracle® Enterprise Manager Cloud Control管理者ガイド
13c リリース2
E78869-07
目次へ移動
目次 		索引へ移動
索引
前
前へ 		次
次へ

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

Enterprise Managerの各種コンポーネントを構成し、そのコンポーネントが効率的に実行している場合、Oracle Management Serviceは、管理対象ホストで実行している管理エージェントから大量のRAWデータを収集し、そのデータを管理リポジトリにロードします。このデータは、後でCloud Controlコンソールで集計、編成、表示されるRAW情報です。

Oracle Management Serviceが管理リポジトリに情報をロードすると、Enterprise Managerは時間の経過とともにデータを集約してパージします。

この項では、次の項目について説明します。

  • 管理リポジトリでのデータのメンテナンスに使用される集計とパージのデフォルトのポリシー。

  • データが集計されて管理リポジトリからパージされるまでのデータの保持時間の変更方法。

20.2.1 管理リポジトリの集計とパージのデフォルトのポリシー

Enterprise Managerは、時単位および日単位でメトリック・データを集計することで、問合せパフォーマンスを高めて管理リポジトリのサイズを最小限に抑えます。データを集計する前に、各データ・ポイントがRAWメトリック・データ表に保存されます。1日に1度、前日のRAWメトリック・データがロールアップまたは集計されて、1時間および1日単位の表にまとめられます。これらの毎時および日次レコードには、毎時および日次のメトリック・データの平均、最小、最大および標準偏差が含まれます。

Enterprise Managerがデータを集計すると、データはパージ対象とみなされます。データは一定の期間が経過してから実際にパージされます。この期間を保存時間と言います。

RAWデータの挿入量が最大の場合、デフォルトの保存時間は最短になり、7日に設定されます。その結果、データが1時間単位のレコードに集計されてから7日が経過すると、RAWデータ・ポイントがパージの対象となります。

注意:

このデータ保持ポリシーは、JVMDおよびADPデータでは異なります。

毎時集計されたメトリック・データ・レコードは、31日後にパージされます。最大レベルの集計(1日)は、12か月間保持されます(約365日)。

表20-1にデフォルトのデータ保持ポリシーをまとめています。

表20-1 デフォルトのリポジトリ・パージ・ポリシー

集計レベル 保存時間

Rawメトリック・データ

7日

毎時の集計メトリック・データ

31日

日次の集計メトリック・データ

24か月

アプリケーション・パフォーマンス管理を構成して有効にしている場合、Enterprise Managerはレスポンス時間データも収集、保存、集計、パージします。レスポンス時間データは、メトリック・データに使用されるものと同様のポリシーを使用してパージされます。表20-2にアプリケーション・パフォーマンス管理のパージ・ポリシーを示します。

表20-2 アプリケーション・パフォーマンス管理データのデフォルトのリポジトリ・パージ・ポリシー

集計レベル 保存時間

RAWレスポンス時間データ

24時間

1時間の集計レスポンス時間データ

7日

1時間の分散レスポンス時間データ

24時間

1日の集計レスポンス時間データ

31日

1日の分散集計レスポンス時間データ

31日

重大度データをデフォルトの期間(6か月)保存しない場合、およびEVENTSパージ・ポリシー用の保存期間を短縮する場合は、次のコマンドを使用します。

em_purge.modify_purge_policy_group('EVENTS',NULL,*l_new_purge_hours*);

このコマンドは、そのグループに関連付けられているすべてのパージ・ポリシーに影響を与えるパージ・ポリシー・グループのみを変更します。パージ・ポリシーがパージ・グループに関連付けられている場合、保存期間はグループの保存期間になります。パージ・ポリシー(パージ・ポリシー・グループに関連付けられている)の保存が変更された場合、保存はパージ・ポリシー・グループではなくパージ・ポリシーから決定されます。

個々のパージ・ポリシーを変更するには、次のコマンドを使用します。

em_purge.modify_purge_policy(
  p_policy_name     IN VARCHAR2,
  p_retention_hours IN NUMBER
)

「設定」メニューから「Cloud Controlの管理」、「リポジトリ」の順に選択して、パージ・ポリシーおよびパーティション保存値を変更できます。このページで「スキーマ」タブを選択し、「パージ・ポリシー」セクション(「変更」をクリック)または「パーティション保存」セクションで必要な変更を加えます。

デフォルトでは、イベント情報は分割されて6か月の履歴データが管理されます。前述の手順を使用して、デフォルトの保存期間を変更することができます。重大度データは、イベント・データのパージ・ポリシーに関連付けられ、適宜調整されます。

このデータのパージによって影響を受ける、修正された表は、次のように示されます。

EM_EVENT_SEQUENCES
EM_EVENT_RAW
EM_EVENT_MSGS
EM_EVENT_CONTEXT
EM_EVENT_ANNOTATIONS
EM_EVENTS_INCIDENT
EM_ISSUES_INTERNAL
EM_ISSUES_MSG
EM_ISSUES_ANNOTATIONS
EM_INCIDENT_ISSUE
EM_PROBLEM_ISSUE
EM_INCIDENTS_PROBLEM

次の一覧は、Enterprise Managerでサポートされる様々なイベント・タイプのデータを保存する表の動的なセットです。新しいイベント・タイプまたはサポートされないイベント・タイプが追加または削除されると、このリストは時間の経過に伴って変化します。

EM_EV_CS_RULE_VIOLATION
EM_EV_CS_SCORE
EM_EV_JOB_STATUS_CHANGE
EM_EV_METRIC_ALERT
EM_EV_METRIC_ERROR
EM_EV_MEXT_UPDATE
EM_EV_MNTR_DISRUPTION
EM_EV_SELFUPDATE
EM_EV_SLA_ALERT
EM_EV_TARGET_AVAILABILITY
EM_EV_USER_REPORTED
EM_EV_ADP_ALERT
EM_EV_APM_KPI_ALERT
EM_EV_JVMDIAG_ALERT
EM_EV_HA_EVENT

20.2.2 その他の管理データに関する管理リポジトリの集計およびパージのデフォルトのポリシー

メトリック・データとアプリケーション・パフォーマンス・モニタリング・データ以外に、その他のタイプのEnterprise Managerデータが時間の経過とともに管理リポジトリに蓄積されます。

たとえば、ターゲットの最後の可用性レコードも管理リポジトリに無期限で残るため、ターゲットの最後の既知の状態が保存されます。

20.2.3 集計およびパージのデフォルトのポリシーの変更

Enterprise Managerの集計およびパージのデフォルトのポリシーは、管理リポジトリに対して最大パフォーマンスと最小ディスク領域の要件を実現し、分析に最も利用可能なデータを提供するように設計されました。そのため、パフォーマンスを改善したり、使用可能なディスク領域を増やしたりするためにこれらのポリシーを変更する必要はありません。

ただし、Enterprise Manager以外のデータ分析ツールを使用してRAWデータや集計データを抽出または確認する場合、管理リポジトリで使用可能なRAWデータや集計データの量を増やすことができます。これを行うには、RAWデータや集計データの保存時間を増やします。

Enterprise Managerリポジトリの中心的なメトリック・データ表のデフォルトの保持時間を変更するために、PL/SQL APIが提供されています。表20-3は、3つの表でそれぞれ保持されるデフォルトのパーティション数、および各表のパーティションのサイズを示しています。APIでは、保持されるパーティション数のみを変更できます。

表20-3 中心的なEMメトリック・データ表および管理リポジトリでのデフォルトのデータ保持

表名 保持されるパーティション パーティション・サイズ

EM_METRIC _VALUES

7

日

EM_METRIC_VALUES_HOURLY

32

日

EM_METRIC_VALUES_DAILY

24

月

前述の表の保持期間を変更するには、次のコマンドを実行します。

SQL> execute gc_interval_partition_mgr.set_retention('SYSMAN', <table name>, <number of partitions to retain>);

<table name>を前述の表の名前に置き換えます。APIでは、保持されるパーティション数のみを変更できます。

たとえば、表EM_METRIC_VALUESのデフォルトの保持期間を7パーティションから14パーティションに変更するには、次の手順に従います。

  1. SQL*Plusを使用してSYSMANユーザーとしてリポジトリ・データベースに接続します。
  2. 保持期間の現在の値を確認します。
    SQL> select table_name, partitions_retained
from em_int_partitioned_tables
where table_name in ('EM_METRIC_VALUES','EM_METRIC_VALUES_HOURLY','EM_METRIC_VALUES_DAILY');
 
TABLE_NAME                 PARTITIONS_RETAINED
-------------------------  -------------------
EM_METRIC_VALUES                             7
EM_METRIC_VALUES_HOURLY                     32
EM_METRIC_VALUES_DAILY                      24
  3. 表EM_METRIC_VALUESのデフォルトの保持期間を7パーティションから14パーティションに変更するには、次のコマンドを実行します。

    SQL> execute gc_interval_partition_mgr.set_retention('SYSMAN', 'EM_METRIC_VALUES', 14);

  4. 保持期間が変更されたことを確認します。
    SQL> select table_name, partitions_retained
from em_int_partitioned_tables
where table_name in ('EM_METRIC_VALUES','EM_METRIC_VALUES_HOURLY','EM_METRIC_VALUES_DAILY');
 
TABLE_NAME                PARTITIONS_RETAINED
------------------------- -------------------
EM_METRIC_VALUES                           14
EM_METRIC_VALUES_HOURLY                    32
EM_METRIC_VALUES_DAILY                     24

20.2.4 ジョブ履歴の保存時間の変更方法

Enterprise Manager Cloud Controlには、30日が経過した古い完了済ジョブの詳細をすべて削除するデフォルトのパージ・ポリシーがあります。この項では、このデフォルトのパージ・ポリシーの変更について詳しく説明します。

完了済ジョブ履歴の実際のパージは、リポジトリ・データベースで一日に1回実行されるDBMS_SCHEDULERジョブで実装されます。ジョブが実行されると、現在の時刻(リポジトリ・データベースのsysdateの値)よりも「n」日古い完了済ジョブを検索し、これらのジョブを削除します。値「n」はデフォルトでは30日に設定されています。

デフォルトのパージ・ポリシーはEnterprise Managerコンソールでは変更できませんが、SQL*Plusを使用して変更できます。

このパージ・ポリシーを変更するには、次の手順を実行します。

  1. リポジトリ・データベースにSQL*Plus経由でSYSMANユーザーとしてログインします。

  2. 次のコマンドを使用してパージ・ポリシーの現在の値を確認します。

    SQL> select * from mgmt_job_purge_policies;

    POLICY_NAME                      TIME_FRAME
-------------------------------- ----------
SYSPURGE_POLICY                          30
REFRESHFROMMETALINKPURGEPOLICY            7
FIXINVENTORYPURGEPOLICY                   7
OPATCHPATCHUPDATE_PAPURGEPOLICY           7

    ジョブ削除を行うパージ・ポリシーをSYSPURGE_POLICYと言います。前述のように、デフォルト値は30日に設定されています。

  3. この期間を変更するには、ポリシーを削除して別の時間枠でポリシーを再作成する必要があります。

    SQL> execute MGMT_JOBS.drop_purge_policy('SYSPURGE_POLICY');

    PL/SQL procedure successfully completed.

    SQL> execute MGMT_JOBS.register_purge_policy('SYSPURGE_POLICY', 60, null);

    PL/SQL procedure successfully completed.

    SQL> COMMIT;

    Commit complete.

    SQL> select * from mgmt_job_purge_policies;

    POLICY_NAME                      TIME_FRAME
-------------------------------- ---------- 
SYSPURGE_POLICY                          60
....

前述のコマンドにより、保存時間が60日に増えています。要件に応じて、時間枠を30日より少なくすることもできます。

次にパージ・ジョブが実行される時間を確認できます。パージが実行される実際の時間は5 AMリポジトリ時間に設定されており、次の手順で確認できます。

  1. SYSMANアカウントを使用してリポジトリ・データベースにログインします。

  2. 次のコマンドを実行します。

    SQL> select job_name,
            to_char(last_start_date, 'DD-MON-YY HH24:MI:SS') last_run,
            to_char(next_run_date,   'DD-MON-YY HH24:MI:SS') next_run
from all_scheduler_jobs
where job_name ='EM_JOB_PURGE_POLICIES';
 
JOB_NAME              LAST_RUN           NEXT_RUN
--------------------- ------------------ ------------------
EM_JOB_PURGE_POLICIES                    07-SEP-11 05:00:00

    次の手順を実行して、Enterprise Managerコンソールでスケジュールを確認することもできます。

    1. 「設定」メニューから、「管理サービス」、「リポジトリ」の順に選択します。

    2. 「リポジトリ操作」タブをクリックします。

    3. リストで、ジョブのパージの次のスケジュール実行と最後のスケジュール実行に関する情報を探します。

    ジョブのパージの次のスケジュール実行時間には、保持期間のカットオフ時間は示されません。カットオフ時間は、ジョブ・パージ実行時にパージ・ポリシーによって決定されます。

20.2.5 DBMS_SCHEDULERのトラブルシューティング

Enterprise Managerでは、データベース・スケジューラ(dbms_scheduler)を使用してリポジトリ内の各種プロセスを実行します。dbms_schedulerが停止されている場合、または操作するための十分なリソースがない場合、Enterprise Managerのプロセスは実行されないか遅延します。次に、dbms_schedulerの正常な実行を妨げる可能性のある、一般的な原因を示します。

ジョブ・キュー・プロセス

dbms_schedulerは、実行するジョブごとに別個のジョブ・キュー・プロセスを使用します。これらのプロセスの最大数は、データベース・パラメータjob_queue_processesによって制御されます。すべてのプロセスが使用中の場合、新しいジョブは開始されません。

次の問合せは、現在実行中のジョブ数を返します。

SQL> SELECT count(*)
FROM dba_scheduler_running_jobs;

数がjob_queue_processesの設定に近い場合、Enterprise Managerのdbms_schedulerジョブは開始できません(時間どおりに)。実行中のdbms_schedulerジョブのいずれかがスタックかどうかを判断して、Job_queue_processesの設定を引き上げることを検討してください。

ジョブ・スレーブ・プロセス

dbms_schedulerは、dbms_schedulerプロパティMAX_JOB_SLAVE_PROCESSESの設定にも依存します。実行中のdbms_schedulerジョブ数がこの設定を超える場合、新しいジョブは開始されません。この属性は、次の問合せを使用して確認できます。

SQL> SELECT value
FROM dba_scheduler_global_attribute
WHERE attribute_name='MAX_JOB_SLAVE_PROCESSES';

数が実行中のdbms_schedulerジョブと等しい場合、実行中のdbms_schedulerジョブのいずれかがスタックかどうかを判断して、この属性の調整方法についてdbms_schedulerのドキュメントを参照してください。

DBMS_SCHEDULERプログラムの無効化

dbms_schedulerには、データベースでこの機能を無効化するように設定できる属性があります。設定されている場合、Enterprise Managerのdbms_schedulerジョブは実行されません。この属性が(間違って)設定されているかどうかを確認するには、次の問合せを実行します。

SQL> SELECT *
FROM dba_scheduler_global_attribute
WHERE attribute_name = 'SCHEDULER_DISABLED';

行が戻された場合、dbms_schedulerは無効化されています。dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');を実行します。

この属性の削除方法については、dbms_schedulerのドキュメントを参照してください。

データベース・セッションが多すぎる

各dbms_schedulerジョブには、2つのデータベース・セッションが必要です。これ以上セッションを使用できない場合、Enterprise Managerのdbms_schedulerジョブは実行されません。次の2つの問合せは、セッションの最大許容数および現在アクティブなセッション数を取得します。

SQL> SELECT value
FROM v$parameter
WHERE name='sessions';

SQL> SELECT count(*)FROM v$session;

現在のセッション数が最大数に近づいた場合、セッションのいずれかがスタックかどうかを判断して、セッションの最大数を引き上げる方法についてOracle Databaseのドキュメントを参照してください。

また、セッション数の最高水位標は、この問題が過去に要因があることを示している場合もあります。

SQL> select * 
from v$resource_limit 
where resource_name = 'sessions' ;

MAX_UTILIZATION列がセッションの最大数に近い値を示す場合、Enterprise Managerの一部のdbms_schedulerジョブが過去に実行されなかった(時間とおりに)ことを説明している可能性があります。

メモリー不足

使用できるメモリーが不足している場合、データベースで新規ジョブ・キュー・プロセスを生成できないことがあります。データベース・アラート・ファイルのjobqスレーブ・プロセスを生成できませんと(空きメモリー = 0.00M)というメッセージの組合せは、この問題を示している可能性があります。このメモリーに関する問題を詳細に診断する方法については、Oracle Databaseのドキュメントを参照してください。

前
前へ 		次
次へ
目次へ移動
目次 		索引へ移動
索引