10gリリース5（10.2.0.5.0）
B53907-01
 目次 |
 索引 |
| Oracle Enterprise Manager アドバンスト構成 10gリリース5（10.2.0.5.0） B53907-01 |
|
この章では、正常に動作する管理リポジトリを保持していくためのメンテナンスおよびトラブルシューティング技術について説明します。
この章では特に、次の項について説明します。
管理データを、安全で信頼性が高く常に使用可能なものにするため、管理リポジトリをデプロイする際は次の設定および構成ガイドラインを参考にしてください。
Enterprise Managerの様々なコンポーネントが構成され、効率的に実行されている場合、Oracle Management Serviceは、管理対象ホストで実行される管理エージェントから大量のRAWデータを収集し、そのデータを管理リポジトリにロードします。このデータは、後からGrid Controlコンソールで集計、整理、表示されるRAW情報です。
Oracle Management Serviceが管理リポジトリに情報をロードすると、Enterprise Managerが一定期間データを集計し、パージします。
詳細は、次の項を参照してください。
Enterprise Managerでは、時間単位および日付単位で管理データを集計し、管理リポジトリのサイズを最小限に抑えます。データを集計する前に、各データ・ポイントがRAWデータ表に保存されます。RAWデータは、1時間分を集計したメトリック表にロールアップ、または集計されます。1時間分のレコードは、1日の表にロールアップされます。
Enterprise Managerがデータを集計すると、データはパージの対象となるかどうかが決定されます。データを実際にパージするには、一定期間経過している必要があります。この期間を保存期間と呼びます。
最も挿入量が多いRAWデータは、デフォルトの保存期間が最も短く、7日間に設定されています。そのため、1時間分のレコードが集計されてから7日が経過すると、RAWデータ・ポイントをパージできるようになります。
1時間分の集計データ・レコードは、1日分のデータ表にロールアップされてから31日後にパージされます。最高レベルの集計、つまり1日分は、365日間にわたって保存されます。
デフォルトのデータ保存ポリシーについては、表9-1にまとめています。
| 集計レベル | 保存期間 |
|---|---|
|
RAWメトリック・データ |
7日間 |
|
1時間分の集計メトリック・データ |
31日間 |
|
1日分の集計メトリック・データ |
365日間 |
Application Performance Managementを構成し、有効にした場合、Enterprise Managerは、レスポンス時間データも収集、保存、集計、およびパージします。レスポンス時間のデータは、メトリック・データと似たポリシーによってパージされます。Application Performance Managementのパージ・ポリシーについては、表9-2を参照してください。
| 集計レベル | 保存期間 |
|---|---|
|
RAWレスポンス時間データ |
24時間 |
|
1時間の集計レスポンス時間データ |
7日間 |
|
1時間分の分散レスポンス時間データ |
24時間 |
|
1日分の集計レスポンス時間データ |
31日間 |
|
1日分の分散集計レスポンス時間データ |
31日間 |
メトリック・データとアプリケーション・パフォーマンス監視データに加え、その他のEnterprise Managerデータも管理リポジトリに一定期間累計されます。
たとえば、ターゲットの最後の可用性レコードも管理リポジトリに無期限に残されるため、ターゲットの最後の既知の状態が保持されます。
Enterprise Managementのデフォルトの集計およびパージ・ポリシーは、管理リポジトリに対してパフォーマンスとディスク領域に最高の要件を提供しながら、利用可能な大半のデータを分析に使用できるよう設計されています。そのため、パフォーマンスの向上、または使用可能なディスク領域の増加のためにはこれらのポリシーを変更しないでください。これらのデフォルト・ポリシーを変更すると、管理リポジトリのパフォーマンスが左右され、Enterprise Managerインストールのスケーラビリティに悪影響が及ぶ可能性があります。
ただし、Enterprise Manager以外のデータ分析ツールを使用してRAWデータまたは集計データを抽出したり検証したりする場合は、管理リポジトリの使用可能なRAWデータまたは集計データを増やす必要がある場合があります。この場合は、RAWデータまたは集計データの保存期間を長くします。
管理リポジトリで、管理データの各レベルのデフォルト保存期間を変更するには、管理リポジトリ・データベースのMGMT_PARAMETERS表に行を追加で挿入する必要があります。
表9-3に、各RAWデータ表と集計データ表の保存期間を変更するために、
MGMT_PARAMETERS表に挿入する必要があるパラメータを示します。
名前に「_RT_」が含まれている表は、アプリケーション・パフォーマンス監視レスポンス時間データで使用される表であることを意味します。「表名」列のdatatypeを、DOMAIN、IPまたはURLのいずれかのデータ型に置換します。
たとえば、MGMT_METRICS_RAW表のデフォルト保存期間を7日間から14日間に変更する手順は、次のとおりです。
デフォルトの管理リポジトリ・ユーザーはsysmanです。
INSERT INTO MGMT_PARAMETERS (PARAMETER_NAME, PARAMETER_VALUE)
VALUES ('mgmt_raw_keep_window','14');
同様に、すべてのMGMT_RT_datatype_1DAY表のデフォルト保存期間を31日間から100日間に変更する手順は、次のとおりです。
デフォルトの管理リポジトリ・ユーザーはsysmanです。
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時間以内は、削除されたターゲットと同じ名前およびタイプの新しいターゲットを追加しないことをお薦めします。同じ名前およびタイプの新しいターゲットを追加すると、最初の24時間は、Grid Controlコンソールには削除されたターゲットに属するデータが表示されます。
RAWメトリック・データの削除を無効にする手順は、次のとおりです。
デフォルトの管理リポジトリ・ユーザーはSYSMANです。次に例を示します。
SQL> connect sysman/oldpassword;
SQL> EXEC MGMT_ADMIN.DISABLE_METRIC_DELETION(); SQL> COMMIT;
後からメトリックの削除を有効にするには、次のSQLコマンドを実行します。
デフォルトの管理リポジトリ・ユーザーはSYSMANです。次に例を示します。
SQL> connect sysman/oldpassword;
SQL> EXEC MGMT_ADMIN.ENABLE_METRIC_DELETION(); SQL> COMMIT;
Enterprise ManagerのGrid Controlには、30日以上経過した完了済ジョブの詳細を削除するという、デフォルトのパージ・ポリシーがあります。この項では、このデフォルト・パージ・ポリシーを変更するための詳細を説明します。
完了済ジョブ履歴の実際のパージは、リポジトリ・データベースで1日に1回実行されるDBMSジョブで実装されます。ジョブが実行されると、現在の時間（リポジトリ・データベース内のsysdateの値）からn日前の完了済ジョブを検索し、それらのジョブを削除します。デフォルトでは、nの値は30日に設定されています。
デフォルトのパージ・ポリシーはEnterprise Managerコンソール経由では変更できませんが、SQL*Plusを使用して変更できます。
このパージ・ポリシーを変更する手順は、次のとおりです。
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のインストールごとに異なります。この時間を各自の設定で決定する手順は、次のとおりです。
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 AMに実行されます。
SYSMANアカウントはEnterprise Managerの設定および管理に使用されるデフォルトのスーパーユーザー・アカウントです。これはOracle Management Repositoryに格納されているオブジェクトを所有するデータベース・アカウントでもあります。このアカウントから、追加の管理者アカウントを設定し、組織内で使用するためEnterprise Managerを設定できます。
SYSMANアカウントはEnterprise Managerのインストール時に管理リポジトリ・データベースで自動的に作成されます。インストール時にSYSMANアカウントのパスワードも指定します。
後にSYSMANデータベース・アカウントのパスワードの変更が必要になった場合は、次の手順を使用します。
これを実行できない場合、SQL*Plusでパスワードを変更した後、エージェントが誤ったパスワードを使用してターゲットに接続することになります。このためSYSMANアカウントがロックされ、それ以降のGrid Controlコンソールへのログインで、ターゲットOMSおよびリポジトリのパスワードを変更できなくなる可能性があります。
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
次に例を示します。
oracle.sysman.eml.mntr.emdRepPwd=new_password oracle.sysman.eml.mntr.emdRepPwdEncrypted=FALSE
emoms.propertiesファイルを終了し、管理リポジトリに関連付けられている各管理サービスを再起動します。
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引数を使用して行います。
管理リポジトリをデータベースから削除するには、次のようにします。
RepManagerスクリプトを探します。
IAS_HOME/sysman/admin/emdrep/bin
$PROMPT> RepManager repository_host repository_port repository_SID -sys_password password_for_sys_account -action drop
この構文例の詳細は次のとおりです。
もう1つの方法として、接続記述子を使用してRepManagerコマンドラインでデータベースを指定できます。接続記述子では、標準的なOracleデータベース構文を使用してデータベースのホスト、ポートおよび名前を指定します。
たとえば、接続記述子を次のように使用して管理リポジトリを作成します。
$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST=host1)(PORT=1521)) (CONNECT_DATE=(SERVICE_NAME=servicename)))" -sys_password efkl34lmn -action drop
管理リポジトリの作成については、Oracle Universal Installerを使用して実行するEnterprise Managerのインストール時に作成することが望ましい方法です。
ただし、既存のデータベースで管理リポジトリを再作成する必要がある場合は、管理サービスのインストール時にインストールされるRepManagerスクリプトを使用します。詳細は次の項を参照してください。
既存のデータベースで管理リポジトリを作成するには、次のようにします。
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は管理リポジトリ・データベースのシステム識別子です。
password_for_sys_account はデータベースに対するSYSユーザーのパスワードです。たとえば、change_on_installなどです。
Enterprise Managerでは、コマンドラインで指定したデータベースに管理リポジトリが作成されます。
もう1つの方法として、接続記述子を使用してRepManagerコマンドラインでデータベースを指定できます。接続記述子では、標準的なOracleデータベース構文を使用してデータベースのホスト、ポートおよび名前を指定します。
たとえば、接続記述子を次のように使用して管理リポジトリを作成します。
$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=host1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=servicename)))"
-sys_password efkl34lmn -action create
接続文字列を使用すると、接続文字列の一部としてアドレス・リストを指定できます。次の例は、RepManagerコマンドラインの一部として2つのリスナーから構成されるアドレス・リストを指定する場合を示しています。1つのホストのリスナーが使用不可になった場合でも、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 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スクリプトで管理リポジトリの削除に成功した場合は、再度リポジトリを作成します。
管理リポジトリの削除の際にエラーが発生した場合は、次の手順を実行します。
たとえば、次のコマンドを使用してSYSMANユーザーの存在を確認します。
prompt> SELECT username FROM DBA_USERS WHERE username='SYSMAN';
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リポジトリをプラットフォーム間で移動する際の最速かつ最適な方法としては、データ・ポンプ（メタデータ向け）に加え、クロス・プラットフォーム・トランスポータブル表領域があります。また、もう1つの移行方法として、データとメタデータの移動にデータ・ポンプを使用するというオプションもあります。しかし、データ・ポンプ方式では、同じ量のデータの処理に、クロス・プラットフォーム・トランスポータブル表領域方式よりも時間がかかります。データ・ポンプ方式の利点とは、オプションと全体的なプロセスに対して細かい制御が可能になることです。たとえば、選択したデータのみを移行し、ソース・データ全体は移行しない場合などです。ソースとターゲットのバージョンが10g上にない場合、クロス・プラットフォームでデータを移行するには、エクスポートとインポート以外の方法はありません。
クロス・プラットフォーム・トランスポータブル表領域、データ・ポンプ、およびエクスポートとインポートのオプションに関する詳細は、Oracle Technology Network（OTN）または『Oracle Database管理者ガイド』を参照してください。
リポジトリ移行に伴う一般的な前提条件は、次のとおりです。
次の項では、リポジトリ移行の方法について説明します。
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を停止し、ジョブのqueue_processesを0に設定し、実行します。
@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
データ・ファイルとメタデータ・ダンプをターゲットに送信し、ターゲット上ですべてのデータ・ファイルを宛先のエンディアンに変換します。
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 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_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
差込み後の手順は、次のとおりです。
@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;
job_queue_processesを元の値にリセットし、実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/
admin_submit_dbms_jobs.sql
移行したリポジトリを反映するよう、emoms.propertiesを更新します。ホスト名oracle.sysman.eml.mntr.emdRepServerとポートを正しい値で更新し、OMSを起動します。
管理サービスとリポジトリ・ターゲットを宛先ホストに移行する必要がある場合は、
em_assoc.handle_relocated_targetを実行してターゲットを再配置するか、ターゲット・ホストにターゲットを再作成します。
EMでターゲット・データベースとリスナーを検索するか、ターゲットをソース・エージェントから宛先エージェントに再配置します。
Oracleのデータ・ポンプ技術では、大量のデータとメタデータをデータベース間で高速かつ並列的に移動できます。データ・ポンプは一般的なSQLコマンドではなくAPIを使用し、データをロードおよびアンロードします。データ・ポンプ操作はEMインタフェース経由で実行可能であり、クロス・プラットフォームのデータベース移行において非常に便利です。
データ・ポンプ・エクスポートとデータ・ポンプ・インポートのツールを使用してデータベースを移行するには、まず、expdpコマンドを実行して、ソース・サーバー上のダンプ・ファイルにデータをエクスポートします。次に、ダンプ・ファイルをターゲット・サーバーにコピーまたは移動し、impdpコマンドを実行してターゲット・サーバー上のOracleにダンプ・ファイルをインポートします。その後、EM固有のインポート後手順を実行します。
BUFFERやRECORDLENGTHなど、従来のエクスポートやインポートで使用されていたチューニング・パラメータは、データ・ポンプ・エクスポートでもインポートでも必要ではなく、サポートもされていません。
データ・ポンプを準備する手順は、次のとおりです。
データ・ポンプの不具合（不具合4386766 - IMPDP WITH COMPRESSED INDEXES FAILS WITH ORA-14071 AND ORA-39083）により、EMリポジトリでimpdpが失敗します。この不具合は10.2で修正されています。10.1.0.4ではバックポートを使用できます。EMリポジトリ移行でexpdp/impdpを使用するには、このRDBMSパッチを適用する必要があります。または、exp/impで抽出し、インポートするという方法もあります。
Create directory data_pump_dir as '/scratch/gachawla/EM102/ttsdata';
OMSを停止し、ジョブのqueue_processesを0に設定し、
@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が発生することがあります。これは、不具合4221775（4233303）によるものです。この不具合は10.2で修正されています。回避策: mgmt_metrics_rawでexpdpデータ・ポンプを使用する場合は、ACCESS_METHOD+EXTERNAL_TABLEパラメータでexpdpを実行します。
expdp directory=db_export dumpfile=exp_st2.dmp logfile=exp_st2.log tables=sysman.mgmt_metrics_raw access_method=external_table
データ・ポンプのインポートを実行する手順は、次のとおりです。
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で次の手順を実行します。
@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
無効なオブジェクトの有無を確認します。ソース・スキーマと宛先スキーマを比較し、数に相違がないか、無効なオブジェクトがないかを確認します。
job_queue_processesを元の値にリセットし、実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/
admin_submit_dbms_jobs.sql
移行したリポジトリを反映するよう、emoms.propertiesを更新します。ホスト名oracle.sysman.eml.mntr.emdRepServerとポートを正しい値で更新し、OMSを起動します。
管理サービスとリポジトリ・ターゲットを宛先ホストに移行する必要がある場合は、
em_assoc.handle_relocated_targetを実行してターゲットを再配置するか、ターゲット・ホストにターゲットを再作成します。
EMでターゲット・データベースとリスナーを検索するか、ターゲットをソース・エージェントから宛先エージェントに再配置します。
ソース・データベースとターゲット・データベースが10g以外である場合、クロス・プラットフォームのデータベース移行を行うには、エクスポートとインポート以外に方法はありません。
エクスポートとインポートのパフォーマンスを向上するには、BUFFERとRECORDLENGTHの値を高く設定します。プロセスの速度が著しく低下するため、NFSにはエクスポートしないでください。ダイレクト・パスを使用してパフォーマンスを向上させることができます。
注意:EMはVPDを使用するため、従来のモードは、ポリシーが定義されている表のOracleでのみ使用されます。
エクスポートを実行するユーザーがすべての行をエクスポートするには、EXEMPT ACCESS POLICY特権が必要です。この特権により、そのユーザーはVPDポリシー強制の適用対象外となります。SYSは、データベースからデータを抽出するために使用されるエクスポート・モード、アプリケーション、またはユーティリティに関係なく、常にVPDまたはOracle Label Securityポリシー強制の適用対象外となります。
エクスポートとインポートを準備する手順は、次のとおりです。
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を超えるパーティションがある場合は、Oracle Bug#4376351を参照してください。この不具合は、10.2では修正されています。あるいは、従来のモードでmgmt_metrics_rawをエクスポートするという回避策もあります。
OMSを停止し、ジョブのqueue_processesを0に設定し、
@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 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で次の手順を実行します。
@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
無効なオブジェクトの有無を確認します。ソース・スキーマと宛先スキーマを比較し、数に相違がないか、無効なオブジェクトがないかを確認します。
job_queue_processesを元の値にリセットし、実行します。
@IAS_HOME/sysman/admin/emdrep/sql/core/latest/admin/
admin_submit_dbms_jobs.sql
移行したリポジトリを反映するよう、emoms.propertiesを更新します。ホスト名oracle.sysman.eml.mntr.emdRepServerとポートを正しい値で更新し、OMSを起動します。
管理サービスとリポジトリ・ターゲットを宛先ホストに移行する必要がある場合は、
em_assoc.handle_relocated_targetを実行してターゲットを再配置するか、ターゲット・ホストにターゲットを再作成します。
EMでターゲット・データベースとリスナーを検索するか、ターゲットをソース・エージェントから宛先エージェントに再配置します。
移行後に次の検証手順を実行し、移行が正常に終了したかどうかを確認する必要があります。
Oracle Enterprise Managerに、管理リポジトリが大きい場合でも、より敏速にコンソールのホームページを表示するオプションが用意されました。通常、アラート、エラー、ポリシーおよび重要なパッチの数などの要因から、表示時間が遅くなることがあります。SQLまたはユーザー・インタフェースをスケールする簡単な方法または単一の要因はないため、すべてのユーザーについて、次のページ要素を削除する簡単なオプション・フラグが追加されました。
LargeRepository=のemoms.propertiesフラグがtrueに設定される場合（通常、デフォルトはfalse）、次の項目のSQLは実行されず、コンソールのページに表示されません。
「デプロイ・サマリー」セクションは、空白部分を埋めるために上に移動します。
|
 Copyright © 2003, 2009 Oracle Corporation. All Rights Reserved. |
|