A Overview of the EM Prerequisite Kit

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

• Running the EM Prerequisite Kit

• Viewing the Log Files Created by the EM Prerequisite Kit

• Repository Prerequisite Checks Run by the EM Prerequisite Kit

About EM Prerequisite Kit

The EM Prerequisite Kit is a 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 actions automatically, to the extent possible, when a prerequisite check fails.

The EM Prerequisite Kit is run internally by the Enterprise Manager Installation Wizard while installing or upgrading an Enterprise Manager system. In addition, you can run the kit yourself beforehand to ensure that your environment meets all the repository-related requirements.

Note:

If you run the EM Prerequisite Kit manually, it only displays the status but, does not perform any corrective action.

WARNING:

If you plan to use a database instance that was created with a preconfigured Management Repository using the database templates offered by Oracle, then make sure you pass the following parameter while invoking the EM Prerequisite Kit.

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

Running the EM Prerequisite Kit

Although the EM Prerequisite Kit is run internally by the Enterprise Manager Installation Wizard while installing or upgrading an Enterprise Manager system, you can choose to run the kit yourself beforehand to ensure that your environment meets all the repository-related requirements. This helps in detecting and fixing repository related issues beforehand, thus enabling a much smoother installation or upgrade experience. You can view the status of the kit on a GUI. This section describes the following ways of viewing the EM Prerequisite Kit for Fresh Install and Upgrade:

• Running the EM Prerequisite Kit on GUI

Running the EM Prerequisite Kit on GUI

Every time the EM Prerequisite Kit is run, the results of the prerequisite checks run for a particular component are displayed on the GUI. The user can view the status of each prerequisite check.

To view the status of the EM prerequisites, follow these steps:

1. Invoke the EM installer with the flag flag EMPREREQ_KIT=true.
   For example,

   ./em13300_linux64.bin EMPREREQ_KIT=true

   You can choose to view the status of the EM Prerequisite check for a:
   • Fresh Install
   • Upgrade
   For Fresh Install
   1. Select the Create a new Enterprise Manager System option.
   2. Click Next.
   3. Enter the database host name, port number, service ID, and the system password in the respective fields.
   For Upgrade
   1. Select the Upgrade an existing Enterprise Manager system option.
   2. Click Next.
   3. Enter the required passwords in the respective fields.
2. Click Execute to view the status of the EM Prerequisite Kit check.
   By default, the failed prerequisite checks are displayed.
3. Click Show All Prereqs to view the status of all the prerequisite checks.
   
   
   
4. Click the required row to view the recommendation and the correction type.

   Note:

   There are three correction types available based on failure types as follows:

   Table A-1 Correction Types

   Correction Type	Description
   Not Required	It is a warning message and you can ignore it and move ahead.
   Manual	It is an error message and you must manually fix it before moving ahead.
   Auto	It is an error message and you can ignore it since EM has predefined corrective actions to fix it.

   Note:

   EM Prerequisite Kit is not supported in silent mode.

Viewing the Log Files Created by the EM Prerequisite Kit

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

Table A-2 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	Contains only the error and stacktrace of the exceptions occurred
emprereqkit.out	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.
<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. The repository.log is present in the <log location>/componentLog directory. For example, $OraInventory/logs/emdbprereqs/LATEST/componentLog/repository.log

Table A-3 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.out file. For emprereqkit.out file, see the note after the table.

Table A-3 EM Prerequisite Kit Log File Locations

