Skip Headers
Oracle® Enterprise Manager Grid Control Release Notes for Linux and Microsoft Windows
10g Release 3 (10.2.0.3.0)

Part Number B40096-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

  View PDF

Oracle® Enterprise Manager

Grid Control Release Notes for Linux and Microsoft Windows

10g Release 3 (10.2.0.3.0)

B40096-03

January 2007

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 for an enterprise grid such as software installation, patching, upgrading, workload balancing, and security.

This Release Notes document is one of the documents that is bundled with 10.2.0.3.0 Grid Control Patch Set. The document provides information about the Patch Set and procedures that help you patch your previous releases of Grid Control and (or) Management Agent, that is any 10.2.x.x.x installation, and upgrade it to 10.2.0.3.0 release.

Note:

This document helps you only patch any previous releases of Grid Control and (or) Management Agent, that is any 10.2.x.x.x installation, and upgrade it to 10.2.0.3.0 release. If you do not have a previous release, but want to have a 10.2.0.3.0 environment, then first install either 10.2.0.1.0 or 10.2.0.2.0 release, and then use this Patch Set to upgrade it to 10.2.0.3.0. For information about installing 10.2.0.1.0 or 10.2.0.2.0 Grid Control, refer to the installation guides available at:

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

This document contains the following sections:

Patch Set Documentation

There are two documents related to this release of Grid Control Patch Set:

Both these documents are included with the 10.2.0.3.0 Patch Set. You can also find a consolidated document, which has the Document ID 405521.1, on OracleMetaLink at:

http://metalink.oracle.com/

To locate document 405521.1:

  1. Click Advanced at the top of the OracleMetaLink page.

  2. Enter 405521.1 in the Document ID field and click Submit.

You can also find this document on the Oracle Technology Network (OTN) Web site:

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

New Components in This Patch Set

The 10.2.0.3.0 Patch Set has the following new components bundled with it:

Oracle Content Database Plug-In

The Oracle Content Database Plug-Ins provide integration of Oracle Content Database Release 10.1.3.2.0 with Management Agent, Management Service, and Repository for Grid Control Release 10.2.0.3.0. In particular, they define target type metadata and default collection to monitor Content DB runtime performance and repository statistics in Grid Control.

Oracle Application Management Pack for Siebel

Oracle Application Management Pack for Siebel is a comprehensive solution for managing the configuration, performance, availability, and service level of Siebel CRM applications. It can be used to monitor the health of the servers and components, measure application response time, track configuration changes, and diagnose performance and execution problems.

Connectors (MOM and Remedy)

Microsoft Operations Management Connector enables Oracle Enterprise Manager to retrieve alerts from Microsoft Operations Manager (MOM). The retrieved alerts are stored in the Enterprise Manager repository and displayed through the Enterprise Manager console.

Remedy Connector enables you to integrate Remedy Trouble Ticket System with Enterprise Manager. This connector creates trouble tickets based on alerts retrieved from the Enterprise Manager notification system.

Oracle Configuration Manager

Oracle Configuration Manager (OCM) is designed to gather and provide customer's configuration information and store it in Oracle repository for maintenance and other related tasks. This feature was introduced from Grid Control Release 10.2.0.2.0 onwards.

Linux Management Pack

Available exclusively as part of the Oracle Unbreakable Linux support program, the Linux Management Pack provides an integrated and cost-effective solution for complete Linux server lifecycle management, including server provisioning, patching, monitoring, and administration.

Linux Server Administration

Enterprise Manager now supports Linux administration features for RedHat (RHEL4) and SuSE Linux (sles9), significantly simplifying the error-prone and time-consuming server setup tasks, such as System Services Configuration and Network Setup.

Preinstallation Tasks

This section describes the preinstallation tasks to be performed.

Preinstallation Tasks in General

The following are the general preinstallation tasks.

  1. Oracle recommends that you back up the ORACLE_HOME that is being 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 to a pre-Patch Set state.

  2. The product prerequisites (required operating system patches, packages, and so on) of 10.2.0.3.0 are the same as that of 10.2.0.1.0/10.2.0.2.0, so they are already met.

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

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

      % cd 5191377

      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

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

Preinstallation Tasks Specific to the Upgrade Type

The preinstallation tasks can be broadly categorized based on the following types of upgrade you can perform:

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.

Note:

For 10.2.0.1, 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.3.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 the each of the Management Agent homes, as they are separate Oracle Homes.

Installation Procedure

This section describes the installation procedure.

Extracting the Software

For upgrading to 10.2.0.3.0, you have to manually download and extract the 10.2.0.3.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:

  1. Download the p3731593_102030_<platform name>.zip patch set installation archive to any directory that may or may not be an Oracle Home directory.

  2. Enter the following command to unzip and extract the installation files:

    $ unzip p3731593_102030_<platform name>.zip

    This extracts the files to the "3731593" directory.

