| Oracle Enterprise Manager管理 11gリリース1（11.1.0.1） B61022-01 |
|
 戻る |
 次へ |
この章では、適切に実行する管理リポジトリを維持するためのメンテナンスおよびトラブルシューティングの技法について説明します。
この章では特に、次の項について説明します。
管理データがセキュアで信頼性があり、常に利用可能になるようにするには、管理リポジトリをデプロイする際に次の設定と構成のガイドラインを検討します。
RAID対応論理ボリューム・マネージャ（Logical Volume Manager: LVM）またはハードウェアRAIDを、管理リポジトリが存在するシステムにインストールします。最低でもオペレーティング・システムでディスクのミラーリングとストリッピングをサポートする必要があります。管理リポジトリのすべてのデータ・ファイルをある程度の冗長構成で構成します。
Real Application Clustersを使用して、管理リポジトリに最高レベルの可用性を提供します。
Enterprise Managerを使用して、本番環境でのエラーや可用性の問題を管理者に知らせる場合、必ずGrid Controlコンポーネントを同じレベルの可用性で構成してください。最低でも、Oracle Data Guardを使用して管理リポジトリ・データベースをミラーリングすることを検討します。データが損失しないようにData Guard環境を構成します。
|
関連項目: Oracle Database高可用性のアーキテクチャおよびベスト・プラクティス『Oracle Data Guard概要および管理』 |
Oracleでは、アーカイブ・ログを有効にして、本番環境でEnterprise Managerの実装を稼働する前に包括的なバックアップ戦略を整えることを強くお薦めします。バックアップ戦略には、必要に応じて増分バックアップと全体バックアップの両方を含めてください。
|
関連項目: 管理リポジトリに必要なデータベース初期化パラメータの詳細は、『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』 |
Enterprise Managerの各種コンポーネントを構成し、そのコンポーネントが効率的に実行している場合、Oracle Management Serviceは、管理対象ホストで実行している管理エージェントから大量のRAWデータを収集し、そのデータを管理リポジトリにロードします。このデータは、後からGrid Controlコンソールで集計、編成、表示されるRAW情報です。
Oracle Management Serviceが管理リポジトリに情報をロードすると、Enterprise Managerは時間の経過とともにデータを集約してパージします。
次の項で説明する内容です。
管理リポジトリでのデータのメンテナンスに使用される集計とパージのデフォルトのポリシー。
データが集計されて管理リポジトリからパージされるまでのデータの保持時間の変更方法。
Enterprise Managerは、時間と日数別に管理データを集計して管理リポジトリのサイズを最小限に抑えます。データを集計する前に、各データ・ポイントがRAWデータ表に保存されます。RAWデータはロールアップ（集計）されて1時間単位の集計メトリック表にまとめられます。その後、1時間単位のレコードは、一日単位の表にロールアップされます。
Enterprise Managerがデータを集計すると、データはパージ対象とみなされます。データは一定の期間が経過してからが実際にパージされます。この期間を保存時間と言います。
RAWデータの挿入量が最大の場合、デフォルトの保存時間は最短になり、7日に設定されます。その結果、データが1時間単位のレコードに集計されてから7日が経過すると、RAWデータ・ポイントがパージの対象となります。
1時間単位の集計データ・レコードは、データが1日単位のデータ表にロールアップされてから31日でパージされます。最大レベルの集計（1日）は365日間保持されます。
表10-1にデフォルトのデータ保持ポリシーをまとめています。
アプリケーション・パフォーマンス管理を構成して有効にしている場合、Enterprise Managerはレスポンス時間データも収集、保存、集計、パージします。レスポンス時間データは、メトリック・データに使用されるものと同様のポリシーを使用してパージされます。表10-2にアプリケーション・パフォーマンス管理のパージ・ポリシーを示します。
メトリック・データとアプリケーション・パフォーマンス監視データ以外に、その他のタイプのEnterprise Managerデータが時間の経過とともに管理リポジトリに蓄積されます。
たとえば、ターゲットの最後の可用性レコードも管理リポジトリに無期限で残るため、ターゲットの最後の既知の状態が保存されます。
Enterprise Managerの集計およびパージのデフォルトのポリシーは、管理リポジトリに対して最大パフォーマンスとディスク領域の要件を実現し、分析に最も利用可能なデータを提供するように設計されました。そのため、パフォーマンスを改善したり、使用可能なディスク領域を増やしたりするためにこれらのポリシーを変更する必要はありません。これらのデフォルトのポリシーを変更すると、管理リポジトリのパフォーマンスが影響を受け、Enterprise Managerインストールのスケーラビリティに有害な影響があります。
ただし、Enterprise Manager以外のデータ分析ツールを使用してRAWデータや集計データを抽出または確認する場合、管理リポジトリで使用可能なRAWデータや集計データの量を増やすことができます。これを行うには、RAWデータや集計データの保存時間を増やします。
管理リポジトリの各レベルの管理データに対するデフォルトの保存時間を変更するには、管理リポジトリ・データベースのMGMT_PARAMETERS表に追加の行を挿入する必要があります。表10-3は、RAWデータや集計データの各表の保存時間を変更するためにMGMT_PARAMETERS表に挿入する必要があるパラメータを示しています。
_RT_が含まれる表名は、アプリケーション・パフォーマンス監視のレスポンス時間データに使用される表を示します。「表名」列で、 datatypeを3つのレスポンス時間データ・タイプDOMAIN、IP、URLのいずれかで置き換えます。
表10-3 管理リポジトリのデフォルトのデータ保存時間を変更するパラメータ
| 表名 | MGMT_PARAMETERS表のパラメータ | デフォルトの保存値 |
|---|---|---|
|
mgmt_raw_keep_window |
7日 |
|
|
mgmt_hour_keep_window |
31日 |
|
|
mgmt_day_keep_window |
365日 |
|
|
mgmt_rt_keep_window |
24時間 |
|
|
mgmt_rt_hour_keep_window |
7日 |
|
|
mgmt_rt_day_keep_window |
31日 |
|
|
mgmt_rt_dist_hour_keep_window |
24時間 |
|
|
mgmt_rt_dist_day_keep_window |
31日 |
|
注意: 表8-3に示す最初の3つの表がパーティション化されない場合、各表のデフォルトの保存値は、パーティション化された表に示された7日、31日、365日ではなくそれぞれ1日、7日、31日になります。 |
たとえば、表MGMT_METRICS_RAWのデフォルトの保存時間を7日から14日に変更するとします。
SQL*Plusを使用して、管理リポジトリ・ユーザーとして管理リポジトリ・データベースに接続します。
デフォルトの管理リポジトリ・ユーザーはsysmanです。
次のSQLを入力して、パラメータを挿入しデフォルト値を変更します。
INSERT INTO MGMT_PARAMETERS (PARAMETER_NAME, PARAMETER_VALUE) VALUES ('mgmt_raw_keep_window','14');
同様に、すべてのMGMT_RT_datatype_1DAY表のデフォルトの保存時間を31日から100日に変更するとします。
SQL*Plusを使用して、管理リポジトリ・ユーザーとして管理リポジトリ・データベースに接続します。
デフォルトの管理リポジトリ・ユーザーはsysmanです。
次のSQLを入力して、パラメータを挿入しデフォルト値を変更します。
INSERT INTO MGMT_PARAMETERS (PARAMETER_NAME, PARAMETER_VALUE) VALUES ('mgmt_rt_day_keep_window', '100');
デフォルトでは、Grid Controlコンソールからターゲットを削除する場合、Enterprise Managerは、管理リポジトリからすべてのターゲット・データを自動的に削除します。
ただし、データベースと他のデータリッチ・ターゲットのRAWデータおよび集計メトリック・データを削除する操作は、リソースを消費します。ターゲットには何十万ものデータ行があり、特に複数のターゲットを一度に削除する場合、このデータ削除作業により、削除する間のEnterprise Managerのパフォーマンスが低下する可能性があります。このリソース消費操作を避けるには、ターゲットを削除するたびにEnterprise Managerでこのタスクが実行されないようにすることができます。Enterprise Managerでこのタスクを実行しないようにする場合、削除されたターゲットのメトリック・データはターゲット削除タスクの一環としてパージされません。かわりに、定期的なパージ・メカニズムの一環としてパージされるため、こちらの方が効率的です。
さらに、Oracleでは、ターゲットを削除してから24時間以内に、削除されたターゲットと同じ名前およびタイプの新しいターゲットを追加しないことを強くお薦めします。同じ名前とタイプの新しいターゲットを追加すると、Grid Controlコンソールには、削除されたターゲットに属するデータが最初の24時間表示されます。
RAWメトリック・データの削除を無効にするには、次の手順を実行します。
SQL*Plusを使用して、管理リポジトリ・ユーザーとして管理リポジトリに接続します。
The default Management Repository user is SYSMAN.次に例を示します。
SQL> connect sysman/sysman_password;
メトリック削除を無効にするには、次のSQLコマンドを実行します。
SQL> EXEC MGMT_ADMIN.DISABLE_METRIC_DELETION(); SQL> COMMIT;
後でメトリック削除を有効にするには、次のSQLコマンドを実行します。
Enterprise Manager Grid Controlには、30日が経過した古い完了済ジョブの詳細をすべて削除するデフォルトのパージ・ポリシーがあります。この項では、このデフォルトのパージ・ポリシーの変更について詳しく説明します。
完了済ジョブ履歴の実際のパージは、リポジトリ・データベースで一日に1回実行されるDBMSジョブで実装されます。ジョブが実行されると、現在の時刻（リポジトリ・データベースの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日より少なくすることもできます。
次にパージ・ジョブが実行される時間を確認できます。ジョブが実行される実際の時間は、各Enterprise Managerインストールによって異なります。お使いの設定でこの時間を判断するには、次の手順を実行します。
SYSMANアカウントを使用してリポジトリ・データベースにログインします。
次のコマンドを実行します。
SQL> alter session set nls_date_format='mm/dd/yy hh:mi:ss pm';
SQL> select what, next_date from user_jobs where what like '%JOB_ENGINE%';
WHAT ------------------------------------------------------------------------------ NEXT_DATE -------------------- MGMT_JOB_ENGINE.apply_purge_policies(); 09/23/08 10:26:17 am
この例では、パージ・ポリシーDBMSジョブは、リポジトリ時間午前10:26:17に毎日実行されます。
SYSMANアカウントは、Enterprise Managerの設定と管理に使用されるデフォルトのスーパー・ユーザー・アカウントです。また、Oracle Management Repositoryに格納されるオブジェクトを所有するデータベース・アカウントでもあります。このアカウントから、組織で使用するために追加の管理者アカウントとEnterprise Managerを設定できます。
SYSMANアカウントは、Enterprise Managerのインストール時に管理リポジトリ・データベースで自動的に作成されます。また、インストール時にSYSMANアカウントのパスワードも指定します。
|
関連項目: Enterprise Managerのインストールの詳細は、『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』 |
後からSYSMANデータベース・アカウントのパスワードを変更する必要がある場合は、次の手順を使用します。
管理リポジトリに関連付けられているすべてのOracle Management Serviceインスタンスを停止します。
ターゲットのOMSとリポジトリを監視しているエージェントを停止します。
停止できない場合、SQL*Plusで変更されると、エージェントは間違ったパスワードでターゲットに接続しようとします。また、SYSMANアカウントがロックされ、その後Grid ControlコンソールにログインしてターゲットのOMSとリポジトリのパスワードを変更できなくなる場合があります。
次のSQL*Plusコマンドを使用して、SYSMANデータベース・アカウントのパスワードを変更します。
SQL>connect sysman/oldpassword; SQL>alter user sysman identified by newpassword;
管理リポジトリに関連付けられている管理サービスごとに、emoms.properties構成ファイルを探します。
emoms.propertiesファイルは、Oracle Management ServiceがインストールおよびデプロイされているOracle Application Serverホームの次のディレクトリにあります。
IAS_HOME/sysman/config/
emoms.propertiesファイルで次のエントリを見つけます。
oracle.sysman.eml.mntr.emdRepPwd=ece067ffc15edc4f oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
最初のエントリに新しいパスワードを入力し、2番目のエントリにFALSEを入力します。
次に例を示します。
oracle.sysman.eml.mntr.emdRepPwd=new_password
oracle.sysman.eml.mntr.emdRepPwdEncrypted=FALSE
emoms.propertiesファイルを保存して終了し、管理リポジトリに関連付けられている各管理サービスを再起動します。
Grid Controlコンソールで、「ターゲット」タブをクリックし、サブタブで「すべてのターゲット」をクリックします。
管理サービスとリポジトリ・ターゲットを選択して「構成」をクリックします。Enterprise Managerには、監視の構成ページが表示されます。
「リポジトリ・パスワード」フィールドに新しいパスワードを入力して、「OK」をクリックします。
管理サービスを起動すると、emoms.propertiesファイルの内容を確認して、入力したパスワードが暗号化されていることを確認できます。
たとえば、次のようなエントリが表示されます。
oracle.sysman.eml.mntr.emdRepPwd=ece067ffc15edc4f oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
MGMT_VIEWユーザーはリポジトリの作成時に作成されます。このビューは、SQLからの表およびSQLレポート要素からのグラフに対して問合せを実行するレポート作成フレームワーク用にGrid Controlで使用されます。OMSはアカウントを使用する唯一のエンティティであるため、パスワードを把握する必要はありません。ただし、選択する場合はパスワードを変更できます。変更するには、OMSを停止する必要があります。パスワードを変更するには、次のPL/SQLコールまたはEMCTLコマンドを使用できます。
PL/SQL:
SQL> exec mgmt_view_priv.change_view_user_password('<random pwd>');
EMCTLコマンド:
emctl config oms –change_view_user_pwd [-sysman_pwd <pwd>] [-user_pwd <pwd>] [-autogenerate]
この項では、Enterprise Managerのインストール後に既存のデータベースから管理リポジトリを削除し、管理リポジトリを再作成する作業について説明します。
管理リポジトリを再作成するには、最初に管理リポジトリ・データベースからEnterprise Managerスキーマを削除します。このタスクを行うには、RepManagerスクリプトに-action drop引数を使用します。これについては、次の手順で説明します。
データベースから管理リポジトリを削除するには、次の手順を実行します。
管理サービスをインストールおよびデプロイしたOracle Application Serverホームの次のディレクトリでRepManagerスクリプトを見つけます。
IAS_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または1526）です。
repository_SIDは、管理リポジトリ・データベースのシステムIDです。
password_for_sys_accountは、データベースのSYSユーザーのパスワードです。たとえば、change_on_installなどです。
-action dropは、管理リポジトリを削除することを示します。
あるいは、接続記述子を使用して、RepManagerコマンドラインでデータベースを特定することもできます。接続記述子は、標準のOracleデータベース構文を使用してデータベースのホスト、ポート、名前を特定します。
たとえば、接続記述子を次のように使用して管理リポジトリを作成できます。
$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST=host1)(PORT=1521)) (CONNECT_DATE=(SERVICE_NAME=servicename)))" -sys_password efkl34lmn -action drop
|
関連項目: 接続記述子を使用したデータベースへの接続の詳細は、『Oracle Database Net Services管理者ガイド』の接続の確立およびネットワークのテストに関する項 |
管理リポジトリを作成するには、Enterprise Managerのインストール時に管理リポジトリを作成する方法がお薦めです。これはOracle Universal Installerを使用して行います。
|
関連項目: Enterprise Managerのインストールの詳細は、『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』 |
ただし、既存のデータベースに管理リポジトリを再作成する必要がある場合は、管理サービスのインストール時にインストールされるRepManagerスクリプトを使用できます。詳細は、次の項を参照してください。
既存のデータベースに管理リポジトリを作成するには、次の手順を実行します。
『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』の説明に従い、管理リポジトリのハードウェアおよびソフトウェアの要件を確認して、「管理リポジトリのデプロイメント・ガイドライン」の項を参照してください。
Oracle Management Serviceホーム・ディレクトリの次のディレクトリでRepManagerスクリプトを見つけます。
ORACLE_HOME/sysman/admin/emdrep/bin
コマンド・プロンプトで次のコマンドを入力します。
$PROMPT> ./RepManager repository_host repository_port repository_SID -sys_password password_for_sys_account -action create
この構文例では次のようになります。
repository_hostは、管理リポジトリ・データベースが配置されるマシン名です。
repository_portは、管理リポジトリ・データベースのリスナー・ポート・アドレス（通常は1521または1526）です。
repository_SIDは、管理リポジトリ・データベースのシステムIDです。
password_for_sys_accountは、データベースのSYSユーザーのパスワードです。たとえば、change_on_installなどです。
Enterprise Managerは、コマンドラインで指定したデータベースに管理リポジトリを作成します。
あるいは、接続記述子を使用してRepManagerコマンドラインでデータベースを特定することもできます。接続記述子は、標準のOracleデータベース構文を使用してデータベースのホスト、ポート、名前を特定します。
たとえば、接続記述子を次のように使用して管理リポジトリを作成できます。
$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST=host1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=servicename)))" -sys_password efkl34lmn -action create
|
関連項目: 接続記述子を使用したデータベースへの接続の詳細は、『Oracle Database Net Services管理者ガイド』の接続の確立およびネットワークのテストに関する項 |
接続文字列の使用により、アドレス・リストを接続文字列の一部として指定できます。次の例は、RepManagerコマンドラインの一部として2つのリスナーで構成されるアドレス・リストの指定方法を示しています。一方のホストのリスナーが使用できなくなると、もう一方のリスナーが引き続き受信リクエストを受け入れることができます。
$PROMPT> ./RepManager -connect "(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521) (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521) (CONNECT_DATE=(SERVICE_NAME=servicename)))" -sys_password efkl34lmn -action create
|
関連項目: Oracle Database高可用性アーキテクチャおよびベスト・プラクティス『Oracle Enterprise Manager Grid 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 Grid Controlインストレーションおよび基本構成』の説明に従って、サポートされているリリースにデータベースをアップグレードします。
管理リポジトリの作成時にエラーが発生した場合、RepManagerスクリプトに-drop引数を指定して実行し、リポジトリを削除します。
RepManagerスクリプトでリポジトリが正常に削除された場合、管理リポジトリの作成を再試行します。
管理リポジトリの削除時にエラーが発生した場合は、次の手順を実行します。
SQL*Plusを使用してSYSDBAとしてデータベースに接続します。
SYSMANデータベース・ユーザーが管理リポジトリ・データベースに存在するかどうかを確認します。
たとえば、次のコマンドを使用してSYSMANユーザーが存在するかどうかを確認します。
prompt> SELECT username FROM DBA_USERS WHERE username='SYSMAN';
SYSMANユーザーが存在する場合、次のSQL*Plusコマンドを入力してそのユーザーを削除します。
prompt> DROP USER SYSMAN CASCADE;
次のトリガーが存在するかどうかを確認します。
SYSMAN.EMD_USER_LOGOFF SYSMAN.EMD_USER_LOGON
たとえば、次のコマンドを使用してEMD_USER_LOGOFFトリガーがデータベースに存在するかどうかを確認します。
prompt> SELECT trigger_name FROM ALL_TRIGGERS
WHERE trigger_name='EMD_USER_LOGOFF';
トリガーが存在する場合、次のコマンドを使用してデータベースからそのトリガーを削除します。
prompt> DROP TRIGGER SYSMAN.EMD_USER_LOGOFF; prompt> DROP TRIGGER SYSMAN.EMD_USER_LOGON;
Enterprise Managerリポジトリをサーバー間およびクロス・プラットフォームで移行するためのユーザー要件があります。
Enterprise Managerリポジトリ移行プロセスは、データベース移行の場合と完全に同じではありません。Enterprise Managerリポジトリ移行の場合、Enterprise Managerに固有のデータ、オプション、前提条件に注意してリポジトリを移動する必要があります。Enterprise ManagerとOracleデータベースの両方の観点からデータの整合性が維持されることを確認する必要があります。
このためには、最短時間で最大効率が得られる、正常で信頼性の高いリポジトリの移行を行うためにエンド・ユーザーが従うプロセスを定義する必要があります。
移行の全体の戦略は次の内容によって異なります。
ソース・データベースとターゲット・データベースのバージョン
リポジトリのデータ/サイズの量
移行する実際のデータ（選択移行/完全移行）
クロス・プラットフォームのトランスポータブル表領域および（メタデータの）データ・ポンプは、プラットフォームから別のプラットフォームに大きなEnterprise Manager Grid Controlリポジトリを移動するための最速かつ最適な方法です。その他の移行オプションとして、データとメタデータの両方の移動にデータ・ポンプを使用する方法もありますが、同じ量のデータを移行する場合、クロス・プラットフォームのトランスポータブル表領域の方法よりも時間がかかります。データ・ポンプ方法を使用する場合、ソース・データ全体ではなく選択したデータの移行のように、オプションやプロセス全体に対して細かな制御を行うことができるメリットがあります。ソースとターゲットがリリース10g以外の場合、クロス・プラットフォームでデータを移行する方法はエクスポート/インポートのみになります。
クロス・プラットフォームのトランスポータブル表領域、データ・ポンプ、エクスポート/インポートのオプションの詳細は、Oracle Technology Network（OTN）または『Oracle Database管理者ガイド』を参照してください。
次に、リポジトリを移行するための一般的な前提条件を示します。
ソースとターゲットのデータベースは、同じ文字セットを使用し、同じリリースにします。
ソースとターゲットのデータベースは、Enterprise Managerインストール・ガイドに示されたEnterprise Managerリポジトリのソフトウェア要件について言及されたすべての前提条件を満たす必要があります。
ソースとターゲットのデータベースが10g以外の場合、クロス・プラットフォームの移行に使用できるのはエクスポート/インポートのみになります。
ソースとターゲットのデータベースが10g上にある場合、クロス・プラットフォームでリポジトリを移行するには、3つのオプション（クロス・プラットフォームのトランスポータブル表領域移行、データ・ポンプ、またはエクスポート/インポート）のいずれかを使用できます。
同じ名前の表領域がすでにあるターゲット・データベースに表領域をトランスポートすることはできません。ただし、トランスポート操作前に、トランスポートする表領域またはトランスポート先の表領域の名前を変更できます。
トランスポータブル表領域セットを別のプラットフォームのOracle Databaseにプラグインするには、両方のデータベースの互換性を最低でも10.0に設定する必要があります。
ほとんどのプラットフォーム（ただしすべてではない）は、クロス・プラットフォームの表領域トランスポートがサポートされています。V$TRANSPORTABLE_PLATFORMビューに問合せを実行して、サポートされるプラットフォームを確認したり、そのプラットフォームIDやエンディアン形式（バイト順序）を判断したりすることができます。
ソースと移行先のホストでは、EMエージェントが実行し、移行するインスタンスに対して構成されている必要があります。
ターゲット・データベースにEMリポジトリがインストールされている場合、ターゲット・データベースに関連する手順を行う前に、RepManagerを使用してEMリポジトリを最初に削除する必要があります。
次の項では、リポジトリ移行の手順について説明します。
Oracleのトランスポータブル表領域機能では、Oracleデータベース間でユーザー表領域をすばやく移動できます。これは、データベース間で大量のデータを移行するのに最も効率的な方法です。Oracle Database 10gより以前のリリースで表領域をトランスポートする場合、ソース・データベースとターゲット・データベースがどちらも同じプラットフォーム上にある必要があります。Oracle Database 10gでは、トランスポータブル表領域に対するクロス・プラットフォームのサポートが追加されています。クロス・プラットフォームのトランスポータブル表領域を使用すると、プラットフォーム間で表領域をトランスポートできます。
クロス・プラットフォームのトランスポータブル表領域では、プラットフォームから別のプラットフォームにデータベースを移行できます（データ・ポンプまたはインポート/エクスポートで使用）。
次の手順でトランスポータブル表領域の準備をします。
ユーザー表領域のセットを準備して、格納違反がないかどうかを確認します。
execute DBMS_TTS.TRANSPORT_SET_CHECK('MGMT_TABLESPACE,MGMT_ECM_DEPOT_TS', TRUE);
select * FROM transport_set_violations;
OMSインスタンスを停止して、移行の準備をします。
Shutdown OMS, set job queue_processes to 0 and run
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_remove_dbms_jobs.sql
トランスポートする表領域を読取り専用で作成します。
alter tablespace MGMT_TABLESPACE read only;
alter tablespace MGMT_ECM_DEPOT_TS read only;
データ・ポンプ・ユーティリティを使用してトランスポータブル表領域のメタデータを抽出します。
データ・ポンプ・ディレクトリを作成します。
create directory data_pump_dir as '/scratch/gachawla/EM102/ttsdata';
データ・ポンプ（またはエクスポート）を使用してメタデータを抽出します。
expdp DUMPFILE=ttsem102.dmp TRANSPORT_TABLESPACES=MGMT_TABLESPACE,MGMT_ECM_DEPOT_TS TRANSPORT_FULL_CHECK=Y
他のオブジェクト（パッケージ、プロシージャ、関数、一時表など、ユーザー表領域には含まれません）を抽出します。
expdp SCHEMAS=SYSMAN CONTENT=METADATA_ONLY EXCLUDE=INDEX,CONSTRAINT DUMPFILE=data_pump_dir:postexp.dmp LOGFILE=data_pump_dir:postexp.log JOB_NAME=expmet
エンディアンチェックを実行し、エンディアンがソースと移行先で異なる場合はデータファイルを変換します。
エンディアンチェックは、ソース・データベースと移行先データベースの両方で実行します。
SELECT endian_format
FROM v$transportable_platform tp, v$database d
WHERE tp.platform_name = d.platform_name;
ソース・プラットフォームとターゲット・プラットフォームのエンディアンが異なる場合、ソース・プラットフォームまたはターゲット・プラットフォームで追加の手順を実行して、トランスポートする表領域をターゲットの形式に変換する必要があります。ソース・プラットフォームとターゲット・プラットフォームのエンディアンが同じ場合、変換は不要です。表領域が同じプラットフォーム上にあるかのようにトランスポートできます。
例:
Source Endian Linux IA (32-bit) - Little Destination Endian Solaris[tm] OE (32-bit) - Big
データファイル、メタデータのダンプをターゲットに送り、RMANを使用してデータファイルを変換します。
データファイルとメタデータのダンプをターゲットに送り、ターゲット側ですべてのデータファイルを移行先のエンディアンに変換します。
CONVERT DATAFILE '/d14/em10g/oradata/em102/mgmt.dbf', '/d14/em10g/oradata/em102/mgmt_ecm_depot1.dbf' FROM PLATFORM 'Linux IA (32-bit)';
RMANによる変換はソースまたはターゲットのいずれかで行うことができます（詳細はRMANドキュメントを参照してください）。ユーザー表領域に複数のデータファイルが含まれる場合は、並列性を使用してプロセスの速度を上げることができます。
次の手順でメタデータをインポートして表領域をプラグインします。
RepManagerを実行してターゲット・リポジトリを削除します（ターゲット・データベースにEMリポジトリがインストールされている場合）。
RepManager repository_host repository_port repository_SID -sys_password password_for_sys_account -action drop
sysmanユーザーを作成し、ターゲット・データベースに対する権限を付与するインポート前の手順を実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_repos_user.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_pre_import.sql
データ・ポンプ・ユーティリティを開始して、ターゲット・データベースに表領域のセットをプラグインします。
impdp DUMPFILE=ttsem102.dmp DIRECTORY=data_pump_dir
TRANSPORT_DATAFILES=/d14/em10g/oradata/em102/mgmt.dbf,/d14/em10g/oradata/em102/mgmt_ecm_depot1.dbf
他のオブジェクト（パッケージ、プロシージャ、関数など）をインポートします。
impdp CONTENT=METADATA_ONLY EXCLUDE=INDEX,CONSTRAINT DUMPFILE=data_pump_dir:postexp.dmp LOGFILE=data_pump_dir:postexp.log
次のプラグイン後の手順を実行します。
無効を再コンパイルしてパブリック・シノニムを作成し、他のユーザーを作成してVPDポリシーを有効にしてからパッケージを再固定するには、プラグイン後の手順を実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_synonyms.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_post_import.sql
無効なオブジェクトがあるかどうかを確認します。ソース・スキーマと移行先のスキーマを比較して数や無効に矛盾があるかどうかを確認します。
ユーザー表領域を読取り書込みモードに戻します。
alter tablespace MGMT_TABLESPACE read write;
alter tablespace MGMT_ECM_DEPOT_TS read write;
EM dbmsジョブを発行します。
job_queue_processesをオリジナルの値にリセットして実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_submit_dbms_jobs.sql
OMSプロパティを更新してOMSを起動します。
emoms.propertiesを更新して、移行されたリポジトリを反映します。ホスト名oracle.sysman.eml.mntr.emdRepServerとポートを正しい値で更新してOMSを起動します。
管理サービスとリポジトリ・ターゲットを再配置します。
管理サービスとリポジトリ・ターゲットを移行先のホストに移行する必要がある場合、em_assoc. handle_relocated_targetを実行してターゲットを再配置するか、ターゲット・ホストにターゲットを再作成します。
データベースおよびデータベース・リスナーのターゲットを検出/再配置します。
EMでターゲット・データベースとリスナーを検出するか、ソース・エージェントから移行先エージェントにターゲットを再配置します。
Oracle Data Pump技術を使用すると、データベースから別のデータベースに大量のデータやメタデータを並列かつ高速に移動できます。データ・ポンプは、通常のSQLコマンドのかわりにAPIを使用してデータをロードおよびアンロードします。データ・ポンプ操作はEMインタフェースで実行でき、クロス・プラットフォームのデータベース移行にかなり役立ちます。
データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートのツールを使用してデータベースを移行するには、次の手順を実行します。expdpコマンドでソース・サーバーのダンプ・ファイルにデータをエクスポートし、ターゲット・サーバーにそのダンプ・ファイルをコピーまたは移動します。次に、impdpコマンドを使用してターゲット・サーバーのOracleにダンプ・ファイルをインポートして、インポート後のEM固有の手順を実行します。
オリジナルのエクスポートとインポートで使用されたパラメータ（BUFFERおよびRECORDLENGTHなど）のチューニングは、データ・ポンプ・エクスポートとデータ・ポンプ・インポートでは不要であり、サポートもされません。
次の手順でデータ・ポンプを準備します。
EMリポジトリにデータ・ポンプを使用するための前提条件
EMリポジトリに対するImpdpは、データ・ポンプのバグ「Bug 4386766 - 圧縮された索引を使用するIMPDPの失敗、ORA-14071およびORA-39083が発生」が原因で失敗します。このバグは10.2で修正されています。バックポートは10.1.0.4で使用できます。このRDBMSパッチは、EMリポジトリの移行でexpdp/impdpを使用する場合に適用する必要があります。あるいは回避策としてエクスポートおよびインポートにexp/impを使用します。
データ・ポンプ・ディレクトリを作成します。
Create directory data_pump_dir as '/scratch/gachawla/EM102/ttsdata';
OMSインスタンスを停止して、移行の準備をします。
Shutdown OMS, set job queue_processes to 0 and run @IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_remove_dbms_jobs.sql
ジョブのスループットを改善するには、PARALLELパラメータを使用して、現在の条件の最大の長所を利用する並列度を設定する必要があります。通常、並列度は、インスタンス上のCPUの数の2倍以上に設定してください。
データ・ポンプのすべての処理は、複数のジョブ（DBMS_JOBジョブ以外のサーバー・プロセス）で行われます。これらのジョブは、アドバンスト・キューイングを使用するマスター制御プロセスで制御されます。実行時に、アドバンスト・キュー表がジョブ名にちなんで付けられた名前で作成され、マスター制御プロセスで使用されます。この表は、データ・ポンプ・ジョブが完了すると削除されます。ジョブとアドバンスト・キューの名前はJOB_NAMEパラメータを使用して付けることができます。
DBMS_DATAPUMP APIを使用してデータ・ポンプのエクスポート/インポートを行うこともできます。すべてのオプションについては、10g管理マニュアルのデータ・ポンプに関する項を参照してください。
次の手順でデータ・ポンプ・エクスポートを実行します。
データ・ポンプ・エクスポートを実行します。
expdp FULL=y DUMPFILE=data_pump_dir:dpfull1%U.dmp, data_pump_dir:dpfull2%U.dmp PARALLEL=4 LOGFILE=data_pump_dir:dpexpfull.log JOB_NAME=dpexpfull Verify the logs for any errors during export
mgmt_metrics_rawの場合、データ・ポンプの直接パスのエクスポートは失敗し、ORA 600が発生することがあります。これはBug 4221775（4233303）が原因で発生します。このバグは10.2で修正されています。回避策: mgmt_metrics_rawに対してexpdpデータ・ポンプを使用する場合、expdpをACCESS_METHOD+EXTERNAL_TABLEパラメータで実行します。
expdp directory=db_export dumpfile=exp_st2.dmp logfile=exp_st2.log tables=sysman.mgmt_metrics_raw access_method=external_table
次の手順でデータ・ポンプ・インポートを実行します。
RepManagerを実行してターゲット・リポジトリを削除します（ターゲット・データベースにEMリポジトリがインストールされている場合）。
RepManager repository_host repository_port repository_SID -sys_password password_for_sys_account -action drop
ターゲット・データベースを準備します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_tablespaces.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_repos_user.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_pre_import.sql
データ・ポンプ・インポートを実行します。
Impdp FULL=y DUMPFILE=data_pump_dir:dpfull1%U.dmp, data_pump_dir:dpfull2%U.dmp PARALLEL=4 LOGFILE=data_pump_dir:dpimpfull.log JOB_NAME=dpimpfull
ログでインポートによる問題がないかどうかを確認します。
インポート後のEnterprise Manager手順について次の操作を実行します。
無効を再コンパイルしてパブリック・シノニムを作成し、他のユーザーを作成してVPDポリシーを有効にしてからパッケージを再固定するには、プラグイン後の手順を実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_synonyms.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_post_import.sql
無効なオブジェクトがあるかどうかを確認します。ソース・スキーマと移行先のスキーマを比較して数や無効に矛盾があるかどうかを確認します。
EM dbmsジョブを発行します。
job_queue_processesをオリジナルの値にリセットして実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_submit_dbms_jobs.sql
OMSプロパティを更新してOMSを起動します。
emoms.propertiesを更新して、移行されたリポジトリを反映します。ホスト名oracle.sysman.eml.mntr.emdRepServerとポートを正しい値で更新してOMSを起動します。
管理サービスとリポジトリ・ターゲットを再配置します。
管理サービスとリポジトリ・ターゲットを移行先のホストに移行する必要がある場合、em_assoc. handle_relocated_targetを実行してターゲットを再配置するか、ターゲット・ホストにターゲットを再作成します。
データベースおよびデータベース・リスナーのターゲットを検出/再配置します。
EMでターゲット・データベースとリスナーを検出するか、ソース・エージェントから移行先エージェントにターゲットを再配置します。
ソース・データベースと移行先データベースが10g以外の場合、クロス・プラットフォームのデータベース移行に使用できるのはエクスポート/インポートのみになります。
エクスポート/インポートのパフォーマンスを改善するには、BUFFERとRECORDLENGTHにより高い値を設定します。プロセスの速度がかなり遅くなるためNFSにエクスポートしないでください。直接パスを使用するとパフォーマンスを改善できます。注意: EMはVPDを使用するため、ポリシーが定義された表でOracleが使用するのは従来のモードのみになります。
また、エクスポートを実行するユーザーは、 VPDポリシーの実施が免除されるように、すべての行をエクスポートするEXEMPT ACCESS POLICY権限が必要です。エクスポート・モード、アプリケーション、またはデータベースからのデータの除外に使用されるユーティリティにかかわらず、SYSはVPDまたはOracle Label Securityポリシーの実施が常に免除されます。
次の手順でエクスポート/インポートを準備します。
Mgmt_metrics_rawパーティションを確認します。
select table_name,partitioning_type type, partition_count count, subpartitioning_type subtype from dba_part_tables where table_name = 'MGMT_METRICS_RAW'
MGMT_METRICS_RAWのパーティションが3276を超える場合、Bug 4376351（10.2で修正）を参照してください。回避策として、mgmt_metrics_rawを従来のモードでエクスポートします。
OMSインスタンスを停止して、移行の準備をします。
Shutdown OMS, set job queue_processes to 0 and run @IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_remove_dbms_jobs.sql
エクスポートするには次の手順を実行します。
データをエクスポートします。
exp full=y constraints=n indexes=n compress=y file=fullem102_1.dmp log=fullem102exp_1.log
データなし、制約ありでエクスポートします。
exp full=y constraints=y indexes=y rows=n ignore=y file=fullem102_2.dmp log=fullem102exp_2.log
インポートするには次の手順を実行します。
RepManagerを実行してターゲット・リポジトリを削除します（ターゲット・データベースにEMリポジトリがインストールされている場合）。
RepManager repository_host repository_port repository_SID -sys_password password_for_sys_account -action drop
ターゲット・データベースで表領域とユーザーを再作成します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_tablespaces.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_repos_user.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_pre_import.sql
データをインポートします。
imp full=y constraints=n indexes=n file=fullem102_1.dmp log=fullem102imp_1.log
データなし、制約ありでインポートします。
imp full=y constraints=y indexes=y rows=n ignore=y file=fullem102_2.dmp log=fullem102imp_2.log
インポート後のEM手順については、次の操作を実行します。
無効を再コンパイルしてパブリック・シノニムを作成し、他のユーザーを作成してVPDポリシーを有効にしてからパッケージを再固定するには、プラグイン後の手順を実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_create_synonyms.sql
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_post_import.sql
無効なオブジェクトがあるかどうかを確認します。ソース・スキーマと移行先のスキーマを比較して数や無効に矛盾があるかどうかを確認します。
EM dbmsジョブを発行します。
job_queue_processesをオリジナルの値にリセットして実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/admin_submit_dbms_jobs.sql
OMSプロパティを更新してOMSを起動します。
emoms.propertiesを更新して、移行されたリポジトリを反映します。ホスト名oracle.sysman.eml.mntr.emdRepServerとポートを正しい値で更新してOMSを起動します。
管理サービスとリポジトリ・ターゲットを再配置します。
管理サービスとリポジトリ・ターゲットを移行先のホストに移行する必要がある場合、em_assoc. handle_relocated_targetを実行してターゲットを再配置するか、ターゲット・ホストにターゲットを再作成します。
データベースおよびデータベース・リスナーのターゲットを検出/再配置します。
EMでターゲット・データベースとリスナーを検出するか、ソース・エージェントから移行先エージェントにターゲットを再配置します。
Oracle Enterprise Managerでは、管理リポジトリが非常に大きな場合のシナリオでもコンソールのホームページをさらにすばやく表示するオプションが用意されています。通常、アラート、エラー、ポリシー、クリティカル・パッチの数などの要因によって表示時間は遅くなる場合があります。SQLやユーザー・インタフェースを縮小/拡大するには、1つの要因や簡単な方法があるわけではないため、すべてのユーザーに関する次のページ要素を削除する簡単なオプション・フラグが追加されています。
emoms.propertiesフラグLargeRepository=をtrueに設定する場合（通常、デフォルトはfalse）、次の項目のSQLは実行されないため、項目はコンソール・ページに表示されません。
概要ページ・セグメントの3つのセクションは次のとおりです。
「すべてのターゲット」の「アラート」
クリティカル
警告
エラー
「すべてのターゲット」の「ポリシー違反」
クリティカル
警告
情報
「すべてのターゲット」の「ジョブ」
問題のある実行(過去7日間)
一時停止中の実行(過去7日間)
「セキュリティ・パッチ違反」や「クリティカル・パッチ・アドバイザ」を含むページ・セグメント
「デプロイ・サマリー」セクションは、上に移動して空の領域を埋めます。
