Oracle® Enterprise Manager

Upgrading the First Oracle Management Service and Repository

When you have multiple Oracle Management Services (OMS), you can choose to upgrade them one-by-one. When you upgrade the first OMS using the Patch Set, note that the Patch Set also upgrades the associated repository.

The steps to be taken before upgrading the first OMS are:

• Leave the repository database and listener instance running.

• In case of Grid Control environment installed via "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.3, apply the patch for bug 4329444 on the Database Home.

  Note:

  The patch for bug 4329444 is currently available for Linux platform. However, for Microsoft Windows, the patch will be available in February 2007.

• If you have patch 5191377 applied in your environment, then follow these steps before upgrading to 10.2.0.3:

  1. Rollback the one-off patch 5191377

     a. Set your current directory to the directory where the patch is located:

     % cd 5191377

     b. Run the following command:

     % opatch rollback -id 5191377

  2. Login as Repository Owner and execute the following command, against SQL prompt

     SQL>drop index mgmt_current_violation_idx_05

• Shut down all OMS instances associated with the repository using the following command from the respective ORACLE_HOMEs from their respective hosts:

  $ORACLE_HOME/opmn/bin/opmnctl stopall

  Note:

  You have to stop all the OMS instances, although you are upgrading only the first OMS. This is because 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 also need to be stopped.

  Also note that 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.

• Apply the 10.2.0.3.0 Patch Set either interactively by executing the runInstaller (For Microsoft Windows, setup.exe) or silently by using the response file.

Upgrading Additional Oracle Management Services After the Repository Is Upgraded to 10.2.0.3.0

After you have upgraded the first OMS and the repository to 10.2.0.3.0, the only step to be performed before upgrading other OMS instances is to ensure that the other OMS instances are shut down, including the first OMS that was upgraded.

Upgrading Management Agents

While manually applying the Patch Set using Oracle Universal Installer (OUI), the only preinstallation 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 Patch Wizard, the Management Agent should be up and running.

Interview Phase

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 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 the OMS.

Oracle Configuration Manager Installation

In this step, the installer collects information to install the 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.

If you install the Management Agent using "Agent Download", then you will have to manually configure OCM. To configure OCM, perform the following steps:

1. Determine your CSI, OracleMetaLink identifier, and the country where you purchased your service contract.

2. 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.

3. The license agreement for Oracle Configuration Manager is displayed. To accept the license agreement, enter "Y".

4. When setup prompts for the CSI, OracleMetaLink identifier, and country code, provide these details.

5. Setup then installs and configures OCM.

6. When setup is complete, OCM gathers configuration information for ORACLE_HOME, and uploads this information to Oracle for use while supporting your site.

7. If you want to check the status of OCM, run the following command:

   $ORACLE_HOME/ccr/bin/emCCR status

Copy and Relink Phase

In this phase, the installer copies all necessary files and does relink operations.

Configuration Phase

In this phase, the installer does the following:

• Updates the Repository: This assistant upgrades the repository to 10.2.0.3 release. If the repository has already been upgraded to 10.2.0.3.0 release and this is an additional OMS being patched, then the configuration phase does not update the repository.

  Note:

  If the "Repository Upgrade Assistant" fails, then do not click Retry, as the Retry button says that the repository upgrade is successful, but the repository upgrade is not clean. For rectifying the repository errors, refer to the "Enterprise Manager Upgrade" section of "Chapter 11: Upgrading Enterprise Manager Grid Control" in the Enterprise Manager Grid Control Installation and Basic Configuration Guide available at:

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

  After rectifying the Repository errors, continue by clicking Retry for other confing assistants to run.

• 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 executed 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:

  1. Login to Enterprise Manager Grid Control as SYSMAN.

  2. Navigate to Deployments, then Provisioning and then to Administration.

  3. Navigate to the Software Library Configuration section and click Add.

  4. Provide a valid directory path where you want to store the raw data for the component(s).

  5. Login to the machine that hosts the OMS, and do the following:

     • Set the environment variable to "ORACLE_HOME" of the OMS

     • Execute the following command:

       <ORACLE_HOME>/bin/PARDeploy -action -force deploy -parDir <OMSHome>/sysman/prov/paf

• 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.

Upgrading Management Agent - One Host at a Time

To upgrade Management Agents, one host at a time, using OUI, follow these steps:

1. Login to the specific host where the Management Agent is running.

2. Stop the Management Agent.

3. Ensure that ORACLE_HOME is set to the ORACLE_HOME that is intended for patching.

