Skip Headers
Oracle® Enterprise Manager Cloud Control Basic Installation Guide
12c Release 2 (12.1.0.2)
E22624-20
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

A Overview of EM Prerequisite Kit Utility

This appendix describes the Enterprise Manager Prerequisite Kit utility (EM Prerequisite Kit) that the installation wizard runs every time it installs or upgrades your Enterprise Manager. In particular, this appendix covers the following:

About EM Prerequisite Kit

The EM Prerequisite Kit is a command line utility that runs repository-related prerequisite checks in your environment to ensure that you meet all the repository requirements for installing or upgrading an Enterprise Manager system.

The kit not only runs the prerequisite checks but also takes corrective action automatically, to the extent possible, when a prerequisite check fails. The kit also takes postrequisite steps to revert the corrective actions taken and ensure that the system is back to how it was before installing or upgrading the Enterprise Manager system.

The EM Prerequisite Kit is run internally by the Enterprise Manager Installation Wizard while installing or upgrading an Enterprise Manager system.


Note:

You can download the latest version of EM Prerequisite Kit from the Self Update framework as follows:
  1. In Cloud Control, from the Setup menu, select Extensibility, and then select Self Update.

  2. On the Self Update page, download the new version of XMLs under the entity EM Deployment Prerequisite Resources Updates, if there are any available.

Once you download and apply these updates, you cannot rollback to the previous version of XMLs.


Running the EM Prerequisite Kit

The EM Prerequisite Kit is run internally by the Enterprise Manager Installation Wizard while installing or upgrading an Enterprise Manager system. However, if any of the repository prerequisite checks fail for some reason, you can manually run them by invoking this kit.

The EM Prerequisite Kit is available in the following location of the software kit (DVD, downloaded software):

install/requisites/bin/emprereqkit


Note:

Ensure that the user running the EM Prerequisite Kit has write permission to the central inventory.

To run the EM Prerequisite Kit, do one of the following:


Note:

To learn about the other arguments that can be passed with the kit, see Running the EM Prerequisite Kit with Additional Arguments.

Once the Enterprise Manager system is installed or upgraded, the EM Prerequisite Kit and all the other files and directories present in the install/requisites/ directory of the software kit (DVD, downloaded software) are copied to the following location in the OMS home. So, in future, if you decide to install any plug-ins, then before installing them, ensure that you invoke the EM Prerequisite Kit from this location.

$<OMS_HOME>/install/requisites/bin/emprereqkit


Note:

The default XML files related to the prerequisite checks, which are stored in the install/requisites/list directory on the software kit (DVD, downloaded software), are current at the time of the release of the product. However, after the release of the product, if a new prerequisite check is introduced or if an existing prerequisite check is updated, then you must do one of the following:
  • Enable the Self Update functionality within Enterprise Manager Cloud Control so that the new or updated prerequisite XML files are automatically downloaded to the $<OMS_HOME>/install/requisites/list directory.

  • Manually download the new or updated prerequisite XML files from Oracle store to the $<OMS_HOME>/install/requisites/list directory.


Running the EM Prerequisite Kit with Additional Arguments

Table A-1 describes the additional arguments you can pass while invoking the EM Prerequisite Kit:

Table A-1 Arguments Supported by EM Prerequisite Kit

Option Optional or Mandatory Value Required? Example Description

-configurationType

Mandatory

Yes

$<OMS_HOME>/install/requisites/bin/emprereqkit -executionType install -prerequisiteXMLLoc <prereq_xml_location> -connectString <connect_string> -dbUser SYS -dbPassword <db_password> -dbRole sysdba -runPrerequisites -configurationType <configuration type ex: SMALL/MEDIUM/LARGE>

Enables performing prerequisite checks for different repository configurations.

-executionType

Mandatory

Yes

-executionType upgrade

Specify the type of execution, which can be one of the following:

  • install

  • upgrade

  • postrequisite

-prerequisiteXMLLoc or prerequisiteXMLRootDir

Mandatory

Yes

-prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list

Specify the absolute path to the location where the XML files related to the prerequisites are present. If you do not specify a location, the default location is ../list/.

  • -connectString <connectstring>

  • -dbHost <hostname> -dbPort <port> -dbSid <sid>

One of these options is mandatory

Yes

For example (connect string):

-connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=15044)))(CONNECT_DATA=(SID=dbview)))"

For example (database details):

-dbHost example.com -dbPort 15044 -dbSid dbview

Specify the database details.

-dbUser

Mandatory

Even if you do not pass this option, you will be prompted to provide a value

Yes

-dbUser SYS

Specify SYS.

-dbPassword

Mandatory

Even if you do not pass this option, you will be prompted to provide a value

Yes

-dbPassword welcome1

Specify the database password.

-dbRole

Mandatory

Even if you do not pass this option, you will be prompted to provide a value

Yes

-dbRole sysdba

Specify sysdba.

-prereqResultLoc

Optional

Yes

-prereqResultLoc /scratch/results

Specify the absolute path to a directory where the results (in the form of XML files) of the prerequisite checks can be stored.

If you do not pass this option, the results are stored in a default location which is the current directory.

Note: If you specify details for a different database before completing all the actions, you will need to specify a different -prereqResultLoc.

-showPrereqs

Optional

No

Example using dhHost, dbPort, and dbSid is:

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -dbHost  example.com -dbPort 15044 -dbSid sv902 -dbUser SYS  -dbPassword example_passwd -dbRole sysdba -showPrereqs

