| Oracle® Enterprise Manager Grid Control Release Notes for AIX 5L Based Systems (64-Bit) 10g Release 3 (10.2.0.3.0) Part Number E10254-01 |
|
| PDF · Mobi · ePub |
| Oracle® Enterprise Manager Grid Control Release Notes for AIX 5L Based Systems (64-Bit) 10g Release 3 (10.2.0.3.0) Part Number E10254-01 |
|
| PDF · Mobi · ePub |
Grid Control Release Notes for AIX 5L Based Systems (64-Bit)
10g Release 3 (10.2.0.3.0)
E10254-01
February 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:This document contains the following sections:
There are two documents related to this release of Grid Control Patch Set:
Oracle Enterprise Manager Grid Control Release Notes, 10g Release 3 (10.2.0.3.0) (this document)
This document provides:
A list of new components included in this Patch Set
Information about how to install or de-install the Patch Set
A list of known issues relating to this release of Grid Control Patch Set
Oracle Enterprise Manager Grid Control List of Bugs Fixed, 10g Release 3 (10.2.0.3.0)
This document provides a list of all generic bugs related to Grid Control that have been fixed in this release.
Both these documents are included with the 10.2.0.3.0 Patch Set. You can also find a consolidated document, which has the Document ID 412426.1, on OracleMetaLink at:
To locate document 412426.1:
Click Advanced at the top of the OracleMetaLink page.
Enter 412426.1 in the Document ID field and click Submit.
You can also find this document on the Oracle Technology Network (OTN) Web site:
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.
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 (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.
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.
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.
This section describes the preinstallation tasks to be performed.
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.
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.
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.
If you have patch 5191377 applied in your environment, then follow these steps before upgrading to 10.2.0.3:
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
Login as Repository Owner and execute the following command, against SQL prompt
SQL>drop index mgmt_current_violation_idx_05
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
Upgrading Additional Oracle Management Services After the Repository Is Upgraded to 10.2.0.3.0
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.
If you have patch 5191377 applied in your environment, then follow these steps before upgrading to 10.2.0.3:
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
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.
After stopping all OMS process, run /usr/sbin/slibclean as a root. Make sure that OBJECT_MODE enviornmnet variable is unset before invoking the runInstaller. To unset OBJECT_MODE, execute unset OBJECT_MODE
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.
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.
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.This section describes the installation procedure.
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:
Download the p3731593_102030_<platform name>.zip patch set installation archive to any directory that may or may not be an Oracle Home directory.
Enter the following command to unzip and extract the installation files:
$ unzip p3731593_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.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.If you have patch 5191377 applied in your environment, then follow these steps before upgrading to 10.2.0.3:
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
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.
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 invokesetupCCR ($ORACLE_HOME/ccr/bin/setupCCR) at a later point of time to configure it. When setupCCR is invoked interactively, it prompts for the required parameter values. You can also accept the license agreement, but choose not to enable the Oracle Configuration Manager. You can disable Oracle Configuration Manager even after accepting the license agreement by unchecking or deselecting the "Enable Oracle Configuration Manager" option.If you install the Management Agent using "Agent Download", then you will have to manually configure OCM. To configure OCM, perform the following steps:
Determine your CSI, OracleMetaLink identifier, and the country where you purchased your service contract.
Execute one of the following commands according to your choice:
If you want to configure using proxy server:
$ORACLE_HOME/ccr/bin/setupCCR -p <proxy server>
If you want to configure without using proxy server:
$ORACLE_HOME/ccr/bin/setupCCR
For more information about using setupCCR, use the setupCCR -help command.
The license agreement for Oracle Configuration Manager is displayed. To accept the license agreement, enter "Y".
When setup prompts for the CSI, OracleMetaLink identifier, and country code, provide these details.
Setup then installs and configures OCM.
When setup is complete, OCM gathers configuration information for ORACLE_HOME, and uploads this information to Oracle for use while supporting your site.
If you want to check the status of OCM, run the following command:
$ORACLE_HOME/ccr/bin/emCCR status
In this phase, the installer copies all necessary files and does relink operations.
In this phase, the installer does the following:
Updates the Repository: 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.
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:
Login to Enterprise Manager Grid Control as SYSMAN.
Navigate to Deployments, then Provisioning and then to Administration.
Navigate to the Software Library Configuration section and click Add.
Provide a valid directory path where you want to store the raw data for the component(s).
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.
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.To upgrade Management Agents, one host at a time, using OUI, follow these steps:
Login to the specific host where the Management Agent is running.
Stop the Management Agent.
Ensure that ORACLE_HOME is set to the ORACLE_HOME that is intended for patching.
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.
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
Login to Enterprise Manager Grid Control using SYSMAN credentials. Click Targets and check if the host is running.
Click Setup from the top-right corner of the Grid Control console. Then select Patching Setup from the panel to the left. Provide the OracleMetalink credentials and click Apply.
Navigate to the Jobs tab. Create a job of the type "RefreshFromMetalink", and execute it.
Click Deployments, then Patch Oracle Software. Provide the patch number 3822442 and select the correct platform and 10.2.0.3.0 release.
You can then select a number of targets to apply the patch. After selecting the target, select "Use default patching script" or "Provide custom script" option to allow OCM to be installed in the target Agent's home.
If the target is a Microsoft Windows machine, then in the pre-script option specify the following:
%emd_root%\EMStagedPatches\3822442\3822442\ecm_3822442.bat
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:
Navigate to the following location:
cd <OMS ORACLE_HOME>/sysman/agent_download/
Create a directory:
mkdir -p patchset/10.2.0.3.0/<platform name>
You can then stage the Patch Set by either copying from a DVD or by extracting the contents of the Metalink patch 3731593.
Copy the p3731593_102030_<platform name>.zip from the DVD or Metalink patch to an empty, temporary directory.
Extract the contents of the ZIP file to that same temporary directory.
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.
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.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:
Login to Enterprise Manager Grid Control. Navigate to the Jobs tab and select a patch job.
Provide the patch number 3822442 and select the correct platform and 10.2.0.3.0 release.
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.
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:
Navigate to the following location:
cd <OMS ORACLE_HOME>/sysman/agent_download/
Create a directory:
mkdir -p patchset/10.2.0.3.0/<platform name>
You can then stage the Patch Set by either copying from the DVD or extracting the contents of the Metalink patch 3731593.
Copy the p3731593_102030_<platform name>.zip from the DVD or Metalink patch to an empty, temparory directory.
Extract the contents of the ZIP file to that same temporary directory.
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.
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.
This section describes the post installation tasks to be performed.
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".
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.
Identify Solaris Agents with Host 3.0 metadata in the Enterprise Manager repository. Upgrade them to 10.2.0.2.0 release or later:
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.
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.
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.
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.
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.
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.
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.
Perform to step 2 (a) to see if there are any more templates with customizations.
Remove filters related to "Generic Log File Monitoring" from "Notification Rules". You can do this by performing the following steps:
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.
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.
Peform step 3 (a).
Remove "Generic Log File Monitoring" related custom configuration done via setting metric thresholds for "Log File Pattern Matched Line Count" host metric:
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.
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.
Perform step 4 (a).
Clear and purge "Log File Pattern Matched Line Count" severities from Solaris 3.0 metadata based hosts:
Run list_lfm_severity_solaris_hosts.sql to identify the hosts:
% sqlplus sysman/<sysman_passwd> @list_lfm_severity_solaris_hosts
If this returns an empty list, go to Step 6.
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.
Perform step 5 (a).
Shutdown the Grid Control Console on all OMS nodes.
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.
Start the Grid Control Console on all OMS nodes.
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
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.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):
Restore the ORACLE_HOME directory that was backed up
Re-install the baseline release and any Patch Sets previously applied, up to but not including this Patch Set
Restore the repository database that was backed up
Restore the Oracle Inventory that was backed up
Regardless of how you de-install a Patch Set, contact Oracle Support Services to verify if the problem you are encountering is being addressed.
This section lists the known issues pertaining to this release.
This section addresses installation and upgrade issues.
This section covers all installation and upgrade issues in general.
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.
(Bug 5648438, 5665837)
If you have patch 5191377 applied in your environment, then follow these steps before upgrading to 10.2.0.3:
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
Login as Repository Owner and execute the following command, against SQL prompt
SQL>drop index mgmt_current_violation_idx_05
(Bug 5758101)
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:
Rebounce the database.
Copy emkey.ora into /OH/sysman/config/
run ./emctl config emkey -emkeyfile /OH/sysman/config/emkey.ora
(Bug 5658897)
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:
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;
Provide the repository credentials for the Specify Database Configuration Screen and click Next.
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.2.0' where component_name='CORE'; commit;
Proceed with the installation.
(Bug 4910745)
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
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)
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)
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)
Patch set upgrade of AIX5L GC Management Agent from 10.2.0.1/10.2.0.2 to 10.2.0.3 from any 10.2 Oracle Management Service fails because of the following error in the applyStandalonePatchUnix job step: /bin/sh[3]: LOGNAME: This variable is read only. This problem occurs only when the custom script is selected in the "Stage or Apply " step of the patch wizard. As a workaround, do not select the "custom script", so that the patch can be applied without any errors. However, note that Oracle Configuration Manager (OCM) will not get configured properly. So you must configure the OCM manually after the patching is complete. For details, refer to the "Oracle Configuration Manager Installation" section of this document.
(Bug 5439873)
As a workaround, make sure that OBJECT_MODE variable is unset before applying the OMS or Agent pacth.(Bug 5844263)
This section addresses OMS and Management Agent-related issues.
For Disk Metrics, the value for "Total IO/Sec" is shown as negative. On IBM AIX 5L systems,the following is not performed: # chdev -l sys0 -a iostat=true, then the disk metrics may show negative values.(Bug 5733032)
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)
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)
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)
You cannot unsecure a Management Agent if the OMS is secured and locked.
(Bug 5531324)
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)
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)
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)
This section addresses patch management -related issues.
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)
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)
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)
The CRS patching deployment procedure is not supported on Microsoft Windows targets.
(Bug 5683930)
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)
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)
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)
This section addresses the client side monitoring issues.
You may see the following message:
"No data coming from a beacon for the forms transactions."
If you do so, then try these:
Verify forms transaction from that beacon.
If it is hanging, then check to see if the Management Agent that the beacon is deployed on is monitoring a Web Cache target.
Due to bug 5700255, if a Management Agent is monitoring a Web Cache target, then it cannot run the forms transactions.
To resolve this issue, deploy the forms transactions on a different Management Agent.
(Bug 5700255)
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)
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)
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)
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)
This section addresses the connector framework issues.
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)
This section addresses enterprise integration issues.
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)
This section addresses Database management issues.
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:
Do not rename the target display name if no urgent request.
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)
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)
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)
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)
This section addresses application server management issues.
If you access Application Server target links using GC console, in the performance section, some graph hint texts are garbled. This isuue is only observed if you view the historical data.
(Bug 5144221)
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)
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)
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:
Upgrade the Management Agent to 10.2.0.3.
Apply the one-off patch 5708626 on the Management Agent.
As a temporary solution, follow these steps:
Open the following file:
${OH}/sysman/admin/metadata/oracle_integrationbpm.xml (agent OH)
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>
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>
Save the file, go to ${OH}/bin (agent OH), and execute the following command:
emctl reload agent
(Bug 5708626, 5704583)
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)
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:
In the Grid Control console, click Deployments to navigate to the Deployments page.
On the Deployments page, click Provisioning and select the Directives tab.
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.
Now click Edit to reach the Edit Directive page.
On the Edit Directive page, click the Upload File tab.
Click the currently associated file manuallymanagedclusterconfig.pl to display the contents.
Now copy the contents of that file to an editor (for example: Notepad or Wordpad.)
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 ];
Save the modified file to your local machine as manuallymangedclusterconfig.pl.
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.
Select Browse and upload the file manuallymangedclusterconfig.pl that was saved in step 9.
Select Finish.
(Bug 5684224)
This section addresses identity management issues.
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 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)
This section addresses Siebel application management issues.
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)
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)
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)
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:
(Bug 5747767)
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)
Manually added services do not get reflected in the services dashboard. To resolve this issue, follow these steps:
Click Reports.
Select the respective service dashboard and click Edit.
Click Elements and then click the Set Parameters link.
Add the newly added service and then click Continue.
Click OK.
(Bug 5718696)
Grid Control cannot handle two Siebel Enterprises with identical names.
(Bug 5654804)
This section addresses host management issues.
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)
This section addresses third-party application server monitoring issues.
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)
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)
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)
This section addresses network appliance filer management issues.
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)
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 AIX 5L Based Systems (64-Bit)
E10254-01
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.
 Copyright © 2007, Oracle. All rights reserved. Legal Notices |
|