Important:

The same Patch Set can be used for patching OMS, Repository, and Management Agent. The procedures are described in the following sections.

Upgrading Oracle Management Service

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 execute the runInstaller (For Microsoft Windows, execute setup.exe).

Note:

The Patch Set contains new components like Siebel and Connectors, besides an older component, that is Oracle Configuration Manager (OCM). For these components to be installed and functioning properly, the Patch Set needs to be applied on OMS as well as on the Management Agent, so that the bits related to OMS and Management Agent are installed accordingly. The Patch Set, depending upon the ORACLE_HOME that is being patched, understands if it is an OMS or Management Agent, and then installs the OMS and Agent bits accordingly.

IMPORTANT:

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

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

      % cd 5191377

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

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.

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.

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 invoke setupCCR ($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:

  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

The Management Agent can be upgraded in two ways - either one host at a time or many hosts at a time.

Important:

The Patch Set contains new components like Siebel and Connectors, besides an older component Oracle Configuration Manager (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. The Patch Set, depending upon the ORACLE_HOME that is being patched, understands if it is an OMS or Management Agent, and installs the OMS and Agent bits accordingly.

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.

Post Installation Tasks

This section describes the post installation tasks to be performed.

Post Installation Tasks in General

If you had chosen to upgrade the OMS instances one-by-one, that is by upgrading the first OMS and the repository, then after the upgrade is complete, restart all the Management Agents that you had stopped. The OMS gets restarted automatically after the upgrade is complete, but the Management Agents have to be manually restarted. For information about upgrading the first OMS and repository, refer to *, "Upgrading the First Oracle Management Service and Repository".

Post Installation Tasks Specific to Solaris Agent Hosts

This section describes the post installation tasks that need to be performed for Solaris Agent Hosts.

Ignore this section if Solaris 10.2.0.1.0 Management Agent was never deployed in your Enterprise Manager deployment. It is sufficient to perform the following steps once after upgrading all the Solaris 10.2.0.1 Management Agents to 10.2.0.2 or later release. If you are not sure, it is acceptable to repeat the process described in this section multiple times.

  1. Identify Solaris Agents with Host 3.0 metadata in the Enterprise Manager repository. Upgrade them to 10.2.0.2.0 release or later:

    1. To check if Solaris 3.0 metadata is present in the Enterprise Manager repository, execute lfm_check_solaris_3_0_metadata:

      % sqlplus sysman/<sysman_passwd> @lfm_check_solaris_3_0_metadata

      If this step returns "0", you can ignore this section.

    2. To identify the hosts that require an upgrade, execute list_lfm_solaris_3_0_metadata_hosts.sql against the Enterprise Manager Repository :

      % sqlplus sysman/<sysman_passwd> @list_lfm_solaris_3_0_metadata_hosts

      If this step returns an empty list, then there are no Solaris Agent Hosts. You can ignore this section.

    3. Download Solaris 10.2.0.2.0 Patch Set or later Patch Set release from OracleMetalink Web site. Apply this patch on the Solaris Agents identified in the previous step.

      Log on to the Solaris host with Management Agent owner account. Upload the pending data using emctl upload command. Shutdown the Management Agent using emctl stop agent. Now apply the 10.2.0.2 Management Agent portion of the Patch Set. Start the Management Agent using emctl start agent.

    4. After an hour, execute list_lfm_solaris_3_0_metadata_hosts.sql again to see if there are any more Agents that need to be patched.

  2. Remove customizations specific to "Generic Log File Monitoring" from "Monitoring Templates". For more details about "Generic Log File Monitoring" feature, refer to "Configuring Generic Log File Monitoring Criteria" online help.

    1. Execute list_lfm_templates.sql to identify the templates with customizations:

      % sqlplus sysman/<sysman_passwd> @list_lfm_templates

      If this step returns an empty list, go to step 3.

    2. For each notification rule listed in the step 2 (a), perform the following steps:

      • Log on to Enterprise Manager Console with appropriate privileges to edit the template.

      • Click Setup, then Monitoring Templates on the left pane.

      • Search the template by it's name and select it by clicking the radio button.

      • You can either delete or update the template to remove the "Generic Log File Monitoring" related customization.

        To delete the template, click View to make note of the Template Settings, so that you can use it at a later point in time. Click OK to return to Monitoring Templates page. Select the template and click Delete. Then, click Yes on the Delete Template Confirmation page.

        To update the template, click Edit and then click the Metrics Thresholds tab. Click the edit icon that is next to "Log File Pattern Matched Line Count", and make a note of the settings in the "Monitored Objects" table for future reference. Click Continue (page level) to return to the Metric Tresholds tab. Select Log File Pattern Matched Line Count and click Remove Metrics from Template to remove it. Click OK (page level) to commit the changes.

    3. Perform to step 2 (a) to see if there are any more templates with customizations.

  3. Remove filters related to "Generic Log File Monitoring" from "Notification Rules". You can do this by performing the following steps:

    1. Execute list_lfm_notif_rules.sql to identify rules with the customization:

      % sqlplus sysman/<sysman_passwd> @list_lfm_notif_rules

      If this step returns an empty list, go to step 4.

    2. For each rule listed in step 3 (a), perform the following steps:

      • Log on to the Grid Control console with credentials/privileges that help you edit the notification rule.

      • Click Preferences, then click Rules under Notification on the left pane. Select the rule by clicking the radio button. You can either delete or update the rule. Update choices include deleting the "Log File Pattern Matched Line Count" metric or updating the "Log File Pattern Matched Line Count" metric to notify on "All Objects".

        To delete a Notification Rule, click View, and make a note of the current settings for future reference. Then click Notification Rules bread crumb to return to the previous page. Then, click Delete and then Yes on the confirmation page.

        To update by removing "Log File Pattern Matched Line Count" metric, click Edit, and then click the Metrics tab. Select the row for "Log File Pattern Matched Line Count" metric and make note of the current settings. Click on table level Remove. Click OK (page level) to commit the changes.

      • To update "Log File Pattern Matched Line Count" metric, to notify on "All Objects", click Edit, and then click the Metrics tab. Click the edit icon that is next to "Log File Pattern Matched Line Count" metric. Make a note of current settings. Select "All Objects" by clicking the radio button and click Continue (page level) to return to the Metrics page. Then, click OK (page level) to commit the changes.

    3. Peform step 3 (a).

  4. Remove "Generic Log File Monitoring" related custom configuration done via setting metric thresholds for "Log File Pattern Matched Line Count" host metric:

    1. Execute list_lfm_threshold_hosts.sql to identify hosts with custom configuration:

      % sqlplus sysman/<sysman_passwd> @list_lfm_threshold_hosts

      If the above step returns an empty list, go to Step 5.

    2. For each host listed in step 4 (a), perform the following steps:

      • Log on to Grid Control console with credentials/privileges that help you edit the host thresholds.

      • Go to the home page for the given host and click Metric and Policy Settings.

      • Click the edit icon that is on the same row as "Log File Pattern Matched Line Count" metric.

      • Make a note of the settings in the "Monitored Objects" table for future reference.

      • Remove all rows from the "Monitored Objects" table except "All others" row.

      • Click Continue (page level) to return to "Metric Thresholds" tab and click OK (page level) to commit the changes.

    3. Perform step 4 (a).

  5. Clear and purge "Log File Pattern Matched Line Count" severities from Solaris 3.0 metadata based hosts:

    1. Run list_lfm_severity_solaris_hosts.sql to identify the hosts:

      % sqlplus sysman/<sysman_passwd> @list_lfm_severity_solaris_hosts

    2. If this returns an empty list, go to Step 6.

    3. For each host listed in the step 5 (a), perform the following steps:

      • Log on to Grid Control console with credentials/privileges that help you edit the host thresholds.

      • Go to the home page for the given host and click Log File Alerts.

      • Click Clear Every Open Alert.

      • To purge the clear alerts, click Show Cleared Alerts and then Purge Every Alert. This is an optional step.

    4. Perform step 5 (a).

  6. Shutdown the Grid Control Console on all OMS nodes.

  7. Execute lfm_fix_host_metadata.sql to the Enterprise Manager Repository:

    % sqlplus sysman/<sysman_passwd> @lfm_fix_host_metadata

    Then quit the sqlplus session by entering the exit command.

  8. Start the Grid Control Console on all OMS nodes.

  9. Verify that the patch has been applied properly. To do this, perform the following steps:

    • Log on to Grid Control console.

    • Go to the home page of a UNIX host (such as Solaris or Linux) and click Metric and Policy Settings.

    • Click the edit icon that is next to "Log File Pattern Matched Line Count", and verify that the following columns are displayed in the "Monitored Objects" table: Select, Log File Name, Match Pattern in Perl, Ignore Pattern in Perl, Comparison Operator, Warning Threshold, Critical Threshold, Corrective Action

  10. Recreate any custom settings that have been removed from the previous steps.

Note:

Never deploy Solaris 10.2.0.1.0 Management Agent in the future. Instead, deploy 10.2.0.2.0 or later releases of Solaris Management Agents.

De-Installation of a Patch Set

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. If you have to de-install a Patch Set, the use one of the following procedures (in the order of preference):

Regardless of how you de-install a Patch Set, contact Oracle Support Services to verify if the problem you are encountering is being addressed.

Known Issues

This section lists the known issues pertaining to this release.

Installation and Upgrade Issues

This section addresses installation and upgrade issues.

Installation and Upgrade Issues In General

This section covers all installation and upgrade issues in general.

Repository Upgrade Failure

When you apply the 10.2.0.3 Patch Set to upgrade your repository, the upgrade may fail.

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.

(Bug 5648438, 5665837)

Repository Upgrade Fails for Sites With 5191377 One-Off Patch

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

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

      % cd 5191377

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

(Bug 5758101)

Errors While Doing an Additional OMS Install

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 the this message, the command that needs to be executed is incorrect. Therefore, follow these steps instead:

  1. Rebounce the database.

  2. Copy emkey.ora into /OH/sysman/config/

  3. run ./emctl config emkey -emkeyfile /OH/sysman/config/emkey.ora

(Bug 5658897)

After Upgrading OMS, Additional OMS Install Is Blocked

You cannot perform an additional 10.2.0.1.0 OMS install by using the repository of 10.2.0.3.0 OMS.

You can install additional OMS with the following workaround, if the repository is already upgraded to 10.2.0.3.0. To do this, perform the following steps:

  1. Convert the repository version to 10.2.0.1.0 from 10.2.0.3.0 by using the following sql statement:

    UPDATE sysman.mgmt_versions SET version = '10.2.0.1.0' where component_name='CORE'; commit;

  2. Provide the repository credentials for the Specify Database Configuration Screen and click Next.

  3. Update the repository version to 10.2.0.3.0 by using the following sql statement:

    UPDATE sysman.mgmt_versions SET version = '10.2.0.3.0' where component_name='CORE'; commit;

  4. Proceed with the installation.

(Bug 4910745)

I/O Error Displayed at the End of Agent Download Installation

While performing an Agent Download Install using the agentdownload.linux script, at the end of the installation, the following error is displayed:

error: db4 error(5) from dbcursor->c_get: Input/output error

This error is harmless and can be ignored. The Management Agent gets installed successfully and works fine.

(Bug 5761062)

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

Application Error Is Displayed If "Temp" Directory Does Not Have Permission

The directory specified in SCRATCH_PATH on your local host should be writable, otherwise you will see an application error. (By default, it is set to C:\tmp)

The directory specified in "nttempdir" in the agentpush.properties file on your remote host should have permission, as this will be used to copy <username>_agentOHQuery.sh (in case of cluster, it is NFS install). Otherwise, you will see an application error. (By default, it is set to C:\tmp)

(Bug 5665925)

sshConnectivity.sh Overwrites the Keys in Silent Install Mode

If you have existing SSH setup on some machines and if you are using the sshConnectivity.sh script to do a new setup manually, then to restore the old setup, you need to perform the following steps manually:

  • mv $HOME/.ssh/identity.pub.ri.bak $HOME/.ssh/identity.pub

  • mv $HOME/.ssh/identity.ri.bak $HOME/.ssh/identity

  • mv $HOME/.ssh/known_hosts.ri.bak $HOME/.ssh/known_hosts

  • mv $HOME/.ssh/config.ri.bak $HOME/.ssh/config

  • chmod 644 $HOME/.ssh/identity.pub

  • chmod 600 $HOME/.ssh/identity

  • chmod 644 $HOME/.ssh/known_hosts

  • chmod 644 $HOME/.ssh/config

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

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

(Bug 5484944)

Test Connection Displays Error During OCM Registration of OUI

When Patch Set is applied on OMS and if the Management Agent is installed interactively from the agent download kit, then on the "Configuration Manager Registration" page, when you click Connection Settings before clicking Test Registration, the following error appears and the install does not proceed.

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

(Bug 5591205)

Oracle Management Service and Management Agent Issues

This section addresses OMS and Management Agent-related issues.

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)

Patch Management Issues

This section addresses patch management -related issues.

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

Client Side Monitoring Issues

This section addresses the client side monitoring issues.

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)

Job System Issues

This section addresses the job system issues.

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)

Connector Framework Issues

This section addresses the connector framework issues.

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)

Enterprise Integration Issues

This section addresses enterprise integration issues.

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)

Enterprise Configuration Management Issues

This section addresses enterprise configuration management issues.

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)

Database Management Issues

This section addresses Database management issues.

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)

Application Server Management Issues

This section addresses application server management issues.

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)

Identity Management Issues

This section addresses identity management issues.

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)

Siebel Applications Management Issues

This section addresses Siebel application management issues.

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)

Host Management Issues

This section addresses host management issues.

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)

Third-Party Application Server Monitoring Issues

This section addresses third-party application server monitoring issues.

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)

Network Appliance Filer Management Issues

This section addresses network appliance filer management issues.

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)

Documentation Accessibility

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 3 (10.2.0.3.0) for Linux and Microsoft Windows

B40096-03

Copyright © 2007, 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.