Example using connectString is:

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -connectString  "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=15044)))(CONNECT_DATA=(SID=sv902)))"  -dbUser SYS -dbPassword example_passwd -dbRole sysdba -showPrereqs

Lists the prerequisite checks to be run.

  • -runPrerequisites

  • -showCorrectiveActions

  • -runCorrectiveActions

  • -showPostCorrectiveActions

  • -runPostCorrectiveActions

One of these options is mandatory.

No

An example for -runPrerequisites:

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -dbHost  example.com -dbPort 15044 -dbSid sv902 -dbUser SYS  -dbPassword example_passwd -dbRole sysdba -runPrerequisites

An example for -showCorrectiveActions:

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -dbHost  example.com -dbPort 15044 -dbSid sv902 -dbUser SYS  -dbPassword example_passwd -dbRole sysdba -showCorrectiveActions

Example for -runCorrectiveActions:

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -dbHost  example.com -dbPort 15044 -dbSid sv902 -dbUser SYS  -dbPassword example_passwd -dbRole sysdba -runCorrectiveActions

Example for -showPostCorrectiveActions:

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -dbHost  example.com -dbPort 15044 -dbSid sv902 -dbUser SYS  -dbPassword example_passwd -dbRole sysdba -showPostCorrectiveActions

Example for -runPostCorrectiveActions

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade  -dbHost  example.com -dbPort 15044 -dbSid sv902 -dbUser SYS  -dbPassword example_passwd -dbRole sysdba -runPostCorrectiveActions
  • Runs the prerequisite checks and lists the ones that passed and failed.

  • Lists the corrective actions that will be taken for the failed prerequisite checks.

  • Takes corrective actions for the failed prerequisite checks.

  • Lists the post-corrective actions that will be taken for the prerequisite checks for which corrective actions were taken.

  • Takes post-corrective actions for the prerequisite checks for which corrective actions were taken. In other words, reverts to values that existed before corrective actions were taken.

Important: If you passed -prereqResultLoc with -runPrerequisites, then pass -prereqResultLoc with the following options also, and specify the same custom location:

-showCorrectiveActions

-runCorrectiveActions

-showPostCorrectiveActions

-runPostCorrectiveActions

Note: Show actions must be independent, that is, they should not be combined with any other action.

-logLoc

Optional

Yes

-logLoc /scratch/logs

Specify the absolute path to a directory where the logs of the execution of the EM Prerequisite Kit utility can be stored. The default location is <prereqResultloc>/prerequisiteResults/log.

-runOnlyFor

Optional

Yes

-runOnlyFor "repository|11.2.0.43"

Specify the components that must be selected instead of the XML files for checking the prerequisites.

{comp1|<version1>, comp2|<version2>}]

If there are two prerequisite XML files with the same component name, then the <version*> is used to select the correct one. This option is particularly useful when running the prerequisites for installing plug-ins.

-responseFile

Optional

Yes

-responseFile /scratch/response.rsp

Specify the absolute path to a location where the response file is available.

-contextName

Optional

Yes

-contextName 11.2.0.1

Specify a unique name for this run. If you do not specify this, a default name with the format executionType_timestamp is created.

-componentVariables

Optional

Yes

-componentVariables global:EM_REPOS_USER:sysman

Specify the name and value of the component variable in the following format:

component_name:variable_name:variable_value

For example:

global:EM_REPOS_USER:sysman

You can pass as many component variables as you want, but ensure that you separate them by a comma.

For example:

global:EM_REPOS_USER:sysman,repository:DB_VERSION:10.2.0.5.0

-logInDB

Optional

Yes

-logInDB false

Defaults to true and stores the result XMLs in the database. If you do not want to store them in the database, pass this option and specify false.

-stopExecOnFirstError

Optional

No

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -dbHost example.com -dbPort 15044 -dbSid sv902 -dbUser SYS -dbPassword example_passwd -dbRole sysdba -runPrerequisites -stopExecOnFirstError

Stops the utility the first time it encounters an error, and does not run the remaining prerequisites.

Note: This action must be executed in combination with runPrerequisites.

-list

Optional

Must be passed independently while invoking the utility

No

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -dbHost example.com -dbPort 15044 -dbSid sv902 -dbUser SYS -dbPassword example_passwd -dbRole sysdba -list

Organizes and lists the prerequisite check results (stored in the database) based on when it was run and the context.

-export

Optional

Must be passed independently while invoking the utility

No

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -dbHost example.com -dbPort 15044 -dbSid sv902 -dbUser SYS -dbPassword example_passwd -dbRole sysdba -export

Copies the prerequisite check results (XML files) from the database to an external file system.

-purge

Optional

Must be passed independently while invoking the utility

No

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -dbHost example.com -dbPort 15044 -dbSid sv902 -dbUser SYS -dbPassword example_passwd -dbRole sysdba -purge

Defaults to false and retains the result XMLs in the database. If you want to delete them from the database, pass this option.

-help

Optional

No

emprereqkit -help

This option gives details of various parameters which can be passed to EM Prerequisite Kit.


Viewing Prerequisite Check Results

Every time the EM Prerequisite Kit is run, the results of the prerequisite checks run for a particular component are stored in an instance XML file. The instance XML file has the file name <component>.xml. The results are in the same format as the information stored in the prerequisite XML files. The only difference is the new column that indicates the actual result of the prerequisite check.

