| Oracle® Enterprise Manager Grid Control Release Notes for HP-UX PA-RISC (64-Bit) 10g Release 4 (10.2.0.4.0) |
|
| Oracle® Enterprise Manager Grid Control Release Notes for HP-UX PA-RISC (64-Bit) 10g Release 4 (10.2.0.4.0) |
|
Grid Control Release Notes for HP-UX PA-RISC (64-Bit)
10g Release 4 (10.2.0.4.0)
E12229-02
July 2008
Oracle Enterprise Manager Grid Control (Grid Control) is a management solution that provides a centralized, integrated framework for managing different versions of Oracle products and some third-party products in the enterprise. Grid Control automates day-to-day maintenance requirements such as software installation, patching, upgrading, workload balancing, and security for an enterprise grid.
This Release Notes document is one of the documents that is bundled with 10.2.0.4.0 Grid Control Patch Set. The document provides information about the Patch Set and procedures that help you patch your 10.2.0.x.0 releases of Grid Control and (or) Management Agent, that is 10.1.0.x.0 or 10.2.0.x.0 or higher installation, and upgrade it to 10.2.0.4.0 release.
Note:
This document helps you patch 10.2.0.x.0 releases of Grid Control and (or) Management Agent, that is 10.1.0.x.0 or 10.2.0.x.0 or higher installation, and upgrade it to the 10.2.0.4.0 release. If you do not have a previous release but want to have a 10.2.0.4.0 environment, then first install 10.2.0.x.0 OMS, and then use this Patch Set to upgrade it to 10.2.0.4.0. For information about installing Grid Control, refer to the Quick Installation guide available at:This document contains the following sections:
There are two documents related to this release of Grid Control Patch Set:
Oracle Enterprise Manager Grid Control Release Notes, 10g Release 4 (10.2.0.4.0) (this document)
This document provides:
A list of new features included in this Patch Set
Information about how to install or de-install the Patch Set
A list of known issues relating to this release of Grid Control Patch Set
Oracle Enterprise Manager Grid Control List of Bugs Fixed, 10g Release 4 (10.2.0.4.0)
This document provides a list of all generic bugs related to Grid Control that have been fixed in this release.
Both these documents are included with the 10.2.0.4.0 Patch Set. You can also find a consolidated document, which has the Document ID 565917.1, on OracleMetaLink at:
To locate document 565917.1:
Click Advanced at the top of the OracleMetaLink page.
Enter 565917.1 in the Document ID field and click Submit.
You can also find this document on the Oracle Technology Network (OTN) Web site:
If you are migrating from Enterprise Manager 10g Grid Control Release 3 (10.2.0.3) to Enterprise Manager 10g Grid Control Release 4 (10.2.0.4), then you will see the following new features:
Provides data masking, that is the capability to replace sensitive data with false but realistic looking data on test and development databases.
Allows usage of commonly-used privileged delegation software, such as sudo or pbrun, to fit into the existing credential subsystem in Enterprise Manager.
Allows bidirectional flow of events between Enterprise Manager and third-party products.
Provides users through the Service Level Management Pack the capability to record transactions on Forms 6i-based applications and periodically replay these transactions to monitor performance and availability.
Provides DHTML transaction recording and monitoring features that allow you to record and playback DHTML-based applications. The features help you to capture mouse and keyboard actions, in addition to the HTTP requests.
Allows you to monitor and manage Oracle BI Suite Enterprise Edition (Maui release). You can discover Oracle BI EE servers, view configuration information, monitor performance, and so on.
Provides, through the Diagnostics Pack for Non-Oracle Middleware, Oracle Application Diagnostics for Java (Oracle AD4J) that allows you to diagnose performance problems in production Java applications with minimal performance overhead and without shutting down the applications.
Provides improved SOA management capabilities that enable you to automate the provisioning of BPEL Processes using the deployment procedures. Also offers configuration management of BPEL Process Manager.
Provides out-of-box plug-in support for Microsoft Exchange targets. Allows you to monitor performance, availability, usage statistics, and administration of Exchange Servers.
Offers support for the following plug-ins:
VMware ESX Server: You can monitor configuration and performance data of VMware ESX Server 3.
Microsoft SQL Server: You can access core administration capabilities.
IBM DB2 Database: You can monitor IBM DB2 Release 9.
Provides Oracle Configuration Manager (OCM) that is designed to gather and provide your configuration information and store it in Oracle repository for maintenance and other related tasks.
Oracle has certified Oracle Enterprise Manager 10g Release 4 Grid Control version 10.2.0.4.0 on the HP-UX PA-RISC (64-bit) (version 11i v3 [11.31]) operating system.
You must first install the following operating system patch:
PHKL_35936
The following kernel parameters are obsolete on HP-UX 11iV3.
maxswapchunks msgmap ncallout semmap vx_ncsize
For installations of Grid Control version 10.2.0.1, before running the installer from the Grid Control 10.2.0.1 media, apply the patch for Bug# 6904096.
This section describes the preinstallation tasks to be performed.
Warning:
There is no mechanism provided for de-installing Patch Sets. If you are concerned about being able to de-install a Patch Set, Oracle recommends that you back up your software installation before applying the Patch Set. See De-Installation of a Patch Set for more information.The following are the general preinstallation tasks.
Important:
For information on upgrade prerequisites, refer to Document ID -464674.1 on Oracle MetaLink at http://metalink.oracle.com/.Oracle recommends that you back up the ORACLE_HOME that must be upgraded using this Patch Set. In the case of a Management Repository, Oracle recommends that you back up the repository database because the Patch Set makes changes to the repository that cannot be rolled back. Also, back up the Oracle Inventory directory.
The product prerequisites (required operating system patches, packages, and so on) of 10.2.0.4.0 are already met in the previous release (10.2.0.x). Refer to the Quick Installation Guide for more details.
http://dowload.oracle.com/docs/cd/B16240_01/doc/install.102/e10081/toc.htm#CHDBCGGE
Before patching your Oracle Management Service, ensure that the shared pool size is set as per your infrastructure. Minimum size for shared pool 512 MB. For information see Table B-2 in the Enterprise Manager Grid Control Installation and Basic Configuration Guide available at:
http://download.oracle.com/docs/cd/B14099_19/manage.1012/b16228/app_database_settings.htm
If your Enterprise Manager is shutdown for a long period of time, you must follow the below steps before conducting the upgrade:
Log into the Repository Database as SYSMAN
Run the following sql:
SQL> exec emd_maintenance.analyze_emd_schema('SYSMAN')
Start the Oracle management service
If you have a Grid Control environment that was installed using the "Enterprise Manager using New Database" option or "Enterprise Manager using an Existing Database" option with the 10.1.0.4 or 10.1.0.5 database, then before upgrading from 10.2.0.3 to 10.2.0.4, apply the patch for bug 4329444 on the Repository Database Home.
Note:
Before upgrading the OMS to 10.2.0.4 from 10.2.0.3 on HP-UX PA-RISC, you must first apply patch 4329444 to the 10.1.0.4 or 10.1.0.5 database that houses the repository. This patch is not required for a Windows 10.1.0.4 or 10.1.0.5 database that houses the repository.Important: Oracle recommends that you back up your database before you perform the upgrade operation. Note that the patch 4329444 might conflict with some previous CPU releases (for example, April 2007 CPU) that might be applied to your repository database. In case of a conflict while applying patch 4329444, do not continue with the upgrade process. Contact Oracle Support to first resolve the patch conflict and then perform the following steps before performing the upgrade:
Login into the Database as SYS user
Check if there are any invalid SYSMAN objects
SQL> select object_name, object_type from all_objects where owner='SYSMAN' and status <> 'VALID';
The above query should return 0 rows. If there are rows, then run the below sql statement:
SQL> @admin_recompile_invalid.sql SYSMAN
The admin_recompile_invalid.sql script is available under ORACLE_HOME/sysman/admin/emdrep/sql/core/latest/admin/ where ORACLE_HOME is the Oracle home directory of the OMS.
Go to step b again to be sure all SYSMAN objects are valid. If you still have invalid SYSMAN objects that are not in the Recycle bin, please contact Oracle support.
Check to be sure there is no invalid SYS object:
SQL> select object_name, object_type from all_objects where status<>'VALID' and object_name like 'DBMS%';
The above query should return 0 rows. If there are rows, then try to "recompile" them. For example:
if the object_type = "PACKAGE" and object_name = "foo" alter package foo compile; if the object_type = "PACKAGE BODY" and object_name = "foo" alter package foo compile body;
If any of the packages fail to become valid even after recompilation, then Contact Oracle Support to assist you. Once this verification is done, continue through with the rest of the pre-installation tasks.
If you have applied the patch 5478872 to your Enterprise Manager Grid Control environment, then you MUST drop the index MGMT_DELTA_SNAP_IDX3 before upgrading Grid Control to 10.2.0.4. If the index is not dropped, the upgrade process will fail.
To drop the index MGMT_DELTA_SNAP_IDX3, run the following command:
Connect to SQL Plus session as EM repository owner (SYSMAN)
Issue the command SQL> drop index MGMT_DELTA_SNAP_IDX3
Refer to MetaLink DocID 558673.1 for details. The fix for bug 5478872 is included in the patch set version 10.2.0.4 so you are not required to apply any additional patches to resolve this bug after upgrading to the 10.2.0.4 version of Grid Control.
If you have applied the patch 6606233 to your Enterprise Manager Grid Control environment, then you MUST roll back the patch before upgrading Grid Control to 10.2.0.4.
After rolling back the patch, upgrade Grid Control to 10.2.0.4 and then apply patch 6606233 that is specific to 10.2.0.4 Grid Control.
To roll back the patch, follow these steps:
Shut down OMS using the following command, where $ORACLE_HOME is the Oracle home directory of the OMS. In case of multi-OMS environment, shut down all OMSes. Leave the EM Repository database and its listener running.
$ORACLE_HOME/bin/emctl stop oms
In case of multi-OMS environment, if the .sql scripts were executed successfully from the first OMS, then run steps (g), (h) and (n). Skip other steps.
If the OMS and Repository are on the same machine, then set the TNS_ADMIN variable to <Repository Database Home>/network/admin, and then invoke SQLPLUS.
If the OMS and the Repository Database are on different machines, then create the tnsnames.ora file and set the TNS_ADMIN variable in the following location, where $ORACLE_HOME is the Oracle home directory of the the OMS:
$ORACLE_HOME/network/admin/
Create a tns alias in tnsnames.ora that points to the Repository database and connect to the Database repository. For example:
sqlplus sysman/<password>@<tns alias from $TNS_ADMIN/tnsnames.ora>
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT what, broken FROM dba_jobs WHERE log_user = priv_user and priv_user = (SELECT owner FROM dba_procedures WHERE object_name = 'MGMT_USER'AND procedure_name = 'DROP_USER') ORDER BY job;
IMPORTANT: Store the results of this query so that you can compare it with the results of the query run in step (l).
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT object_name FROM user_objects WHERE status = 'INVALID' order by object_name;
IMPORTANT: Store the results of this query so that you can compare it with the results of the query run in step (m).
Note the value of job_queue_processes in init.ora parameter<original count>:
SQL> show parameter job_queue_processes;
Connect to sqlplus as the SYSMAN:
ALTER SYSTEM SET job_queue_processes = 0;
Make sure the following query returns 0 rows. If the query returns non-zero records please wait and run again:
SELECT /*+ RULE */ * FROM DBA_JOBS_RUNNING ;
Set your current directory to the $ORACLE_HOME directory of the OMS where the patch is located:
% cd 6606233
Ensure that the directory containing the opatch script appears in your $PATH; then run the following command:
$ opatch rollback -id 6606233
Connect to sqlplus as the sysman and run the following SQL files (Be sure that the SQL commands are executed in the order mentioned below):
SQL> @?/sysman/admin/emdrep/sql/core/latest/esm/esm_pkgdefs.sqlSQL> @?/sysman/admin/emdrep/sql/core/latest/esm/esm_pkgbodys.sql
Recompile the SQL packages in sysman schema by running the following pl/sql procedure:
SQL> @?/sysman/admin/emdrep/sql/core/latest/admin/admin_recompile_invalid <repository owner>
Where <repository owner> is the repository owner username in Upper caps (for example, SYSMAN and not sysman).
SQL> ALTER SYSTEM SET job_queue_processes=<original count>;
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT what, broken FROM dba_jobs WHERE log_user = priv_user and priv_user = (SELECT owner FROM dba_procedures WHERE object_name = 'MGMT_USER' AND procedure_name = 'DROP_USER') ORDER BY job;
Be sure that the output from the above query is exactly the same as the output obtained in Step b. If not, please call Oracle Support immediately.
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT object_name FROM user_objects WHERE status = 'INVALID' order by object_name ;
Be sure that the output from the above query is exactly the same as the output obtained in Step c. If not, please call Oracle Support immediately.
Start the OMS using the following command. In case of a multi-OMS environment, start all the OMSes:
$ORACLE_HOME/bin/emctl start oms
The above steps are also mentioned in the README document of the Patch. For information on upgrade prerequisites, refer to Document ID- 464674.1 on Oracle MetaLink at http://metalink.oracle.com/.
Before proceeding with the upgrade, make sure that the dbms jobs are stopped. To do this, follow these steps:
Login into the SQL as SYSMAN
Run the following SQL command:
SQL> execute emd_maintenance.remove_em_dbms_jobs;
SQL>commit;
Stop the Repository Database
Start the Repository Database
If you are using the corrective actions feature, then you may run into a schema inconsistency that could cause an upgrade to fail (bug 5855008). If you are using corrective actions, then run the following PL/SQL block in the Enterprise Manager repository using sqlplus (connected as SYSMAN), BEFORE doing the upgrade, in order to clean up the inconsistent data.
BEGIN
FOR r IN (SELECT job_id
FROM mgmt_corrective_action a
WHERE NOT EXISTS
(SELECT 1
FROM mgmt_job j
WHERE j.job_id = a.job_id)
) LOOP
UPDATE mgmt_policy_assoc_cfg c
SET crit_action_job_id = NULL
WHERE crit_action_job_id = r.job_id
;
UPDATE mgmt_policy_assoc_cfg c
SET warn_action_job_id = NULL
WHERE warn_action_job_id = r.job_id
;
UPDATE mgmt_policy_assoc_cfg c
SET info_action_job_id = NULL
WHERE info_action_job_id = r.job_id
;
DELETE
FROM mgmt_corrective_action
WHERE job_id = r.job_id
;
COMMIT;
END LOOP;
COMMIT;
END;
/
The preinstallation tasks can be broadly categorized based on the following types of upgrades that you can perform:
To upgrade multiple Oracle Management Services (OMS), shut down all the OMS's, apply the patch set to any one of the OMS's so that the associated Management Repository is also upgraded, then apply the patch to the rest of the Oracle Management Services.
Note:
Database version 10.2.0.4 is not certified as Grid control Repository. This applies to all the 10.2.0.4 Repository Upgrade references in the Release Note.The steps to be taken before upgrading the first OMS are:
While applying the OMS patchset, leave the repository database and listener instance running.
If you have a Grid Control environment that was installed using "Enterprise Manager using New Database" option or "Enterprise Manager using an Existing Database" option with 10.1.0.4 or 10.1.0.5 Database, then before upgrading to 10.2.0.4, apply the patch for bug 4329444 on the Repository Database Home.
Note:
Before upgrading the OMS to 10.2.0.4 from 10.2.0.3 on HP-UX PA-RISC, you must first apply patch 4329444 to the 10.1.0.4 or 10.1.0.5 database that houses the repository. This patch is not required for a Windows 10.1.0.4 or 10.1.0.5 database that houses the repository.Important: Oracle recommends that you back up your database before you perform the upgrade operation. Note that the patch 4329444 might conflict with some previous CPU releases (for example, April 2007 CPU) that might be applied to your repository database. In case of a conflict while applying patch 4329444, do not continue with the upgrade process. Contact Oracle Support to first resolve the patch conflict and then perform the following steps before performing the upgrade:
Login into the Database as SYS user
Check if there are any invalid SYSMAN objects
SQL> select object_name, object_type from all_objects where owner='SYSMAN' and status <> 'VALID';
The above query should return 0 rows. If there are rows, then run the below sql statement:
SQL> @admin_recompile_invalid.sql SYSMAN
The admin_recompile_invalid.sql script is available under ORACLE_HOME/sysman/admin/emdrep/sql/core/latest/admin/ where ORACLE_HOME is the Oracle home directory of the OMS.
Go to step b again to be sure all SYSMAN objects are valid. If you still have invalid SYSMAN objects that are not in the Recycle bin, please contact Oracle support.
Check to be sure there is no invalid SYS object:
SQL> select object_name, object_type from all_objects where status<>'VALID' and object_name like 'DBMS%';
The above query should return 0 rows. If there are rows, then try to "recompile" them. For example:
if the object_type = "PACKAGE" and object_name = "foo" alter package foo compile; if the object_type = "PACKAGE BODY" and object_name = "foo" alter package foo compile body;
If any of the packages fail to become valid even after recompilation, then Contact Oracle Support to assist you. Once this verification is done, continue through with the rest of the pre-installation tasks.
Shut down all OMS instances attached to the repository from the respective ORACLE_HOMEs in their respective hosts. Also stop the Application Server components that run in each $ORACLE_HOME of the OMS.
Note:
If you have multiple Oracle Management Services then you must stop all the OMS instances. When you upgrade the first OMS, the Patch Set also upgrades the repository, and since the other OMS instances connect to the same repository, they must also be stopped.Stopping the Management Agents is not mandatory, and as a result, there may be an increase in the number of Agent-related log files. However, this is harmless and can be ignored.
To stop all the Grid Control components on a host, follow these steps:
Stop the OMS.
$PROMPT> $ORACLE_HOME/bin/emctl stop oms
Stop the Application Server Control Console, which is used to manage the Oracle Application Server instance used to deploy the Management Service.
$PROMPT> $ORACLE_HOME/bin/emctl stop iasconsole
Stop all the application server components, such as Oracle HTTP Server, OracleAS Web Cache.
$PROMPT> $ORACLE_HOME/opmn/bin/opmnctl stopall
Wait for four to five minutes to ensure that all the OPMN processes are stopped and TCP ports are released.
Change the directory to the Oracle home directory for the Management Agent and stop the Management Agent.
$PROMPT> $ORACLE_HOME/bin/emctl stop agent
Set the Oracle_Home to your Oracle home directory of the Oracle Management Services before applying the patch set.
Apply the 10.2.0.4.0 Patch Set either interactively by executing the runInstaller or silently by using the response file.
Note:
If your Repository Upgrade Configuration Assistant fails during the configuration step then you might be experiencing bug 6901072. Refer to Installation and Upgrade Issues In General. For more information about bug 6901072, refer to the document ID -559658.1 on Oracle MetaLink at http://metalink.oracle.com.After you have upgraded the first OMS and the Grid Control repository (Sysman schema) to version 10.2.0.4.0, the first OMS starts up automatically and you must then patch the unpatched OMS's to version 10.2.0.4.0.
Note:
Do not start an OMS that has not been patched to version 10.2.0.4.For example, assume there are four versions of 10.2.0.3 Oracle Management Services labeled OMS A, B, C, and D. In the previous section, all four OMS's are down and you decide to patch OMS B first. After you patch OMS B to version 10.2.0.4.0, the Enterprise Manager Repository is also patched and OMS B is now up and running. However OMS A, C, and D remain down.
You can then patch OMS A, C, and D in parallel or in serial to version 10.2.0.4.0 but you must not bring up the unpatched version of those OMS's at any time prior to patching them to version 10.2.0.4.0.
While manually applying the Patch Set using Oracle Universal Installer (OUI), the only pre-installation step to be performed is to shut down the Management Agent. Note that OUI validates for running Management Agent processes. If any Management Agent process is running, then the installer prompts to shut down the Management Agent, and then proceeds with the copying of files and subsequent relinking operation.
While applying the Patch Set using the Grid Control Patch Wizard, the Management Agent to be patched should be up and running.
Note:
The OMS installation not only installs an OMS but also automatically installs a Management Agent. However, when you upgrade that OMS to 10.2.0.4.0 using the Patch Set, the Patch Set does not upgrade any of the associated Management Agents. To upgrade the Management Agents, you have to manually apply the Patch Set on each of the Management Agent homes, as they are separate Oracle Homes.This section describes the installation procedure.
For upgrading to 10.2.0.4.0, you have to manually download and extract the 10.2.0.4.0 Patch Set.
Note:
Mass Agent patching is an exception. For Mass Agent patching, refer to Upgrading Management Agent - Multiple Hosts at a Time.To download and extract the Patch Set:
Download the p3731593_102040_<platform name>.zip patch set installation archive to any directory that may or may not be an Oracle Home directory.
Enter the following command to unzip and extract the installation files:
$ unzip p3731593_102040_<platform name>.zip
This extracts the files to the "3731593" directory.
Important:
The same Patch Set can be used for patching Oracle Managment Service, Repository, and Management Agent. The procedures are described in the following sections.Ensure that ORACLE_HOME is set to the Oracle Home of the OMS that is intended to be upgraded. Navigate to the 3731593/Disk1 subdirectory and run the runInstaller.
IMPORTANT:
In the case of a Grid Control environment being installed via the "Enterprise Manager using New Database" option or the "Enterprise Manager using an existing Database" option with version 10.1.0.4 or 10.1.0.5 database, then before upgrading to 10.2.0.4, apply the patch for bug 4329444 on the Repository Database Home.
Patch 4329444 must be applied on all 10.1.0.4 or 10.1.0.5 repository databases but not for Windows 10.1.0.4 or 10.1.0.5 repository databases.
Oracle recommends that you back up your database before you perform the upgrade operation. Note that the patch 4329444 might conflict with some previous CPU releases (for example, April 2007 CPU) that might be applied to your repository database. In case of a conflict while applying patch 4329444, do not continue with the upgrade process. Contact Oracle Support to first resolve the patch conflict and then perform the following steps before performing the upgrade:
Login into the Database as SYS user
Check if there are any invalid SYSMAN objects
SQL> select object_name, object_type from all_objects where owner='SYSMAN' and status <> 'VALID';
The above query should return 0 rows. If there are rows, then run the below sql statement:
SQL> @admin_recompile_invalid.sql SYSMAN
The admin_recompile_invalid.sql script is available under ORACLE_HOME/sysman/admin/emdrep/sql/core/latest/admin/ where ORACLE_HOME is the Oracle home directory of the OMS.
Go to step 2 again to be sure all SYSMAN objects are valid. If you still have invalid SYSMAN objects that are not in the Recycle bin, please contact Oracle support.
Check to be sure there is no invalid SYS object:
SQL> select object_name, object_type from all_objects where status<>'VALID' and object_name like 'DBMS%';
The above query should return 0 rows. If there are rows, then try to "recompile" them. For example:
if the object_type = "PACKAGE" and object_name = "foo" alter package foo compile; if the object_type = "PACKAGE BODY" and object_name = "foo" alter package foo compile body;
If any of the packages fail to become valid even after recompilation, then Contact Oracle Support to assist you. Once this verification is done, continue through with the rest of the pre-installation tasks.
If ORACLE_HOME is set in the environment or passed as a command line argument, then OUI automatically picks it up and goes through the following three phases.
In this phase, OUI picks up the repository connection details from the configuration files and then prompts for the SYS password of the repository database. It validates if there are any existing connections from Oracle management service to the repository. It does not check for operating system processes but looks for specific entries in the Enterprise Manager repository. Wait for few minutes for the session entries to get cleared after you shut down all the OMSs.
It also checks for background DBMS jobs that are running. If any jobs are running, then follow the steps below:
Run the following SQL procedure as SYSMAN to remove the scheduled EM dbms jobs:
SQL> execute emd_maintenance.remove_em_dbms_jobs;SQL> commit;
Run the following SQL statement as DBA user until no rows are returned, which indicates that all outstanding running dbms jobs are completed:
SQL> Select count(*) FROM dba_jobs_running run_job, gv$session sess WHERE sess.sid = run_job.sid AND sess.schemaname = 'SYSMAN';
Oracle Configuration Manager Installation
In this step, the installer collects information to install Oracle Configuration Manager (OCM) into the existing ORACLE_HOME location. OCM will be configured only if the license agreement is accepted.
Provide the Customer Service Identification (CSI), OracleMetaLink Account User Name and the Country of license origin when configuring OCM on the OCM Configuration Page. If you want to configure the proxy settings, then click Connection Settings on the Configuration Page and provide the proxy settings.
Note:
OCM is installed even when you decline the license agreement, but is not configured. The necessary directories are created and files are instantiated. You need to invokesetupCCR ($ORACLE_HOME/ccr/bin/setupCCR) at a later point of time to configure it. When setupCCR is invoked interactively, it prompts for the required parameter values. You can also accept the license agreement, but choose not to enable the Oracle Configuration Manager. You can disable Oracle Configuration Manager even after accepting the license agreement by unchecking or deselecting the "Enable Oracle Configuration Manager" option.If you install the Management Agent using "Agent Download", then you will have to manually configure OCM. To configure OCM, perform the following steps:
Determine your CSI, OracleMetaLink identifier, and the country where you purchased your service contract.
Execute one of the following commands according to your choice:
If you want to configure using proxy server:
$ORACLE_HOME/ccr/bin/setupCCR -p <proxy server>
If you want to configure without using proxy server:
$ORACLE_HOME/ccr/bin/setupCCR
For more information about using setupCCR, use the setupCCR -help command.
The license agreement for Oracle Configuration Manager is displayed. To accept the license agreement, enter "Y".
When setup prompts for the CSI, OracleMetaLink identifier, and country code, provide these details.
Setup then installs and configures OCM.
When setup is complete, OCM gathers configuration information for ORACLE_HOME, and uploads this information to Oracle for use while supporting your site.
If you want to check the status of OCM, run the following command:
$ORACLE_HOME/ccr/bin/emCCR status
In this phase, the installer copies all necessary files and does relink operations.
In this phase, the installer does the following:
Updates the Repository: This assistant upgrades the repository to 10.2.0.4 release. If the repository has already been upgraded to 10.2.0.4.0 release and this is an additional OMS being patched, then the configuration phase does not upgrade the repository.
Note:
If the Repository Upgrade Assistant fails during the 10.2.0.4.0 OMS patchset install, then do not click Retry.Check the error messages in the latest log file that is available in the following location, where $ORACLE_HOME is the Oracle home directory of the OMS:
<$ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<LATEST_TIME_STAMP>.log.
If the following error message is present in the log, then the repository upgrade is going on from another OMS patchset install:
STATUS - 2 : Repository Upgrade is already running from another OMS install. Wait until upgrade finishes.
Run the below SQL query to find the Repository Upgrade status.
select status from sysman.mgmt_versions where component_name='_UPGRADE_'
Wait until the status shows '4' which indicates that the upgrade is complete without any errors. Then click Retry to continue with Install.
If the following error message is present in the log, then the repository upgrade has failed:
SEVERE: oracle.sysman.top.oms:Repository Upgrade is failed with errors.Rectify the errors and retry the install.
For additional details on configuration issues, you may refer to these log files available in the following location, where $ORACLE_HOME is the Oracle home directory of the OMS:
<$ORACLE_HOME>/cfgtoollogs/cfgfw
For additional details on repository failures, you may refer to the log files available in the following location, where $ORACLE_HOME is the Oracle home directory of the OMS:
<$ORACLE_HOME>/sysman/log/emrepmgr.log.10.2.0.4.0
<$ORACLE_HOME>/sysman/log/emrepmgr.log.10.2.0.4.0.errors
If you cannot identify the repository issues, contact Oracle Support and provide the above log files. If the errors from the schema upgrade were analyzed and rectified, then the following can be executed to allow the installer to continue upon Retry:
Log in to the database as SYSMAN
Execute emd_maintenance.set_comp_status('_UPGRADE_', EMD_MAINTENANCE.G_STATUS_CONFIGURED_READY);
Exit SQLplus
Click Retry on the installer. Alternately, you can run the runConfig command to run the failed config tools manually.
Go to the <ORACLE_HOME>/oui/bin directory and run the command below:
./runConfig.sh ORACLE_HOME=<OMS_ORACLE_HOME> ACTION=patchsetConfigure MODE=perform COMPONENT_XML={oracle.sysman.top.oms.10_2_0_4_0.xml} RERUN=true
Redeploys the Enterprise Manager Application: In this step, the OC4J application is redeployed.
Deploys the Provisioning Application: In this step, various provisioning application steps are configured, which you can use to deploy an application. Here, the Provision Archive files are also updated to the Enterprise Manager Repository. A Provisioning Archive file typically consists of new procedures, new directives, and new components that are used by the application.
If the software library is not set up, then a message is displayed stating that the provisioning configuration did not succeed. The tool has to be run manually after upgrade and after setting up the software library. Software library can be created using any mounted file system that is readable and writeable from the all OMS instances.
To correct this, perform the following steps:
Login to Enterprise Manager Grid Control as SYSMAN.
Navigate to Deployments, then Provisioning and then to Administration.
Navigate to the Software Library Configuration section and click Add.
Provide a valid directory path where you want to store the raw data for the component(s).
Log in to the machine that hosts the OMS and do the following:
Set the ORACLE HOME environment variable to the Oracle home directory of the OMS
Run the following command:
<ORACLE_HOME>/bin/PARDeploy -action deploy -parDir <ORACLE_HOME>/sysman/prov/paf -force
Starting Oracle Management Service: In this step, the OMS is started.
Configures Oracle Configuration Manager: This step configures the OCM, if you have accepted the license agreement. The necessary directories are created and files are instantiated. If there are problems during configuration, then the configuration is not performed. To configure it later, you can invoke setupCCR ($ORACLE_HOME/ccr/bin/setupCCR) at a later point of time.
The Management Agent can be upgraded in two ways - either one host at a time or many hosts at a time.
Important:
Oracle recommends you upgrade your Management Agent to version 10.2.0.4. The Patch Set contains some new components for the proper functioning of the new features.Oracle Configuration Manager Installation
In this step, the installer collects information to install Oracle Configuration Manager (OCM) into the existing ORACLE_HOME location. OCM will be configured only if the license agreement is accepted.
Provide the Customer Service Identification (CSI), OracleMetaLink Account User Name and the Country of license origin when configuring OCM on the OCM Configuration Page. If you want to configure the proxy settings, then click Connection Settings on the Configuration Page and provide the proxy settings.
Note:
OCM is installed even when you decline the license agreement, but is not configured. The necessary directories are created and files are instantiated. You need to invokesetupCCR ($ORACLE_HOME/ccr/bin/setupCCR) at a later point of time to configure it. When setupCCR is invoked interactively, it prompts for the required parameter values. You can also accept the license agreement, but choose not to enable the Oracle Configuration Manager. You can disable Oracle Configuration Manager even after accepting the license agreement by unchecking or deselecting the "Enable Oracle Configuration Manager" option.If you install the Management Agent using "Agent Download", then you will have to manually configure OCM. To configure OCM, perform the following steps:
Determine your CSI, OracleMetaLink identifier, and the country where you purchased your service contract.
Execute one of the following commands according to your choice:
If you want to configure using proxy server:
$ORACLE_HOME/ccr/bin/setupCCR -p <proxy server>
If you want to configure without using proxy server:
$ORACLE_HOME/ccr/bin/setupCCR
For more information about using setupCCR, use the setupCCR -help command.
The license agreement for Oracle Configuration Manager is displayed. To accept the license agreement, enter "Y".
When setup prompts for the CSI, OracleMetaLink identifier, and country code, provide these details.
Setup then installs and configures OCM.
When setup is complete, OCM gathers configuration information for ORACLE_HOME, and uploads this information to Oracle for use while supporting your site.
If you want to check the status of OCM, run the following command:
$ORACLE_HOME/ccr/bin/emCCR status
To upgrade Management Agents one host at a time using OUI, follow these steps:
Login to the specific host where the Management Agent is running.
Stop the Management Agent.
Ensure that ORACLE_HOME is set to the Oracle home directory of the Management Agent that need to be patched.
Extract the software as per the section 4.1 and then run the runInstaller executable from the 3731593/Disk1 subdirectory.
If the ORACLE_HOME is set in the environment or passed as a command line argument, then OUI automatically picks it up.
Patch set installer validates whether the Management Agent is up and running from its ORACLE_HOME. If it is running, then the installer prompts the Management Agent to shut down, and then proceeds with the copying of files and subsequent relinking operation.After the installation is complete, the Patch Set automatically restarts the Management Agent.
To upgrade Management Agents multiple hosts at a time, use either of the following two methods:
Method 1 - By Distributing the Full Patch Set to a Number of Hosts
Method 2 - By Staging the Patch Set and Distributing Scripts to a Number of Hosts
You can choose one of the methods for mass patching of Management Agents. Method 1 is based on a "push" technique in which the entire set of patch binaries is transferred to all the hosts. Method 2 is based on a "pull" technique in which only a script is transferred to the targets and the patch is then installed over HTTP. Since it does not require to transfer the entire set of patch binaries in Method 2, it is the recommended method for large number of targets, whereas Method 1 is more suitable for a limited number of targets. Note that for Method 2, the wget utility must be installed on the target machines and present in the PATH environment variable.
Method 1 - By Distributing the Full Patch Set to a Number of Hosts
Log in to Enterprise Manager Grid Control using SYSMAN credentials. Go to the Targets--> Hosts tab to ensure that the required host targets are up and running.
Click Setup from the top-right corner of the Grid Control console. Then select Patching Setup from the panel to the left. Provide the OracleMetalink credentials and click Apply.
Navigate to the Jobs tab. Create a job of the type "RefreshFromMetalink", and run it.
If you have already upgraded the OMS to version 10.2.0.4, click the Deployments tab, then click the Patch Agent link. For OMS version 10.2.0.3, click Deployments, then Patch Oracle Software. Provide the patch number 3822442 and select the correct platform and 10.2.0.4.0 release.
You can then select a number of targets to apply the patch. After selecting the target, select "Use default patching script" or "Provide custom script" option to allow OCM to be installed in the target Agent's home.
If the target is a Microsoft Windows machine, then in the pre-script option specify the following:
%emd_root%\EMStagedPatches\3822442\3822442\ecm_3822442.bat
If the target is on Solaris, Aix 5L, or HP-UX PA-RISC, then you must select Custom Post Command/Script, select Use sudo, and provide Custom Post Command/Script value as %emdroot%/root.sh. If Sudo is not installed on the target box then this step will not work. In this case root.sh will not run and you must manually run the root.sh on the target from the Oracle home directory of the Management Agent.
This method copies the patch to the Oracle home directory of the Management Agent of the selected targets and runs a script to apply the patch. The script creates blackouts, shuts down the Management Agent before applying the Patch Set, applies the Patch Set, clears the blackouts after applying the Patch Set, and then restarts the Management Agent. It is advisable to choose a reasonable number of nodes so that the network is not overloaded.
Method 2 - By Staging the Patch Set and Distributing Scripts to a Number of Nodes
Note:
For Microsoft Windows target machines, patching through this method requires wget.exe to be in the PATH environment variable. If wget.exe is not in the PATH of the target machine, then add it to the PATH and rebounce the Management Agent by executing the following:<ORACLE_HOME>/bin/emctl stop agent
<ORACLE_HOME>/bin/emctl start agent
Perform the following steps on the OMS host:
Navigate to the following location, where $ORACLE_HOME is the Oracle home directory of the OMS:
cd <$ORACLE_HOME>/sysman/agent_download/
Create a directory:
mkdir -p patchset/10.2.0.4.0/<platform name>
You can then stage the Patch Set by either copying from a DVD or by extracting the contents of the Metalink patch 3731593.
Copy the p3731593_102040_<platform name>.zip from the DVD or Metalink patch to an empty, temporary directory.
Extract the contents of the ZIP file to the same temporary directory created above.
Now navigate to the 3731593/Disk1 directory and copy its contents to the newly created directory in step (2):
To navigate:
cd 3731593/Disk1
To copy the contents to the newly created directory in step (2):
cp -r * <ORACLE_HOME>/sysman/agent_download/patchset/10.2.0.4.0/<platform name>
Here, ORACLE_HOME is the Oracle home directory of the OMS and "platform name" is one of the following:
Table 1 Descriptions of Platform Names
| Platform Name | Description |
|---|---|
|
linux |
Linux |
|
x86_64 |
Linux X86_64 |
|
ppc64 |
Linux on power PC |
|
linux390 |
z/Linux |
|
ia64linux |
IA64 Linux |
|
solaris |
Solaris 64 bit |
|
solarisx86 |
Solaris-x86 |
|
hpux |
HP-UX |
|
decunix |
HP Tru64 UNIX |
|
hpunix |
HP 64 bit |
|
hpi |
HPUX-Itanium |
|
aix |
AIX5L |
|
macosx |
MACOSX |
|
vms |
VMS |
|
windows_ia64 |
Microsoft Windows (64-bit IA) |
|
windows_x64 |
Microsoft Windows (64-bit AMD64) |
|
win32 |
Microsoft Windows 32 bit |
The above-mentioned operation stages the contents of the Patch Set in the OMS host.
Note:
For an environment with multiple OMS servers, repeat steps 1 through 6 for each OMS server.After this happens, follow these steps:
(a) Login to Enterprise Manager Grid Control using SYSMAN credentials. Click Targets and check to see that the host is running.
(b) Click Setup from the top right corner of the Grid Control console. Select Patching Setup from the panel to the left. Provide the OracleMetalink credentials and click Apply.
(c) Navigate to the Jobs tab. Create a job of the type RefreshFromMetalink and run it.
(d) If you have already upgraded the OMS to version 10.2.0.4, click the Deployments tab, then click the Patch Agent link. For versions of the OMS 10.2.0.3 or earlier, click Deployments, then Patch Oracle Software. Provide the patch number 3731596 and select the correct platform and 10.2.0.4.0 release.
(e) You can then select a number of targets to apply the patch. After selecting the target, select Use default patch script or Provide custom script option to allow OCM to be installed in the target Agent's home.
(f) If the target is a Microsoft Windows machine, then in the pre-script option specify the following:
%emd_root%\EMStagedPatches\3731596\3731596\ecm_3731596.bat
(g) If the target is on Solaris, Aix 5L, or HP-UX PA-RISC, then you must select Custom Post Command/Script, select Use sudo, and provide Custom Post Command/Script value as %emdroot%/root.sh. If Sudo is not installed on the target box then this step will not work. In this case root.sh will not run and you must manually run the root.sh on the target from the Oracle Home directory of the Management Agent.
This method copies the script to the selected number of hosts and runs a script to apply the Patch Set from the above staged location. It is advisable to choose a reasonable number of nodes so that the network is not overloaded.
You can patch the Management Agent on selected nodes of a cluster. To do this, you can use either of the following two methods:
Method 1 - By Distributing the Full Patch Set to a Number of Hosts
Method 2 - By Staging the Patch Set and Distributing Scripts to a Number of Hosts
You can choose one of the methods for mass patching of Management Agents. Method 1 is based on a "push" technique in which the entire set of patch binaries is transferred to all the hosts. Method 2 is based on a "pull" technique in which only a script is transferred to the targets and the patch is then installed over HTTP. Since it does not require to transfer the entire set of patch binaries in Method 2, it is the recommended method for large number of targets whereas Method 1 is more suitable for a limited number of targets. Note that for Method 2, the wget utility must be installed on the target machines and present in the PATH environment variable.
Method 1 - By Distributing the Full Patch Set to a Number of Hosts:
Login to Enterprise Manager Grid Control using SYSMAN credentials. Click Targets and check to see that the host is running.
Click Setup from the top right corner of the Grid Control console. Select Patching Setup from the panel to the left. Provide the OracleMetalink credentials and click Apply.
Navigate to the Jobs tab. Create a job of the type RefreshFromMetalink and run it.
If you have already upgraded the OMS to version 10.2.0.4, click the Deployments tab, then click the Patch Agent link. For OMS version 10.2.0.3, click Deployments, then Patch Oracle Software. Provide the patch number 3822442 and select the correct platform and 10.2.0.4.0 release..
You can then select all the cluster nodes to apply the patch. After selecting the target, select the Provide custom script option to allow OCM to be installed in the target Agent's home.
If the target is a Microsoft Windows machine, then in the pre-script option specify the following:
%emd_root%\EMStagedPatches\3822442\3822442\ecm_3822442.bat
If the target is on Solaris, Aix 5L, or HP-UX PA-RISC, then you must select Custom Post Command/Script, select Use sudo, and provide Custom Post Command/Script value as %emdroot%/root.sh. If Sudo is not installed on the target box then this step will not work. In this case root.sh will not run and you must manually run the root.sh on the target from the Oracle home directory of the Management Agent.
This method copies the patch to the selected cluster nodes and runs a script to apply the patch. The script creates blackouts, shutsdown the Management Agent before applying the Patch Set, clears the blackouts after applying the Patch Set, and then starts up the Management Agent. If the cluster is a very large one, then it is advisable to choose a reasonable number of nodes so that the network is not overloaded.
Method 2 - By Staging the Patch Set and Distributing Scripts to a Number of Hosts:
Note:
For Microsoft Windows target machines, patching through this method requires wget.exe to be in the PATH environment variable. If wget.exe is not in the PATH of the target machine, then add it to the PATH and rebounce the Management Agent by executing the following:<ORACLE_HOME>/bin/emctl stop agent
<ORACLE_HOME>/bin/emctl start agent
Perform the following steps on the OMS host:
Navigate to the following location, where <ORACLE_HOME> is the Oracle home directory of the OMS:
cd <ORACLE_HOME>/sysman/agent_download/
Create a directory:
mkdir -p patchset/10.2.0.4.0/<platform name>
You can then stage the Patch Set by either copying from the DVD or extracting the contents of the Metalink patch 3731593.
Copy the p3731593_102040_<platform name>.zip from the DVD or Metalink patch to an empty, temparory directory.
Extract the contents of the ZIP file to the same temporary directory created above.
Now navigate to the 3731593/Disk1 directory and copy its contents to the newly created directory in step (2):
To navigate:
cd 3731593/Disk1
To copy the contents to the newly created directory in step (2):
cp -r * <ORACLE_HOME>/sysman/agent_download/patchset/10.2.0.4.0/<platform name>
Here, ORACLE_HOME is the Oracle home directory of the OMS and "platform name" is one of the following:
Table 2 Descriptions of Platform Names
| Platform Name | Description |
|---|---|
|
linux |
Linux |
|
x86_64 |
Linux X86_64 |
|
ppc64 |
Linux on power PC |
|
linux390 |
z/Linux |
|
ia64linux |
IA64 Linux |
|
solaris |
Solaris 64 bit |
|
solarisx86 |
Solaris-x86 |
|
hpux |
HP-UX |
|
decunix |
HP Tru64 UNIX |
|
hpunix |
HP 64 bit |
|
hpi |
HPUX-Itanium |
|
aix |
AIX5L |
|
macosx |
MACOSX |
|
vms |
VMS |
|
windows_ia64 |
Microsoft Windows (64-bit IA) |
|
windows_x64 |
Microsoft Windows (64-bit AMD64) |
|
win32 |
Microsoft Windows 32 bit |
The above operation stages the contents of the Patch Set in the OMS host.
Note:
For an environment with multiple OMS servers, repeat steps 1 through 6 for each OMS server.After this happens, follow these steps:
(a) Login to Enterprise Manager Grid Control using SYSMAN credentials. Click Targets and check to see that the host is running.
(b) Click Setup from the top right corner of the Grid Control console. Select Patching Setup from the panel to the left. Provide the OracleMetalink credentials and click Apply.
(c) Navigate to the Jobs tab. Create a job of the type RefreshFromMetalink and execute it.
(d) If you have already upgraded the OMS to version 10.2.0.4, click the Deployments tab, then click the Patch Agent link. For versions of the OMS 10.2.0.3 or earlier, click Deployments, then Patch Oracle Software. Provide the patch number 3731596 and select the correct platform and 10.2.0.4.0 release.
(e) You can then select all the cluster nodes to apply the patch. After selecting the target, select the Provide custom script option to allow OCM to be installed in the target Agent's home.
(f) If the target is a Microsoft Windows machine, then in the pre-script option specify the following:
%emd_root%\EMStagedPatches\3731596\3731596\ecm_3731596.bat
(g) If the target is on Solaris, Aix 5L, or HP-UX PA-RISC, then you must select Custom Post Command/Script, select Use sudo, and provide Custom Post Command/Script value as %emdroot%/root.sh. If Sudo is not installed on the target box, then you must manually run the root.sh on the target from the Oracle home directory of the Management Agent.
This method copies the patch to the selected cluster nodes and runs a script to apply the Patch Set from the above staged location. It is advisable to choose a reasonable number of nodes so that the network is not overloaded.
This section describes the post installation tasks to be performed.
If you had upgraded multiple Oracle Management Services (OMS) by applying the patch set to one of the OMS's first, and then subsequently upgraded the remaining OMS's, then after the upgrade is complete the OMS restarts automatically. If the Agents are shutdown prior to the OMS upgrade then they must be restarted manually.
For information about upgrading the first OMS and repository, refer to Upgrading the First Oracle Management Service and Repository.
As part of the upgrade of a Grid Control installation from 10.2.0.3 or higher, you must download and install Clone Support Files from MetaLink and install the files onto each OMS as part of a post-patch configuration task to enable clone support for Oracle Tech stack components.
This step can often be overlooked and will result in issues for the cloning and provisioning subsystems.
(Bug 5975464)
Important:
If you have stopped your dbms jobs before applying the patchset then after applying the patchset you need to manually start your dbms jobs. To do this, follow these steps:Login into the SQL as SYSMAN
Run the following SQL command:
SQL> exec emd_maintenance.submit_em_dbms_jobs;
There is no mechanism provided for de-installing Patch Sets. If you are concerned about being able to revert to the environment that was existing before applying the Patch Set, then Oracle recommends that you back up your software installation before applying the Patch Set.
After applying the Patch Set, at any point if you want to revert to your old environment, then restore the backed-up software installation following these steps (in the order designated):
Restore the ORACLE_HOME directory that was backed up
Restore the repository database that was backed up
Restore the Oracle Inventory that was backed up
Contact Oracle Support Services if you are encounter any problem.
This section lists the known issues pertaining to this release.
This section addresses installation and upgrade issues.
This section covers all installation and upgrade issues in general.
Important:
For more information about upgrading the Grid Control environment, refer to the Document ID- 464674.1 on Oracle MetaLink at http://metalink.oracle.com/.When you apply the 10.2.0.4 Patch Set to upgrade your repository, the upgrade may fail.
In case of the Grid Control environment being installed via the "Enterprise Manager using New Database" option or "Enterprise Manager using an existing Database" option with a 10.1.0.4 or 10.1.0.5 database, then before upgrading to 10.2.0.4, apply the patch for bug 4329444 on the repository Database Home to avoid repository upgrade failure.
Note:
Patch 4329444 must be applied on the 10.1.0.4 or 10.1.0.5 repository databases that houses the repository. This patch is not required for Windows 10.1.0.4 or 10.1.0.5 databases that house the repository.Important: Oracle recommends that you back up your database before you perform the upgrade operation. Note that the patch 4329444 might conflict with some previous CPU releases (for example, April 2007 CPU) that might be applied to your repository database. In case of a conflict while applying patch 4329444, do not continue with the upgrade process. Contact Oracle Support to first resolve the patch conflict and then perform the following steps before performing the upgrade:
Login into the Database as SYS user
Check if there are any invalid SYSMAN objects
SQL> select object_name, object_type from all_objects where owner='SYSMAN' and status <> 'VALID';
The above query should return 0 rows. If there are rows, then run the below sql statement:
SQL> @admin_recompile_invalid.sql SYSMAN
The admin_recompile_invalid.sql script is available under ORACLE_HOME/sysman/admin/emdrep/sql/core/latest/admin/ where ORACLE_HOME is the Oracle home directory of the OMS.
Go to step 2 again to be sure all SYSMAN objects are valid. If you still have invalid SYSMAN objects that are not in the Recycle bin, please contact Oracle support.
Check to be sure there is no invalid SYS object:
SQL> select object_name, object_type from all_objects where status<>'VALID' and object_name like 'DBMS%';
The above query should return 0 rows. If there are rows, then try to "recompile" them. For example:
if the object_type = "PACKAGE" and object_name = "foo" alter package foo compile; if the object_type = "PACKAGE BODY" and object_name = "foo" alter package foo compile body;
If any of the packages fail to become valid even after recompilation, then Contact Oracle Support to assist you. Once this verification is done and to resume the upgrade process, go to <ORACLE_HOME>/oui/bin, where ORACLE_HOME is the Oracle home directory of the OMS and then run the following command:
./runConfig.sh ORACLE_HOME=<OMS_ORACLE_HOME> ACTION=patchsetConfigure MODE=perform COMPONENT_XML={oracle.sysman.top.oms.10_2_0_4_0.xml}
(Bug 5648438, 5665837)
While upgrading the OMS to 10.2.0.4, the repository upgrade might fail and the installer will display the following message:
OUI-25031: Some of the configuration assistants failed. It is recommended that you retry the configuration assistants as this time. Not successfully running any "Recommended" assistants means your system will not be correctly configured. 1. Check the Details panel on the Configuration Assistant Screen to see the errors resulting in the failures. 2. Fix the errors causing these failures. 3. Select the failed assistants and click the 'Retry' button to retry them.
When you see this message, go to the Oracle home directory of the OMS, that is, $ORACLE_HOME/sysman/log, and check the contents of emrepmgr.log.10.2.0.4.0.errors file created with the following:
ORA-20206: Target does not exist: :host ORA-06512: at "SYSMAN.MGMT_TARGET", line 571 ORA-06512: at "SYSMAN.EM_RAC_LICENSE", line 273 ORA-06512: at "SYSMAN.EM_LICENSE", line 221 ORA-06512: at line 27
Ensure that the above-mentioned error is the only error in the emrepmgr.log.10.2.0.4.0.errors file. Also confirm that the following error is captured in the $ORACLE_HOME/sysman/log/emrepmgr.log.10.2.0.4.0 file:
@ 85 END;--exception was added since we are granting @ license @ 86 --by invoking 'insert into table' directly and @ not through grant_license api; @ 87 --wherein otherwise this exception would be @ handled in grant_license() @ 88 END IF; @ 89 END LOOP;-- end c1 @ 90 END LOOP; @ 91 END IF; @ 92 COMMIT; @ 93 END; @ 94 / @ DECLARE @ * @ ERROR at line 1: @ ORA-20206: Target does not exist: :host @ ORA-06512: at "SYSMAN.MGMT_TARGET", line 571 @ ORA-06512: at "SYSMAN.EM_RAC_LICENSE", line 273 @ ORA-06512: at "SYSMAN.EM_LICENSE", line 221 @ ORA-06512: at line 27 @ .
This above error is harmless and it means that the "auto licensing" of these new packs introduced in 10.2.0.4GC (they are Identity Management Pack, Data Masking Pack and Oracle BI Management Pack) may not have worked for certain targets.
After you confirm the error messages, follow the steps:
Log in to the database as SYSMAN
Execute emd_maintenance.set_comp_status('_UPGRADE_', EMD_MAINTENANCE.G_STATUS_CONFIGURED_READY');
Exit SQLplus
Click Retry on the installer. Alternately, you can exit the Installer and run the runConfig command to run the failed config tools manually
Go to the <ORACLE_HOME>/oui/bin directory, where ORACLE_HOME is the Oracle home directory of the OMS, and run the following command:
./runConfig.sh ORACLE_HOME=<OMS_ORACLE_HOME> ACTION=patchsetConfigure MODE=perform COMPONENT_XML=(oracle.sysman.top.oms.10_2_0_4_0.xml)
Once the upgrade is completed successfully by following the steps mentioned above, use the Grid Control console to manually grant licenses for these packs. In the Grid Control console, log in as Super Administrator and click Setup, and then click Management Pack Access.
You can also refer to Document ID -559658-1 on OracleMetaLink at http://metalink.oracle.com/.
(Bug 6901072)
If you have applied the patch 5478872 to your Enterprise Manager Grid Control environment, then you MUST drop the index MGMT_DELTA_SNAP_IDX3 only before upgrading Grid Control to 10.2.0.4. If the index is not dropped, the upgrade process will fail.
To drop the index MGMT_DELTA_SNAP_IDX3, execute the following command:
Connect to SQL Plus session as EM repository owner (SYSMAN)
Issue the command SQL> drop index MGMT_DELTA_SNAP_IDX3
The fix for bug 5478872 is included in the patch set version 10.2.0.4 so you are not required to apply any additional patches to resolve this bug after upgrading to the 10.2.0.4 version of Grid Control. For details, refer to Document ID -558673.1 on OracleMetaLink at http://metalink.oracle.com.
If you have applied the patch 6606233 to your Enterprise Manager Grid Control environment, then you MUST roll back the patch before upgrading Grid Control to 10.2.0.4.
After rolling back the patch, upgrade Grid Control to 10.2.0.4 and then apply patch 6606233 that is specific to 10.2.0.4 Grid Control.
To roll back the patch, follow these steps:
Shut down OMS using the following command, where $ORACLE_HOME is the Oracle home directory of the OMS. In case of multi-OMS environment, shut down all OMSes. Leave the EM Repository database and its listener running.
$ORACLE_HOME/bin/emctl stop oms
In case of multi-OMS environment, if the .sql scripts were executed successfully from the first OMS, then run steps (7), (8 and (14). Skip other steps.
If the OMS and Repository are on the same machine, then set the TNS_ADMIN variable to <Repository Database Home>/network/admin, and then invoke SQLPLUS.
If the OMS and the Repository Database are on different machines, then create the tnsnames.ora file and set the TNS_ADMIN variable in the following location, where $ORACLE_HOME is the Oracle home directory of the the OMS:
$ORACLE_HOME/network/admin/
Create a tns alias in tnsnames.ora that points to the Repository database and connect to the Database repository. For example:
sqlplus sysman/<password>@<tns alias from $TNS_ADMIN/tnsnames.ora>
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT what, broken FROM dba_jobs WHERE log_user = priv_user and priv_user = (SELECT owner FROM dba_procedures WHERE object_name = 'MGMT_USER'AND procedure_name = 'DROP_USER') ORDER BY job;
IMPORTANT: Store the results of this query so that you can compare it with the results of the query run in step (9).
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT object_name FROM user_objects WHERE status = 'INVALID' order by object_name;
IMPORTANT: Store the results of this query so that you can compare it with the results of the query run in step (13).
Note the value of job_queue_processes in init.ora parameter<original count>:
SQL> show parameter job_queue_processes;
Connect to sqlplus as the SYSMAN:
ALTER SYSTEM SET job_queue_processes = 0;
Make sure the following query returns 0 rows. If the query returns non-zero records please wait and run again:
SELECT /*+ RULE */ * FROM DBA_JOBS_RUNNING ;
Set your current directory to the $ORACLE_HOME directory of the OMS where the patch is located:
% cd 6606233
Ensure that the directory containing the opatch script appears in your $PATH; then run the following command:
$ opatch rollback -id 6606233
Connect to sqlplus as the sysman and run the following SQL files (Be sure that the SQL commands are run in the order mentioned below):
SQL> @?/sysman/admin/emdrep/sql/core/latest/esm/esm_pkgdefs.sqlSQL> @?/sysman/admin/emdrep/sql/core/latest/esm/esm_pkgbodys.sql
Recompile the SQL packages in sysman schema by running the following pl/sql procedure:
SQL> @?/sysman/admin/emdrep/sql/core/latest/admin/admin_recompile_invalid <repository owner>
Where <repository owner> is the repository owner username in Upper caps (for example, SYSMAN and not sysman).
SQL> ALTER SYSTEM SET job_queue_processes=<original count>;
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT what, broken FROM dba_jobs WHERE log_user = priv_user and priv_user = (SELECT owner FROM dba_procedures WHERE object_name = 'MGMT_USER' AND procedure_name = 'DROP_USER') ORDER BY job;
Be sure that the output from the above query is exactly the same as the output obtained in Step 2. If not, please call Oracle Support immediately.
Connect to sqlplus as SYSMAN and run the following command:
SQL> SELECT object_name FROM user_objects WHERE status = 'INVALID' order by object_name ;
Be sure that the output from the above query is exactly the same as the output obtained in Step 3. If not, please call Oracle Support immediately.
Start the OMS using the following command. In case of a multi-OMS environment, start all the OMSes:
$ORACLE_HOME/bin/emctl start oms
Here, $ORACLE_HOME is the Oracle home directory of the OMS and "platform name" is one of the following
The above steps are also mentioned in the README document of the Patch. For information on upgrade prerequisites, refer to Document ID- 464674.1 on Oracle MetaLink at http://metalink.oracle.com/
If you are doing an additional OMS install pointing to a repository whose key is not present, then you will see following message:
"The emkey for securing the current Management Service does not exist in the repository you have specified. From the first Oracle Management Service install, execute "emctl prepare repository -new_oms_install" before proceeding with this install."
In this message, the command that needs to be run is incorrect. Therefore, follow these steps instead:
Rebounce the database.
Copy emkey.ora into /OH/sysman/config/
run ./emctl config emkey -emkeyfile /OH/sysman/config/emkey.ora
(Bug 5658897)
Agent configuration assistant may fail on RAC. To work around this issue, follow the steps below:
Exit the OUI terminal.
Set the ORACLE_HOME environmental variable to the Oracle home dir of the Agent:
export ORACLE_HOME=<Oracle home directory of the Agent>
Set the Path variable:
$ export PATH=$ORACLE_HOME/bin:$PATH
Go to the Oracle home directory of the Agent/bin and run the following command:
./agentca -f -c "node1,node2" -i <location of oraInst.loc file>
Note that the above command must be executed on each of the RAC nodes individually, one at a time. Each attempt will create/configure the agent directories on the local node. Once the command is executed successfully for each node, check the agent status on each node.
(Bug 6981631)
You cannot perform an additional 10.2.0.3.0 OMS install by using the repository of 10.2.0.4.0 OMS.
You can install additional 10.2.0.3.0 OMS with the following workaround if the repository is already upgraded to 10.2.0.4.0. To do this, complete the following steps:
Convert the repository version to 10.2.0.3.0 from 10.2.0.4.0 by using the following sql statement:
UPDATE sysman.mgmt_versions SET version = '10.2.0.3.0' where component_name='CORE'; commit;
Invoke the Installer from the 10.2.0.3.0 DVD and choose the Additional Management Service option.
Provide the repository credentials for the Specify Database Configuration Screen and click Next, then stop here. (Do not proceed with the install.)
Go to the database Oracle Home where the OMS is using the 10.2.0.4.0 repository and connect to the database through SQLplus.
Update the repository version to 10.2.0.4.0 by using the following sql statement:
UPDATE sysman.mgmt_versions SET version = '10.2.0.4.0' where component_name='CORE'; commit;
Then click Next to proceed with the installation from where it was previously stopped.
Once the 10.2.0.3 install has completed, both the Agent and the OMS must be shut down immediately by executing the commands below:
<ORACLE_HOME>/bin/emctl stop agent
Where ORACLE_HOME is the Oracle home Directory of the Management Agent
<ORACLE_HOME>/opmn/bin/opmnctl stopall
Where ORACLE_HOME is the Oracle home Directory of the OMS
Patch the OMS to 10.2.0.4 using the 10.2.0.4 Patch Set. Refer to Preinstallation Tasks Specific to the Upgrade Type in this document for more information on how to patch the OMS to version 10.2.0.4.
Once the OMS has been patched to 10.2.0.4 successfully, it will start automatically.
Restart the agent from the Oracle home directory of Management Agent:
<Oracle Home>/bin/emctl/start agent
(Bug 4910745)
Repository upgrade fails if the shared_pool_size is less than 512 MB. Ensure that the shared pool size is set as per your infrastructure. For information see Table B-2 in the Enterprise Manager Grid Control Installation and Basic Configuration Guide available at:
http://download.oracle.com/docs/cd/B14099_19/manage.1012/b16228/app_database_settings.htm
After setting the Shared pool size, continue with the upgrade.
(Bug 6887851)
If /etc/hosts of one or more nodes in a cluster do not have a hostname with the fully qualified domain name, then the state directories will be created with a short name and may end up with STATE directories in the agent home; one node with a FQDN hostname and another with a short hostname.For example, if there are two nodes in a cluster, host1.us.oracle.com and host2.us.oracle.com, then the /etc/hosts in both should have the hosts with fully qualified hostnames as seen below:
128.87.0.01 host2.us.oracle.com host2128.87.0.02 host1.us.oracle.com host1
(Bug 6217277)
If TAF (Transparent Application Failover) string is used in 10.2.0.x.x Grid Control, then the patching process will fail while patching an existing release of Enterprise Manager Grid Control to 10.2.0.2.0, 10.2.0.3.0, or 10.2.0.4.0 or higher.
To resolve this issue, select one of the approaches below:
Approach 1
Follow these steps:
Change the ConnectDescriptor in the emoms.properties to the sqlnet ConnectDescriptor. Then try running the configuration tool again.
For example, the sqlnet connect descriptor is:
oracle.sysman.eml.mntr.emdRepConnectDescriptor=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=stada37.us.oracle.com)(PORT\=1521)))(CONNECT_DATA\=(SERVICE_NAME\=emrep11.us.oracle.com)))
After the installation completes, change the connect string back to TAF.
Alternatively, you can exit the OUI installer.
Change the ConnectDescriptor in the emoms.properties to the sqlnet Connect Descriptor. Then run the following runConfig command to continue the installation.
Navigate to the bin directory:
cd <ORACLE_HOME>/oui/bin
Where ORACLE_HOME is the Oracle home Directory of the Management Agent
Go to <ORACLE_HOME>/oui/bin, where ORACLE_HOME is the Oracle home directory of the OMS, and then run the following command:
./runConfig.sh ORACLE_HOME=<OMS_Oracle_Home> ACTION=patchsetConfigure MODE=perform COMPONENT_XML={oracle.sysman.top.oms.<version>.xml}(version can be '10_2_0_4_0')
After the installation (configuration) completes, change the connect string back to TAF.
Approach 2
If you upgraded the repository manually after the installation fails, then in order to run the remaining configuration tools by skipping the Repository Upgrade Config Tool, follow these steps:
Exit the OUI installer
Create the response file (for example, patchsetconfig.rsp) by adding the following parameter:
b_reposPatchUpgrade=false
Move to the bin directory
cd <ORACLE_HOME>/oui/bin
Where ORACLE_HOME is the Oracle home Directory of the OMS
Go to <ORACLE_HOME>/oui/bin, where ORACLE_HOME is the Oracle home directory of the OMS, and then run the following command:
./runConfig.sh ORACLE_HOME=<OMS_Oracle_Home> ACTION=patchsetConfigure MODE=perform COMPONENT_XML={oracle.sysman.top.oms.<version>.xml} (version can be '10_2_0_4_0')
(Bug 5672859)
If you used the seed database during a 10.2.0.3 installation and are upgrading to 10.2.0.4, please use the following steps before running the OUI to be sure Management Connectors are deployed correctly:
Log into the repository as sysman and run the following query:
SELECT * FROM mgmt$connector;
If you see an error that says the table or view does not exist or there is no record returned, proceed with the next step. Otherwise, skip the step.
Rename the following directories in the OMS home:
mv $ORACLE_HOME/sysman/connector/Remedy_Connector $ORACLE_HOME/sysman/connector/Remedy_Connector.orig.1
mv $ORACLE_HOME/sysman/connector/Microsoft_Operations_Manager_Connector
$ORACLE_HOME/sysman/connector/Microsoft_Operations_Manager_Connector.orig.1
(Bug 6939959)
The Oracle Central Inventory directory (oraInventory) stores an inventory of all software installed on the system. It is required by, and shared by, all Oracle software installations on a single system. The first time you install Oracle software on a system, Oracle Universal Installer prompts you to specify the path to this directory. The path to the Oracle Central Inventory directory should be on a local file system.
(Bug 6945830)
When installing version 10gR2 RAC on Oracle Enterprise Linux 5 or RHEL5 or SLES10, you must address a series of issues during installation. The problems and solutions are described in the MetaLink ID -414163.1. If these issues were not resolved during installation, patching RAC by way of Deployment Procedures could result in errors.
For example the 'Stop' and 'Start' steps along with steps that use the 'srvctl' command will result in errors.
You must ensure the steps mentioned in the above MetaLink note are addressed during installation before using the patching deployment procedures.
(Bug 6908484)
After performing a version 10.2.0.4 software-only installation, the Agent may not upload because of a failure to update the emd.properties (<AOH>/sysman/config/emd.properties) file with the correct value of EM_UPLOAD_PORT. To correct this issue, please run the following command:
agentca -f from <AOH>\bin
(Bug 6998503)
After upgrading the Agent, the Agent appears in blackout and you must manually stop the blackout. The blackout can be stopped either from the Grid Control console or through the command line.
To stop the blackout from the command line, follow these steps:
Go to the Oracle Home Dir of the Agent/bin
Run the command below:
$ emctl stop blackout
To stop the blackout from the Grid Control console, follow these steps:
Go to the Grid Control Home page -> Click on the Setup (extreme right corner) ->Click on the Blackout section from the left panel
Search the Blackout for the required Agent and stop it
(Bug 5736358)
This section covers issues that related to the Agent Deploy application.
ignoreMessages.txt is not picked up by remote infrastructure if it is edited with text editors like Microsoft Word or Wordpad. The agent deploy application results in an application error.It is a good practice to backup a file before modifying it. Use text editors like Notepad or Vim to edit the ignoreMessages.txt available at the following location, where $ORACLE_HOME is the Oracle home directory of the OMS:
<$ORACLE_HOME>/sysman/prov/resources
(Bug 5727231)
If there is a banner displayed in the remote machine, make sure it is not displayed for non-interactive shell commands. You can accomplish this by enveloping the banner message script in an "if" condition for interactive mode, as seen in the example below. The banner script is typically found in a shell rc file - .bashrc, .cshrc or in a .profile file in the user home.
For bash shell:
if [ -n "$PS1" ]; then echo "hello world" fi
For C shell and its variants:
if ($?prompt) then echo "hello world" endif
As a result, the banner message will be displayed in interactive logins but will not interfere with remote non-interactive commands.
(Bug 6371499)
On rebooting a machine where the agent is installed, the agent startup script might not bring up the agent automatically on those machines where su has not been installed/configured to accept the parameters "-l" & "-c". On those machines the user may have to start the agent manually by the command:
$ORACLE _HOME\bin\emctl start agent
Where ORACLE_HOME is the Oracle home Directory of the Management Agent.
(Bug 6752541)
On securing the Solaris version 10.2.0.4 Agent manually you may receive the following error message:
AsciiDecode: Failed to allocate ascii encoding buffer (status-1).
Decrypt: Failed to ascii decode encrypted-text (status=1).
This error is harmless and you can ignore it if securing of the agent is successful.
(Bug 6813669)
If OCM is chosen in the agent deploy interview screens and the user does not have permission to edit the crontab, the OCM configuration may fail. To correct this, follow the steps below:
Manually set up SSH using the SSHConnectivity.sh file available under <OMS_HOME>/sysman/prov/resources/scripts.
Run the following command on the OMS box where the username is the install user and the hostname is the target machine:
# ssh -l username hostname env
Search for the pattern SHELL=<shell name> in the output of the previous command to get the default login shell on the target machine.
On the target machine edit the corresponding rc script for that shell in the install user's home directory. For example, for C shell edit the <install_user_home_dir>/.cshrc and add the following command:
setenv CCR_DISABLE_CRON_ENTRY 1
Proceed with agent install using the agent deploy application.
(Bug 6473318)
CCR Agent configuration is not completed. The CCR configuration will run only after the agent configuration completes and it produces no CCR logs. Manual execution of CCR failed because the userid is not present in crontab. Adding the userid (oracle) in /usr/lib/cron/cron.allow after adding the ccrconfig fixes the problem.(Bug 6826399)
When configuring High Availability environments using a Server Load Balancer (SLB), changes made to the security frame work of Grid Control deprecate the need to have a separate pool to secure agents. As a result, you no longer need to configure the 'genWallet' pool as described in the Common Configurations chapter (Chapter 3) of the Oracle Enterprise Manager Advanced Configuration guide.
(Bug 5121288)
This section addresses the issues related to OMS and Management Agent.
When using the seed db option for a 10.2.0.3 Grid Control repository, there will be an ORA-14074 error in the system error log in addition to having more than 2000 partitions on the mgmt_metrics_raw/1hour/1day table. The workaround is to re-install using the no-seed database. Optionally you can instead complete the following steps:
Stop OMS
Stop DBMS jobs
Run the following in sqlplus as the repository owner:
exec emd_maintenance.ADD_PARTITIONS('MGMT_METRICS_RAW',5,FALSE);exec emd_maintenanceADD_PARTITIONS('MGMT_METRICS_1HOUR' ,5,TRUE);exec emd_maintenance.ADD_PARTITIONS('MGMT_METRICS_1DAY', 5,TRUE);
You can optionally run the following to remove the large number of created partitions, however this will take time:
exec emd_maintenance.partition_maintenanceStart DBMS_JOBS
Start OMS
(Bug 6413404)
If Enterprise Manager is shutdown for a long period of time, you must run emd_maintenance.analyze_emd_schema() before conducting the upgrade.
(Bug 6377899)
Running jobs through powerbroker is not supported in grid control in 10.2.0.4. Selecting the powerbroker option when setting preferred or overridden credentials for a job will cause the job to fail.
(Bug 6453707)
Enterprise Manager displays only one application instance per Oracle Home even though multiple instances might have been configured. Apply ARU Patch Request No. 9808755 to resolve this error. Access Automated Releases Updates at http://aru.us.oracle.com/.
(Bug 6644329)
For proper functioning of the Linux Administration feature, the user whose credentials are entered in the OMS for Linux Administration needs to have a home directory on the target machine being administered and write access to $HOME/.y2log on the target machine. If the above conditions are not fulfilled, blank lines may be seen in Linux Administration tables in addition to the actual data.
(Bug 6919918)
This section addresses patch management issues.
Patching windows shared RAC agent with a patchset or patch is not supported through the Patch Wizard.
You must upgrade the agent using the Oracle Universal Installer (OUI). Do not use the Patch Wizard. For more information on how to upgrade the agent using the OUI, see Preinstallation Tasks Specific to the Upgrade Type.
(Bug 6393304)
If the Linux target (including Oracle Enterprise Linux) has a sudo version 1.6.8, and SELinux (Security Enhanced) is enabled, then Emergency patching and Update Job from Linux host patching may fail without errors.
This is a known issue from Redhat. Bug 178429: SELinux Patch Breaks sudo noexec Capability is a precedent for this issue. For details, you can refer to the following site:
https://bugzilla.redhat.com/show_bug.cgi?id=178429
As a workaround, you can do the following:
Update sudo version to 1.6.9 (recommended)
Remove sudo selinux patch. (Rebuild sudo without the selinux)
To determine whether SELinux is activated, you can run the following command:
ls -Z
If SELinux is activated, a valid output is displayed. If SELinux is not activated, an error message, -Z option is valid only for SELinux machines is displayed.
(Bug 6395554)
The repository in the Staging server host is corrupted or not created properly. This may be because either the Staging server host may be a part of any Linux Patching Groups created or the up2date tool method is used in patching the staging server host through Emergency patching or Linux Hosts Patching deployment procedure. This corrupts the header files created in the staging server by the Linux Staging Server Deployment Procedure. The procedure configures the up2date tool to communicate with the subscribed ULN channels. Header files created by running yum-arch and the createrepo tool gets deleted.
To address this problem remove the 'Staging Server Host' from all of the Linux Patching Groups if present. Then run the following steps in the Staging Server Host:
Login as root user in the Stage server machine
Edit the file /etc/sysconfig/rhn/sources
Comment out the following line:
yum LocalRPMRepos <Local Repository> ( #yum LocalRPMRepos <Local Repository>)
Uncomment the line:
#up2date default to up2date default
Re-run the "Linux Staging Server" Deployment Procedure
Note:
To patch the Staging server host, use the "Patch Linux Host" Deployment Procedure and select YUM update tool only to update the host.(Bug 6429484)
When this error occurs, delete the component p4898608_10.2.0.4_2000 from the software library and rerun the Opatch Update job.
To remove the above component please complete the following steps:
Navigate to the Deployments tab and choose Provisioning, then Components, and finally OracleSoftwareUpdates.
Click on the radio button next to the component p4898608_10.2.0.4_2000
Click Delete.
(Bug 6519240)
This section addresses the client side monitoring issues.
10.2.0.4 beacon cannot playback a Oracle Apps R12 Forms transaction if the beacon is created on an agent installed out of the box. You can see the following error message :
"Forms version not supported: apps". In order for beacon to playback a forms transaction, a set of Forms jar files must exist under EM agent $EMAGENT_HOME/jlib/forms/<version>/ directory that exactly matches the jar files on the Forms server. 10.2.0.4 agent shiphome build contains release version of the jar files from Forms 9.0.4.3 and 10.1.2.2, but not the custom patched Forms version contained in Apps R12 tech stack. As a workaround, you need to copy the following jar files manually from your Oracle Apps deployment to EM agent:
$COMMON_TOP/java/classes/oracle/apps/fnd/jar/fndforms.jar $COMMON_TOP/java/classes/oracle/apps/fnd/jar/fndewt.jar
These jars need to be copied to the following directory for every beacon agent which is used to monitor the application:
.$EMAgent_HOME/jlib/forms/apps/
Only one version of Oracle Apps can be monitored by a single EM Agent. If you have two deployments of Apps with different versions, then you need two EM Agents to monitor them. You need to apply the workaround for each of those agents.
(Bug 5458061)
HTTP session cookies are cleared incorrectly before the final logout step is performed. As a result, the session is not being logged out from the EBS server and would cause lingering session on the server.
There is no workaround for this issue. A patch is available to address this problem.
(Bug 6445743)
When displaying the Disk Details page from the Performance page of the Host Target home, the Top Disk Devices table shows the following incorrect column values:
Blocks Read (512 bytes per second) shows total transfers instead of only blocks read
Blocks Written (512 bytes per second) always (incorrectly) shows zero
When displaying the Disk Activity page from the All Metrics page of the Host Target home, the Disk Activity table shows the following incorrect column values:
Difference in Number of Reads shows difference in total transfers instead of difference in number of reads
Difference in Number of Writes is always shown (incorrectly) as zero
Disk Block Writes (per second) is always shown (incorrectly) as zero
(Bug 6767592)
When viewing Disk Details on the Host Performance page, the Top Disk Devices table can sometimes show negative values for Average Service Time (ms).
When viewing Disk Activity details from the All Metrics page of the Host target, the Disk Activity table can sometimes show negative values for Bulk IO Ticks and Average Disk I/O Service Time (ms).
(Bug 6911699)
The following are known licensing issues.
The Grid Control Licensing Information page of the Grid Control console, accessible from the About Oracle Enterprise Manager page identifies premium functionality contained within Enterprise Manager that requires a separate Oracle license. The Licensing Information page is missing information or displaying incorrect information as described below:
The Provisioning Pack for Oracle Application Server does not appear on the Licensing Information page. The Provisioning Pack for Oracle Application Server automates deployment of software, applications, and patches. This pack provides functionality for provisioning of operating systems and software images, cloning of existing installations and software images on both bare-metal and live machines, and patching. Sizeable decreases in person-hours and costs can be achieved by using mass provisioning and patching, offering an easily quantifiable return on the investment of this management pack. Key features include the following:
Extensible, out-of-box best practice
Deployment procedures for provisioning and patching
Oracle Home cloning
Extend Oracle Application Server DCM Managed Cluster
Bare metal provisioning
Automated patching for the Oracle Application Server and underlying operating system
Software image library
CLI driven runtime
Critical Patch Facility
Enterprise Security Advisory
Provisioning and deployment reports
(Bug 6403098)
Provisioning Pack for Oracle Database does not appear on the Licensing Information page
Diagnostics Pack for Non-Oracle Middleware does not appear on the Licensing Information page. The Oracle Diagnostics Pack for Non-Oracle Middleware displays the following target types:
BEA WebLogic Server
IBM WebSphere Application Server
JBoss Application Server
The Diagnostics Pack for Non-Oracle Middleware ensures high availability of mission-critical applications hosted by non-Oracle middleware by reducing the complex tasks of diagnosing and correcting application performance problems. Key features include the following:
Monitor availability and performance statistics out-of-box
Monitor end-user performance
Perform trend analysis on collected performance information
View and compare configuration data, as well as track configuration changes
Receive email and/or page notification concerning potential problems surrounding availability and performance
Gain access to out-of-box, customizable reports
Monitor third party software via remote Management Agent. For remote monitoring, the Management Agent does not need to be on the same computer as the third party software
(Bug 6403105)
System Monitoring Plug-in for Non-Oracle Middleware erroneously includes affiliated target types of BEA WebLogic Managed Server, IBM Websphere Application Server, a JBoss Application Server. These target types should be affiliated with the Diagnostics Pack for Non-Oracle Middleware.
The System Monitoring Plug-in for Non-Oracle Middleware should include only the following targets:
IBM WebSphere MQ
Microsoft Exchange Server
Microsoft Active Directory
Microsoft Internet Information Services
Microsoft Internet Security and Acceleration Server
Microsoft Commerce Server
Microsoft BizTalk Server
Microsoft .NET Framework
(Bug 6403069)
On the Management Pack Access page of the Enterprise Manager Version 10.2.0.4 console, the tip text at the bottom of the page should read as follows:
For a detailed description of the above functionality and where they can be used within the product, refer to the Oracle Database Licensing Information document, the Oracle Application Server Licensing Information document, or the Oracle Enterprise Manager Licensing Information document.
This corrects an issue when selecting either Web Application or Service from the drop-down list. As written, the previous and incorrect tip text does not accurately indicate that licensable information for web applications or services is not documented in the Oracle Database Licensing Information guide or the Oracle Application Server Licensing Information document. It is only available in the Enterprise Manager Licensing Information document.
(Bug 6373701)
The following are known console issues.
After navigating to Targets > Databases, if you enter a search criteria and click Go, then you may encounter the following error:
An error has occurred! Error retrieving information from database. Exception: java.sql.SQLException: No more data to read from socket
As a workaround, apply the RDBMS one-off patch for bug 6266400.
(Bug 6169403)
During table creation for 8.1.7 target databases, tablespaces are not being displayed in the LOV of the Search & Select Tablespace page. The issue does not prevent any create table functionality. A list of tablespaces can be retrieved from the tablespaces link. An alternative workaround is to type in the desired tablespace name.
This issue is also encountered for a single instance 8.1.7.4.1 database on a Windows host that is monitored by a 10.2.0.4 Grid Control site on HP-UX Itanium.
(Bug 6408462)
If you select one of the real time choices in the View Data list on the Oracle Access Manager Performance page and then wait for a period of time, the charts (with the exception of "Sucessful Authentication") will not be shown. Instead, an unhandled Java exception will occur and will be displayed in the location of the charts.
This is an installation issue regarding Access Manager monitoring.
(Bug 6405009)
When monitoring a 8.1.7.4 database, the Instance Lock page may not work. If there are two sessions both trying to gain an exclusive lock on a table, one of them would be blocked without the Instance Lock page indicating such.
This should work properly on 8i databases if you log in with a user that has 'select any table' privileges.
(Bug 6460295)
When adding or deleting a 10.2.0.x database instance, the following error may occur after entering Host Credentials on the Cluster Credentials page:
Error Cannot get SQLEngine Operation Failed. Refer logs at $ORACLE_HOME/cfgtoollogs/rconfig/rconfig.log and $ORACLE_HOME/cfgtoollogs/dbca/trace.log for more details
This is due to a Sun JCE mismatch in the 10.2.0.x Database Home. You can fix the problem by modifying $ORACLE_HOME/bin/rconfig in the Database Home to change the JRE_DIR location from:
$ORACLE_HOME/jdk/jre
to
$ORACLE_HOME/jdk/opt/jdk1.4/jre
(Bug 6910792)
When using the Add Instance wizard to add a database instance to a cluster database, you may receive the following error on Step 2 - Add Instance: Host if there are any stale database instance targets in the Cluster Database.
oracle.sysman.emo.util.rconfig.StepExecutionException: java.lang.NullPointerException
You can remove a stale database instance target, which is in an error state, by following the Monitoring Configuration link from the Cluster Database home page. Once the stale target is removed, the Add Instance wizard should proceed.
(Bug 6918474)
The following sections describe known security issues.
You may find that OMS and Agent using the SLB are initally secure and working. However, after a period of time the communication between the agent and OMS through SLB may stop working. wget https://smpperf-gsvc4.us.oracle.com:1159/em/upload (SLB does not work) wget https://staka14.us.oracle.com:1159/em/upload (Directly to OMS works) wget http://smpperf-gsvc4.us.oracle.com:4889/em/wallets/emd (SLB does not work)
wget http://staka14.us.oracle.com:4889/em/wallets/emd (Directly to OMS works) To restore communication between the OMS via SLB and the agent, reboot the agent machine. Rebooting the SLB does not clear the problem.
(Bug 6025580)
Communication between EM agents and EM management services stops occasionally when the management services are fronted by a load balancer. This appears to be a TCP stack issue that manifests itself on some Linux platforms when communication is done via a load balancer. Internal test sites have exhibited this issue when agents and management services are running RedHat Linux and communicating through a IGIP load balancer. Turn off tcp_timestamps option. On most flavours of Linux this can be done by setting the following sysctl parameter: # Turn off the tcp_timestamps net.ipv4.tcp_timestamps = 0
(Bug 6085086)
Prior to version 10.2.0.4, Enterprise Manager created users with uppercase passwords. Version 10gR2 and earlier databases supported only case-insensitive passwords. EM users were able to log in to EM providing passwords in any case.
Starting in version 11g, support for case-sensitive passwords was initiated. As a result, if you use DB11g for the repository and creates a user, for example TEST_USER with password TestUser01, then the user will be successfully authenticated only if he provides exactly "TestUser01" as the password. Any other variation such as "testuser01" or "TESTUSER01" will fail during authentication.
However, if you use a pre-11g database for the repository the user will be able to provide any of the "testuser01" variations to log in to the database. Also, if the database that holds the repository is upgraded to version 11g, then all existing user passwords will be converted to upper case passwords and only upper case passwords are allowed for authentication.
There is an init.ora parameter that version 11g databases support that allows for old-style case-insensitve authentication.
(Bug 6073321, 6073322)
The following sections are known deployment library issues.
Component/Image/Directive with a non-English configuration property name leads to provisioning failure. Further, component/image/directive UI may not show any data when you save a component/image/directive that has a property name in locale other than English.
This is a dynamic reference and it cannot be non-English.
As a workaround, always create a configuration property with English locale.
(Bug 6315953)
The following sections are known data masking issues and limitations.
Data Masking performs masking operation based on a user-specified masking definition which includes masking columns and masking formats. If the masking format contained multibyte character strings, masked data appears garbled rather than in a specified multibyte character string format. This is a known limitation in data masking and will be addressed in a future release. In version 10.2.0.4.0 of Grid Control, use only an English string format to mask character data.
(Bug 6474636)
If a masking definition or format library contained multibyte character strings, after Export an attempt to Import an xml file into another Grid Control system results in garbled strings replacing multibyte character strings. This is a bug in Import and will be fixed in a future release.
(Bug 6474596)
The following sections are known provisioning issues.
When running the Oracle Patch Prerequisite Checker for Standalone Database deployment procedure, the step Run Prerequisite Checks fails with the following message:
Incorrect Component URN: null
The problem itself is not a product defect but is due to the fact that Oracle does not ship all Software Library Components for all platforms by default. Please refer to WebIV note:
http://webiv.oraclecorp.com/cgi-bin/webiv/do.pl/Get?WwwID=note:468344.1
The WebIV note explains how to create the missing component for the affected platforms.
(Bug 6797068)
In a setup where the cluster is owned by user 'A' and the agent by user 'B', the deployment procedure Patch Oracle Clusterware fails in the Targets Discovery step. To address this, run the Targets Discovery step of the deployment procedure as the agent owner. For example, run this step with Run Privilege sudo and Run Privilege Command sudo -u A.
(Bug 6862744)
The deployment procedure Patch Oracle Clusterware cannot be run with some other user as the patching user in 'Sudo' mode. The deployment procedure has a small number of execute root scripts that change the permission of files in CRS home. These steps, if executed with a different patching user, create files with permission of patch users rather than CRS home owner. For example:
X is crs_home owner
Y is patching user
A CRS patchset is applied with user Y and sudo command of sudo -u X. After patching, the CRS dir contains many files with ownership of B user. There is no workaround for the above issue.
(Bug 6338831)
Application Server has very restrictive permissions for group and others. All directories under AS Home have permissions of either 700 or 600. Therefore even if users A and B belong to the same group, AS is not being discovered by the OMS. This is true even for the AS target cloning. The cloned AS target will not appear in the OMS until it has been manually discovered after applying the below mentioned workaround:
Permissions of following files and directories in iAS home have to be recursively set to 770:
<iashome>/sysman/emd/targets.xml
<iashome>/sysman/emd/centralagents.lst
Permissions of following files/directories in GC Agent home have to be recursively set to 770:
<gcagenthome>/sysman/emd/targets.xml
<gcagenthome>/sysman/opmn/
<gcagenthome>/sysman/opmn/conf/
For an example of setting permissions recursively, consider setting 770 permissions to <iashome>/sysman/emd/targets.xml. This should be performed similar to the following:
chmod 750 <iashome>/
chmod 750 <iashome>/sysman/
chmod 750 <iashome>/sysman/emd/
chmod 770 <iashome>/sysman/emd/targets.xml
For an example of restoring permissions, consider restoring permissions of <iashome>/sysman/emd/targets.xml to 700. This should be performed as seen below:
chmod 700 <iashome>/sysman/emd/targets.xml
chmod 700 <iashome>/sysman/emd/
chmod 700 <iashome>/sysman/
chmod 700 <iashome>/
Note:
Please set 770 permissions to these optional files, only if required. For example, you should only set permissions only if discovery still fails after the below activities are performed:<iashome>/opmn/conf/opmn.xml
<iashome>/config/ias.properties
<iashome>/sysman/config/emd.properties
Please restore the permissions at the end of discovery.
(Bug 6576991)
Prereq deployment procedure has not been ported to HP-UX Platform. It is certified only on Linux, Windows, and Solaris platforms.
If the OUI version is less than 10.2.0.3.0, then download the OUI from MetaLink. The patch number for OUI 10.2.0.4.0 is 6640752. Install the OUI component that was downloaded. This will upgrade the OUI in the Oracle Home to 10.2.0.4.0. Then follow the workaround mentioned in the following note:
http://webiv.oraclecorp.com/cgi-bin/webiv/do.pl/Get?WwwID=note:468344.1
(Bug 6797068,6905935)
If the user executing the clone operation is not the Agent user on the target machine, then the clone operation will fail when trying to add the newly cloned Oracle Home to the OUIinventories.add file.
The permission of $ORACLE_HOME/sysman/config/OUIinventories.add must be the changed so that the group to which it belongs also has write privileges to the file. The user executing the clone operation must belong to the same group. This file is in the Agent Oracle Home.
(Bug 6871174)
While installing Application Server only from Gold Image with the Stand Alone option, the installation fails in the configure step. Provisioning Standalone AS 10.1.3 from Gold Image fails with the below error
"getaddrinfo(, , 1) failed (host/servname not known): Unresolved discovery multicast address and port:, unable to reload opmnctl"
There is no workaround for the above issue.
(bug 6868378)
If the Application Server shiphome exceeds 2.1 GB of size, then Application Server Provisioning fails. It will result in an error while unzipping the files.
Bug (6878555)
Extending Oracle Clusterware on HP-UX using the Enterprise Manager Cloning Wizard is deprecated. To extend a cluster, use the Extend Cluster Database deployment procedure that is available on the Deployments page.
To access the Extend Cluster Database deployment link, log in to Enterprise Manager Grid Control and click Deployments. In the Deployments page, from the Deployment Procedure Manager section, click Extend Cluster Database. Enterprise Manager Grid Control displays the Extend Real Application Clusters page. Click Help for information about what details to specify and how to run the deployment procedure.
(Bug 6921833)
The following table lists the deprecated use-cases for provisioning Oracle Software using the Enterprise Manager Cloning Wizard and the corresponding Deployment Procedure to be used instead.
| Use Case | Deployment Procedure |
|---|---|
| Scale up the RAC stack | Extend Cluster Database (Deployments Tab->Extend Cluster Database link) |
| Single Instance Database Provisioning | Database Provisioning Procedures (Deployments Tab->Database Provisioning Procedures) |
| Oracle Clusterware / RAC Database Provisioning | RAC Provisioning Procedures (Deployments Tab->RAC Provisioning Procedures) |
| AS 10.1.2.0.2 myJ2EE (webtier + apptier) farm | Application Server Provisioning Procedures (Deployments Tab->->Application Server Provisioning Procedures) |
| AS 10.1.3 myJ2EE webtier or apptier standalone | Application Server Provisioning Procedures (Deployments Tab->->Application Server Provisioning Procedures) |
The above listed scenarios are in correspondence to the Enterprise Manager cloning Functionality available.
(Bug 6914611)
During patchset application on a CRS target using the "Patch Oracle Clusterware - Rolling" Deployment Procedure, the CRS version might not be updated on the Enterprise Manager Console, despite successful application of the patchset on the target. Workaround for this is to bounce (stop and then start) agents on the cluster nodes and then run the Refresh Host Configuration job for each cluster node. This will result in the correct version being reflected at the Enterprise Manager Console.
(Bug 6955323)
During patchset application on a CRS target using the Patch Oracle Clusterware - Rolling Deployment Procedure or patchset application on a RAC target using the Patch Oracle RAC Database - All Nodes Deployment Procedure, certain RAC database targets running on the cluster may appear to be unconfigured on the Enterprise Manager console. To address this issue, reconfigure Monitor Password for the unconfigured targets.
(Bug 7018196)
Follow the steps below to create a swlib component for platforms other than Linux-32, Solaris-64, and Windows.
Pick the OUI from the oracle home of the target being patched
Pick the OPatch from: <OMS_ORACLE_HOME>/sysman/prov/paf/patchAdvisor.par
Make OUI_OPATCH component with these `oui' & `OPatch' in Enterprise Manager
Run the pre-req deployment procedure
Once the 10.2.4.3 Opatch comes out (the base bug) in step 2 above, use the 10.2.4.4 opatch which is available from Metalink or the Oracle home.
(Bug 7016060)
The database shiphome can be created using software library using the following steps:
Download the zip file (10201_database.zip) from the OTN site
Unzip the contents of the zip file. The root directory should be Disk1. Rename the directory to database. The sub-directories remain unchanged.
Zip the database directory and name the zip file 10201_database_hpux.parisc.zip
Upload the zip file (10201_database_hpux.parisc.zip) as database shiphome
(Bug 7010301)
SIDB provision with installed software as source fails at the step Run Database Configuration Tools.
(Bug 7010737)
CVU checks for the existence of many packages and OS patches on a HP-UX PA-RISC machine, all of which are not required for CRS installation. The pre-install CVU check step may fail as a result of this.
The user can verify whether the necessary patches and packages required for installation (specified in stage/prereq/crs/refhost.xml) are present on the machine.
The command to list the existing patches is:
/usr/sbin/swlist -l patch -a supersedes
The command to list the existing products is :
/usr/sbin/swlist -l product
After verifying that the necessary bundles and patches are available, the user can ignore the step failure and continue with the rest of the deployment procedure.
(Bug 7032023)
During the extend cluster Deployment Procedure, $CRS_HOME/evm does not contain a log directory. This results in the installation failing to dump any logs and the installation subsequently hangs.
To fix this problem, a log directory is created under $CRS_HOME/evm as part of the 'Verify prerequisite checks' step.
(Bug 7121050)
On running the RAC provisioning Deployment Procedure in HP version 11.31, the Deployment Procedure succeeds until the DB verification step where it fails because the DB is not up and the CRS is not configured properly.
Running vipca (as part of CRS root scripts) fails with the following message:
Running vipca(silent) for configuring nodeapps. The given interface(s), "lan0" is not public. Public interfaces should be used to configure virtual IPs.
However, if vipca is run manually from the command prompt and the same public interface (lan0) is used, CRS is configured properly and comes up successfully. Since CRS was not configured initially, configuration scripts for DB (netca and dbca) also fail. These must be run manually using the same commands as used in the directives to configure the database.
Once these are executed manually, both CRS and DB come up successfully and the verification step succeeds on retrying.
(Bug 7128866)
The Deployment Procedure checks for the Operating System version in the prereqs step and displays the following error:
Checking operating system version: must be B.11.23. Actual B.11.31
The 10.2.0.1 shiphome does not support the 11.31 Operating System version for HP. It only supports versions 11.11 and 11.23. Since the platform is certified post production, the user can ignore the step and continue.
(Bug 7109865)
This section addresses third-party application server monitoring issues.
When Admin Security on WebSphere 6.1 Server is enabled, Grid Control is unable to discover and monitor the targets. The SOAPConnectorClient, which is a part of the WebSphere jar files, uses the "contains" method of the String class. The "contains" method was introduced since jdk 1.5. But the current version of Java shipped along with Agent is jdk 1.4. You can continue to add and monitor WebSphere 6.1 provided Admin Security is not enabled.
(Bug 6241737)
This section addresses configuration standard framework issues.
Repository Upgrade configuration assistant fails when you upgrade a Grid Control environment that has a seed database. As a workaround, you need to apply ARU 8885534 (that contains ARU "4329444") on top of DB 10104 before you upgrade to Grid Control 10.2.0.3.
(Bug 5648438)
On HP-UX Itanium systems, a system sometimes reboots after running for four days or longer.
If the agent is installed on a file system of type lofs (a loopback file system), it is possible for the agent to cause a kernel panic, crashing the entire system. Oracle strongly recommends that you not install the agent on such a loopback filesystem.
Note that a loopback file system mount can be created either explicitly, or when a host mounts an NFS volume exported by the host itself. If there is any doubt about whether a particular file system is mounted with lofs, run '/usr/bin/df -F lofs' for a list of all loopback file systems currently mounted.
If this kernel panic does occur, analysis of the resulting crash file with adb will indicate the following stack:
lo_realvfs+0x110
freelonode+0x170
lo_badop+0x1b70
vn_rele+0x420
lookuppnvp+0x3b0
lookuppn+0x90
lookupname+0x60
vn_open+0x80
copen+0x190
open+0x80
syscall+0x920
(Bug 6790425)
Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at
http://www.oracle.com/accessibility/
Accessibility of Code Examples in Documentation
Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.
TTY Access to Oracle Support Services
Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the United States of America 24 hours a day, seven days a week. For TTY support, call 800.446.2398.
Oracle Enterprise Manager Grid Control Release Notes, 10g Release 4 (10.2.0.4.0) for HP-UX PA-RISC (64-Bit)
Copyright © 2008, Oracle. All rights reserved.
The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|