プライマリ・コンテンツに移動
Oracle® Enterprise Manager Cloud Control基本インストレーション・ガイド
13c リリース3
E98537-01
目次へ移動
目次 		索引へ移動
索引
前
前へ 		次
次へ

A EM前提条件キットの概要

この付録では、Enterprise Managerをインストールまたはアップグレードするたびにインストール・ウィザードが実行するEnterprise Manager前提条件キット・ユーティリティ(EM前提条件キット)について説明します。この付録の具体的な内容は次のとおりです。

A.1 EM前提条件キットについて

EM前提条件キットは、環境内でリポジトリ関連の前提条件チェックを実行し、Enterprise Managerシステムのインストールまたはアップグレードのすべてのリポジトリ要件を満たしているかを確認するユーティリティです。

このキットは前提条件のチェックを行うだけでなく、前提条件チェックが失敗した場合には、可能なかぎり自動的に修正も行います。

EM前提条件キットは、Enterprise Managerシステムのインストールまたはアップグレード中に、Enterprise Managerインストール・ウィザードが内部で実行します。さらに、事前にキットを実行し、環境がすべてのリポジトリ関係要件を満たしていることを確認できます。

注意:

手動でEM前提条件キットを実行すると、ステータスのみが表示され、修正処理は実行されません。

警告:

オラクル社提供のデータベース・テンプレートを使用して事前構成済の管理リポジトリで作成されたデータベース・インスタンスの使用を計画している場合は、EM前提条件キットを呼び出す際に次のパラメータを必ず渡してください。

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

A.2 EM前提条件キットの実行

EM前提条件キットは、Enterprise Managerシステムのインストールまたはアップグレード中に、Enterprise Managerインストールウィザードによって内部で実行されますが、事前に実行して環境がすべてのリポジトリ関係要件を満たしていることを確認できます。そうすることによって、リポジトリ関係の問題を事前に発見および修正でき、インストールやアップグレードをよりスムーズに行えます。GUIでキットのステータスを表示できます。この項では、フレッシュ・インストールおよびアップグレードでEM前提条件キットを表示する次の方法を説明します。

A.2.1 GUIでのEM前提条件キットの実行

EM前提条件キットを実行するたびに、特定のコンポーネントに対して実行した前提条件チェックの結果がGUIで表示されます。ユーザーは各前提チェックのステータスを表示できます。

EM前提条件のステータスを表示する手順は次のとおりです。

  1. フラグflag EMPREREQ_KIT=trueを指定してEMインストーラを起動します。
    次に例を示します。
    ./em13300_linux64.bin EMPREREQ_KIT=true
    次に対してEM前提条件チェックのステータスの表示を選択できます。
    • フレッシュ・インストール
    • アップグレード
    フレッシュ・インストールの場合
    1. 「Enterprise Managerシステムの新規作成」オプションを選択します。
    2. 「次へ」をクリックします。
    3. データベースのホスト名、ポート番号、サービスIDおよびシステム・パスワードをそれぞれのフィールドに入力します。
    アップグレードの場合
    1. 「既存のEnterprise Managerシステムのアップグレード」オプションを選択します。
    2. 「次へ」をクリックします。
    3. 必要なパスワードをそれぞれのフィールドに入力します。
  2. 「実行」をクリックしてEM前提条件キット・チェックのステータスを表示します。
    デフォルトでは、失敗した前提条件チェックが表示されます。
  3. すべての前提条件の表示をクリックしてすべての前提条件チェックのステータスを表示します。

    Enterprise Managerの「前提条件チェック」
  4. 必要な行をクリックして推奨事項と修正タイプを表示します。

    注意:

    次のように、失敗のタイプに基づいた使用可能な3つの修正タイプがあります。

    表A-1 修正タイプ

    修正タイプ 説明

    不要

    これは警告メッセージであり、無視して先に進むことができます。

    手動

    これはエラー・メッセージであり、手動で修正してから先に進む必要があります。

    自動

    これはエラー・メッセージであり、EMで修正するための修正処理が事前定義されているため、無視できます。

    注意:

    EM前提条件キットは、サイレント・モードではサポートされていません。

A.3 EM前提条件キットによって作成されるログ・ファイルの表示

表A-2は、EM前提条件キットを実行するたびに作成されるすべてのログ・ファイルを示します。

表A-2 EM前提条件キット・ログ・ファイル

ログ・ファイル名 説明

emprereqkit.log

キットが実行した各手順やアクションに関する情報が含まれます。

emprereqkit.err

発生した例外のエラーおよびスタックトレースのみが含まれます。

emprereqkit.out

実行するすべての前提条件チェックのステータス(合格または不合格)に関する情報が含まれます。各前提条件チェックに関する詳細な情報も含まれます。たとえば前提条件名、実行ステータス、詳細な推奨内容(不合格の前提条件を修正するためにどの問合せを実行するべきか)などが含まれます。

<functional_area>.log