Table A-2 lists the instance file locations depending on how the EM Prerequisite Kit was invoked.

Table A-2 EM Prerequisite Kit Result File Location (Instance XML File)

invocation Type Instance File LocationFoot 1  Latest Instance File LocationFoot 2 

Manually Invoked

<prereqResultLoc>/resultXMLs/<time-stamp>

Note: When you provide prereqResultLoc value, the result xml location is as mentioned above. Else, the result xml location is <Current Directory>/ prerequisiteResults/resultXMLs/<time-stamp>

<prereqResultLoc>/resultXMLs/LATEST/

Note: When you provide prereqResultLoc value, the result xml location is as mentioned above. Else, the result xml location is <Current Directory>/ prerequisiteResults/resultXMLs/LATEST

Automatically Invoked by the Enterprise Manager Cloud Control Installation Wizard

<MW_HOME>/.gcinstall_temp/resultXMLs/<time-stamp>

Note: When you proceed through the installation wizard pages, EM Prerequisite Kit result XMLs are created in /tmp/OraInstall<timestamp>/emprereqkit/resultXMLs/<time-stamp>.

When install begins, the /tmp/OraInstall<timestamp>/emprereqkit/resultXMLs/<time-stamp> result xmls are copied to <MWHOME>/.gcinstall_temp/resultXMLs/<time-stamp>.

<MW_HOME>/.gcinstall_temp/resultXMLs/LATEST

Note: When you proceed through the installation wizard pages, EM Prerequisite Kit result xmls are created in /tmp/OraInstall<timestamp>/ emprereqkit/p; resultXMLs/LATEST.

When install begins, the /tmp/OraInstall<timestamp>/ emprereqkit/ resultXMLs/LATEST result xmls are copied to <MW_HOME>/.gcinstall_temp/resultXMLs/LATEST


Footnote 1 Instance File Location refers to the <time-stamp> directory that is created dynamically by the utility every time the EM Prerequisite Kit is run. The instance file created here is retained until you decide to delete it.

Footnote 2 Latest Instance File Location refers to a single, standard location maintained for the latest instance file created when the EM Prerequisite Kit was last run. The instance file created here is overwritten every time the utility is run.


Note:

The <prereqResultLoc> location refers to the location you enter for the -prereqResultLoc option while invoking the utility. If this option is not passed, then by default, the directory from where you invoke the utility is considered as the base directory, and a directory titled prerequisiteResults is dynamically created in it, and then the instance file is stored in it.

Viewing Log Files

Table A-3 lists all the log files that are created every time the EM Prerequisite Kit is run.

Table A-3 EM Prerequisite Kit Log Files

Log File Name Description

emprereqkit.log

Contains information about every step taken or action performed by the kit

emprereqkit.err.log

Contains only the error and stacktrace of the exceptions occurred

emprereqkit.output

Contains information about the status (pass or fail) of all the prerequisite checks that are run. It also contains detailed information regarding each prerequisite check.For example, prerequisite name, execution status, detailed recommendation (what queries are to be executed to correct the failed prerequisite), and so on.s

<functional_area>.log

Contains information about the function area-specific prerequisite checks that are run. For example, repository.log that contains repository-specific performance-related prerequisite checks that are run.


Table A-4 lists the log file locations depending on how the EM Prerequisite Kit was invoked. This table lists the locations for all the log files except for the emprereqkit.output file. For emprereqkit.output file, see the note after the table.

Table A-4 EM Prerequisite Kit Log File Locations

invocation Type Latest Log File LocationFoot 1  Log File LocationFoot 2 

Manually Invoked

<logLoc>/LATEST

Note: When you provide logLoc as the value, the log location is as mentioned above. Else, it is <Current Directory>/prerequisiteResults/log/LATEST

<logLoc>/<time-stamp>

Note: When you provide logLoc as the value, the log location is as mentioned above. Else, it is <Current Directory>/ prerequisiteResults/log/<time-stamp>

Automatically Invoked by the Enterprise Manager Cloud Control Installation Wizard

<MW_HOME>/.gcinstall_temp/LATEST

Note: When you proceed through the installation wizard pages, EM Prerequisite Kit logs are created in either $OraInventory/logs/emdbprereqs/LATEST or /tmp/OraInstall<timestamp>/ emdbprereqs/LATEST

When install begins, the /tmp/OraInstall<timestamp>/emprereqkit logs are copied to <MW_HOME>/.gcinstall_temp/ /emprereq/LATEST

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

Note: When you proceed through the installation wizard pages, EM Prerequisite Kit logs are created in either $OraInventory/logs/emdbprereqs/<timestamp> or /tmp/OraInstall<timestamp>/ emdbprereqs/<timestamp>

When install begins, the /tmp/OraInstall<timestamp>/ emdbprereqs/<time-stamp> logs are copied to <MW_HOME>/.gcinstall_temp/ /emprereq/<time-stamp>


Footnote 1 Latest Log File location refers to a single, standard location maintained for the latest log files created when the EM Prerequisite Kit was last run. The log files created here are overwritten every time the utility is run.

Footnote 2 Log File Location refers to the <time-stamp> directory that is created dynamically by the utility every time the EM Prerequisite Kit is run. The log file created here are retained until you decide to delete them.


Note:

When the EM Prerequisite Kit is run manually, the log file emprereqkit.output is stored in <prereqResultLoc>/log/<time-stamp>. The latest log file is stored in <prereqResultLoc>/log/LATEST/.

