| Oracle® Enterprise Manager Cloud Control管理者ガイド 12c リリース5 (12.1.0.5) B65081-16 |
|
 前 |
 次 |
この章では、適切に実行する管理リポジトリを維持するためのメンテナンスおよびトラブルシューティングの技法について説明します。
この章では特に、次の項について説明します。
管理データがセキュアで信頼性があり、常に利用可能になるようにするには、管理リポジトリをデプロイする際に次の設定と構成のガイドラインを検討します。
RAID対応論理ボリューム・マネージャ(Logical Volume Manager: LVM)またはハードウェアRAIDを、管理リポジトリが存在するシステムにインストールします。最低でもオペレーティング・システムでディスクのミラーリングとストリッピングをサポートする必要があります。管理リポジトリのすべてのデータ・ファイルをある程度の冗長構成で構成します。
Real Application Clustersを使用して、管理リポジトリに最高レベルの可用性を提供します。
Enterprise Managerを使用して、本番環境でのエラーや可用性の問題を管理者に知らせる場合、必ずCloud Controlコンポーネントを同じレベルの可用性で構成してください。最低でも、Oracle Data Guardを使用して管理リポジトリ・データベースをミラーリングすることを検討します。データ損失をゼロにするようにData Guardを構成します。使用環境やニーズに基づいて、最大可用性または最大保護を選択します。
|
関連項目: Oracle Database高可用性のアーキテクチャおよびベスト・プラクティス『Oracle Data Guard概要および管理』 |
アーカイブ・ログを有効にして、本番環境でEnterprise Managerの実装を稼働する前に包括的なバックアップ戦略を整えることを強くお薦めします。バックアップ戦略には、必要に応じてアーカイブ・バックアップと、増分バックアップと全体バックアップの両方を含めてください。
|
関連項目: 管理リポジトリに必要なデータベース初期化パラメータの詳細は、Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイド |
オラクル社は、Enterprise Manager Cloud ControlリポジトリでSQL計画管理(SQL計画ベースラインおよび取得)を使用しないことをお薦めします。固有の問題のためにそれを使用する必要がある場合は、使用後すぐに停止してください。SQL計画管理を使用すると、未検証計画を使用したSQLパフォーマンスの大幅な低下や、SQL計画管理の取得とEnterprise ManagerセキュリティVPDの間のデッドロックなど、Enterprise Manager Cloud Controlリポジトリの問題が発生する可能性があります。
リポジトリ・データベースと、ORAエラーに関する監査エントリの監査を有効化すると、Enterprise Managerアプリケーション・ログ(emoms.trc、MGMT_SYSTEM_ERROR_LOG表、リポジトリ・データベースのalert.logなど)にエラー・メッセージがレポートされない場合、これらは無視されます。
このような場合のエラーは無害です。
リポジトリに対して実行する必要がある、通常のメンテナンス・アクティビティの一覧を表示するには、『Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の「Enterprise Managerデプロイメントのサイジング」を参照してください。
Enterprise Managerのユーザー・インタフェースを使用してリポジトリ・データベースのアクティビティを監視するには、第14章「Enterprise Managerの管理」を参照してください。
Enterprise Managerの各種コンポーネントを構成し、そのコンポーネントが効率的に実行している場合、Oracle Management Serviceは、管理対象ホストで実行している管理エージェントから大量のRAWデータを収集し、そのデータを管理リポジトリにロードします。このデータは、後でCloud Controlコンソールで集計、編成、表示されるRAW情報です。
Oracle Management Serviceが管理リポジトリに情報をロードすると、Enterprise Managerは時間の経過とともにデータを集約してパージします。
次の項で説明する内容です。
管理リポジトリでのデータのメンテナンスに使用される集計とパージのデフォルトのポリシー。
データが集計されて管理リポジトリからパージされるまでのデータの保持時間の変更方法。
Enterprise Managerは、時単位および日単位でメトリック・データを集計することで、問合せパフォーマンスを高めて管理リポジトリのサイズを最小限に抑えます。データを集計する前に、各データ・ポイントがRAWメトリック・データ表に保存されます。1日に1度、前日のRAWメトリック・データがロールアップまたは集計されて、1時間および1日単位の表にまとめられます。これらの毎時および日次レコードには、毎時および日次のメトリック・データの平均、最小、最大および標準偏差が含まれます。
Enterprise Managerがデータを集計すると、データはパージ対象とみなされます。データは一定の期間が経過してから実際にパージされます。この期間を保存時間と言います。
RAWデータの挿入量が最大の場合、デフォルトの保存時間は最短になり、7日に設定されます。その結果、データが1時間単位のレコードに集計されてから7日が経過すると、RAWデータ・ポイントがパージの対象となります。
|
注意: このデータ保持ポリシーは、JVMDおよびADPデータでは異なります。 |
毎時集計されたメトリック・データ・レコードは、31日後にパージされます。最大レベルの集計(1日)は、12か月間保持されます(約365日)。
表15-1にデフォルトのデータ保持ポリシーをまとめています。
アプリケーション・パフォーマンス管理を構成して有効にしている場合、Enterprise Managerはレスポンス時間データも収集、保存、集計、パージします。レスポンス時間データは、メトリック・データに使用されるものと同様のポリシーを使用してパージされます。表15-2にアプリケーション・パフォーマンス管理のパージ・ポリシーを示します。
表15-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*);
デフォルトでは、イベント情報は分割されて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
メトリック・データとアプリケーション・パフォーマンス監視データ以外に、その他のタイプのEnterprise Managerデータが時間の経過とともに管理リポジトリに蓄積されます。
たとえば、ターゲットの最後の可用性レコードも管理リポジトリに無期限で残るため、ターゲットの最後の既知の状態が保存されます。
Enterprise Managerの集計およびパージのデフォルトのポリシーは、管理リポジトリに対して最大パフォーマンスと最小ディスク領域の要件を実現し、分析に最も利用可能なデータを提供するように設計されました。そのため、パフォーマンスを改善したり、使用可能なディスク領域を増やしたりするためにこれらのポリシーを変更する必要はありません。
ただし、Enterprise Manager以外のデータ分析ツールを使用してRAWデータや集計データを抽出または確認する場合、管理リポジトリで使用可能なRAWデータや集計データの量を増やすことができます。これを行うには、RAWデータや集計データの保存時間を増やします。
Enterprise Managerリポジトリの中心的なメトリック・データ表のデフォルトの保持時間を変更するために、PL/SQL APIが提供されています。表15-3は、3つの表でそれぞれ保持されるデフォルトのパーティション数、および各表のパーティションのサイズを示しています。APIでは、保持されるパーティション数のみを変更できます。
前述の表の保持期間を変更するには、次のコマンドを実行します。
SQL> execute gc_interval_partition_mgr.set_retention('SYSMAN', <table name>, <number of partitions to retain>);
<table name>を前述の表の名前に置き換えます。APIでは、保持されるパーティション数のみを変更できます。
たとえば、表EM_METRIC_VALUESのデフォルトの保持期間を7パーティションから14パーティションに変更するには、次の手順に従います。
SQL*Plusを使用してSYSMANユーザーとしてリポジトリ・データベースに接続します。
保持期間の現在の値を確認します。
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
表EM_METRIC_VALUESのデフォルトの保持期間を7パーティションから14パーティションに変更するには、次のコマンドを実行します。
SQL> execute gc_interval_partition_mgr.set_retention('SYSMAN', 'EM_METRIC_VALUES', 14);
保持期間が変更されたことを確認します。
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
Enterprise Manager Cloud Controlには、30日が経過した古い完了済ジョブの詳細をすべて削除するデフォルトのパージ・ポリシーがあります。この項では、このデフォルトのパージ・ポリシーの変更について詳しく説明します。
完了済ジョブ履歴の実際のパージは、リポジトリ・データベースで一日に1回実行されるDBMS_SCHEDULERジョブで実装されます。ジョブが実行されると、現在の時刻(リポジトリ・データベースのsysdateの値)よりも「n」日古い完了済ジョブを検索し、これらのジョブを削除します。値「n」はデフォルトでは30日に設定されています。
デフォルトのパージ・ポリシーはEnterprise Managerコンソールでは変更できませんが、SQL*Plusを使用して変更できます。
リポジトリ・データベースにSQL*Plus経由でSYSMANユーザーとしてログインします。
次のコマンドを使用してパージ・ポリシーの現在の値を確認します。
SQL> select * from mgmt_job_purge_policies;
POLICY_NAME TIME_FRAME -------------------------------- ---------- SYSPURGE_POLICY 30 REFRESHFROMMETALINKPURGEPOLICY 7 FIXINVENTORYPURGEPOLICY 7 OPATCHPATCHUPDATE_PAPURGEPOLICY 7
ジョブ削除を行うパージ・ポリシーをSYSPURGE_POLICYと言います。前述のように、デフォルト値は30日に設定されています。
この期間を変更するには、ポリシーを削除して別の時間枠でポリシーを再作成する必要があります。
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リポジトリ時間に設定されており、次の手順で確認できます。
SYSMANアカウントを使用してリポジトリ・データベースにログインします。
次のコマンドを実行します。
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コンソールでスケジュールを確認することもできます。
「設定」メニューから、「管理サービス」、「リポジトリ」の順に選択します。
「リポジトリ操作」タブをクリックします。
リストで、ジョブのパージの次のスケジュール実行と最後のスケジュール実行に関する情報を探します。
ジョブのパージの次のスケジュール実行時間には、保持期間のカットオフ時間は示されません。カットオフ時間は、ジョブ・パージ実行時にパージ・ポリシーによって決定されます。
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のドキュメントを参照してください。
この項では、Enterprise Managerのインストール後に既存のデータベースから管理リポジトリを削除し、管理リポジトリを再作成する作業について説明します。
dropコマンドからのリカバリはないため、このアクションは、Enterprise Managerサイトを廃止した場合にのみ該当することに注意する必要があります。
管理リポジトリを再作成するには、最初に管理リポジトリ・データベースからEnterprise Managerスキーマを削除します。このタスクを行うには、RepManagerスクリプトに-action drop引数を使用します。これについては、次の手順で説明します。
データベースから管理リポジトリを削除するには、次の手順を実行します。
管理サービスをインストールおよびデプロイしたミドルウェア・ホームの次のディレクトリで、RepManagerスクリプトを見つけます。
ORACLE_HOME/sysman/admin/emdrep/bin
コマンド・プロンプトで次のコマンドを入力します。
$PROMPT> RepManager repository_host repository_port repository_SID -sys_password password_for_sys_account -action drop
この構文例では次のようになります。
repository_hostは、管理リポジトリ・データベースが配置されるマシン名です。
repository_portは、管理リポジトリ・データベースのリスナー・ポート・アドレスです(通常は1521)。
repository_SIDは、管理リポジトリ・データベースのシステムIDです。
password_for_sys_accountは、データベースのSYSユーザーのパスワードです。たとえば、change_on_installなどです。
-action dropは、管理リポジトリ、MDS、OPSS、APMおよびスキーマを削除することを示します。dropを使用する場合、コマンドは管理リポジトリのみを削除します。
あるいは、接続記述子を使用して、RepManagerコマンドラインでデータベースを特定することもできます。接続記述子は、標準のOracleデータベース構文を使用してデータベースのホスト、ポート、名前を特定します。
たとえば、接続記述子を次のように使用して管理リポジトリを作成できます。
$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST=host1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=servicename)))" -sys_password efkl34lmn -action drop
|
関連項目: 接続記述子を使用したデータベースへの接続の詳細は、『Oracle Enterprise Managerライセンス情報』の接続の確立およびネットワークのテストに関する項。 |
管理リポジトリを作成するには、Enterprise Managerのインストール時に管理リポジトリを作成する方法がお薦めです。これはOracle Universal Installerを使用して行います。
|
関連項目: Enterprise Managerのインストールの詳細は、Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイド。 |
リポジトリが削除されると、RepManager createコマンドを使用してリポジトリを単独で作ることはできません。コマンドはリポジトリ・データベース内に必要なすべてのユーザーを作成するわけではありません。リポジトリを作成するには、Cloud Controlを完全に再インストールする必要があります。
定期的にリポジトリをバックアップすることにより、推奨されるベスト・プラクティスに従っている場合、次のうちのいずれかに該当するかぎり、リポジトリのバックアップを使用できます。
プライマリOMSホームが完全である
プライマリOMSのエクスポート/構成がある
プライマリOMSのファイル・システムのバックアップがある。
接続記述子を使用してRepManagerコマンドラインでデータベースを指定できます。接続記述子は、標準のOracleデータベース構文を使用してデータベースのホスト、ポート、名前を特定します。
たとえば、接続記述子を次のように使用して管理リポジトリを作成できます。
$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=host1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=servicename)))"
-sys_password efkl34lmn -action create
|
関連項目: 接続記述子を使用したデータベースへの接続の詳細は、『Oracle Enterprise Managerライセンス情報』の接続の確立およびネットワークのテストに関する項。 |
接続文字列の使用により、アドレス・リストを接続文字列の一部として指定できます。次の例は、RepManagerコマンドラインの一部として2つのリスナーで構成されるアドレス・リストの指定方法を示しています。一方のホストのリスナーが使用できなくなると、もう一方のリスナーが引き続き受信リクエストを受け入れることができます。
$PROMPT> ./RepManager -connect "(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521) (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521) (CONNECT_DATA=(SERVICE_NAME=servicename)))" -sys_password efkl34lmn -action create
|
関連項目: Oracle Database高可用性のアーキテクチャおよびベスト・プラクティスOracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイド |
Oracle Universal Installerは、インストール・プロセスの最後に構成手順を使用して管理リポジトリを作成します。リポジトリ構成ツールが失敗した場合、構成ツール・ウィンドウに表示される正確なエラー・メッセージを書き留め、それ以外の構成ツールが終了するまで待機してUniversal Installerを終了し、次の項を使用して問題を解決します。
管理リポジトリの作成が中断した場合、後から管理リポジトリを作成または削除しようとすると次のエラーが表示されます。
SQL> ERROR: ORA-00604: error occurred at recursive SQL level 1 ORA-04068: existing state of packages has been discarded ORA-04067: not executed, package body "SYSMAN.MGMT_USER" does not exist ORA-06508: PL/SQL: could not find program unit being called ORA-06512: at "SYSMAN.SETEMUSERCONTEXT", line 5 ORA-06512: at "SYSMAN.CLEAR_EMCONTEXT_ON_LOGOFF", line 4 ORA-06512: at line 4
この問題を修正するには、「管理リポジトリを作成するための一般的なトラブルシューティング技法」を参照してください。
管理リポジトリ・データベースに接続しようとする際に次のようなエラーが発生する場合、サポートされていないリリースのOracle Databaseが使用されている可能性があります。
Server Connection Hung
問題を修正するには、Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイドの説明に従って、サポートされているリリースにデータベースをアップグレードします。
管理リポジトリの作成時にエラーが発生した場合、RepManagerスクリプトに-drop引数を指定して実行し、リポジトリを削除します。
RepManagerスクリプトでリポジトリが正常に削除された場合、管理リポジトリの作成を再試行します。
なんらかの理由でRepManager -action drop/dropが失敗した場合、次の手順を実行します。
バンドル・パッチを12c OMSホームに適用します。この手順は、12.1.0.1 OMSにのみ該当します。手順については、My Oracle Supportノート1393173.1: Enterprise Manager Cloud Controlバンドル・パッチ1および12.1.0.2プラグインのインストール手順を参照してください。
OMSを停止し、すべてのWLS / OMSプロセスがOMSホームで停止されたことを確認します。
cd <OMS_HOME>/bin emctl stop oms -all
|
注意: 管理サーバーも同様に停止するように、-allオプションを使用する必要があります。 |
実行中のWLS / OMSプロセスがないことを確認します。
$ ps -ef | grep EMGC $ ps -ef | grep java
"Repmanager drop"コマンドを使用してリポジトリ・オブジェクトを削除します。
cd <OMS_HOME>/sysman/admin/emdrep/bin RepManager <database hostname> <database listener port> <database sid> -action drop -dbUser sys -dbPassword <sys user password> -dbRole sysdba -mwHome <Middleware Home> -mwOraHome <Middleware Home> -oracleHome <OMS Home>
次に例を示します。
RepManager repomachine.domain 1521 orcl -action drop -dbUser sys -dbPassword oracle123 -dbRole sysdba -mwHome /home/oracle/Middleware -mwOraHome /home/oracle/Middleware -oracleHome /home/oracle/Middleware/oms
リポジトリ・データベースにsysまたはDBAユーザーとしてログインし、すべてのリポジトリ・オブジェクトが削除されたことを確認します。
SQL> select username,account_status from dba_users where username in ('SYSMAN', 'SYSMAN_MDS','MGMT_VIEW','SYSMAN_BIPLATFORM','SYSMAN_APM','BIP','SYSMAN_OPSS','SYSMAN_RO') ;
SQL> select owner,synonym_name from dba_synonyms where table_owner in ('SYSMAN', 'SYSMAN_MDS','MGMT_VIEW','SYSMAN_BIPLATFORM','SYSMAN_APM','BIP','SYSMAN_OPSS','SYSMAN_RO') ;
SQL> select tablespace_name from dba_tablespaces where tablespace_name like 'MGMT%';
SQL> select comp_name from SCHEMA_VERSION_REGISTRY;
前述の問合せはどれも行を戻す必要はありません。前述の問合せのいずれかで行が戻された場合は、OracleサポートとSRを作成します。
|
注意: 前述のソリューションはOMSが実行中の場合に適用できます。OMSホームが使用できないか、損傷している場合は、OracleサポートとSRを作成します。 |
Enterprise Managerリポジトリをサーバー間およびクロス・プラットフォームで移行するためのユーザー要件があります。
Enterprise Managerリポジトリ移行プロセスは、データベース移行の場合と完全に同じではありません。Enterprise Managerリポジトリ移行の場合、Enterprise Managerに固有のデータ、オプション、前提条件に注意してリポジトリを移動する必要があります。Enterprise ManagerとOracleデータベースの両方の観点からデータの整合性が維持されることを確認する必要があります。
このためには、最短時間で最大効率が得られる、正常で信頼性の高いリポジトリの移行を行うためにエンド・ユーザーが従うプロセスを定義する必要があります。
移行の全体の戦略は次の内容によって異なります。
ソース・データベースとターゲット・データベースのバージョン
リポジトリのデータ/サイズの量
移行する実際のデータ(選択移行/完全移行)
ソースとターゲットがリリース12c以外の場合、クロス・プラットフォームでデータを移行する方法はエクスポート/インポートのみになります。
クロス・プラットフォームのトランスポータブル表領域、データ・ポンプ、エクスポート/インポートのオプションの詳細は、Oracle Technology Network(OTN)または『Oracle Database管理者ガイド』を参照してください。
次に、リポジトリを移行するための一般的な前提条件を示します。
ソースとターゲットのデータベースは、同じ文字セットを使用し、同じリリースにします。
ソース・データベースとターゲット・データベースのプラットフォームは同じエンディアン形式である必要があります。
ターゲットのデータベースは、Oracle Enterprise Managerインストレーション・ガイドに示されたEnterprise Managerリポジトリのソフトウェア要件について言及されたすべての前提条件を満たす必要があります。
ソースとターゲットのデータベースが10gR2およびそれ以上のrdbmsバージョンにある場合、その他の前提条件を満たしているならば、クロス・プラットフォーム・リポジトリ移行に、クロス・プラットフォーム・トランスポータブル・データベース移行を使用できます。
同じ名前の表領域がすでにあるターゲット・データベースに表領域をトランスポートすることはできません。ただし、トランスポート操作前に、トランスポートする表領域またはトランスポート先の表領域の名前を変更できます。
トランスポータブル表領域セットを別のプラットフォームのOracle Databaseにプラグインするには、両方のデータベースの互換性を最低でもリリース10.0に設定する必要があります。
ほとんどのプラットフォーム(ただしすべてではない)は、クロス・プラットフォームの表領域トランスポートがサポートされています。V$TRANSPORTABLE_PLATFORMビューに問合せを実行して、サポートされるプラットフォームを確認したり、そのプラットフォームIDやエンディアン形式(バイト順序)を判断したりすることができます。
ソースと移行先のホストでは、Enterprise Managerの管理エージェントが実行され、移行するインスタンスのために構成されている必要があります。
ターゲット・データベースにEnterprise Managerリポジトリがインストールされている場合、ターゲット・データベースに関連する手順を行う前に、RepManagerを使用してEMリポジトリを最初に削除する必要があります。
次の項では、リポジトリ移行の2つの手順について説明します。
Oracleのトランスポータブル・データベース機能では、Oracleデータベース間でユーザー表領域をすばやく移動できます。この方法は、データベース間で大量データを移動するのに最も効率的です。クロス・プラットフォーム・トランスポータブル・データベースを使用すると、プラットフォーム間で表領域をトランスポートできます。
クロス・プラットフォームのトランスポータブル・データベースでは、プラットフォームから別のプラットフォームにデータベースを移行できます(データ・ポンプまたはインポート/エクスポートで使用)。次のトランスポータブル・データベースを使用した移行手順は、同じエンディアンのプラットフォーム間での移行に使用できます。
v$db_transportable_platformから宛先プラットフォームで移行が可能かどうかを確認します。
SQL> select platform_name from v$db_transportable_platform;
次のリストのようなプラットフォームのリストが表示されます。
Microsoft Windows IA (32-bit) Linux IA (32-bit) HP Tru64 UNIX Linux IA (64-bit) HP Open VMS Microsoft Windows IA (64-bit) Linux x86 64-bit Microsoft Windows x86 64-bit Solaris Operating System (x86) HP IA Open VMS Solaris Operating System (x86-64)
外部表およびファイルがデータベースに存在することを確認します。
SQL> set serveroutput on SQL> declare x boolean; 2 begin x := dbms_tdb.check_external; 3 end; 4 /
結果は次のように出力されます。
The following external tables exist in the database: SH.SALES_TRANSACTIONS_EXT The following directories exist in the database: SYS.SUBDIR, SYS.SS_OE_XMLDIR, SYS.MEDIA_DIR, SYS.LOG_FILE_DIR, SYS.DATA_FILE_DIR, SYS.XMLDIR, SYS.DATA_PUMP_DIR, SYS.ORACLE_OCM_CONFIG_DIR The following BFILEs exist in the database: PM.PRINT_MEDIA
次のコマンドを入力します。
SQL> select directory_path from dba_directories;
結果は次のように出力されます。
DIRECTORY_PATH -------------------------------------------------------------------------------- /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/order_entry//2002/Sep /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/order_entry/ /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/log/ /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/sales_history/ /ade/b/1191423112/oracle/rdbms/xml /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media/ /home/oracle/app/oracle/admin/orcl/dpdump/ /home/oracle/app/oracle/product/11.2.0/dbhome_1/ccr/state 8 rows selected.
次のコマンドを入力します。
SQL> select directory_path||'/'||location External_file_path from dba_directories a, dba_external_locations b where a.directory_name=b.directory_name;
結果は次のように出力されます。
EXTERNAL_FILE_PATH ---------------------------------------------------------------------------- /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/sales_history//sale1v3.dat
次のコマンドを入力します。
SQL> @tgt_get_bfile_dirs.sql
結果は次のように出力されます。
The following directories contain external files for BFILE columns Copy the files within these directories to the same path on the target system /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media/ There are 1 directories, 4 total BFILEs SQL> @tgt_get_bfiles.sql External files for BFILE column AD_GRAPHIC in table PM.PRINT_MEDIA /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//monitor.jpg /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//mousepad.jpg /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//keyboard.jpg /home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//modem.jpg
OMSを停止します。
emctl stop oms -all
次のSQLコマンドを入力します。
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 1473089536 bytes Fixed Size 1336596 bytes Variable Size 1124076268 bytes Database Buffers 335544320 bytes Redo Buffers 12132352 bytes Database mounted.
データベースを読取り専用モードでオープンします。
SQL> alter database open read only;
次のSQLコマンドを入力します。
SQL> set serveroutput on
SQL> declare
2 retcode boolean;
3 begin
4 retcode := dbms_tdb.check_db('Linux IA (64-bit)',dbms_tdb.skip_none);
5 end;
6 /
SQL> declare
2 retcode boolean;
3 begin
4 retcode := dbms_tdb.check_db('Linux x86 64-bit',dbms_tdb.skip_none);
5 end;
6 /
PL/SQL procedure successfully completed.
RMAN変換スクリプトを生成します。
[oracle]$ ./rman Recovery Manager: Release 11.2.0.1.0 - Production on Fri dd-mm-yy 12:10:29 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. RMAN> connect target / connected to target database: ORCL (DBID=1308105793) RMAN> convert database on target platform 2> convert script '/tmp/convert_mydb.rman' 3> transport script '/tmp/transport_mydb.sql' 4> new database 'mydb' 5> format '/tmp/mydb%U' 6> db_file_name_convert '/home/oracle/app/oracle/oradata/mydb/','/tmp'; Starting conversion at source at dd-mm-yy using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=135 device type=DISK External table SH.SALES_TRANSACTIONS_EXT found in the database Directory SYS.SUBDIR found in the database Directory SYS.SS_OE_XMLDIR found in the database Directory SYS.MEDIA_DIR found in the database Directory SYS.LOG_FILE_DIR found in the database Directory SYS.DATA_FILE_DIR found in the database Directory SYS.XMLDIR found in the database Directory SYS.DATA_PUMP_DIR found in the database Directory SYS.ORACLE_OCM_CONFIG_DIR found in the database BFILE PM.PRINT_MEDIA found in the database User SYS with SYSDBA and SYSOPER privilege found in password file channel ORA_DISK_1: starting to check datafiles input datafile file number=00001 name=/home/oracle/app/oracle/oradata/orcl/system01.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00002 name=/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00007 name=/home/oracle/app/oracle/oradata/orcl/mgmt.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00003 name=/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00008 name=/home/oracle/app/oracle/oradata/orcl/mgmt_ad4j.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00005 name=/home/oracle/app/oracle/oradata/orcl/example01.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00006 name=/home/oracle/app/oracle/oradata/orcl/mgmt_depot.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile file number=00004 name=/home/oracle/app/oracle/oradata/orcl/users01.dbf channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 Edit init.ora file /tmp/init_mydb00nbs6dl_1_0.ora. This PFILE will be used to create the database on the target platform Run RMAN script /tmp/convert_mydb.rman on target platform to convert datafiles Run SQL script /tmp/transport_mydb.sql on the target platform to create database To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform To change the internal database identifier, use DBNEWID Utility Finished conversion at source at dd-mm-yy
必要なファイルはすべて一時的な場所にコピーし、ターゲット・マシンにマウントします。
convert_mydb.rman init_mydb.ora transport_mydb.sql (and other data files listed in rman script [convert_mydb.rman] and redolog files)
手順5で生成したスクリプトをターゲット・マシンで実行します。
RMANスクリプトにはデータファイルの変換コマンドが含まれています。SQLスクリプトには、コントロール・ファイルの作成、オブジェクトの無効化、オブジェクトの再コンパイルが含まれます。ターゲット・マシンで、次を実行します。
RMAN> connect target /
RMAN> @/home/oracle/migrate/convert_mydb.rman
データベースが稼働中で、リスナーに登録されていることを確認します。
RMAN> STARTUP NOMOUNT PFILE = '/home/oracle/migrate/init_mydb00nbs6dl_1_0.ora'; database is already started
OMSを開始して、管理サーバーが起動中であることを確認します。
[oracle]$ ./emctl status oms
[oracle]$ ./emctl start oms
OMSを停止します。
[oracle]$ ./emctl stop oms
リポジトリ・データベース接続の詳細を更新します。
[oracle]$ ./emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=evildead.idc.oracle.com)(PORT=1521)))(CONNECT_DATA=(SID=mydb)))" -repos_user SYSMAN -repos_pwd Oracle123
この環境にOracle Management Serviceが複数ある場合は、それらすべてでこのstore_repos_detailsコマンドを実行します。
OMSを再起動します。
[oracle]$ ./emctl start oms
[oracle]$ ./emctl status oms
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.4.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. WebTier is Up Oracle Management Server is Up
管理サービスとリポジトリ・ターゲットを再配置します。
次の手順で、フィジカル・スタンバイを使用してリポジトリを移行するのに使用できるプロセスについて説明します。この方法は、ソースとターゲットのプラットフォームがサポートされる場合に使用できます。サポートされるプラットフォームの組合せの詳細は、My Oracle Supportノート:413484.1を参照してください。
データベースORACLE_HOMEをターゲット・マシンにインストールします。バイナリはソースと同じバージョンである必要があります。
ターゲット・マシンがWindowsの場合、管理エージェントのデプロイには、WindowsマシンにCYGWINをインストールして構成します。
管理エージェントをターゲット・サーバーにデプロイします。
Data Guardのドキュメントに従い、フィジカル・スタンバイを作成します。
Data Guard Brokerのドキュメントに従い、Data Guard Brokerを構成します。
OMSを停止します。
emctl stop oms -all
OMS接続記述子を確認します。
./emctl config oms -list_repos_details
dgmgrlを使用してデータベースをスイッチオーバーします。
次のコマンドを使用します。
DGMGRL> switchover to target_db verify show configuration show database target_db show database source_db
OMS管理サーバーを起動します。
emctl start oms -admin_only
スタンバイ・データベースを指すように接続記述子を更新します。
eemctl config oms -store_repos_details -repos_conndesc "(DESC= )" -repos_user sysman
[oracle]$ ./emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sample2.us.company.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=test_win)))" -repos_user sysman
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.4.0
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.
Enter Repository User's Password :
Successfully updated datasources and stored repository details in Credential Store.
この環境にOracle Management Serviceが複数ある場合は、それらすべてでこのstore_repos_detailsコマンドを実行します。
すべてのOracle Management Serviceを停止します。
emctl stop oms -all
OMSを開始します。
emctl start oms
Oracle Management Serviceとリポジトリを再配置します。
emctl config emrep -agent <agent_name> -conn_desc
[oracle]$ ./emctl config emrep -agent sample2.us.company.com:3872 -conn_desc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sample2.us.company)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=test_win)))" Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.4.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Please enter repository password: Enter password : Login successful Moved all targets from sample.us.company.com:3872 to sample2.us.company.com:3872 Command completed successfully! Enter password : Login successful Moved all targets from sample.us.company.com:3872 to sample2.us.company.com:3872 Command completed successfully!
OMSのバックアップを作成します(管理サーバーが動作しているOMS)。
$ <OMS_HOME>/bin/emctl exportconfig oms [-sysman_pwd <sysman password>]
バックアップ・ファイルを保存するディレクトリを指定します。
[-dir <backup dir>]
OMSが仮想のホスト名を使用してインストール(ORACLE_HOSTNAME=<virtual_hostname>を使用)された場合は、次のパラメータを指定します。
[-keep_host]
次の検証手順を移行後に実行し、移行が完全に成功したかどうかを確認します。
ソース・データベースとターゲット・データベースをEnterprise Managerで比較してオブジェクトの矛盾を検証します。
移行されたデータベースをEnterprise Managerで検証し、データベースが問題なく実行しているかどうかを確認します。
リポジトリ操作、dbmsジョブ、管理システム・エラーが報告されているかどうかを検証します。
すべてのEnterprise Manager機能が移行後適切に機能しているかどうかを検証します。
Enterprise Managerによる検証で、管理サービスとリポジトリ・データベースが適切に再配置されていることを確認します。
