Oracle Support Master Note for 10g Enterprise Manager Grid Control Agent Performance & Core Dump issues (Doc ID 1087997.1)

 

 

For most current information refer Master Note for 10g Enterprise Manager Grid Control Agent Performance & Core Dump issues (Doc ID 1087997.1)

 

 

In this Document
  Purpose
  
Scope and Application
  
Master Note for 10g Enterprise Manager Grid Control Agent Performance & Core Dump issues
     Functional Overview of Grid Control Agent Subsystems
     
What can impact Agent Performance?
     Configuring Agent for Optimal Performance
     
Diagnostic Tools Available for Troubleshooting Agent Performance & Core Dumps issues
     
Note for Troubleshooting the Grid Control Agent
     
Troubleshooting the Grid Control Agent Core Dump
     
Troubleshooting the Grid Control Agent High CPU Utilization
     
Troubleshooting the Grid Control Agent High Memory Consumption
     
Troubleshooting the Grid Control Agent "File handles exhausted" / "Too many open files"
     
Best Practices (Certification, Maintenance Activities, OCM, Healthcheck, CPU & PSU)
  
References


Applies to:

Enterprise Manager Grid Control - Version: 10.1.0.2 to 10.2.0.5 - Release: 10.1 to 10.2
Information in this document applies to any platform.

Purpose

This Master Note helps understand 10g Management Agent Performance and Core Dump issues and provides assistance in using diagnostics effectively to debug/troubleshoot and resolve issues encountered. 

Scope and Application

This document is intended to assist Enterprise Manager Grid Control Administrators effectively troubleshoot 10g Grid Control / Management Agent Performance and Core Dump issues. This document covers the following topics:

1. Functional Overview of Grid Control Agent Subsystems
2. What can impact Agent Performance?
3. Configuring Agent for Optimal Performance
4. Diagnostic Tools Available for Troubleshooting Agent Performance & Core Dumps issues
5. Troubleshooting and using Diagnostics effectively.
6. Best Practices (Certification, Maintenance Activities, OCM, Healthcheck, CPU & PSU)

Master Note for 10g Enterprise Manager Grid Control Agent Performance & Core Dump issues

Functional Overview of Grid Control Agent Subsystems


An understanding of Grid Control Agent subsystems is fundamental to effective performance analysis. 

  • HTTP Listener and Client

Listens in persistent thread - Spawns new threads to handle incoming connections - Other agent components (upload, job, ping ..etc) can start outgoing (client) connections in their own threads - Manage HTTP/1.1 protocol - SSL support using NZ layer - Not an Apache listener- Handles all communication to-and from the Agent - All communication via HTTP[s].

  • Ping Manager

Performs the initial handshake between the Agent and the OMS - Exchanges timezone - protocol (version) information - A successful ping from the agent to the OMS is required before any uploads will occur.
Periodically, sends HTTP heartbeat request to OMS and verifies response, OMS response dictates interval before next ping.

  • Upload Manager

Uploads metric data and violations to the OMS. This data gets uploaded over different channels. The priority and upload interval of the data depends on the channel in which it gets uploaded.

Note: For more information about HTTP Listener,Ping Manager & Upload Manager, refer to Note 1084777.1: Description of Important Communication Components in a 10g Enterprise Manager Grid Control Agent.

 

  • Job Engine (Task Executor)

Runs OS commands on request - Execute Job steps - Execute File operations (getFile & putFile) - Execute Agent-to-Agent requests (fileFromRemoteEMD & pipedRemoteOps) - Runs OS metrics.

  • Dispatcher Manager

Runs in threads launched by HTTP listener to handle incoming connections - Parses XML request (using Remote API "classes") - Takes requests via EMD Client and dispatches them to the relevant modules.
Calls into appropriate agent subsystem to handle request - Constructs XML response and sends to client.

  • Target Manager

Loads target instances from the file targets.xml and provides them to the rest of the subsystems. Responsible for computing Dynamic properties of the monitored targets.

  • Metric Engine