When the EM Prerequisite Kit is run internally by the Enterprise Manager Cloud Control Installation Wizard, the log file emprereqkit.output is stored in <MW_HOME>/.gcinstall_temp/log/<time-stamp>. And the latest log file is stored in <MW_HOME>/.gcinstall_temp/log/<LATEST>.


Repository Prerequisites

This section describes all the repository prerequisites that the EM Prerequisites Kit checks. This section also describes how to manually check these prerequisites.

Following are the repository prerequisites for upgrading Enterprise Manager.

Table A-5 Repository Prerequisites for Upgrading Enterprise Manager System

Prerequisite Applies to Install/Upgrade Automatic Description

Basic Policy Requirements

Upgrade

No

Ensure that valid policy exists for MGMT_TARGETS. To verify, run the following query:

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') )

The query must not return any rows.

Active Jobs Requirements

Upgrade

No

Ensure that there are no background DBMS jobs currently running in the Repository Database. To verify, run the following query:

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

If the result of the query is 0 then there are no active DBMS jobs, if result is not 0 then wait for the active jobs to complete.

Checks if GVM Performance collection job is running

Upgrade

Yes

Ensure that the GVM Performance Metric Collection job is stopped and deleted. To verify if a job named GVMPERFMETRICCOLL exists, run the following query:

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

If it exists, then stop and delete.

Valid Reference Requirements

Upgrade

No

Ensure that all entries for execution_id in MGMT_JOB_EXECUTION either point to a valid entry in MGMT_JOB_EXEC_SUMMARY, or are NULL.

To verify, run the following query. The query must not return any rows.

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

Job Type Uniqueness Requirements

Upgrade

No

Ensure that there are no duplicate entries in MGMT_JOB_TYPE_INFO for the following set of columns: job_type, job_type_owner, major_version, minor_version1, minor_version2.

To verify, run the following query. The query must not return any rows.

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 Plan Baseline Capture Parameter Requirements

Install, Upgrade

No

Ensure that the parameter optimizer_capture_sql_plan_baselines is set to FALSE (or default).

The SQL plan baseline capture must never be turned on for the Management Repository. Enterprise Manager heavily depends on updated CBO statistics. If stale CBO statistics exist, the SQL plan baseline capture could cause bad execution plans to be used for critical functionality.

Current Availability Index Requirements

Install, Upgrade

No

Ensure that the current availability index is renamed to the following:

  • If you are running the kit before upgrading to 12c release, then rename it to MGMT_CURRENT_AVAILABILITY_PK.

  • If you are running the kit after upgrading to 12c release, then rename it to EM_CURRENT_AVAILABILITY_PK.

My Oracle Support User Name Size Requirements

Upgrade

No

Ensure that the My Oracle Support user name is not longer than 239 characters. If it is, then you cannot upgrade.

ARU User Name Size Requirements

Upgrade

No

Ensure that the ARU user name is not longer than 239 characters. If it is, you cannot upgrade.

DBMS Package Requirements

Install, Upgrade

No

Ensure that you compile the required DBMS packages.

Log in to the database, where the Management Repository is configured, as SYS user, and run the following query to retrieve the list of invalid DBMS packages:

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

If the package is invalid, run the following query:

  • For package:

    ALTER PACKAGE <PACKAGE_NAME> COMPILE
    
  • For package body:

    ALTER PACKAGE <PACKAGE_NAME> COMPILE BODY
    

If the packages do not compile successfully, contact Oracle Support.

Snapshot Log Requirements

Upgrade

No

Ensure that the snapshot logs are deleted from the tables.

Connector Configuration Table Requirements

Upgrade

No

Ensure that there is no bad data in the connector configuration table. If there is any, then run the following query to clean the table.

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

Compatible Instance Parameter Requirements

Install, Upgrade

No

Ensure that the compatible instance parameter is set to the same version value as the database instance of the Management Repository. Any other value might result in unexpected problems, poor performance, or both.

Primary Key and Foreign Key Requirements

Upgrade

No

Ensure that Primary Key and Foreign keys are not disabled. To verify, run the following query:

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')

If the result is not 0, then use the following query to enable the constraint:

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

If the constraints cannot be enabled for any reason, contact Oracle Support.

Enable Queue Requirements

Upgrade

No

Ensure that queues are enabled in the Repository Database. To verify, run the following query:

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

If result is not 0, use the following query to retrieve the list of disabled queue names:

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%'))

Execute the following SQL statement to enable the queue:

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

If the queue cannot be started, contact Oracle Support.

Trigger Requirements

Upgrade

No

Ensure that all the triggers in the Repository Database are not disabled. To verify, run the following query:

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

If result is not 0, then enable the trigger.

SYSTEM tablespace requirement

Install and Upgrade

No

Ensure that the SYSTEM tablespace has at least one datafile set to autoextensible. To verify, run the following query:

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

If the result is 0, then add a new datafile with the autoextend attribute to the SYSTEM tablespace so it has at least one listed in the DBA_DATA_FILES view with autoextensible equal to 'YES'. Contact Oracle Support if there are any errors

emkey requirement

Upgrade

No

Ensure that the emkey is copied to the repository. To verify, run the following query:

select COUNT(*) from sysman.mgmt_repos_time_coefficient

If the result of the query is not 1, then copy the emkey.ora file from another OMS or backup machine to the ORACLE_HOME/sysman/config directory.