実行する機能領域固有の前提条件チェックに関する情報が含まれます。たとえば、実行するリポジトリ固有のパフォーマンス関連の前提条件チェックを含むrepository.logなどです。repository.logは<ログの場所>/componentLogディレクトリにあります。

例: $OraInventory/logs/emdbprereqs/LATEST/componentLog/repository.log

表A-3は、EM前提条件キットの起動方法によって異なるログ・ファイルの場所を示します。この表は、emprereqkit.outファイル以外のすべてのログ・ファイルの場所を示しています。emprereqkit.outファイルについては、表の後の注意を参照してください。

表A-3 EM前提条件キット・ログ・ファイルの場所

起動タイプ 最新のログ・ファイルの場所(1) ログ・ファイルの場所(2)

手動で起動

<logLoc>/LATEST

注意: logLocを値として提供する場合、ログの場所は前述のようになります。それ以外の場合は<Current Directory>/prerequisiteResults/log/LATESTです。

<logLoc>/<time-stamp>

注意: logLocを値として提供する場合、ログの場所は前述のようになります。それ以外の場合は<Current Directory>/ prerequisiteResults/log/<time-stamp>です。

Enterprise Manager Cloud Controlインストール・ウィザードが自動的に起動

<ORACLE_HOME>/.gcinstall_temp/LATEST

注意: インストール・ウィザードのページを進むと、EM前提条件キット・ログが$OraInventory/logs/emdbprereqs/LATESTまたは/tmp/OraInstall<timestamp>/ emdbprereqs/LATESTに作成されます。

インストールが開始されると、/tmp/OraInstall<timestamp>/emprereqkitログが<ORACLE_HOME>/.gcinstall_temp/emprereq/LATESTにコピーされます

<ORACLE_HOME>/.gcinstall_temp/<time-stamp>

注意: インストール・ウィザードのページを進むと、EM前提条件キット・ログが$OraInventory/logs/emdbprereqs/<timestamp>または/tmp/OraInstall<timestamp>/ emdbprereqs/<timestamp>に作成されます。

インストールが開始されると、/tmp/OraInstall<timestamp>/ emdbprereqs/<time-stamp> ログが<ORACLE_HOME>/.gcinstall_temp/emprereq/<time-stamp>にコピーされます

脚注 1 最新のログ・ファイルの場所とは、EM前提条件キットを最後に実行したときに作成された、最新のログ・ファイル用に確保されている単一の標準的な場所を指します。ここで作成されたログ・ファイルは、ユーティリティを実行するたびに上書きされます。

脚注 2 ログ・ファイルの場所とは、EM前提条件キットを実行するたびにユーティリティが動的に作成する<time-stamp>ディレクトリを指します。ここで作成されるログ・ファイルは、削除するまで維持されます。

注意:

EM前提条件キットを手動で実行すると、ログ・ファイルemprereqkit.outは<prereqResultLoc>/log/<time-stamp>に保存されます。最新のログ・ファイルは<prereqResultLoc>/log/LATEST/に保存されます。

Enterprise Manager Cloud Controlインストール・ウィザードの内部でEM前提条件キットが実行されると、ログ・ファイルemprereqkit.outが<ORACLE_HOME>/.gcinstall_temp/log/<time-stamp>に保存されます。最新のログ・ファイルは <ORACLE_HOME>/.gcinstall_temp/log/<LATEST>に保存されます。

A.4 EM前提条件キットによって実行されるリポジトリ前提条件チェック

表A-4に、EM前提条件キットがチェックするすべてのリポジトリ前提条件を説明します。この項ではこれらの前提条件を手動でチェックする方法についても説明します。

表A-4 リポジトリの前提条件

前提条件 インストール/アップグレードに適用 説明

基本ポリシー要件

アップグレード

MGMT_TARGETS用の有効なポリシーが存在していることを確認します。

これを手動で確認するには、次の問合せを実行します。

select 'EM_TARGET_POLICY' from dual where not exists (select policy_name from dba_policies where object_owner=’SYSMAN' and pf_owner='SYSMAN' and object_name='MGMT_TARGETS')

この問合せによって行が戻されないようにしてください。

アクティブなジョブの要件

アップグレード

リポジトリ・データベース内で、バックグラウンドDBMSジョブが現在実行中でないことを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) FROM dba_jobs_running run_job,gv$session sess WHERE sess.sid=run_job.sid AND sess.schemaname='SYSMAN'

問合せの結果が0の場合はアクティブなDBMSジョブはありません。結果が0以外の場合は、アクティブなジョブが完了するまで待機します。

GVMパフォーマンス収集ジョブが実行中かどうかの確認

アップグレード

GVMパフォーマンス・メトリック収集ジョブが停止し、削除されていることを確認します。

GVMPERFMETRICCOLL という名前のジョブが存在するかどうかを手動で確認するには、次の問合せを実行します。

select count(*) from mgmt_job where job_name = 'GVMPERFMETRICCOLL' and job_type = 'UpdateGVMPerfMetric'

存在する場合は、停止して削除します。

有効な参照の要件