Loads target metadata and is responsible for evaluating metrics. It processes these metric results and generates data files.

  • Fetchlet Manager

Maintains a list of all the fetchlets registered with the agent. It looks at fetchlets.reg to build this list. Channels the metric evaluation request to the appropriate fetchlet. For more information refer to the documentation Enterprise Manager Extensibility Guide - Section Fetchlets.

  • Recvlet Manager

Maintains a list of all the receivelets registered with the agent. It looks at recvlets.reg to assemble this list. Once the receivelets are initialized, the agent can then generate appropriate server generated alerts. For more information refer to the documentation Enterprise Manager Extensibility Guide - Section Receivelets.

  • Scheduler Manager

Schedules activities in next runtime order, with multiple schedule formats (once, interval, weekly & monthly)
Basically used by any component that needs to perform certain actions at specific times.
To check the scheduled elements issue "emctl status agent scheduler" command.

  • Collection Manager

Loads collection metadata and schedules collections for target instances that are being monitored by the agent.

Default Collections: Collection metadata that is applicable for all targets of a target-type.
Target Collections: Collection metadata that is applicable for a specific target instance. 

  • Blackout Manager

Manage blackout information stored in AGENT_HOME/sysman/emd/blackouts.xml. Scheduled collections consult Blackout Manager, if target is currently blacked-out, collection does not proceed.

  • Job Auxiliary Programs (nmo, nmocat, & nmosudo)

nmo: Executable launched by agent, responsible for authenticating OS user credentials, impersonating user, and running command.
nmosudo: Acts as a proxy for the Agent to ensure that all commands that are run using sudo/pbrun are 'trusted' that is, they came from the agent binary and not from someone running the command from the command line.
nmocat: Executable used by getFile/putFile copies from stdin to created file, or file to stdout.

  • Reload Manager

Reloads any changed configuration data without requiring an agent bounce - Handles all reload requests from command-line, Remote API, or agent component - Serialized, so only one thread is reloading at a time.
Components reloaded in initialization order, so a component's dependencies have already reloaded before it does - Many components check the file system timestamps in order to reload only the changed content.

  • Health Monitor

Provides the functionality to call other modules back if they have not completed an operation within a certain time frame.
Health Monitor does not have the knowledge of the other subsystems - The other components subscribe to the Health Monitor, telling it to perform certain actions 'callbacks' if the operation has not completed in the time specified. Most 'Callbacks' simply restart the agent.

  • EMDClient Interface

The Agent provides an EMDClient Java Interface that communicates with the agent over HTTP/HTTPS protocol. The agent processes the requests and responses in the Dispatcher layer.

  • Cluster Manager ( Only for Clustered Agent (RAC Agent) )

Target-types that exist on multiple nodes (for example a RAC database) are monitored by only one agent in the cluster at a time, known as the Master Agent. 

For more details on the above components, refer to 
Note.1101615.1: Description of Important Components / Threads in a 10g Enterprise Manager Grid Control Agent 

=======================================================================

What can impact Agent Performance?

The Enterprise Manager Grid Control Agent is installed on a host to monitor targets deployed on the same host. Typical monitored targets are host, database, application server, listener.. etc. Grid Control Agent resource consumption scales almost linearly with increasing amount of monitored targets.

The main common resource consumers are:

  • Targets

The purpose of the agent is to administer and maintain 'targets'. A target is an entity, defined by the EM administrators, which needs to be monitored.
Number of Targets Monitored by the Agent could be a reason of high resource consumption.

  • Metrics

Every target has a set of 'metrics' defined for it, which will get executed to determine the health and the status of the target. These metrics are monitoring entities, which are getting called on a regular basis by the Agent.

Child processes are sometimes created by the Management Agent in the course of evaluating a metric or running a job. For example a shell script fired by the Fetchlet Manager thread to collect a metric against one of the targets or a Database Server Process serving the Agent queries.

  • Agent Process