Configure the emkey.ora file by running emctl config emkey -copy_to_repos -sysman_pwd <sysman_pwd>.

EM_USER_CONTEXT requirements

Upgrade

No

Ensure that EM_USER_CONTEXT is present in the repository. To verify, run the following query:

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

If the query result is 0, check that the procedure SETEMUSERCONTEXT is valid by executing the following query:

select status from all_objects

where object_name='SETEMUSERCONTEXT' and owner='SYSMAN'

The above query must return 'VALID'. Then run:

alter session set current_schema='SYSMAN';

Create or replace context EM_USER_CONTEXT using SETEMUSERCONTEXT;

If the context cannot be created for any reason, contact Oracle Support.

Audit Master table requirement

Upgrade

No

Ensure that there are no abnormal conditions stored in the Audit Master Table. To verify, run the following query:

select count(*) from sysman.mgmt_audit_master

If the query result is not 1 then, contact Oracle Support to analyze the Enterprise Manager repository before attempting to perform the patch/upgrade.

Exempt Access Policy requirement

Upgrade

No

Ensure that EXEMPT ACCESS POLICY is not granted directly to SYSMAN or indirectly grants to a role that is granted to SYSMAN. To verify, run the following query:

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')

If the result of the query is not 0, then revoke EXEMPT ACCESS POLICY from SYSMAN and the roles.

For example:

revoke exempt access policy from SYSMAN

max_enabled_roles init parameter requirement

Install and Upgrade

No

Ensure that the max_enabled_roles parameter value is set such that it contains at least 3 more than the flattened roles granted to SYS. To verify, run the following query:

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;

If the result of the query is not 1 then, increase the max_enabled_roles parameter to ensure it contains at least 3 more than the flattened roles granted to SYS.

To modify max_enabled_roles, perform the following steps:

  1. Bring down all the OMS instances.

  2. Bring down the database cleanly.

  3. Modify the max_enabled_roles parameter in the init.ora or whichever is used by the database's initialization process.

  4. Bring up the database cleanly.

  5. Verify with v$parameter to ensure the parameter value is indeed increased.

PAF execution requirements

Upgrade

No

Ensure that no PAF executions are scheduled or running. To verify, run the following query:

SELECT count(1) 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)

If the query result is not 0, then abort or wait for PAF executions to complete.

Secured Agent requirements

Upgrade

No

Ensure that all the agents are secured with latest CA. To know the list of agents to be secured, run the following command:

emcli get_ca_info -details

Pre-upgrade console patch requirements

Upgrade

No

Ensure that pre-upgrade patch is applied. To verify, run the following query:

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

If the result of the query is not 1, then apply pre-upgrade Console patch before upgrading.

Global Stale percentage requirements

Install and Upgrade

No

Ensure that global stale percentage is in between 5 and 25. To verify, run the following query:

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

The query result must be 1.

Account status requirements

Upgrade

No

Ensure that SYSMAN, MGMT_VIEW and ORACLE_OCM accounts are not locked or expired. To verify, run the following queries:

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';

The query result must be OPEN.

SYSMAN schema requirements

Upgrade

No

Ensure that SYSMAN schema is present for upgrade. To verify, run the following query:

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

The query result must be 1.

Redo Log size requirement

Install and Upgrade

No

Ensure that size of the log file is 300 megabytes or greater. To verify, run the following query:

select min(bytes) from v$log

The query result must be greater or equal to 300000000 (bytes).

Existing Database Not to Be in QUIESCE Mode

Install and Upgrade

No

Ensure that existing, certified Oracle Database is not in QUIESCE mode. To verify this, run the following SQL in the database in the SYS role:

select active_state from v$instance;

The result returned must be NORMAL.

Existing Database Not to Have Database Control (only for fresh install)

Fresh Install

No

(If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or higher, which uses an Oracle Database where the Management Repository is already created, that is, where the Grid Control SYSMAN schema is already created, then ignore this prerequisite. This prerequisite applies only when you install Enterprise Manager 12c Cloud Control using an existing, certified Oracle Database that has Database Control SYSMAN schema created, which you want to replace now with Grid Control SYSMAN schema.)

Ensure that your existing, certified Oracle Database does NOT have Database Control SYSMAN schema. If it has, that is, if your existing database is configured with Database Control, then deconfigure it.

  1. Verify whether your database has Database Control SYSMAN schema.

    To do so, log in to the database as SYS user and run the following query:

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

    If the result of this query is 1, then the database has this schema, so deconfigure it.

  2. Before deconfiguring the Database Control, set the environment variable ORACLE_HOME to the Oracle home of the database, and ORACLE_SID to the SID of the database.

    For example, in bash shell, you can set them in the following way:

    export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
    export ORACLE_SID=orcl
    
  3. Deconfigure the Database Control.

    To deconfigure Database Control for a standalone database, run the following command from the Oracle home of the database as the user who installed the database. If the command hangs, then restart the database and rerun the command.

    $<ORACLE_HOME>/bin/emca -deconfig dbcontrol db -repos drop -SYS_PWD <sys pasword> -SYSMAN_PWD <sysman password>
    

    To deconfigure Database Control for a Real Application Cluster (Oracle RAC) database, run the following command from the Oracle home of the database as the user who installed the database. If the command hangs, then restart the database and rerun the command.

    $<ORACLE_HOME>/bin/emca -deconfig dbcontrol db -repos drop -cluster -SYS_PWD <sys pasword> -SYSMAN_PWD <sysman password>
    

