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:
Viewing the Results of the Prerequisite Checks Run by the EM Prerequisite Kit
Repository Prerequisite Checks Run by the 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 actions automatically, to the extent possible, when a prerequisite check fails. The kit also takes postrequisite steps automatically 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. In addition, you can run the kit yourself beforehand to ensure that your environment meets all the repository-related requirements.
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
This section describes the following ways of 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.
This section describes how you can run the EM Prerequisite Kit for fresh installation and for upgrade.
Note:
Ensure that the user running the EM Prerequisite Kit has write permission to the central inventory. On Microsoft Windows, runsetup_em13100_win64.exe.To run the EM Prerequisite Kit, do one of the following:
To view a list of repository requirements to be met without taking any corrective actions, run the EM Prerequisite Kit as a SYS user and pass a response file that contains all the necessary arguments. To learn about the other arguments that can be passed in the response file, see Section A.2.1.3.
./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=<absolute_path_to_reponse_file>
Ensure that your response file contains the following arguments:
installerMode=emprereqkit executionType=<install|upgrade|postrequisite|plugindeploy> prerequisiteXMLRootDir=<absolute_path_to_/install/requisites/list/_directory connectString=<connect_string> dbUser=SYS dbPassword=<db_password> dbRole=sysdba reposUser=SYSMAN showPrereqs=true
For example,
./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=/u01/software/em13c/temp/emprereqkit.rsp
The following are the contents of the response file.
installerMode=emprereqkit
executionType=install
prerequisiteXMLRootDir=/net/xyz.example.com/scratch/username/view_storage/username_empreq/work/omsOracleHome/install/requisites/list
connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xyz.example.com)(PORT=15044)))(CONNECT_DATA=(SID=sv505)))
dbUser=SYS
dbPassword=password
dbRole=sysdba
reposUser=SYSMAN
showPrereqs=true
To run the prerequisite utility and also take corrective actions to meet the repository requirements, run the EM Prerequisite Kit as a SYS user in the following way. To learn about the other arguments that can be passed with the kit, see Section A.2.1.3.
Run the EM Prerequisite Kit.
./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=/u01/software/em13c/temp/emprereqkit.rsp
The following are the contents of the response file.
installerMode=emprereqkit executionType=<install|upgrade|postrequisite|plugindeploy> prerequisiteXMLRootDir=<absolute_path_to_/install/requisites/list/_directory connectString=<connect_string> dbUser=SYS dbPassword=db_password dbRole=sysdba reposUser=SYSMAN runPrerequisites=true
For example,
installerMode=emprereqkit
executionType=install
prerequisiteXMLRootDir=/net/xyz.example.com/scratch/username/view_storage/username_empreq/work/omsOracleHome/install/requisites/list
connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xyz.example.com)(PORT=15044)))(CONNECT_DATA=(SID=sv505)))
dbUser=SYS
dbPassword=password
dbRole=sysdba
reposUser=SYSMAN
runPrerequisites=true
Run the EM Prerequisite Kit to take corrective actions.
./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=/u01/software/em13c/temp/emprereqkit.rsp
The following are the contents of the response file.
installerMode=emprereqkit executionType=<install|upgrade|postrequisite|plugindeploy> prerequisiteXMLRootDir=<absolute_path_to_/install/requisites/list/_directory connectString=<connect_string> dbUser=SYS dbPassword=db_password dbRole=sysdba reposUser=SYSMAN runCorrectiveActions=true
For example,
installerMode=emprereqkit
executionType=install
prerequisiteXMLRootDir=/net/xyz.example.com/scratch/username/view_storage/username_empreq/work/omsOracleHome/install/requisites/list
connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xyz.example.com)(PORT=15044)))(CONNECT_DATA=(SID=sv505)))
dbUser=SYS
dbPassword=password
dbRole=sysdba
reposUser=SYSMAN
runCorrectiveActions=true
For upgrade, you have the following options:
You can run the EM Prerequisite Kit using the .bin file of the 13c software, and pass a response file with the necessary arguments.
To do so, run the following command. To learn about the other arguments that can be passed in the response file, see Section A.2.1.3.
./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=<absolute_path_to_reponse_file>
You can run the EM Prerequisite Kit from the /install/requisites/bin/ directory of the OMS home or the middleware home, and pass all the necessary arguments along with the command instead of using a response file.
This is because once the Enterprise Manager system is installed, the EM Prerequisite Kit and all the other files and directories are copied to the /install/requisites/bin/ directory of the OMS home or the middleware home, and therefore, you can run the kit from this location.
To run the EM Prerequisite Kit from the /install/requisites/bin/ directory, follow these steps:
Procure the new or updated prerequisite XML files in one of the following ways:
Enable the Self Update functionality within Enterprise Manager Cloud Control so that the new or updated prerequisite XML files are automatically downloaded to the /install/requisites/list directory within the OMS home or the middleware home.
To set up Self Update, see Oracle Enterprise Manager Cloud Control Administrator's Guide. To download the updates, see Oracle Enterprise Manager Cloud Control Administrator's Guide.
Manually download the new or updated prerequisite XML files from Oracle store to the /install/requisites/list directory within the OMS home or the middleware home.
Invoke the kit by running the following command with all the necessary arguments in the command line instead of a response file. To learn about the other arguments that can be passed in the command line, see Section A.2.1.3.
$<ORACLE_HOME>/install/requisites/bin/emprereqkit <list_of_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? | Description | Example |
|---|---|---|---|---|
|
|
Mandatory |
Yes |
Indicates that the installer is being invoked in the EM Prerequisite Kit mode. Always specify the value |
|
|
|
Optional |
Yes |
Enables performing prerequisite checks for different repository configurations such as small, medium, and large. If you do not pass this option, then by default, the prerequisite checks are run for medium deployment size. |
|
|
Mandatory |
Yes |
Specify the type of execution, which can be one of the following:
|
|
|
|
OR
|
Mandatory |
Yes |
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 If you use -prerequisiteResourceLocs, then pass a comma-separated list of prerequisite resource locations in the following format: |
OR
|
|
One of these options is mandatory |
Yes |
Specify the database details. When you invoke the kit for fresh installation, you invoke When you invoke the kit for upgrade, you invoke the kit from the Oracle home of the OMS host (or the middleware home) and pass all the arguments in the command line (instead of a response file). In this case, ensure that the connect string IS enclosed in double quotation marks. |
For example (connect string when passed in a response file for fresh installation, when the kit is invoked using the
For example (connect string when passed in the command line for upgrade, when the kit is invoked from the middleware home):
For example (database details):
|
|
Mandatory |
Yes |
Specify Also always specify |
|
|
|
Optional |
Yes |
Specify the password for the database user. If you do not pass this option, you will be prompted for a password. |
|
|
|
If |
Yes |
Specify |
|
|
|
Optional |
Yes |
Create a directory where the results (in the form of XML files) of the prerequisite checks can be stored, and specify the path to that directory. 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. |
|
|
(Important: These options must be passed in the sequence listed here. Do not change their order.) |
One of these options is mandatory. |
No |
Important: If you passed
Note: Show actions must be independent, that is, they should not be combined with any other action. |
|
|
|
Optional |
Yes |
The default XML files related to the prerequisite checks 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 can download the new or updated XMLs either manually or using Self Update. If you have XMLs for two higher versions (for example, for 13.1.0.0.0 and 13.1.0.1.0), then while upgrading, you can run the prerequisite checks for even one of them by passing the |
|
|
Optional |
Yes |
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 |
|
|
|
Optional |
Yes |
Specify the components that must be selected instead of the XML files for checking the prerequisites.
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. |
|
|
|
Optional |
Yes |
Specify the absolute path to a location where the response file is available. |
|
|
|
Optional |
Yes |
Specify a unique name for this run. If you do not specify this, a default name with the format |
|
|
|
Optional |
Yes |
Specify the name and value of the component variable in the following format:
For example:
You can pass as many component variables as you want, but ensure that you separate them by a comma. For example:
|
|
|
|
Optional |
Yes |
Defaults to |
|
|
|
Optional |
No |
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 |
|
|
|
Optional Must be passed as independent options; do not combine it any other option |
No |
Organizes and lists the prerequisite check results (stored in the database) based on when it was run and the context. |
|
|
|
|
Optional Must be passed as independent options; do not combine it any other option |
No |
Copies the prerequisite check results (XML files) from the database to an external file system. |
|
|
Optional Must be passed as independent options; do not combine it any other option |
No |
Defaults to |
|
|
|
-help |
Optional |
No |
Supported only when the kit is invoked from the Oracle home of the OMS host (the middleware home). In this case, you can pass this option in the command line. Provides details of various parameters which can be passed to the kit. |
|
This section describes how you can run the EM Prerequisite Kit using Enterprise Manager Command Line Interface (EM CLI). However, at the moment, using EM CLI you can only view the list prerequisites and run the prerequisite checks for upgrade. In particular, this section covers the following:
Viewing the EM Prerequisite Kit Prerequisite Checks Using EM CLI
Running the EM Prerequisite Kit Prerequisite Checks Using EM CLI
Description of the Parameters Passed While Running the EM Prerequisite Kit Using EM CLI
To view a list of prerequisites, follow these steps:
Log in to EM CLI:
emcli login -username=sysman
Synchronize EM CLI:
emcli sync
List the prerequisites:
$<ORACLE_HOME>/bin/emcli list_prerequisites -db_user=<database_user> -db_password=<database_password> -db_role=<database_role> (needed only when dbUser is SYS) -repos_user=<repository_user> (needed only when dbUser is SYS) -prerequisite_xml_root_dir=<absolute_path_to_all_prerequisite_XMLs> [-prerequisite_resource_locs=<prereq_xml_location>] [-log_loc=<absolute_path_to_log_file_location>] [-upgrade_version=<EM_version_to_which_upgrade_is_being_done_eg_13.1.0.0.0>] [-configuration_type=<configuration/deployment_type_eg_MINI/SMALL/MEDIUM/LARGE>]
For example,
/u01/software/em13c/oraclehome/bin/emcli list_prerequisites -db_user=SYS -db_password=mypwd -db_role=sysdba -repos_user=SYSMAN -prerequisite_xml_root_dir=$ORACLE_HOME/install/requisites/list -upgrade_version=13.1.0.0.0 -configuration_type=MEDIUM
For any additional information, use emcli help <verb_name>.
To run the prerequisite checks, follow these steps:
Log in to EM CLI:
emcli login -username=sysman
Synchronize EM CLI:
emcli sync
Run the prerequisites:
$<ORACLE_HOME>/bin/emcli run_prerequisites -db_user=<database_user> -db_password=<database_password> -db_role=<database_role> (needed only when dbUser is SYS) -repos_user=<repository_user> (needed only when dbUser is SYS) -prerequisite_xml_root_dir=<absolute_path_to_all_prerequisite_XMLs> [-prerequisite_resource_locs=<prereq_xml_location>] [-log_loc=<absolute_path_to_log_file_location>] [-upgrade_version=<EM_version_to_which_upgrade_is_being_done_eg_13.1.0.0.0>] [-configuration_type=<configuration/deployment_type_eg_MINI/SMALL/MEDIUM/LARGE>]
For example,
/u01/software/em13c/oraclehome/bin/emcli run_prerequisites -db_user=SYS -db_password=mypwd -db_role=sysdba -repos_user=SYSMAN -prerequisite_xml_root_dir=$ORACLE_HOME/install/requisites/list -upgrade_version=13.1.0.0.0 -configuration_type=MEDIUM
For any additional information, use emcli help <verb_name>.
db_user
Enter SYS. The connection to the database is established using this user account.
db_password
Enter the password for the SYS database user account.
db_role
Enter sysdba.
repos_user
Enter SYSMAN. The prerequisite checks will be run using this user account.
prerequisite_xml_root_dir
Enter the absolute path to the requisites/list directory where the XML files are available. The XML files may be in a subdirectory within the requisites/list directory, but make sure the path you enter leads only up to the list directory. The following is the location:
$<ORACLE_HOME>/install/requisites/list
For example,
/u01/software/em13c/oraclehome/install/requisites/list
prerequisite_resource_locs
Enter the absolute path to the directory where the plug-in .opar files or the platform binaries, which contain the XML files for the prerequisite checks, are present. If you are entering the path to the plug-in .opar files, then make sure the you follow the format plugin_id=<plugin_home>.
log_loc
Enter the absolute path to a directory where the logs of the execution of the EM Prerequisite Kit can be stored.
upgrade_version
Enter the version of Enterprise Manager to which you are upgrading. For example, 13.1.0.0.0.
configuration_type
Enter the deployment size—SMALL, MEDIUM, LARGE. For information on these deployment sizes, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
Note:
(Only for Upgrade to Next Enterprise Manager Cloud Control Software Release) You can download the latest version of EM Prerequisite Kit from the Self Update framework as follows:
In Cloud Control, from the Setup menu, select Extensibility, and then select Self Update.
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.
If you have XMLs for two higher versions (for example, for 13.1.0.0.0 and 13.1.0.1.0), then while upgrading, you can run the prerequisite checks for even one of them by passing the -upgrade_version argument.
For example,
/u01/software/em13c/oraclehome/bin/emcli run_prerequisites -db_user=SYS -db_password=mypwd -db_role=sysdba -repos_user=SYSMAN -prerequisite_xml_root_dir=<ORACLE_HOME>/install/requisites/list/ -upgrade_version=13.1.0.0.0
When you run the prerequisite checks using these revised XMLs for your next deployment, the revised XMLs are copied to the Management Repository automatically. If the downloaded revised XMLs are more recent than the ones available in the next Enterprise Manager Cloud Control software release, then the Enterprise Manager Installation Wizard uses these revised XMLs directly from the Management Repository instead of the ones available in the downloaded software.
Do not run multiple emcli run_prerequisites commands in parallel (from different EM CLI clients) to run the prerequisite checks with the downloaded revised XMLs and copy the XMLs to the Management Repository.
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 |
|---|---|---|
|
Note: When you provide |
Note: When you provide |
|
|
Automatically Invoked by the Enterprise Manager Cloud Control Installation Wizard |
Note: When you proceed through the installation wizard pages, EM Prerequisite Kit result XMLs are created in When install begins, the |
Note: When you proceed through the installation wizard pages, EM Prerequisite Kit result xmls are created in When install begins, the |
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.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 |
|---|---|
|
Contains information about every step taken or action performed by the kit |
|
|
Contains only the error and stacktrace of the exceptions occurred |
|
|
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. |
|
|
Contains information about the function area-specific prerequisite checks that are run. For example, For example, |
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.out file. For emprereqkit.out 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 |
|---|---|---|
|
Note: When you provide |
Note: When you provide |
|
|
Automatically Invoked by the Enterprise Manager Cloud Control Installation Wizard |
Note: When you proceed through the installation wizard pages, EM Prerequisite Kit logs are created in either When install begins, the / |
Note: When you proceed through the installation wizard pages, EM Prerequisite Kit logs are created in either When install begins, the |
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 fileemprereqkit.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>.
Table A-5 describes all the repository prerequisites that the EM Prerequisites Kit checks. This section also describes how to manually check these prerequisites.
Table A-5 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:
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
If it exists, then stop and delete. |
|
Valid Reference Requirements |
Upgrade |
Ensures that all entries for To manually verify this, run the following query. The query must not return any rows.
|
|
Job Type Uniqueness Requirements |
Upgrade |
Ensures that there are no duplicate entries in To manually verify this, run the following query. The query must not return any rows.
|
|
SQL Plan Baseline Capture Parameter Requirements |
Install, Upgrade |
Ensures that the parameter 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 |
|
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, 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:
If the package is invalid, run the following query:
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:
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:
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 |
|
EM_USER_CONTEXT requirements |
Upgrade |
Ensures that EM_USER_CONTEXT is present in the repository. To manually verify this, run the following query:
If the query result is 0, check that the procedure SETEMUSERCONTEXT is valid by executing the following query:
where object_name='SETEMUSERCONTEXT' and owner='SYSMAN' The above query must return 'VALID'. Then run:
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:
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:
If the result of the query is not 0, then revoke EXEMPT ACCESS POLICY from SYSMAN and the roles. For example:
|
|
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:
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:
|
|
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.
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:
|
|
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:
|
|
Pre-upgrade console patch requirements |
Upgrade |
Ensures that pre-upgrade patch is applied. To manually verify this, run the following query:
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:
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:
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 |
|
Existing Database Not to Have Database Control (only for fresh install) |
Fresh Install |
Ensures 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. To manually deconfigure the Database Control SYSMAN schema, follow these steps:
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 |
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 Oracle Enterprise Manager Cloud Control 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. For information about the database initialization parameters to be set for various deployment sizes, refer to the Oracle Enterprise Manager Cloud Control 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 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 |
(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 |
|
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 11g Release 1 (11.1). |
|
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:
|
|
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.
|
|
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, log in to the database as SYS:
|
|
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, log in to the database as SYS and run the following commands: For Oracle Database 10g (10.2.0.4) or higher:
For Oracle Database 11g (11.1.0.7) or higher:
|
|
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, 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 |
Ensures that SYSMAN_OPSS account is not locked. To manually 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) |
Ensures that Global names of old and new database are not same. To manually 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 |
Ensures that you are using Oracle Enterprise Database edition to install Enterprise Manager. To manually 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 |
Ensures that existing database does not have previous Enterprise Manager's details in schema_version_registry table. To manually 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 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, 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 and deinstall the Enterprise Manager software that had created these schemas. For instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide. |
|
DB Secure File Requirements |
Install, Upgrade |
Ensure that the |
|
Optimizer Adaptive Feature Requirements |
Install, Upgrade |
Checks whether the |