The Agent process or one of its main threads. This is the most visible one.
One of the Agent's subsystem could be a reason behind Agent's performance problem.

For more information refer to Note 375509.1: Understanding Oracle Enterprise Manager 10g Agent Resource Consumption 

Back to Top

=======================================================================

Configuring Agent for Optimal Performance

Note 464851.1: Agent Monitoring Large Number of Targets Experiences Performance Problems 

Note 786978.1: Best Practices for Monitoring Large Number of AS 10.1.3.x OC4J Targets Using Grid Control Agent 

Note 428410.1: How to Increase the Virtual Memory Limit for the Agent to Avoid Unnecessary Agent Re-starts? 

Back to Top

=======================================================================

Diagnostic Tools Available for Troubleshooting Agent Performance & Core Dumps issues

  • Grid Console

Enterprise Manager Grid Control comes with a comprehensive set of performance and health metrics that enables automated monitoring of key components in your environment, such as applications, application servers, databases, as well as the back-end components on which they rely (hosts, operating systems, storage, and so on).

When a metric reaches the predefined warning or critical threshold, Enterprise Manager generates an alert, which shows up in the monitoring pages, as well as in the notifications that you define. In this way, you can monitor services, systems, groups, and any other target that you want to manage.

The lists of all Agent & Host Metrics are available here:

Enterprise Manager Framework, Host, and Services Metric Reference Manual

Among these the following Metrics are related to the Agent & Host Performance:

1. Agent

1.1 Agent Process Statistics

1.1.1 Agent Resident Memory Utilization (KB)
1.1.2 Agent Virtual Memory Utilization (KB)
1.1.3 CPU Usage (%)
1.1.4 Number Files Open
1.1.5 Number Handles Open
1.1.6 Number Threads Created
1.1.7 Process ID
1.1.8 Resident Memory Utilization (%)
1.1.9 Resident Memory Utilization (KB)
1.1.10 Virtual Memory Utilization (KB)
1.1.11 Virtual Memory Utilization Growth (%)

2. Host

2.4 CPU Usage

2.4.1 CPU Interrupt Time (%)

2.16 Load

2.16.1 CPU in IO-Wait (%)
2.16.2 CPU Interrupt Time (%)
2.16.3 CPU Queue Length
2.16.4 CPU Utilization (%)
2.16.5 Memory Page Scan Rate (per second)
2.16.6 Memory Utilization (%)
2.16.7 Page Transfers Rate
2.16.8 Run Queue Length (1 minute average)
2.16.9 Run Queue Length (15 minute average)
2.16.10 Run Queue Length (5 minute average)
2.16.11 Swap Utilization (%)

2.26 Program Resource Utilization

2.26.1 Program's Max CPU Time Accumulated (Minutes)
2.26.2 Program's Max CPU Utilization (%)
2.26.3 Program's Max Process Count
2.26.4 Program's Max Resident Memory (MB)
2.26.5 Program's Min Process Count
2.26.6 Program's Total CPU Time Accumulated (Minutes)
2.26.7 Program's Total CPU Utilization (%)

  • Metric Browser

The Metrics browser is a troubleshooting tool that can be used with the Enterprise Manager 10g framework to see the 'raw' data being collected by the Management Agent.

Note 276350.1: How to Enable the Metrics Browser/Agent Browser for the Oracle Management Agent

  • RDA

The Remote Diagnostic Agent (RDA) can be executed specifically with the Grid Control Agent profile which is called AGT, when you run the RDA using the module AGTthis will collect the information for the Grid Control Management Agent. Use this option if you have a problem on the Grid Control Management Agent itself or if you have a problem with all or some targets monitored by the Grid Control Management Agent.
The steps to execute the RDA with AGT profile are explained under "Run the RDA against the Grid Control Management Agent" section in the following Note:

Note 1057051.1: How to Run the RDA against a Grid Control Installation

  • Using OS level Utilities:

Unix/Linux

·         OS Watcher:

The OS Watcher is a tool developed by the Database Center Of Expertise team that can be very helpful in collecting OS related statistics that can be used when diagnosing a performance problem.

1.      OS Watcher (OSW) is a series of shell scripts that collect specific kinds of data, using operating system diagnostic utilities.

2.      Control is passed to individually spawned operating system data collector processes, which in turn collect specific data, timestamp the data output, and append the data to pre-generated and named files.

3.      Each data collector will have its own file, created and named by the File Manager process.

4.      OSW invokes the distinct operating system utilities listed below as data collectors.

5.      These utilities will be supported, or their equivalents, as available for each supported target platform:

ps
top
mpstat
iostat
netstat
traceroute
vmstat

Note 301137.1: OS Watcher User Guide

·         Custom Script (agent_snap.sh)

Note 464414.1: Script for Checking the Agent CPU, Memory & Threads Usage.  (available  for Linux, Oracle Solaris & AIX)

Microsoft Windows Utilities

·         OS Watcher (for Microsoft Windows):

Note 433472.1: OS Watcher For Windows (OSWFW) User Guide 

·         Microsoft Sysinternals Utilities

Process Explorer
It has a GUI interface and displays more information about each running process. Find out what files, registry keys and other objects processes have open, which DLLs they have loaded, and more. This uniquely powerful utility will even show you everything about the process (CPU,Memory,Handles ...etc)

Process Monitor
Monitor file system, Registry, process, thread and DLL activity in real-time.

PsList
Show information about processes and threads.

ProcDump 
Is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike.

VMMap
See a breakdown of a process's committed virtual memory types as well as the amount of physical memory (working set) assigned by the operating system to those types. Identify the sources of process memory usage and the memory cost of application features.

Handle
This handy command-line utility will show you what files are open by which processes, and much more.

Note: Microsoft Sysinternals Utilities are third party tools and any problems faced while using these tools cannot be supported by Oracle Support. Also, the above mentioned download links are not maintained by Oracle and hence are subject to change.

Back to Top

=======================================================================

 

Note for Troubleshooting the Grid Control Agent

Every Subsystem/Thread in the Agent can be traced individually, to avoid putting the entire agent process in debug mode to investigate an issue.

 

All the available subsystems/threads are listed in the file emd.properties. 
Refer to 
Note 235290.1: Understanding the Enterprise Manager Management Agent 10g 'emd.properties' File

Section "Table2: Agent Tracing Parameters"

Note.1101615.1: Description of Important Components / Threads in a 10g Enterprise Manager Grid Control Agent 

To change the trace level for a specific subsystem, refer to the 
Note 229624.1: How to Locate and Control the Size and the Content of Grid Control Agent 10g Log / Trace Files
Section "Controlling the Content (Trace Level) of Management Agent Trace Files"

Back to Top

Troubleshooting the Grid Control Agent Core Dump

Core dumps are the sign of an abnormal situation and in most of the cases it happens due to a heavily loaded server.Two main reasons for Agent to produce a core dump:

  • The Agent crashes due to signal trap (for example SIGSEGV)

The file emagent.nohup shows the following messages:

signal handler called due to abnormal condition; dumping core due to signal SIGSEGV

EMAgent has exited due to an internal error

  • The Agent is hung and the watchdog kills it.

The file emagent.nohup file shows the following messages:

EMAgent either hung or in abnormal state.
EMAgent will be restarted/thrashed.

For troubleshooting steps, refer to the Note 1087674.1: How To Effectively Investigate & Diagnose Grid Control Agent Core Dump Issues?

To find all documents related to the Grid Control Agent Core Dump issues:

Log in to My Oracle Support then Click on the Knowledge tab.
From the left pane "Browse Knowledge" click on:
Enterprise Management -> Enterprise Manager Consoles - Packs - and Plugins -> Enterprise Manager Grid Control ->All of Enterprise Manager Grid Control.
Enter a search with the following keywords:

Grid Control Agent Generating Core Dumps <symptom that you have found in the log/trace files>
Grid Control Agent Crashes with Core Dump <symptom that you have found in the log/trace files>
Grid Control Agent Restarts with Core Dump <symptom that you have found in the log/trace files>
Grid Control Agent Hangs with Core Dump <symptom that you have found in the log/trace files>

Note: the Grid Control Agent log/trace files are located in the Agent $ORACLE_HOME/sysman/log directory or in the Agent $ORACLE_HOME/nodename/sysman/log directory for a clustered agent.


Some examples:
Grid Control Agent Crashes with Core Dump due to DBSNMP User Password is in Grace Period
Grid Control Agent Restarts with Core Dump when Monitoring NetApps Filer Target
Grid Control Agent Hangs with Core Dump due to "remote api of type 10634 has timed out" Error in emagent.trc File
Grid Control Agent Generating Core Dumps when ulimit of Open File Descriptors is Set Too Low

Back to Top

Troubleshooting the Grid Control Agent High CPU Utilization

CPU utilization reflects amount of time the Grid Control Agent process was scheduled and actually executed by a CPU. The CPU utilization by Grid Control Agent depends on number of factors including the Agent itself and Host/Targets characteristics.

For troubleshooting steps, refer to the 
Note 1089898.1: How To Effectively Investigate & Diagnose Grid Control Agent High CPU Utilization Issues? 

To find all the documents related to the Grid Control Agent consuming high CPU:

Log in to My Oracle Support then Click on the Knowledge tab.
From the left pane "Browse Knowledge" click on:
Enterprise Management -> Enterprise Manager Consoles - Packs - and Plugins -> Enterprise Manager Grid Control ->All of Enterprise Manager Grid Control.
Enter a search with the following keywords:

Grid Control Agent Consumes High CPU <symptom that you have found in the log/trace files>

Some examples:
Grid Control Agent Consumes High CPU when Executing parse-log1.pl / Log File Monitoring Metric
Grid Control Agent Consumes High CPU when File Descriptor Limit is Set to Unlimited
Grid Control Agent Consumes High CPU when "emdprocstats.pl" Script Spawned by the Agent


Back to Top 

Troubleshooting the Grid Control Agent High Memory Consumption

The Grid Control Agent Memory growth can occur due to various reasons including leaks in Agent/dependent subsystems, child processes are sometimes created by the Management Agent in the course of evaluating a metric or running a job or when there are many monitored targets.

For troubleshooting steps, refer to the 
Note 1092466.1: How To Effectively Investigate & Diagnose Grid Control Agent High Memory Utilization Issues? 

To find all the documents related to Grid Control Agent consuming High memory:

Log in to My Oracle Support then Click on the Knowledge tab.
From the left pane "Browse Knowledge click on:
Enterprise Management -> Enterprise Manager Consoles - Packs - and Plugins -> Enterprise Manager Grid Control ->All of Enterprise Manager Grid Control.
Enter a search with the following keywords:

Grid Control Agent Consumes High Memory <symptom that you have found in the log/trace files>

Some examples:
Grid Control Agent Consumes High Memory while Monitoring many OC4J Targets
Grid Control Agent Consumes High Memory while Monitoring Netapp Targets

Troubleshooting the Grid Control Agent "File handles exhausted" / "Too many open files"

Grid Control Agent exhausting file descriptors / handles issues have a specific error messages in emagent.trc or emgent.log files and sometimes the issue can be verified by issuing the command :

> $ emctl status agent

 

The Agent may generate error messages in emagent.trc or emagent.log files as below:

Too many open files (errno=24)

<DATE> Thread-# ERROR upload: Agent has run into EMFILE error when trying to open a file. This could leak to discrepancy between agent's state in memory and state in files. Please investigate and fix the cause of the too many open file issue and restart agent

<DATE> Thread-# WARN upload: nmehum_mergeLFIFiles1: Failed to open file, ret = -2, filename: B0000117.tmp, (errno=24: Too many open files)