Note: If the deconfigure operation hangs, then refer to My Oracle Support note 375946.1

Existing Database Not to Have SYSMAN and SYSMAN_MDS Schema

Fresh Install

No

(If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or higher, which uses an Oracle Database where the Management Repository is already created, that is, where the Grid Control SYSMAN schema is already created, then ignore this prerequisite. This prerequisite applies only when you install Enterprise Manager 12c Cloud Control using an existing, certified Oracle Database that has Database Control SYSMAN schema created, which you want to replace now with Grid Control SYSMAN schema.)

Ensure that your existing, certified Oracle Database does NOT have Enterprise Manager Grid Control SYSMAN schema and Metadata (MDS) schema.

  1. Verify whether your database has Enterprise Manager Grid Control SYSMAN schema and MDS schema.

    To do so, log in to the database as SYS user and run the following query:

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

    If the result of this query is 1, then the database has these schemas, so drop them.

  2. Before dropping the schema, set the environment variable LD_LIBRARY_PATH to the ORACLE_HOME/lib directory of the OMS. Also set the ORACLE_HOME to the Oracle home of the OMS.

  3. Drop the schema by running the following command from the Oracle home of the OMS.

    $<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>
    

    If you are dropping the schemas that belong to a 10g Release 2 (10.2.x.x) Management Repository, then run previous command without these arguments: -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>

    Note: For Microsoft Windows, invoke RepManager.bat. RepManager 11.1 supports -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN). RepManager 10.2.0.5 supports -action drop (drops only SYSMAN). Also, the action dropall might not drop all the repository objects. For learn more about this issue and the workaround to be used, see My Oracle Support note 1365820.1.

  4. After dropping the schema, manually delete the database files mgmt.dbf and mgmt_ecm_depot1.dbf.

    You can find these files by running the following command as SYS:

    SELECT FILE_NAME FROM DBA_DATA_FILES WHERE UPPER (TABLESPACE_NAME) LIKE 'MGMT%';
    

Database Initialization Parameters Requirements

Install and Upgrade except db_block_size which applies only to install.

No

Ensure that you have correctly set the database initialization parameters.

For information about the database initialization parameters to be set, refer to Setting Database Initialization Parameters.

Fine-Grained Access Control Requirements

Upgrade

No

Ensure that the fine-grained access control option is set to TRUE in the existing, certified Oracle Database so that the Management Repository can be created. To verify this, run the following command:

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

UNDO Tablespace Size Requirements

Install and Upgrade

No

Ensure that the UNDO tablespace has a minimum space of 200 MB. To verify this, run the following query:

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;

Note: The result of this query is in bytes.

If the minimum space is less than 200 MB, then set it to 200 MB by running the following command:

alter database datafile <location datafile> resize 200M;

UNDO Tablespace and Temporary Tablespace Settings Requirements

Install and Upgrade

No

Ensure that the UNDO tablespace and the TEMP tablespace are autoextensible in the existing, certified Oracle Database. To verify this, run the following command:

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';

If the result of the query is 0, then the tablespace is autoextensible. If the result it not 0, then refer to Oracle Database Administrator's Guide available at the following location to make the tablespace autoextensible.

http://www.oracle.com/technology/documentation/database.html

Archive Logging Settings Requirements

Install and Upgrade

No

(Recommended) Ensure that you turn on archive logging in the existing, certified Oracle Database for any environment where continuity of data is important. To verify this, run the following command in the SYS role:

select log_mode from v$database;

The result returned must be ARCHIVELOG.

Tablespace-Related Hard Disk Space Requirements

Install

No

Ensure that you allocate a minimum of 200 MB hard disk space for the following tablespaces:

- Management Tablespace (mgmt.dbf)

- Configuration Data Tablespace (mgmt_ecm_depot1.dbf)

- JVM Diagnostics Data Tablespace (mgmt_ad4j.dbf)

Oracle also recommends that you keep the auto-extend feature enabled for the tablespace data files.

Note that the space requirement increases as the number of monitored targets increase, along with the input/output performance demands on the storage devices.

Existing Management Repository

Upgrade

No

Ensure that the existing, certified Oracle Database, which houses the Management Repository, already has a Management Repository configured, and that the Management Repository is compatible with Oracle Management Service 11g Release 1 (11.1).

Database Partitioning Requirements

Install and Upgrade

No

Ensure that the existing, certified Oracle Database has the Partitioning Option enabled (therefore, ensure that you install it into Oracle Database Enterprise Edition.) Installing and using the partitioning option in the Enterprise Manager repository does not add costs to customers when used solely by Enterprise Manager.

To verify this, connect to the database as SYSDBA and run the following query:

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

The result of this query should be VALUE=TRUE. No additional partitioning license is required for the database that houses the Management Repository.

Database Partition Maintenance Requirements

Upgrade

No

If the Enterprise Manager system that you are about to upgrade was shut down for a long period of time, then you will not have partitions created in the existing, certified Oracle Database, which houses the Management Repository, to load new data. Therefore, under such circumstances, do the following:

  1. Log in to the database as SYSMAN and run the following command:

    execute emd_maintenance.analyze_emd_schema('SYSMAN');
    commit;
    
  2. Restart the OMS from its Oracle home:

    $<ORACLE_HOME>/bin/emctl start oms
    