アップグレード

MGMT_JOB_EXECUTION 内のexecution_idのすべてのエントリが、MGMT_JOB_EXEC_SUMMARY内の有効なエントリを指しているか、NULLであることを確認します。

これを手動で確認するには、次の問合せを実行します。この問合せによって行が戻されないようにしてください。

SELECT COUNT(1) FROM MGMT_JOB_EXECUTION e WHERE NOT EXISTS (SELECT 1 FROM MGMT_JOB_EXEC_SUMMARY s WHERE s.execution_id = e.execution_id) AND execution_id IS NOT NULL

ジョブ・タイプの一意性要件

アップグレード

MGMT_JOB_TYPE_INFOにjob_type, job_type_owner, major_version, minor_version1, minor_version2の列セットに重複するエントリがないことを確認します。

これを手動で確認するには、次の問合せを実行します。この問合せによって行が戻されないようにしてください。

SELECT job_type FROM MGMT_JOB_TYPE_INFO GROUP BY job_type, job_type_owner, major_version, minor_version1, minor_version2 HAVING COUNT(1) > 1

SQL計画ベースライン・キャプチャ・パラメータ要件

インストール、アップグレード

パラメータoptimizer_capture_sql_plan_baselinesがFALSE (またはデフォルト)に設定されていることを確認します。

管理リポジトリに対しては、SQL計画ベースライン・キャプチャを決してオンにしないでください。Enterprise Managerは、更新されたCBO統計に大きく依存します。古いCBO統計が存在する場合、SQL計画ベースライン・キャプチャが原因で不正な実行計画がクリティカル機能に使用されることがあります。

現在の可用性索引要件

インストール、アップグレード

現在の可用性索引をEM_CURRENT_AVAILABILITY_PKに設定します。

My Oracle Supportユーザー名サイズ要件

アップグレード

My Oracle Supportユーザー名が239文字を超えていないことを確認します。超えている場合は、アップグレードできません。

ARUユーザー名サイズ要件

アップグレード

ARUユーザー名が239文字を超えていないことを確認します。超えている場合は、アップグレードできません。

DBMSパッケージ要件

インストール、アップグレード

必要なDBMSパッケージをコンパイルします。

パッケージを手動でコンパイルするには、管理リポジトリが構成されているデータベースにSYSユーザーとしてサイン・インし、次の問合せを実行して無効なDBMSパッケージのリストを取得します。

SELECT object_name, object_type FROM all_objects WHERE status = 'INVALID' AND object_name LIKE 'DBMS%'

パッケージが無効な場合は、次の問合せを実行します。

  • パッケージ:

    ALTER PACKAGE <PACKAGE_NAME> COMPILE

  • パッケージ本体:

    ALTER PACKAGE <PACKAGE_NAME> COMPILE BODY

パッケージが正常にコンパイルされない場合は、Oracleサポートに問い合せてください。

スナップショット・ログ要件

アップグレード

スナップショット・ログが表から削除されていることを確認します。

コネクタ構成表要件

アップグレード

コネクタ構成表に不正なデータがないことを確認します。ある場合は、次の問合せを実行して表をクリーニングします。

delete from mgmt_cntr_config where connector_guid is null or connector_type_guid is null; commit;

compatibleインスタンス・パラメータ要件

インストール、アップグレード

互換性があるインスタンス・パラメータが、管理リポジトリのデータベース・インスタンスと同じバージョン値に設定されていることを確認します。他の値では、予期しない問題、パフォーマンスの低下、またはその両方が発生することがあります。

プライマリ・キーと外部キーの要件

アップグレード

プライマリ・キーと外部キーが無効になっていないことを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from (select constraint_name, table_name from DBA_CONSTRAINTS where owner = 'SYSMAN' and (constraint_type = 'P' or constraint_type = 'R') and status = 'DISABLED')

結果が0以外の場合、次の問合せを使用して制限を有効にします。

alter table SYSMAN.<TABLE_NAME> modify constraint <CONSTRAINT_NAME> enable

なんらかの理由で制限を有効にできない場合は、Oracleサポートに連絡してください。

キューの有効化要件

アップグレード

リポジトリ・データベース内で、キューが有効になっていることを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from dba_queues where owner = 'SYSMAN' and queue_type like '%NORMAL_QUEUE%' and (enqueue_enabled like '%NO%' OR dequeue_enabled like '%NO%')

結果が0以外の場合、次の問合せを使用して無効になっているキュー名のリストを取得します。

select name, queue_table from dba_queues where owner = 'SYSMAN' and upper(queue_type) not like 'EXCEPTION_QUEUE' and (upper(enqueue_enabled) NOT LIKE '%YES%' OR upper(dequeue_enabled) NOT LIKE '%YES%')

次のSQL文を実行して、キューを有効にします。

begin dbms_aqadm.start_queue('<disabled_queue_name>'); end;

キューを開始できない場合は、Oracleサポートに連絡してください。

トリガー要件

アップグレード