4. Run the runInstaller executable from the Patch Set media Disk1 subdirectory (For Microsoft Windows, run setup.exe).

   If the ORACLE_HOME is set in the environment or passed as a command line argument, then OUI automatically picks it up.

   It then validates if the Management Agent is up and running from ORACLE_HOME. If it is running, then the installer prompts to shut down the Management Agent, 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.

Upgrading Management Agent - Multiple Hosts at a Time

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 Nodes

• Method 2 - By Staging the Patch Set and Distributing Scripts to a Number of Nodes

You can choose one of the methods for mass patching of Management Agents. Method 1 is based on "push" technique in which the entire set of patch binaries is transferred to all the targets. Method 2 is based on "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 executable needs to 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 Nodes

  1. Login to Enterprise Manager Grid Control using SYSMAN credentials. Click Targets and check if the host is running.

  2. 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.

  3. Navigate to the Jobs tab. Create a job of the type "RefreshFromMetalink", and execute it.

  4. Click Deployments, then Patch Oracle Software. Provide the patch number 3822442 and select the correct platform and 10.2.0.3.0 release.

  5. 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.

  6. 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

  This method copies the patch to the selected number of 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.

  Important:

  The Patch Set contains new components like Siebel and Connectors, besides an older component, that is OCM. For these components to be installed and functioning properly, the Patch Set needs to be applied on OMS as well as on Management Agent, so that the bits related to OMS and Agent are installed accordingly.

• 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:

  1. Navigate to the following location:

     cd <OMS ORACLE_HOME>/sysman/agent_download/

  2. Create a directory:

     mkdir -p patchset/10.2.0.3.0/<platform name>

  3. You can then stage the Patch Set by either copying from a DVD or by extracting the contents of the Metalink patch 3731593.

  4. Copy the p3731593_102030_<platform name>.zip from the DVD or Metalink patch to an empty, temporary directory.

  5. Extract the contents of the ZIP file to that same temporary directory.

  6. 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.3.0/<platform name>

     Here, ORACLE_HOME is the OMS ORACLE_HOME 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

     
     

     The above-mentioned operation stages the contents of the Patch Set in the OMS host.

  7. After this happens, follow these steps:

     (a) Login to Enterprise Manager Grid Control and navigate to the Jobs tab, and select a patch job.

     (b) Provide the patch number 3731596 and select the correct platform and release of the target.

     (c) You can then select a number of targets to apply the patch. After selecting the target, select "Provide custom script" option to allow OCM to be installed in the target Agent's home.

     (d) 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

  This method copies the script to the selected number of 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.

  Important:

  The Patch Set contains new components like Siebel and Connectors, besides an older component, that is OCM. For these components to be installed and functioning properly, the Patch Set needs to be applied on OMS as well as on Management Agent, so that the bits related to OMS and Agent are installed accordingly.

Upgrading Management Agent Clusters

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 Nodes

• Method 2 - By Staging the Patch Set and Distributing Scripts to a Number of Nodes

You can choose one of the methods for mass patching of Management Agents. Method 1 is based on "push" technique in which the entire set of patch binaries is transferred to all the targets. Method 2 is based on "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 executable needs to 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 Nodes:

  1. Login to Enterprise Manager Grid Control. Navigate to the Jobs tab and select a patch job.

  2. Provide the patch number 3822442 and select the correct platform and 10.2.0.3.0 release.

  3. You can then select all the cluster nodes to apply the patch. After selecting the target, select "Provide custom script" option to allow OCM to be installed in the target Agent's home.

  4. 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

  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 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:

  1. Navigate to the following location:

     cd <OMS ORACLE_HOME>/sysman/agent_download/

  2. Create a directory:

     mkdir -p patchset/10.2.0.3.0/<platform name>

  3. You can then stage the Patch Set by either copying from the DVD or extracting the contents of the Metalink patch 3731593.

  4. Copy the p3731593_102030_<platform name>.zip from the DVD or Metalink patch to an empty, temparory directory.

  5. Extract the contents of the ZIP file to that same temporary directory.

  6. 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.3.0/<platform name>

     Here, ORACLE_HOME is the OMS ORACLE_HOME 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

     
     

     The above operation stages the contents of the Patch Set in the OMS host.

  7. After this happens, follow these steps:

     (a) Login to Enterprise Manager Grid Control and navigate to the Jobs tab, and select a patch job.

     (b) Provide the patch number 3731596 and select the correct platform and release of the target.

     (c) You can then select a number of targets to apply the patch. After selecting the target, select "Provide custom script" option to allow OCM to be installed in the target Agent's home.

     (d) 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

  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.

Installation and Upgrade Issues In General

This section covers all installation and upgrade issues in general.

Installation and Upgrade Issues Specific to Agent Deploy Application

This section covers issues that related to the Agent Deploy application.