Database and Listener Status Requirements

Install

No

Ensure that the existing, certified Oracle Database and its listener are running.

Valid Objects Requirements

Install, Upgrade, and Post requisite

No

Ensure that you do have only valid SYSMAN and SYS objects in the existing, certified Oracle Database.

  • To verify whether there are only valid SYSMAN objects, log in to the database as SYS and run the following command:

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

    The command must return 0 rows. However, if it returns one or more rows, then you have some invalid objects, and to turn them valid, run the following command as SYSMAN:

    @admin_recompile_invalid.sql SYSMAN
    

    Run this command again to ensure that all SYSMAN objects are valid. If you still have invalid SYSMAN objects, then contact Oracle Support.

    Note: The admin_recompile_invalid.sql script is in the following location of the Oracle home of the OMS:

    <ORACLE_HOME>/sysman/admin/emdrep/sql/core/latest/admin
    
  • To verify whether there are only valid SYS objects, log in to the database as SYS and run the following command:

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

    The command must return 0 rows. However, if it returns one or more rows, then you have some invalid objects, and to turn them valid, recompile them by running the following command:

    alter <object type> <object name> compile;

    For example, if the object_type is mypackage and the object_name is foo, then run the following command:

    alter mypackage foo compile;

    Run this command again to ensure that all the packages are valid. If you still have invalid packages, then contact Oracle Support.

DBMS Jobs and DBMS Scheduler Status Requirements

Install and Upgrade

Yes

Ensure that you stop the DBMS Jobs and the DBMS Scheduler in the existing, certified Oracle Database. To do so, log in to the database as SYS:

  1. Write down the value of job_queue_processes by running the following command:

    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. Stop the DBMS JOBS and DBMS scheduler by running the following command:

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

    Note: This will allow the currently running jobs to finish, but will not allow any new jobs to be started.

  3. Ensure that there are no active jobs by running the following:

    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;
    

Gather Statistics Job Status Requirements

Install and Upgrade

Yes

Ensure that you stop the Gather Statistics job that is running in the existing, certified Oracle Database. To do so, log in to the database as SYS and run the following commands:

For Oracle Database 10g (10.2.0.4) or higher:

execute dbms_scheduler.disable('GATHER_STATS_JOB',TRUE);

execute dbms_scheduler.stop_job('GATHER_STATS_JOB',TRUE);

For Oracle Database 11g (11.1.0.7) or higher:

execute dbms_auto_task_admin.disable('auto optimizer stats collection',null,null);

User Privilege Requirements

Upgrade

No

Ensure that SYSMAN and DBSNMP users have EXECUTE privileges to access the DBMS_RANDOM package in the existing, certified Oracle Database. To verify whether the users have EXECUTE privileges, run the following query. When you run this query for the SYSMAN user, the <user_account_name> must be SYSMAN, and when you run it for the DBSNMP user, the <user_account_name> must be 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
)

If these users do not have EXECUTE privileges, then grant them the privileges by running the following command. When you run this command for granting the privileges for the SYSMAN user, the <user_account_name> must be SYSMAN, and when you run it for the DBSNMP user, the <user_account_name> must be DBSNMP.

SQL> GRANT EXECUTE ON DBMS_RANDOM TO <user_account_name>;

Environment Variable Setting Requirements

Install

No

Ensure that the environment variable ORACLE_HOME is set to the Oracle home of the OMS.

For example, in Cshell, set it in the following way:

setenv ORACLE_HOME /home/OraHomes/oms10g

For example, in bash shell, set it in the following way:

export ORACLE_HOME= /home/OraHomes/oms10g

SUDO Configuration Requirements

Install

No

Ensure that you configure SUDO in your environment. If you are unable to do so or if you have already upgraded any of the core components (OMS or Management Agent) without configuring SUDO, then follow the workaround described in My Oracle Support note 789363.1.

User-Defined Metric Script Definition Requirement

Upgrade

No

If you have any user-defined metric scripts in the Oracle home of a Management Agent that you are upgrading, then ensure that you manually copy all those scripts to another directory outside any Oracle home, and then update the user-defined metric definitions to reflect the new script location.

This is because, after the Management Agent is upgraded, the user-defined metric scripts are not automatically copied to the new Oracle home.

TEMP Tablespace Group requirement

Upgrade/Install

No

Ensure that there is no tablespace group name called TEMP already existing. If it does, then ensure that you rename it to a different name before installing or upgrade Enterprise Manager. You can always revert to the original name after you finish installing or upgrading.

To verify this, log in to the database as SYS user, and run the following query:

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

The result of the above query should not be 0.

SYSMAN_OPSS account status requirement

Upgrade

No

Ensure that SYSMAN_OPSS account is not locked.

To verify this, log in to the database as SYS user and run the following query:

select account_status from dba_users where username='SYSMAN_OPSS'

SYSMAN_OPSS account status should be unlocked and unexpired

Global Name requirement

Upgrade(2-system upgrade only)

No

Ensure that Global names of old and new database are not same.

To verify this, log in to the database as SYS user and run the following query:

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')

The result of the above query should be 0, if not then change global-names in old repository to a temporary name as this repository/Enterprise Manager would cease to exist after upgrade; or change GLOBAL_NAME of new repository.

Database Edition Requirements

Install

No

Ensure that you are using Oracle Enterprise Database edition to install Enterprise Manager.

To verify this, log in to the database as SYS user and run the following query:

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