リポジトリ・データベース内ですべてのトリガーが無効になっていないことを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from (select trigger_name, trigger_type, table_name from DBA_TRIGGERS where table_owner = 'SYSMAN' and status = 'DISABLED')

結果が0以外の場合、トリガーを有効にします。

SYSTEM表領域要件

インストールとアップグレード

SYSTEM表領域に、autoextensibleが設定されたデータファイルが1つ以上あることを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from dba_data_files where tablespace_name = 'SYSTEM' and autoextensible = 'YES'

結果が0の場合、autoextendの属性を持つ新しいデータファイルをSYSTEM表領域に追加して、autoextensibleが'YES'になったものがDBA_DATA_FILESビューに1つ以上表示されるようにします。エラーが発生した場合は、Oracleサポートに連絡してください。

emkey要件

アップグレード

emkeyがリポジトリにコピーされていることを確認します。

これを手動で確認するには、次の問合せを実行します。

select COUNT(*) from sysman.mgmt_repos_time_coefficient

問合せの結果が1以外の場合は、emkey.oraファイルを別なOMSまたはバックアップ・マシンからORACLE_HOME/sysman/configディレクトリにコピーします。

emctl config emkey -copy_to_repos -sysman_pwd <sysman_pwd>を実行して、emkey.oraファイルを構成します。

EM_USER_CONTEXTの要件

アップグレード

EM_USER_CONTEXTがリポジトリ内に存在していることを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from dba_context where schema='SYSMAN' and upper(namespace)='EM_USER_CONTEXT'

問合せ結果が0の場合、次の問合せを実行してプロシージャSETEMUSERCONTEXTが有効であることを確認します。

select status from all_objects

ここで、object_name='SETEMUSERCONTEXT'およびowner='SYSMAN'です。

前述の問合せでは'VALID'が戻される必要があります。その後、次を実行します。

alter session set current_schema='SYSMAN';

SETEMUSERCONTEXTを使用して、コンテキストEM_USER_CONTEXTを作成または置換します。

なんらかの理由でコンテキストを作成できない場合は、Oracleサポートに連絡してください。

Audit Master表の要件

アップグレード

Audit Master表に異常な状態が保存されていないことを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from sysman.mgmt_audit_master

問合せ結果が1以外の場合、Oracleサポートにお問い合せいただき、パッチ/アップグレード前にEnterprise Managerリポジトリを分析してください。

Exempt Access Policy要件

アップグレード

EXEMPT ACCESS POLICYがSYSMANに対して直接付与されていないこと、あるいはSYSMANに付与されているロールに間接的に付与されていることを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from dba_sys_privs where upper(privilege)='EXEMPT ACCESS POLICY' and (grantee = 'sysman' or grantee in (select distinct granted_role from dba_role_privs start with grantee='SYSMAN' connect by prior granted_role=grantee) or grantee = 'sysman')

問合せ結果が0以外の場合、SYSMANおよびロールのEXEMPT ACCESS POLICYを無効にします。

次に例を示します。

revoke exempt access policy from SYSMAN

max_enabled_roles init parameter要件

インストールとアップグレード

max_enabled_rolesパラメータ値に、SYSに付与されたフラット・ロールよりも3つ以上多く含むように設定されていることを確認します。

これを手動で確認するには、次の問合せを実行します。

select 1 from DUAL where (select count(*) from v$instance where version like '9.%') = 0 or (select value from v$parameter where name like 'max_enabled_roles') > (select count(*) from dba_role_privs start with grantee='SYS' connect by prior granted_role=grantee)+2;

問合せ結果が1以外の場合は、max_enabled_rolesパラメータ値を増やして、SYSに付与されたフラット・ロールよりも3つ以上多く含むようにします。

max_enabled_rolesを修正するには次の手順を実行します。

  1. すべてのOMSインスタンスを停止します。

  2. データベースをクリーンに停止します。

  3. init.oraやデータベースの初期化プロセスで使用されているその他のファイルで、max_enabled_rolesパラメータを変更します。

  4. データベースをクリーンに起動します。

  5. v$parameterを使用して、パラメータ値が増加したことを確認します。

PAF実行要件

アップグレード

PAFの実行が予定されていない、または実行中でないことを確認します。

手動で確認するには、次の問合せを実行し、予定されている、または実行されているデプロイメント・プロシージャのGUIDを書き留めてください。

SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s, SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p WHERE p.procedure_guid = i.procedure_guid AND s.instance_guid = i.instance_guid AND s.state_type = 0 AND s.status in (0,1)

予定されている、または実行されているデプロイメント・プロシージャを手動で停止するには、次の問合せを実行し、前述のコマンド出力から書き留めたGUIDを渡します。

emcli stop_instance -instance=<instance id from sql query>

Secured Agent要件

アップグレード

最新のCAによってすべてのエージェントの安全性が確保されていることを確認します。

安全性確保が必要なエージェントのリストを入手するには、次のコマンドを実行します。

emcli get_ca_info -details

アップグレード前のコンソール・パッチ要件