For more information about Management Agent deployment, refer to the Management Agent Deployment Best Practices document available at:

http://www.oracle.com/technology/products/oem/pdf/10gr2_agent_deploy_bp.pdf

Unable to locate Oracle Configuration Manager Trusted Keystore /scratch/DUMMY/.dummy/ccr/admin/security/certca( No such file or directory

Issues While Configuring Server Load Balancer

While configuring Server Load Balancer between Grid Control console and Management Service as described in the Section 3.6.2 of Oracle® Enterprise Manager Advanced Configuration 10g Release 2 (10.2), the Management Service redirects the client browser to a Management Service host bypassing the Server Load balancer.

For example, in a Grid Control deployment with three Oracle Management Services (say on omshost1.example.com, omshost2.example.com, omshost3.example.com) and a Server Load Balancer (slbhost.example.com), the client browser request for http(s)://slbhost.example.com[:port]/em gets redirected to http(s)://omshost[1,2,3][:port]/em.

To prevent the browser from bypassing the load balancer when a URL is redirected, edit the *|ServerName|* directive defined in the Oracle HTTP Server configuration file at $ORACLE_HOME/sysman/config/httpd_em.conf to match the name of the server load balancer host. So, for the example above, the directive should look as follows :

ServerName slbhost.example.com

This workaround has to be done in addition to the configuration defined in Section 3.6.2.3 "Configuring Oracle HTTP Server When Using a Server Load Balancer for the Grid Control Console" of the Oracle® Enterprise Manager Advanced Configuration 10g Release 2 (10.2).

Also, note that in a multi-OMS setup, this workaround has to be done for all the Management Services.

(Bug 5692755)

Memory Leak Issue in Management Agent

There is a memory leak in the Management Agent that is amplified while monitoring iAS targets, or more generally, when a lot of HTTP requests are sent to the Management Agent. The leak is in the xdk code that is used by the Management Agent and is tracked by bug 5573534.

To resolve this issue, apply the one-off patch for bug 5573534.

(Bug 5575154, 5573534)

RDBMS Issues Related to Daylight Saving Time

According to the "The Energy Policy Act of 2005" beginning 2007, the Daylight Saving Time has been extended by one month and the schedule for the states of the United States that adopt daylight saving time will use the following rules:

• Start: Second Sunday in March

• End: First Sunday in November

• Time: 2 am local time

The new rules have been incorporated in jdk "1.5.0_06". The details can be found at this site:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6317178

Oracle recommends that you apply the patch to reflect this change. Otherwise, it can cause unexpected behavior in the Grid Control, especially with the job system. This includes jobs being scheduled an hour later than expected.

For more information, see Metalink Note:359145.1 titled "Impact of 2007 USA daylight savings changes on the Oracle database" on the OracleMetalink site.

(Bug 5351247)

Unsecuring of Management Agent Not Supported if OMS Is Secured

You cannot unsecure a Management Agent if the OMS is secured and locked.

(Bug 5531324)

Helpsets Missing in Japanese Version

The translated online help is not available for the following:

• Target Metrics: Oracle Content DB Metrics, Voicemail and Fax Recording Service, JBoss Application Server Metrics, Oracle BPEL Process Manager Metrics, IBM WebSphere MQ Queue Manager Metrics, Identity Manager Server Target Metrics, Identity Manager Repository Target Metrics, Access Manager - Identity Server Metrics, Access Manager - Access Server Metrics, Siebel Server Target Metrics, Siebel Component Metrics, Siebel Gateway Target Metrics, and Siebel Component Group Target Metrics.

• Application Server Management: Managing Oracle BPEL Process Manager, Managing IBM WebSphere MQ Queue Manager, Managing Identity Federation Server, Managing JBoss Application Server, Managing Identity Manager, Managing Access Manager - Access and Identity Servers, Managing JBoss Partition, and Managing IBM WebSphere MQ Cluster.

• Target Policies: Secure Configuration for Oracle Database, Secure Configuration for Oracle Real Application Cluster Database, and Secure Configuration for Oracle Listener.

• Management Operations: Managing Data Exchange, Managing Management Connectors, Managing Policy Groups, and Managing Siebel Targets.

(Bug 5715773)

SQL Exception While Deleting OOB Reports

The repository upgrade from 10.2.0.1 production to 10.2.0.2 Patch Set release may fail if the SYSMAN user has created new reports from out-of-box reports, that is by using the "Create Like" feature, with the same name as the out-of-the-box report. This failure may occur only if the 10.2.0.2 release includes a new copy of the out-of-box reports.

To resolve this issue, as a Super Administrator of Enterprise Manager, you can either rename the newly created report so that the name is unique across the enterprise or delete the newly created report. Once the report is renamed or deleted, rerun the upgrade process.

(Bug 5225689)

Loaders Errors After Upgrading to10.2.0.3 Grid Control with Seed

After you upgrade to 10.2.0.3 release with seed, you will see some loader errors. This is because of bug 4482253 that deals with loader being unable to process files due to ORA-01801 errors. This problem is caused by RDBMS bug 3944226.

To resolve this issue, try restarting the repository database. If the problem is persistent, then contact Oracle Support to obtain the patch for RDBMS bug 3944226.

(Bug 5614815)

"Oracle Patch Prerequisite Checker for CRS" Fails in "Stage Patches" Step

CRS home is owned by the root. If a non-root user is running the CRS pre-req DP and has provided a patch staging folder under ORACLE_HOME, then there will be permission-related issue.

The resolve this issue, provide a folder outside the CRS Home with permission for the patching user to stage the patch, for example: /tmp.

(Bug 5686511)

Patching Deployment Procedures Fail at Initialization Stage

For all patching Deployment Procedures where the opatch upgrade step is enabled, the opatch patches for the right release of the homes being patched must be in the software library. Either the opatch patch should be uploaded manualy to the software library or the job "Optach patch" should be run successfully. This job needs to be run only once. A dump directory needs to be provided for this job to run, which can be specified on the Offline Patching Settings page. To veiw that page, select Setup and then select Patching Setup.

(Bug 5701915)

"Patch Oracle Clusterware -Rolling" Hangs at the "Execute Root Script" Step

While applying a Patch Set on 10.2.0.1 CRS, if you are a user as specified in Target Credentials who does not have "sudo" privileges on the CRS targets or nodes, then you would ideally customize the "Patch Oracle Clusterware" CRS deployment procedure to execute the "sudo" steps as "PAM" steps and also specify a PAM command script. However, if you have not updated the PAM command script to set the umask value to 0022, then you will see the following error in a loop and the Deployment Procedure execution hangs at the "Execute Root Script" step.

Startup will be queued to init within 90 seconds. 
/scratch/aime/CRS/crs/bin/crsctl.bin: error while loading shared libraries: 
libclntsh.so.10.1: cannot open shared object file: No such file or directory

To resolve this issue, ensure that the PAM command script being used is updated to have the umask value set to 0022.

(Bug 5691165)

CRS Patching Not Supported on Microsoft Windows

The CRS patching deployment procedure is not supported on Microsoft Windows targets.

(Bug 5683930)

"Patch Oracle Clusterware" Deployment Procedure - Failure Due to Home Ownership

If patching fails at "Opatch upgrade" step because of home ownership issue, then run the deployment procedure with the following updates:

• Disable the "Upgrade opatch" step and validate that the opatch version on the CRS Home is as per patch requirements.

• Stage the patch outside the CRS Home in a directory where the patching user has write permission.

(Bug 5704923)

Microsoft Windows Patchset Application Fails for ASM and Database (Some Releases)

Application of 10.2.0.2.0 and 10.2.0.3.0 Patch Sets for RDBMS and ASM could fail, when Deployment Procedures are used for application of the patch. This issue is relevant for Microsoft Windows targets only. The deployment procedure could fail at "Apply Patch" step due to this issue.

As a workaround, you may modify the "Apply Patch" directive with the following:

L1045: $runInst_loc_win = File::Spec -> catfile($runInst_loc_win, "oui.exe");

(Bug 5759231)

AS Deployment Patch Fails on Microsoft Windows

On Microsoft Windows, while applying the patch using the AS Deployment Procedure, the procedure fails at the "Shutdown Application Server" step. This happens because the perl module "Config" was not used in the scripts.

To resolve this issue, modify the scripts of the following two directives to include the module "Config" as the first line of the script as "Use Config":

Directive: Oracle Directives/Common/AS/All/Generic/PA_Startup_AS
Name of script: pa_startup_as.pl
Directive: Oracle Directives/Common/AS/All/Generic/PA_Shutdown_AS
Name of the script: pa_shutdown_as.pl

(Bug 5757192)

Cannot Monitor Web Cache Target and Forms Transactions from the Same Agent

You may see the following message:

"No data coming from a beacon for the forms transactions."

If you do so, then try these:

1. Verify forms transaction from that beacon.

2. If it is hanging, then check to see if the Management Agent that the beacon is deployed on is monitoring a Web Cache target.

3. Due to bug 5700255, if a Management Agent is monitoring a Web Cache target, then it cannot run the forms transactions.

4. To resolve this issue, deploy the forms transactions on a different Management Agent.

(Bug 5700255)

Beacon Availability Computation Error Under Management Services and Repository

In Grid Control, when you select Targets, All Targets, and then Management Services and Repository from the list of targets, you are taken to the Overview page of the selected Management Services and Repository. From here, when you select the Errors tab, you may see the following errors:

Beacon Availability Computation n/a Nov 13, 2006 5:07:04 PM Error EXEC_AVAIL_JOB failed. Error: ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS2'

Note that if Grid Control is installed on a pre-existing database, then it does not create UNDO tablespaces. To resolve this issue, you should ensure that the UNDO tablespace is already existing in the database with at least 200MB of space.

(Bug 5659103)

Issues While Adding Beacon to 10.2.0.3 Management Agent That Is Pointing to 10.2.0.2 OMS

Certain beacon operations such as adding a beacon to a 10.2.0.3 Management Agent fail when attempted from older release of OMS, that is from release 10.1.0.x, 10.2.0.1, or 10.2.0.2. When the operation fails, the following error message is displayed

Error:
oracle.sysman.emSDK.emd.comm.CommException: SAXParseException in parsing
Response :: Key columns cannot be transient or computed

For these operations to succeed, you should first upgrade your OMS to 10.2.0.3. If you do not want to upgrade the OMS only for this purpose, then you can download the one-off patch for bug 5729053 and apply it on the Management agent.

(Bug 5729053)

Cannot Create Service Tests if OMS Is installed on a Remote Repository

If you are setting up OMS on a remote repository (not the one declared in the emoms.properties file), then you will run into the problem of test metadata not being populated correctly. You will experience the following:

• Not being able to create a service with any test type.

• Not being able to see any tests in the service create or edit pages.

The workaround is to run the following commands:

$ORACLE_HOME/jdk/jre/bin/java -classpath

$ORACLE_HOME/jdbc/lib/ojdbc14.jar:$ORACLE_HOME/sysman/jlib/emCORE.jar:$ORACLE_HOME/sysman/jlib/log4j-core.jar:$ORACLE_HOME/lib/servlet.jar:$ORACLE_HOME/jdbc/lib/orai18n.jar:$ORACLE_HOME/sysman/jlib/emagentSDK.jar

oracle.sysman.eml.gensvc.test.data.SeedMetadata "<<repository connect string>>" <<db_sysman_username>> <<db_sysman_password>> "$ORACLE_HOME"

If you are using Microsoft Windows, then the variables should be referred as %VAR_NAME% instead of $VAR_NAME. That is, $ORACLE_HOME would be %ORACLE_HOME%.

(Bug 5584394)

Cannot Create a Test-Based Service Target from Scratch

When you create a test-based Forms Application target, you need to record a Forms transaction for the target to be created. The recording would fail if the Forms server has not been previously configured to enable transaction monitoring. However, the link to the "Enable Forms Transaction Monitoring" page is only available in the context of a Forms Application target that's already been created.

You need to first create the Forms Application target as system-based, then configure the Forms server on "Enable Forms Transaction Monitoring" page, then change the Forms Application target to be test-based, and then record the transactions.

(Bug 5696760)

Upgrade Failed - Inconsistent Corrective Action Data

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 CAs, 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;
/

(Bug 5855008)

Run PL/SQL Procedure Periodically

Oracle recommends that you run the following PL/SQL procedure as the repository owner (SYSMAN) periodically. For normal load, run the procedure weekly. If there are large numbers of tickets created everyday, then run it daily.

To run the procedure, login to the repository database as SYSMAN through SQLPLUS and run the following command:

execute mgmt_cntr_tt.clean_up_old_ticket_recs;/

(Bug 5700394)

Cannot Delete the Underlying Jobs of the Sessions Associated with a Hub

After deleting a data exchange hub, the underlying sessions associated with the hub are deleted, but the underlying jobs associated with the outbound data exchange sessions are not deleted. This problem exists only for outbound data exchange sessions and not for inbound ones. On the contrary, these jobs are still scheduled and run.

To resolve this issue, delete the sessions if any before deleting the hub. Alternatively, navigate to the Jobs page and delete all the jobs corresponding to the outbound sessions.

(Bug 5664615)

Collection Warning Reported on the Console After Upgrading 10.2.0.2 OMS to 10.2.0.3

When you upgrade your 10.2.0.2 OMS to 10.2.0.3, then one will see an Inventory Collection warning. The warning message is:

unknown external name for the following patchset: Patchset: internal name:
<oracle.sysman.patchset>; external name: <UNKNOWN>; version: <10.2.0.2.0>;
install time: <>; description: <>

This warning message is benign and can be ignored.

If you upgrade a 10.2.0.1 OMS to 10.2.0.3 directly without applying the 10.2.0.2 Patch Set, then this warning does not occur.

(Bug 5854480)

Invalid UTF8 Encoding Error Occurs

While executing "db2gc", you may see the error the following error in the terminal session window.

Invalid UTF8 encoding. : Start of root element expected

This error occurs only when the charset encoding setting of the terminal session window is not UTF8-based, and if you choose to rename the current target display name to another one that includes multibyte and native language-based characters.

To resolve this issue, do these:

1. Do not rename the target display name if no urgent request.

2. Make sure the charset encoding setting of the terminal session window is UTF8-based. If it is not, set it to UTF8 and try again.

(Bug 5724384)

Issues While Migrating Collections with Node Names That Do Not Have Domain Name

The db2gc utility does not migrate metric customizations to GridControl for RAC database targets. After the target migration, review the All Metrics page to customize Metric Thresholds and (or) Collection Frequency as needed.

(Bug 5709028)

"Add Instance" of RAC Though Grid Control Has Error

You may face errors while performing the "Add Instance" operation of a RAC Database. To workaround this problem, add "+ASM2.instance_number=2" to the init.ora file of source node, stop the ASM instance with "srvctl stop asm -n destination_node_name" and start it again with "srvctl start asm -n destination_node_name", and then instance2 can be started normally with "srvctl stop instance -d RAC_DB_NAME -i Destination_INSTANCE_NAME".

(Bug 5260570)

Issues with Starting and Stopping 9i Series RAC Database

If you have any 9i series RAC Database on Microsoft Windows, then you cannot start or stop these targets from the Cluster Database Home Page of the Grid Control console.

However, starting and stopping is possible at instance level. So if you have multiple database instances within a cluster, then you can navigate to the home page of any of those database instances, and then start or stop them.

(Bug 5730084)

Metric Collection Errors for 10.1.3 Oracle HTTP Server

In order to see accurate values on the "mod_oc4j Metrics Page" for a version 10.1.3.0 Oracle HTTP Server, you must patch your Oracle Application Server 10.1.3.0 installation with patch 5161311 and patch 5088239 available on OracleMetalink site. For additional information, refer to the patches' ReadMes.

(Bug 5042008)

Issues While Discovering Oracle Application Server Release 9.0.4

Grid Control fails to discover some installations of Oracle Application Server release 9.0.4. This is due to an internal error that occurs during the discovery, and this is likely to happen when Oracle Process Connect component is present in the application server instance. However, no error message is displayed.

(Bug 5735044)

BPEL Processes Monitoring Issues When Using 10.2.0.2 Agent with OMS 10.2.0.3

If you have upgraded your OMS to 10.2.0.3, but have left the Management Agent as 10.2.0.2 or any other previous release, then for the Oracle BPEL Process Manager target, that is BPEL Process Manager release 10.1.3.1, will always show "Down" status. Also, on the Processes page, the processes will not get listed.

To resolve this issue and view the processes on the Processes page, upgrade the Management Agent to 10.2.0.3.

To view the correct status, do one of these:

1. Upgrade the Management Agent to 10.2.0.3.

2. Apply the one-off patch 5708626 on the Management Agent.

3. As a temporary solution, follow these steps:

   1. Open the following file:

      ${OH}/sysman/admin/metadata/oracle_integrationbpm.xml (agent OH)

   2. Go to the Response metric and look for the following line in the execution descriptor:

      <Filter COLUMN_NAME="opmn_process_type" OPERATOR="CONTAINS">OC4J_BPEL</Filter>

   3. In that line, replace "OC4J_BPEL" with the name of the OC4J instance on which BPEL is running. For example, if the OC4J instance name is "home", then after making the changes, the line would look like this:

      <Filter COLUMN_NAME="opmn_process_type" OPERATOR="CONTAINS">home</Filter>

   4. Save the file, go to ${OH}/bin (agent OH), and execute the following command:

      emctl reload agent

(Bug 5708626, 5704583)

OC4J "Enable Logging" Takes You to the OC4J Topology Page Instead of the Trace Configuration Page

As a Grid Control admin user, when you try to configure 10.1.3.1 OC4J to enable the end-to-end tracing feature by clicking Enable Logging on the Manage OC4J Data Collection page, you are redirected to the Application Server Control.

The desired behavior is that after you login to Application Server Control, you should be redirected to the OC4J Trace Property Configuration Page. Instead, you are re-directed to the Application Server Control Topology Page, where you have to manually drill down to get to the appropriate page. This problem is applicable to Application Server 10.1.3.1 Release.

To workaround this issue, after you login to Application Server Control, on the Topology page, select the appropriate OC4J instance, click the Administration tab, click Edit Server Properties, and then scroll down to the bottom of the page and click Trace Properties.

(Bug 5439369)

Deployment Procedure Fails to Restart the Web Tier

When you try the deployment procedure using Grid Control to restart the web tier, the procedure may end successfully with the message that the web tier has been restarted, but it may not actually restart the web tier.

To resolve this issue, you have to modify the directive manuallymanagedclusterconfig.pl before executing of the deployment procedure.

To modify the directive manuallymanagedclusterconfig.pl, follow these steps:

1. In the Grid Control console, click Deployments to navigate to the Deployments page.

2. On the Deployments page, click Provisioning and select the Directives tab.

3. From the table, select Directives, then select Oracle Directives, then select myJ2EECompany Provisioning. Now select 10.1.2.0.2 and then select Configure Manually Managed Cluster.

4. Now click Edit to reach the Edit Directive page.

5. On the Edit Directive page, click the Upload File tab.

6. Click the currently associated file manuallymanagedclusterconfig.pl to display the contents.

7. Now copy the contents of that file to an editor (for example: Notepad or Wordpad.)

8. Make the following changes:

   • In the function parseCommandLineParams(), change line number 135, that is $hmpParams{"INSTALL_BASE"} = "true"; to $hmpParams{"INSTALL_BASE"} = $ARGV[ $i + 1 ];

   • Similarly, change line number 140, that is $hmpParams{"VIRTUAL_HOST"} = "true"; to $hmpParams{"VIRTUAL_HOST"} = $ARGV[ $i + 1 ];

9. Save the modified file to your local machine as manuallymangedclusterconfig.pl.

10. In the Grid Control console, on the Edit Directive page where you see the currently associated file under the Upload File tab, select Upload from Local Machine.

11. Select Browse and upload the file manuallymangedclusterconfig.pl that was saved in step 9.

12. Select Finish.

(Bug 5684224)

Infrastructure Performance Charts of an Identity Federation Server Have No Value

When you access the Infrastructure Performance tab of an Identity Federation System, and select Real Time: Manual Refresh from the View Data menu to view metric information at real time, the charts appear but the data is not depicted.

(Bug 5700277)

Internal Error Is Thrown While Associating Oracle Identity Manager Targets with Existing Identity Management System

Internal exception is found while associating discovered Oracle Identity Manager targets with existing Identity Manager system. Therefore, the discovery of Oracle Identity Manager components fails to complete.

To resolve this issue, discover the Oracle Identity Manager components by associating them with new Identity Manager system. You can then add these components to an existing system from the Systems tab of the Grid Control console.

(Bug 5751839)

Beacon Enhancement Is Not Supported on Microsoft Internet Explorer 7

The Beacon Enhancement functionality is not being supported on Microsoft Internet Explorer 7 browser, as Siebel does not support this browser currently for High Interactive applications.

For more information on the support provided, refer to this site:

http://supportweb.siebel.com/support/private/content/knowledgedocs/enu/SOD/IE7-SOD.pdf

Refer to the "Planned Support for Microsoft Internet Explorer 7 on Windows XP SP2" section. According to this document, the support for High Interactivity applications on Microsoft Internet Exxplorer 7 will be provided in early CYQ207.

(Bug 5724954)

Siebel Service Status Is Always "Down" Even Though the Service Test Runs

The Management Agent performs the remote playback functionality. For this, it spawns a browser and replays the recorded script. The Management Agent runs as a Windows service using the system account credentials. If the system account does not have appropriate privileges or permissions, then this functionality is not permitted.

This particular issue is faced with beacons on Microsoft Windows 2003 Server. So, on these hosts, the status of the application is always shown "Down", and the metrics collected do not have any values. This issue is not faced on Microsoft Windows 2000 and Microsoft Windows XP hosts.

(Bug 5676927)

Siebel Enterprise Discovery Fails, or Only a Subset of Components Are Discovered

In Grid Control 10.2.0.3.0 release, support is not provided for monitoring a Siebel server when the total number of enabled Siebel components and component groups in that server is more than 70.

(Bug 5724329)

Issues With Starting and Stopping Siebel Server Components

When there are multiple Siebel server installations, if the siebel home directories on which the servers are installed are different on different machines, then you may face issues while starting and stopping the components of a Siebel server.

Make sure that the installation directories of the siebel servers are identical across all machines. Otherwise, as a workaround, perform your start/stop operations from the server manager utility.

For information about using the server manager utility, refer to the following document available at:

http://supportweb.siebel.com/support/private/content/Bookshelf/78Siebel/books/SystAdm/SystAdm_SrvrMgrCLI.html#wp1003500

(Bug 5747767)

View Configuration Page Property Navigation Does Not Work

The navigation in View Configuration Page for Siebel targets, that is for Siebel Server, Siebel Gateway Server, and Siebel components, does not work.

To resolve this issue, use the "Show All" option from the navigation menu.

(Bug 5702824)

Newly Added Services Do Not Get Reflected in the Service Dashboard

Manually added services do not get reflected in the services dashboard. To resolve this issue, follow these steps:

1. Click Reports.

2. Select the respective service dashboard and click Edit.

3. Click Elements and then click the Set Parameters link.

4. Add the newly added service and then click Continue.

5. Click OK.

(Bug 5718696)

Cannot Handle Two Siebel Enterprises with Identical Names

Grid Control cannot handle two Siebel Enterprises with identical names.

(Bug 5654804)

Need to Package Release Version of Sarmquery with Management Agent

SARM metrics are not getting collected in Siebel 7.7 and 7.8 environments as SARM query executables are not bundled with Siebel 7.7 and 7.8 versions. To resolve this issue, apply the one-off patch for bug 5684381.

(Bug 5684381)

Incorrect Values Shown in Charts

The charts that appear on the Siebel Enterprise Home Page show incorrect values.

(Bug 5747754)

99% Memory Cosmopolite on Patching 10.2.0.1 OMS to 10.2.0.2

After applying the 10.2.0.3 patch on OMS, Grid Control might report 99% memory utilization for the target host.

To resolve this problem, select Deployment and click Refresh Host Configuration on that page. Now, select the related host from the Available Hosts and click Refresh Hosts.

(Bug 5141414)

Issues with Microsoft Windows OMS and Management Agent

Administration Tab is shown for the Microsoft Windows host targets, even though this feature is supported for RedHat(RHEL4) and Suse Linux (sles9) hosts only. This issue will be addressed in the next Patch Set.

(Bug 5689719)

Message to Instal YAST Patch Is Displayed Even if it Is Installed

In case of Full agent install or Patch agent install on RHEL4 or sles9, the UI asks you to install the required components and patches, even if the YaST patch for Suse is already installed.

To resolve this issue, follow these steps:

Full agent install on RHEL4 or sles9

• Bounce the agent by running the following commands:

  emctl stop agent

  emctl start agent

Patch agent install on RHEL4 or sles9

• Bounce the agent by running the following commands:

  emctl stop agent

  emctl start agent

• Change the permissions in $ORACLE_HOME/sysman/admin/scripts as follows:

  chmod 755 EM*.ycp

  chmod 755 DiscoverYast2.pl

  chmod 755 RunYast.sh

(Bug 5718456)

RedHat Linux Specific Issues with Network Cards

On the Network Card page, changing the Name Server IP address under Global DNS Settings does not work. This issue will be fixed in the next Patch Set.

(Bug 5724608)

Metric Collection Error While Monitoring BEA WebLogic Managed Server Targets

While monitoring BEA WebLogic Managed Server targets, you may face metric collection errors. You may see an error message like:

weblogic.rmi.extensions.RemoteRuntimeException: Unexpected Exception - with nested exception

This error is caused when a Management Agent is used to monitor one application server target that is compatible with one version of JMX, and another application server target that is compatible with another version of JMX. For example, when you monitor BEA WebLogic release 8.1 and BEA WebLogic release 9 using the same Management Agent, you will see this error.

To resolve this issue, do not use the same Management Agent for monitoring both these targets. Have one Management Agent monitor one target and another one monitor another target.

(Bug 5458460)

Management Agent Should Be Restarted After Discovering Third-Party Application Servers

After discovering IBM WebSphere Application Server, IBM WebSphere Application Server Cell, or BEA WebLogic Server Domain, restart the Management Agent. This is required only when you are discovering these third-party application server for the first time.

(Bug 4451228)

Discovery of MQ Target Fails on Microsoft Windows Non-English Edition

If IBM MQ Series is installed on Microsoft Windows non-English edition, or on Linux with characterset of OS locale that is neither 'iso88591' nor 'UTF8', then discovering MQ target from Grid Control fails.

To resolve this issue, install IBM MQ Series on Microsoft Windows English edition or on Linux with OS locale using characterset 'iso88591' or 'utf8'. For example, en_US.iso88591 and zh_CN.utf8.

(Bug 5722258)

After Testing The Connection, Clear The Encrypted Fields and Re-Enter Them While Reloading The "Add Target" Page

While adding a target on the Agent home page, you may choose to test the connection. While doing so, the test may be successful and you may be able to add the target to Grid Control. However, when you return to that target's home page, you will see metric collection error for the response metric.

To resolve this issue, when test connection is successful, remove and re-enter the encrypted password before adding the target to Grid Control.

(Bug 5642074)