The result of the above query should not be 0.

Existing database not to have previous Enterprise Manager's details in schema_version_registry table

Install

No

Ensure that existing database does not have previous Enterprise Manager's details in schema_version_registry table.

To verify this, log in to the database as SYS user and run the following query:

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

If the result of the above query is not 0 then delete the entries from SCHEMA_VERSION_REGISTRY using the following query:

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

Existing Database Not to Have any Enterprise Manager Repository schemas

Install

No

Ensure that your existing, certified Oracle Database does not have Enterprise Manager Repository schemas:

  1. Verify whether your database has Enterprise Manager Repository schemas.

    To do so, log in to the database as SYS user and run the following query:

    SELECT COUNT(*) FROM ALL_USERS WHERE USERNAME IN ('SYSMAN', 'SYSMAN_MDS', 'MGMT_VIEW', 'SYSMAN_BIP','SYSMAN_APM','BIP', 'SYSMAN_OPSS', 'SYSMAN_RO');
    

    If the result of this query is not 0, then the database has these schemas, so drop them.

  2. Before dropping the schema, set the environment variable LD_LIBRARY_PATH to the ORACLE_HOME/lib directory of the OMS. Also set the ORACLE_HOME to the Oracle home of the OMS.

  3. Drop the schema by running the following command from the Oracle home of the OMS.

    $<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>
    

    If you are dropping the schemas that belong to a 10g Release 2 (10.2.x.x) Management Repository, then run previous command without these arguments: -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>

    Note: For Microsoft Windows, invoke RepManager.bat. RepManager 11.1 supports -action dropall.

  4. After dropping the schema, manually delete the database files mgmt.dbf and mgmt_ecm_depot1.dbf.

    You can find these files by running the following command as SYS:

    SELECT FILE_NAME FROM DBA_DATA_FILES WHERE UPPER (TABLESPACE_NAME) LIKE 'MGMT%'
    

Existing database Not to have tablespaces of previous Enterprise Manager

Install

No

Ensure that your existing, certified Oracle Database does not have tablespaces of previous Enterprise Manager.

Following query can be used to verify if the database contains such table spaces:

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

If the result of the above query is not 0, then you can drop these table spaces otherwise new Enterprise Manager will re-use it.

Existing database not to have public synonym on the tables owned by any of the following Enterprise Manager Repository schemas: SYSMAN', SYSMAN_MDS,MGMT_VIEW,'SYSMAN_BIP,'SYSMAN_APM,BIP,SYSMAN_OPSS and SYSMAN_RO

Install

No

Ensure that your existing, certified Oracle Database does NOT have any public synonyms on the tables owned by any of the following schemas:

SYSMAN', SYSMAN_MDS,MGMT_VIEW,'SYSMAN_BIP,'SYSMAN_APM,BIP,SYSMAN_OPSS and SYSMAN_RO

  1. Verify whether your database has the public synonyms owned by Enterprise Manager database schemas. To do so, log in to the database as SYS user and run the following query:

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

    If the result of this query is not 0, then the database has these public synonyms, so drop them.

  2. Before dropping the schema, set the environment variable LD_LIBRARY_PATH to the ORACLE_HOME/lib directory of the OMS. Also set the ORACLE_HOME to the Oracle home of the OMS.

  3. Drop the schema by running the following command from the Oracle home f the OMS

    $<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>
    

    If you are dropping the schemas that belong to a 10g Release 2 (10.2.x.x) Management Repository, then run previous command without these arguments: -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>

    Note: For Microsoft Windows, invoke RepManager.bat. RepManager 11.1 supports -action dropall.


Setting Database Initialization Parameters

This section describes the following:

Setting Database Initialization Parameters for Advanced Installation

For an advanced installation, the database initialization parameters to be set for different deployment sizes (small, medium, large) are described in Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Setting Database Initialization Parameters for Simple Installation

For a simple installation, the following are the database initialization parameters to be set:

Table A-6 Database Initialization Parameters Set for Simple Installation

Parameter Value

DB_BLOCK_SIZE_VALUE

8192

PROCESSES_PARAMETER_VALUE

300

PGA_AGGREGATE_TARGET_PARAMETER_VALUE

200000000

SESSION_CACHED_CURSORS_PARAM_MIN_VALUE

200

SESSION_CACHED_CURSORS_PARAM_MAX_VALUE

500

JOB_QUEUE_PROCESSES_PARAM_INS_VALUE

20

JOB_QUEUE_PROCESSES_PARAM_UPG_VALUE

0

OPEN_CURSORS_PARAM_MIN_VALUE

300

OPEN_CURSORS_PARAM_MAX_VALUE

400

SGA_TARGET_PARAM_VALUE

800000000

LOG_BUFFER_PARAM_VALUE

1000000

SHARED_POOL_SIZE_PARAM_VALUE

300000000

DB_CACHE_SIZE_PARAM_DEFAULT_VALUE

TRUE

LARGE_POOL_SIZE_PARAM_DEFAULT_VALUE

TRUE

JAVA_POOL_SIZE_PARAM_DEFAULT_VALUE

TRUE

STREAMS_POOL_SIZE_PARAM_DEFAULT_VALUE

TRUE

TIMED_STATISTICS_PARAM_DEFAULT_VALUE

TRUE

TIMED_STATISTICS_PARAM_VALUE

TRUE

STATISTICS_LEVEL_PARAM_DEFAULT_VALUE

TRUE