アップグレード

アップグレード前にパッチが適用されていることを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from all_objects where object_name ='PRE_UPGC_MASTER_INFO' and object_type='TABLE' and owner='SYSMAN'

問合せ結果が1以外の場合は、アップグレード前にアップグレード前コンソール・パッチを適用してください。

Global Stale割合要件

インストールとアップグレード

グローバル・ステール割合が5から25の間であることを確認します。

これを手動で確認するには、次の問合せを実行します。

select count(*) from dual where dbms_stats.get_prefs('STALE_PERCENT') between 5 and 25

問合せ結果は1である必要があります。

アカウント・ステータス要件

アップグレード

SYSMAN、MGMT_VIEWおよびORACLE_OCMアカウントがロックされていない、または失効していないことを確認します。

これを手動で確認するには、次の問合せを実行します。

select account_status from dba_users where username='SYSMAN';
select account_status from dba_users where username='MGMT_VIEW';
select account_status from dba_users where username='ORACLE_OCM';

問合せ結果はOPENである必要があります。

SYSMANスキーマ要件

アップグレード

アップグレード用のSYSMANスキーマがあることを確認します。

これを手動で確認するには、次の問合せを実行します。

SELECT COUNT(*) FROM ALL_USERS WHERE USERNAME='SYSMAN'

問合せ結果は1である必要があります。

Redo Logサイズ要件

インストールとアップグレード

ログ・ファイルのサイズが、別のインストール・タイプとデプロイメント・オプションで定義された次の値以上であることを確認します。

  • 簡易インストール: 300MB以上

  • 拡張インストール:

    -小規模: 300MB以上

    -中規模: 600MB以上

    -大規模: 1000MB以上

これを手動で確認するには、次の問合せを実行します。

select min(bytes) from v$log

既存のデータベースがQUIESCE(停止)モードではないこと

インストールとアップグレード

動作保証済の既存のOracle DatabaseがQUIESCEモードになっていないことを確認します。

これを手動で確認するには、SYSロールで次のSQLをデータベースに実行します。

select active_state from v$instance;

問合せ結果はNORMALである必要があります。

既存のデータベースにSYSMANおよびSYSMAN_MDSスキーマがない

フレッシュ・インストール

動作保証済の既存のOracle Databaseに、Enterprise ManagerのSYSMANスキーマおよびMetadata (MDS)スキーマがまだ構成されていないことを確認します。これらのスキーマが存在するのは、過去に別のEnterprise Managerインストールでデータベースが構成され、同じデータベースを新規インストールで再利用を試みていることを示します。

スキーマが存在することを手動で確認し、削除するには、次の問合せを実行します。

SELECT COUNT(*) FROM ALL_USERS WHERE USERNAME IN ('SYSMAN','SYSMAN_MDS');

問合せの結果が1の場合、データベースにこれらのスキーマがあることを示します。この場合、スキーマを削除して、スキーマを作成したEnterprise Managerソフトウェアを削除します。手順については、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』を参照してください。

データベース初期化パラメータの要件

インストールして、インストールにのみ適用されるdb_block_size以外のアップグレードを行います。
データベース初期化パラメータを正しく設定したことを確認します。

注意:

Cloud Controlのインストール中に、リポジトリ・データベースdb_block_sizeを8192に設定する必要があります。

様々なデプロイメント・サイズに対して設定されるデータベース初期化パラメータの詳細は、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』を参照してください。

ファイングレイン・アクセス・コントロール要件

アップグレード

管理リポジトリを作成できるように、動作保証済の既存のOracle Database内でファイングレイン・アクセス制御オプションがTRUEに設定されていることを確認します。

これを手動で確認するには、次のコマンドを実行します。

select value from v$option where parameter = 'Fine-grained access control';

UNDO表領域のサイズ要件

インストールとアップグレード

UNDO表領域に200MB以上の領域があることを確認します。

これを手動で確認するには、次の問合せを実行します。

SELECT SUM(DECODE(autoextensible,'YES',200*1024*1024+1,bytes)) total
 
FROM dba_data_files f, dba_tablespaces s
 
WHERE s.contents = 'UNDO'
 
AND s.tablespace_name = f.tablespace_name;

注意:

この問合せの結果はバイト数です。

最小領域が200MB未満の場合、次のコマンドを実行して、200MBに設定してください。

alter database datafile <location datafile> resize 200M;

UNDO表領域および一時表領域の設定要件

インストールとアップグレード

動作保証済の既存のOracle Database内でUNDO表領域とTEMP表領域が自動拡張可能になっていることを確認します。

これを手動で確認するには、次のコマンドを実行します。

select count(*) from  dba_temp_files where tablespace_name='TEMP' and AUTOEXTENSIBLE  <> 'YES';
 
select count(*) from dba_data_files where tablespace_name='UNDOTBS' and AUTOEXTENSIBLE <> 'YES';

問合せの結果が0の場合、表領域は自動拡張可能です。結果が0以外の場合、『Oracle Database管理者ガイド』を参照して、表領域を自動拡張可能にしてください。