<DATE> Thread-# ERROR upload: Error opening B0000030.tmp for output (errno=24: Too many open files)

ERROR command: Error initializing stdin pipes: (errno=24: Too many open files)

ERROR: snmeuf_dirlist can't list directory: <ORACLE_HOME>/sysman/emd/upload: Too many open files (errno=24)

> $ emctl status agent - command shows output as below:

Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
Agent Version : 10.2.0.5.0
OMS Version : 10.2.0.5.0
Proto Version : 10.2.0.5.0
........
.......
Total Megabytes of XML files uploaded so far : 190.63
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 0.00
Available disk space on upload filesystem : 74.52%
Collection Status : File handles exhausted
Last attempted heartbeat to OMS : 2009-06-19 11:22:32
Last successful heartbeat to OMS : 2009-06-19 03:00:52
---------------------------------------------------------------
Agent is Running and Ready

 

For troubleshooting steps, refer to the Note 1092777.1: How To Effectively Investigate & Diagnose Grid Control Agent "File handles exhausted" / "Too many open files" Issues? 

To find all the documents related to the Grid Control Agent "File handles exhausted" / "Too many open files" issues:

Log in to My Oracle Support then Click on the Knowledge tab.
From the left pane "Browse Knowledge click on:
Enterprise Management -> Enterprise Manager Consoles - Packs - and Plugins -> Enterprise Manager Grid Control ->All of Enterprise Manager Grid Control.
Enter a search with the following keywords:

'Too many open files'
'File handles exhausted'
'EMFILE error'

=======================================================================

Best Practices (Certification, Maintenance Activities, OCM, Healthcheck, CPU & PSU)

EM Certification Checker

It is strongly recommended that you always use a certified combination of OMS, Agent and Repository Database for managing Targets which are certified with this combination. The Enterprise Manager Certification details are available in:

Note 412431.1: Oracle Enterprise Manager 10g Grid Control Certification

Maintenance Activities

This section lists some of the best practices which will help prevent problems with Agent:

  • There are plenty of metrics available in the console to check Agent's health, always check the available out-of-box Agent Metrics, you may use the following Grid Control URL to list the Agents: 

https://OMShostname:port/em/console/admin/rep/emdList

  • The out-of-box default collection frequencies for the metrics are based on an average load on the machine and the monitored target, and will be more than adequate for most targets. If a metric is timing out, it indicates a case of severe load on either the box or the monitored target (or both) that will need to get investigated. If this load is considered normal and will most likely continue as-is, the collection interval of the affected metrics will need to be altered.
  • Take valid backup of the Agent Home at regular intervals.
  • Take a backup of all the files & directories under AGENT_HOME/sysman/config & AGENT_HOME/sysman/emd to restore back any configuration files that are deleted by accident.
  • Never delete any files under AGENT_HOME/sysman/emd in order to fix problems, this will create more problems.

OCM

Oracle Configuration Manager (OCM) works with My Oracle Support to enable proactive support capability that helps you organize, collect and manage your Oracle configurations by providing Proactive configuration-specific notification of Security and General Alerts, HealthCheck recommendations based on Support Best practices when using configuration auto-collection, Simplified Service Request logging, tracking and reporting and Project cataloging of key milestones and contacts associated with your configurations.

  • Among the above, the following topics are related to the Enterprise Manager:
    • 2.52 Oracle Enterprise Manager 10g Grid Control Management Agent
    • 2.54 Oracle Enterprise Manager 10g Grid Control Management Service
    • 2.53 Oracle Enterprise Manager 10g Grid Control Management Repository
    • 2.72 Oracle Grid Control Repository (for oracle_emrep target)
    • 2.38 Oracle Agent Deployment Configuration (oracle_emd target)
    • 2.73 Oracle Home
    • 2.23 Host