invocation Type	Latest Log File Location(1)	Log File Location(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	<ORACLE_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 <ORACLE_HOME>/.gcinstall_temp/emprereq/LATEST	<ORACLE_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 <ORACLE_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.out 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.out is stored in <ORACLE_HOME>/.gcinstall_temp/log/<time-stamp>. And the latest log file is stored in <ORACLE_HOME>/.gcinstall_temp/log/<LATEST>.

Repository Prerequisite Checks Run by the EM Prerequisite Kit

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

Table A-4 Repository Prerequisites

Prerequisite	Applies to Install/Upgrade	Description
Basic Policy Requirements	Upgrade	Ensures that valid policy exists for MGMT_TARGETS. To manually verify this, 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	Ensures that there are no background DBMS jobs currently running in the Repository Database. To manually verify this, 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	Ensures that the GVM Performance Metric Collection job is stopped and deleted. To manually 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	Ensures 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 manually verify this, 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	Ensures 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 manually verify this, 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	Ensures 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	Set the current availability index to EM_CURRENT_AVAILABILITY_PK.
My Oracle Support User Name Size Requirements	Upgrade	Ensures 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	Ensures that the ARU user name is not longer than 239 characters. If it is, you cannot upgrade.
DBMS Package Requirements	Install, Upgrade	Ensures that you compile the required DBMS packages. To manually compile the packages, sign 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	Ensures that the snapshot logs are deleted from the tables.
Connector Configuration Table Requirements	Upgrade	Ensures 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	Ensures 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	Ensures that Primary Key and Foreign keys are not disabled. To manually verify this, 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	Ensures that queues are enabled in the Repository Database. To manually verify this, 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	Ensures that all the triggers in the Repository Database are not disabled. To manually verify this, 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	Ensures that the SYSTEM tablespace has at least one datafile set to autoextensible. To manually verify this, 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	Ensures that the emkey is copied to the repository. To manually verify this, 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	Ensures that EM_USER_CONTEXT is present in the repository. To manually verify this, 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	Ensures that there are no abnormal conditions stored in the Audit Master Table. To manually verify this, 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	Ensures that EXEMPT ACCESS POLICY is not granted directly to SYSMAN or indirectly grants to a role that is granted to SYSMAN. To manually verify this, 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	Ensures 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 manually verify this, 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: Bring down all the OMS instances. Bring down the database cleanly. Modify the max_enabled_roles parameter in the init.ora or whichever is used by the database's initialization process. Bring up the database cleanly. Verify with v$parameter to ensure the parameter value is indeed increased.
PAF execution requirements	Upgrade	Ensures that no PAF executions are scheduled or running. To manually verify this, run the following query, and note down the GUID of the running or scheduled deployment procedures. 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) To manually stop the running or scheduled deployment procedures, run the following query, and pass the GUID you noted down from the output of the preceding command: emcli stop_instance -instance=<instance id from sql query>
Secured Agent requirements	Upgrade	Ensures 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	Ensures that pre-upgrade patch is applied. To manually verify this, 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	Ensures that global stale percentage is in between 5 and 25. To manually verify this, 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	Ensures that SYSMAN, MGMT_VIEW and ORACLE_OCM accounts are not locked or expired. To manually verify this, 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	Ensures that SYSMAN schema is present for upgrade. To manually verify this, 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	Ensures that the size of the log file is equal or greater than following the values defined for different installation types and deployment options: Simple Installation: 300 MB or greater. Advanced Installation: - Small: 300 MB or greater - Medium: 600 MB or greater - Large: 1000 MB or greater To manually verify this, run the following query: select min(bytes) from v$log
Existing Database Not to Be in QUIESCE Mode	Install and Upgrade	Ensures that existing, certified Oracle Database is not in QUIESCE mode. To manually 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 SYSMAN and SYSMAN_MDS Schema	Fresh Install	Ensures that your existing, certified Oracle Database does NOT have the Enterprise Manager SYSMAN schema and the Metadata (MDS) schema already configured. These schemas can exist if you had configured the database for another Enterprise Manager installation in the past, and if you are now trying to reuse the same database for a new installation. To manually verify if the schemas are present and to drop them, 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. In this case, drop the schemas and deinstall the Enterprise Manager software that had created these schemas. For instructions, see the Oracle Enterprise Manager Advanced Installation and Configuration Guide.
Database Initialization Parameters Requirements	Install and Upgrade except db_block_size which applies only to install.	Ensures that you have correctly set the database initialization parameters. Note: While installing Cloud Control, the repository database db_block_size should be set to 8192. For information about the database initialization parameters to be set for various deployment sizes, see the Oracle Enterprise Manager Advanced Installation and Configuration Guide.
Fine-Grained Access Control Requirements	Upgrade	Ensures 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 manually verify this, run the following command: select value from v$option where parameter = 'Fine-grained access control';
UNDO Tablespace Size Requirements	Install and Upgrade	Ensures that the UNDO tablespace has a minimum space of 200 MB. To manually 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	Ensures that the UNDO tablespace and the TEMP tablespace are autoextensible in the existing, certified Oracle Database. To manually 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 to make the tablespace autoextensible.
Archive Logging Settings Requirements	Install and Upgrade	(Recommended) Ensures that you turn on archive logging in the existing, certified Oracle Database for any environment where continuity of data is important. To manually 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	Ensures 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_deepdive.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	Ensures 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 13c Release 3 (13.3).
Database Partitioning Requirements	Install and Upgrade	Ensures 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 manually 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	Checks if the partitions have been created in the database. 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, to manually create the partitions, follow these steps: Sign in to the database as SYSMAN and run the following command: execute emd_maintenance.analyze_emd_schema('SYSMAN'); commit; Restart the OMS from its Oracle home: $<ORACLE_HOME>/bin/emctl start oms
Database and Listener Status Requirements	Install	Ensures that the existing, certified Oracle Database and its listener are running.
Valid Objects Requirements	Install, Upgrade, and Post requisite	Ensures that you do have only valid SYSMAN and SYS objects in the existing, certified Oracle Database. To manually verify whether there are only valid SYSMAN objects, sign 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 home: <ORACLE_HOME>/sysman/admin/emdrep/sql/core/latest/admin To manually verify whether there are only valid SYS objects, sign 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	Ensures that you stop the DBMS Jobs and the DBMS Scheduler in the existing, certified Oracle Database. To manually stop the jobs and the scheduler, sign in to the database as SYS: 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'; The value of job_queue_processes should be equal or greater than 20. If that's not the case, Oracle recommends to set the value to '20' after the installation process is completed. Stop the DBMS JOBS and DBMS scheduler by running the following command: execute sysman.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. 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	Ensures that you stop the Gather Statistics job that is running in the existing, certified Oracle Database. To manually stop the job, sign 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	Ensures that SYSMAN and DBSNMP users have EXECUTE privileges to access the DBMS_RANDOM package in the existing, certified Oracle Database. To manually 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	Ensures 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 /u01/software/em13c/oraclehome For example, in bash shell, set it in the following way: export ORACLE_HOME= /u01/software/em13c/oraclehome
SUDO Configuration Requirements	Install	Ensures 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	If you have any user-defined metric scripts in the Oracle home of a Management Agent that you are upgrading, then checks if you have manually copied all those scripts to another directory outside any Oracle home, and then updated 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	Ensures 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 manually verify this, sign 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	Ensures that SYSMAN_OPSS account is not locked. To manually verify this, sign 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)	Ensures that Global names of old and new database are not same. To manually verify this, sign 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	Ensures that you are using Oracle Enterprise Database edition to install Enterprise Manager. To manually verify this, sign 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	Ensures that existing database does not have previous Enterprise Manager's details in schema_version_registry table. To manually verify this, sign 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','OracleBI and EPM','Service Table');
Existing database Not to have tablespaces of previous Enterprise Manager	Install	Ensures that your existing, certified Oracle Database does not have tablespaces of previous Enterprise Manager. To manually verify if the database contains such table spaces, run the following query: 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 reuse 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	Ensures 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 To manually verify whether your database has the public synonyms owned by Enterprise Manager database schemas, sign 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 and de-install the Enterprise Manager software that had created these schemas. For instructions, see the Oracle Enterprise Manager Advanced Installation and Configuration Guide.
Optimizer Adaptive Feature Requirements	Install, Upgrade	Checks whether the optimizer_adaptive_features parameter is set to false.