アーカイブ・ロギングの設定要件

インストールとアップグレード

(推奨)データの連続性が重要となる環境では、動作保証済の既存のOracle Database内で、アーカイブ・ロギングが有効になっていることを確認します。

これを手動で確認するには、次のコマンドをSYSロールで実行します。

select log_mode from v$database;

問合せ結果はARCHIVELOGである必要があります。

表領域関連のハード・ディスク領域の要件

インストール

次の表領域に200MB以上のハード・ディスク領域を割り当てていることを確認します。

- 管理表領域(mgmt.dbf)

- 構成データ表領域(mgmt_ecm_depot1.dbf)

- JVM診断データ表領域(mgmt_deepdive.dbf)

また、表領域データファイルに対して自動拡張機能を常に有効にしておくことをお薦めします。

モニター対象のターゲット数が増えれば、ストレージ・デバイスに対する入出力パフォーマンスの需要も増加し、領域要件も大きくなることに注意してください。

既存の管理リポジトリ

アップグレード

管理リポジトリを格納する動作保証済の既存のOracle Databaseにすでに管理リポジトリが構成済であること、およびその管理リポジトリがOracle Management Service 13cリリース3 (13.3)と互換性があることを確認します。

データベース・パーティション化の要件

インストールとアップグレード

動作保証済の既存のOracle Databaseで「パーティション化」オプションが有効になっていることを確認します(したがって、Oracle Database Enterprise Editionへのインストールを確認します。)Enterprise Managerリポジトリへのインストールと、「パーティション化」オプションの使用は、Enterprise Managerのみで使用する場合は追加の費用はかかりません。

これを手動で確認するには、SYSDBAとしてデータベースへ接続し、次の問合せを実行します。

select value from v$option where parameter = 'Partitioning';

この問合せの結果はVALUE=TRUEになるはずです。管理リポジトリを格納するデータベースには、追加のパーティション化ライセンスは必要ありません。

データベースのパーティション・メンテナンス要件

アップグレード

パーティションがデータベースに作成されていることを確認します。

アップグレードするEnterprise Managerシステムが長期間にわたり停止していた場合、管理リポジトリを格納する既存の動作保証済Oracleデータベースには、新規データをロードするためのパーティションは作成されません。したがって、そのような状況のときには、次の手順に従って、パーティションを手動で作成します。

  1. SYSMANとしてデータベースにサイン・インし、次のコマンドを実行します。

    execute emd_maintenance.analyze_emd_schema('SYSMAN'); commit;

  2. OracleホームからOMSを再起動します。

    $<ORACLE_HOME>/bin/emctl start oms

データベースおよびリスナー・ステータスの要件

インストール

動作保証済の既存のOracle Databaseおよびそのリスナーが実行されていることを確認します。

有効なオブジェクトの要件

インストール、アップグレード、前提条件チェック後

動作保証済の既存のOracle Database内に有効なSYSMANおよびSYSオブジェクトのみが存在していることを確認します。

  • 手動で、正当なSYSMANオブジェクトのみがあることを確認するには、データベースにSYSとしてサイン・インし、次のコマンドを実行します。

    select object_name, object_type from all_objects where owner='SYSMAN' and status <> 'VALID';

    このコマンドは0行を戻す必要があります。1行以上を戻す場合は、無効なオブジェクトが存在しているので、有効にするには、SYSMANとして次のコマンドを実行します。

    @admin_recompile_invalid.sql SYSMAN

    このコマンドを再度実行し、すべてのSYSMANオブジェクトが有効であることを確認します。無効なSYSMANオブジェクトが依然としてある場合、Oracleサポート・サービスに連絡してください。

    注意: admin_recompile_invalid.sqlスクリプトは、OMSホームのOracleホームの次の場所にあります。

    <ORACLE_HOME>/sysman/admin/emdrep/sql/core/latest/admin

  • 手動で、正当なSYSオブジェクトのみがあることを確認するには、データベースにSYSとしてサイン・インし、次のコマンドを実行します。

    select object_name, object_type from all_objects where status<>'VALID' and object_name like 'DBMS%';

    このコマンドは0行を戻す必要があります。ただし、1つ以上の行が返される場合はいくつかの無効なオブジェクトがあり、それらを有効にするには次のコマンドを実行して再コンパイルします。

    alter <object type> <object name> compile;

    たとえば、object_typeがmypackageで、object_nameがfooの場合は、次のコマンドを実行します。

    alter mypackage foo compile;

    このコマンドを再度実行し、すべてのパッケージが有効であることを確認します。無効なパッケージが依然としてある場合、Oracleサポート・サービスに連絡してください。

DBMSジョブおよびDBMSスケジューラ・ステータス要件

インストールとアップグレード

動作保証済の既存のOracle Database内でDBMSジョブおよびDBMSスケジューラが停止していることを確認します。