Note: The above list is expected to be expanded as and when new collections are introduced in future.

 

  • It is also advisable to review the collections available for the Database instance, so that the Database hosting the repository can be monitored as well:
    • 2.10 Database Instance
    • 2.78 Oracle Listener

Healthcheck

Healthchecks are executed dynamically against the Oracle Configuration Manager uploaded configurations in My Oracle Support. These checks, based on Oracle Best practices, will proactively notify you of potential problems in your environment, and provide recommendations that help you improve system performance and avoid problems in your Oracle environment.

  • If you are receiving any Healthcheck alerts in My Oracle support, then refer to the following document for the alert details and its corresponding document for resolving the same:

Note 868955.1 My Oracle Support Health Checks Catalog

  • For Healthchecks specific to the Enterprise Manager and Repository Database, refer to the sections titled:

Enterprise Manager (for the OMS)
Oracle Database (for the Database hosting the Repository)



CPU and PSU

  • CPU

Critical Patch Updates (CPU) is the primary means of releasing security fixes for Oracle products. They are released on the Tuesday closest to the 15th day of January, April, July and October. This page lists all the currently available Critical Patch Updates (CPUs) in chronological order and is updated whenever new Critical Patch is released. You can also subscribe to the CPU Email Alerts using the steps listed here

To obtain the latest CPU patch details for the Enterprise Manager Grid Control and its dependent products - Oracle Application Server and Oracle Database:

- In the
 page, click on the link shown for the latest CPU in the table under the 'Critical Patch Updates'
- The next page, lists all the products which have security fixes in the chosen CPU release.Scroll down to 'Patch Availability Table ..' topic and find the table with details for the Product Group and Patch Availability and Installation Information.
- In the table, find the row related to Product Group: 'Oracle Enterprise Manager' and pick up the document number given in the Patch Availability and Installation Information column. In the document, navigate to:

"Critical Patch Update Availability for Oracle Products" and then to
"Oracle Enterprise Manager Grid Control"

Back to Top

  • PSU

Patch Set Updates (PSU) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule. PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October. The PSUs serve as a new baseline version for reporting issues to Oracle, hence it is always recommended to be on the latest PSU release.

    • For more details on PSU, refer Note 854428.1: Patch Set Updates for Oracle Products
    • For Enterprise Manager specific PSU, refer Note 822485.1: Oracle Recommended Patches -- Oracle Enterprise Manager
  • Choosing between CPU / PSU patches

    The PSU and CPU released each quarter contain the same security content. However, the patches employ different patching mechanisms, so customers need to choose wisely which patch satisfies their needs better:
    • A PSU can be applied on the CPU released at the same time or on an any earlier CPU for the base release version. A PSU can be applied on any earlier PSU or the base release version. CPUs are only created on the base release version.
    • Once a PSU has been installed, the recommended way to get future security content is to apply subsequent PSUs. Reverting from PSU back to CPU, while possible, would require significant effort, and so is not advised.
  • Getting CPU / PSU patch recommendations via OCM

    OCM also collects and recommends the latest CPU and PSU patch that can be applied to a particular Oracle Home. These details can be seen in the My Oracle Support ->Patches and Updates -> Patch Recommendations section

    - 'Security' patch recommendations include the CPU patches.
    - 'Other Recommendations' include the PSU patches. 

References

NOTE:1081865.1 - Master Note for 10g Grid Control OMS Process Control (Start, Stop and Status) & Configuration
NOTE:1082009.1 - Master Note for 10g Grid Control Agent Process Control (Start, Stop & Status) & Configuration
NOTE:1086343.1 - Master Note for 10g Grid Control Enterprise Manager Communication and Upload issues
NOTE:1092513.1 - Master Note for 10g Enterprise Manager Grid Control Security Framework
NOTE:1098262.1 - Master Note for Diagnostic Tools for 10g Enterprise Manager Grid Control Components
NOTE:1161003.1 - Master Note for 10g Grid Control OMS Performance Issues

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

News and Troubleshooting tips for Oracle Database and Enterprise Manager

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today