手動でジョブおよびスケジューラを停止するには、SYSとしてデータベースにサイン・インします。

  1. 次のコマンドを実行して、job_queue_processesの値を書き留めます。

    select a.instance_name as sid, b.value as jobqueue from gv$instance a, gv$parameter b where a.inst_id = b.inst_id and b.name='job_queue_processes';

  2. 次のコマンドを実行して、DBMS JOBSとDBMSスケジューラを停止します。

    execute sysman.emd_maintenance.remove_em_dbms_jobs;
alter system set job_queue_processes=0 SID='*';
commit;

    注意:

    このコマンドでは現在実行中のジョブを終了できますが、新しいジョブを開始できません。

  3. 次を実行して、アクティブなジョブがないことを確認します。

    select l.id2 job, l.sid, to_char(last_date, 'DD-MON-YYYY:HH24.MI.SS') last_date, to_char(this_date, 'DD-MON-YYYY:HH24.MI.SS') this_date, l.inst_id instance from sys.job$ j, gv$lock l where l.type = 'JQ' and j.job (+) = l.id2 order by 5, 4;

統計の採取ジョブのステータス要件

インストールとアップグレード

動作保証済の既存のOracle Database内で実行されている「統計の収集」ジョブを停止する必要があります。

手動でジョブを停止するには、データベースにSYSとしてサイン・インし、次のコマンドを実行します。

Oracle Database 10g (10.2.0.4)以上の場合:

dbms_scheduler.disable('GATHER_STATS_JOB',TRUE)を実行;

dbms_scheduler.stop_job('GATHER_STATS_JOB',TRUE)を実行;

Oracle Database 11g (11.1.0.7)以上の場合:

dbms_auto_task_admin.disable('auto optimizer stats collection',null,null)を実行;

ユーザー権限要件

アップグレード

SYSMANユーザーとDBSNMPユーザーに、動作保証済の既存のOracle Database内のDBMS_RANDOMパッケージにアクセスするためのEXECUTE権限があることを確認します。

ユーザーにEXECUTE権限があるかどうかを手動で確認するには、次の問合せを実行します。SYSMANユーザーに対してこの問合せを実行する場合、<user_account_name>はSYSMAN、DBSNMPユーザーに対して問合せを実行する場合、<user_account_name>はDBSNMPとする必要があります。

SQL> CONNECT AS SYS;
SQL> SELECT grantee, grantor, owner, table_name
FROM DBA_TAB_PRIVS
WHERE table_name = 'DBMS_RANDOM'
AND privilege = 'EXECUTE'
AND grantee IN
(
SELECT DISTINCT granted_role
FROM DBA_ROLE_PRIVS
START WITH grantee = '<user_account_name>'
CONNECT BY PRIOR granted_role=grantee
UNION ALL
SELECT '<user_account_name>'
FROM dual
WHERE ROWNUM = 1
UNION ALL
SELECT 'PUBLIC'
FROM dual
WHERE ROWNUM = 1
)

ユーザーにEXECUTE権限がない場合、次のコマンドを実行して権限をユーザーに付与します。SYSMANユーザーに権限を付与するためにこのコマンドを実行する場合、<user_account_name>はSYSMAN、DBSNMPユーザーに対してコマンドを実行する場合、<user_account_name>はDBSNMPとする必要があります。

SQL> GRANT EXECUTE ON DBMS_RANDOM TO <user_account_name>;

環境変数の設定要件

インストール

環境変数ORACLE_HOMEが、OMSのOracleホームに設定されていることを確認します。

たとえば、Cshellシェルで、次のように設定します。

setenv ORACLE_HOME /u01/software/em13c/oraclehome

たとえば、bashシェルで、次のように設定します。

export ORACLE_HOME= /u01/software/em13c/oraclehome

SUDO構成の要件

インストール

環境内にSUDOを構成する必要があります。SUDOを構成できない場合、またはSUDOを構成せずにコア・コンポーネント(OMSまたは管理エージェント)をすでにアップグレード済の場合、My Oracle Supportのノート789363.1で説明されている対処方法に従ってください。

ユーザー定義メトリック・スクリプト定義の要件

アップグレード

アップグレードする管理エージェントのOracleホーム内にユーザー定義メトリック・スクリプトがある場合は、そのすべてのスクリプトをOracleホーム外の別のディレクトリに手動でコピーできているか確認し、スクリプトの新しい場所を反映するようにユーザー定義のメトリック定義を更新する必要があります。

これは、管理エージェントがアップグレードされた後、ユーザー定義メトリック・スクリプトは新しいOracleホームに自動的にコピーされないためです。

TEMP表領域グループ要件

アップグレード/インストール

TEMPという表領域グループ名が存在していないことを確認します。存在する場合は、Enterprise Managerをインストールまたはアップグレードする前に別の名前に変更します。インストールまたはアップグレードの完了後に、いつでも元の名前に戻すことができます。

これを手動で確認するには、SYSユーザーとしてデータベースにサイン・インし、次の問合せを実行します。

select count(*) group_name from DBA_TABLESPACE_GROUPS where UPPER(group_name)='TEMP'

前述の問合せの結果は0でない必要があります。

SYSMAN_OPSSアカウント・ステータス要件

アップグレード

SYSMAN_OPSSアカウントがロックされていないことを確認します。

これを手動で確認するには、SYSユーザーとしてデータベースにサイン・インし、次の問合せを実行します。

select account_status from dba_users where username='SYSMAN_OPSS'

SYSMAN_OPSSアカウント・ステータスが「ロック解除」および「有効」である必要があります。

グローバル名要件

アップグレード(2システム・アップグレードのみ)

古いデータベースと新しいデータベースのグローバル名が同じでないことを確認します。

これを手動で確認するには、SYSユーザーとしてデータベースにサイン・インし、次の問合せを実行します。

select count(1) from global_name where global_name=(select property_value from SYSMAN.pre_upgc_master_info where upper(property_name)=upper('oldReposGlobalName') and rownum=1) and exists (select 1 from ${EM_REPOS_USER}.pre_upgc_master_info where upper(property_name)=upper('upgrade_type') and upper(property_value) =upper('TWO_SYSTEM')) and exists (select 1 from SYSMAN.pre_upgc_master_info where upper(property_name)=upper('oldReposGlobalNames') and rownum=1 and upper(property_value)='TRUE')

前述の問合せの結果は0である必要があります。そうでない場合、このリポジトリ/Enterprise Managerはアップグレード後に存在しなくなるため、古いリポジトリ内のグローバル名を一時的な名前に変更します。または、新しいリポジトリのGLOBAL_NAMEを変更します。

データベース・エディション要件

インストール

Oracle Enterprise Databaseエディションを使用してEnterprise Managerをインストールしていることを確認します。

これを手動で確認するには、SYSユーザーとしてデータベースにサイン・インし、次の問合せを実行します。

select count(1) from PRODUCT_COMPONENT_VERSION where PRODUCT like '%Oracle Database%' and instr(PRODUCT,'Enterprise Edition')>0

前述の問合せの結果は0でない必要があります。

既存のデータベースのschema_version_registry表に以前のEnterprise Managerの詳細がない

インストール

既存のデータベースのschema_version_registry表に、以前のEnterprise Managerの詳細がないことを確認します。

これを手動で確認するには、SYSユーザーとしてデータベースにサイン・インし、次の問合せを実行します。

select count(1) from SCHEMA_VERSION_REGISTRY where comp_name in ('Authorization Policy Manager','Metadata Services','Oracle Platform Security Services')

前述の問合せの結果が0でない場合は、次の問合せを使用してSCHEMA_VERSION_REGISTRYからエントリを削除します。

Delete from SCHEMA_VERSION_REGISTRY where comp_name in ('Authorization Policy Manager','Metadata Services','Oracle Platform Security Services'); commit;

既存のデータベースに以前のEnterprise Managerの表領域がない

インストール

動作保証済の既存のOracle Databaseに、以前のEnterprise Managerの表領域がないことを確認します。

データベースにそのような表領域があるかを手動で確認するには、次の問合せを実行します。

select count(1) from dba_tablespaces where TABLESPACE_NAME in ('MGMT_ECM_DEPOT_TS','MGMT_TABLESPACE','MGMT_AD4J_TS')

前述の問合せの結果が0ではない場合はこれらの表領域を削除でき、削除しない場合は新しいEnterprise Managerで再利用されます。

既存のデータベースに、SYSMAN'、SYSMAN_MDS、MGMT_VIEW、'SYSMAN_BIP、'SYSMAN_APM、BIP、SYSMAN_OPSS、SYSMAN_ROのいずれかのEnterprise Managerリポジトリ・スキーマによって所有される表のパブリック・シノニムがない

インストール

動作保証済の既存のOracle Databaseに、次のいずれかのスキーマによって所有される表のパブリック・シノニムがないことを確認します。

SYSMAN'、SYSMAN_MDS、MGMT_VIEW、'SYSMAN_BIP、'SYSMAN_APM、BIP、SYSMAN_OPSSおよびSYSMAN_RO

データベースに、Enterprise Managerデータベース・スキーマによって所有されるパブリック・シノニムがあるかどうかを手動で確認するには、データベースにSYSユーザーとしてサイン・インし、次の問合せを実行します。

select count(1) from dba_synonyms where table_owner in ('SYSMAN','SYSMAN_MDS','MGMT_VIEW','SYSMAN_BIP','SYSMAN_APM','BIP','SYSMAN_OPSS','SYSMAN_RO')

この問合せの結果が0ではない場合は、データベースにパブリック・シノニムがあるので、それらを削除し、スキーマを作成したEnterprise Managerソフトウェアを削除します。手順については、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』を参照してください。

適応的なオプティマイザ機能の要件

インストール、アップグレード

optimizer_adaptive_featuresパラメータがfalseに設定されているかどうかがチェックされます。
前
前へ 		次
次へ
目次へ移動
目次 		索引へ移動
索引