Monday Nov 18, 2013

Fusion Middleware Error Correction Policy - Have You Got a Patch and Maintain Strategy?

It is not uncommon to come across Fusion Middleware 11g product solutions which do not have the latest patch set applied. Example: a business has a SOA Suite in production. The solution has been working fine for three years, and then new business requirements forces an application change. The change, unfortunately, breaks rather than enhances existing functionality. A Service Request is logged with My Oracle Support and the business receive the news that the problem is caused by a bug, a patch for which is available. "Good news!" But, it is a patch which can only be applied against the latest patch set. Furthermore, the fix will not be backported to "Oh .. really .. why can't we get a fix for the patch set we are on? Lifetime Support Policy - Level: Premier Support - has not yet expired for 11g."

The business has been blissfully unaware of the Server Technology Products Software Error Correction Policy.  This document describes the different types of patches which Oracle may release for products and the policies which surround them. It is particularly important, however, to read the product line specific advice found in the Appendix. To part quote, the advice for Oracle Fusion Middleware:

Grace Period: up to 1 year, minimum 3 months.

You have up to one year from the initial release of the patch set to install the new patch set, and can receive new bug fixes for the previous patch set during that time ...

For details (including links to documents containing error correction dates for specific products and patch sets), see

Error Correction Support Dates for Oracle Fusion Middleware (10g/11g/WLS) (Doc ID 944866.1).

In 944866.1, you will find a link to

Error Correction Support Dates for Oracle Fusion Middleware 11g (11.1.1/11.1.2) (Doc ID 1290894.1)

which shows that the error correction grace period for Fusion Middleware (which covers SOA) ended in January 2012. This explains why, in our scenario above, the business will need to first apply the latest available patch set, followed by the interim patch in order to fix their issue.

In conclusion, having a patch and maintain strategy is essential. Maintaining Fusion Middleware products at the latest major version and/or patch set release + updates has the following benefits:

  • Proactively applying the latest patch set and updates can avoid problems and therefore minimize downtime.
  • It can reduce the time taken to consume or obtain fixes for new issues.

If you are using Oracle Fusion Middleware 11g, bookmark and regularly review:

Information Center: Patching and Maintaining Oracle Fusion Middleware 11g (Doc ID 1341616.2)

Screenshot of Information Center: Patching and Maintain Fusion Middleware 11g

This Information Center contains links to knowledge articles which discuss the Error Correction policy and list Error Correction end dates. The Information Center is also a one stop shop for links to patch and patch set collateral:

  • Patch Set Release Announcements
  • Patch Set Updates (including Critical Patch Update) information
  • Patching Documentation 
  • And more ..

Get proactive, know your error correction end dates and put in a place a strategy to keep your product up to date with the latest patch set and updates.

Tuesday Nov 20, 2012

RDA and Fusion Middleware Diagnostic Framework Integration

Further to my last blog entry "FMw Diagnostic Framework : Automatic Capture of Diagnostic Data Upon First Failure!" I have spent some time exploring how Remote Diagnostic Agent (RDA) integrates with Diagnostic Framework.

Remote Diagnostic Agent, by default, collects the information about the last 10 incidents which have been captured in the Automatic Diagnostic Repository (ADR). This information can be located via RDA's Start Page Menu system. See screenshot below.

Screenshot - Viewing Diagnostic Framework Incident Information in a RDA Package

Note: In the next release of RDA - version 4.30 - the Diagnostic Repository menu label will have it's own position in the weblogic managed server sub menu hierarchy rather than be a child menu item of the logs menu

Diagnostic Framework is also capable of launching RDA engine and including the output in an incident package. This is achieved via the command "IPS GENERATE PACKAGE". The RDA output is written to

DOMAIN_HOME/servers/<server name>/adr/diag/ofm/<domain name>/<server name>/

The RDA collected files are best viewed (as shown in the screenshot above) by opening the RDA Start Page - "DFW__start.htm" - from this directory in a browser. If you do not have a browser available on the host machine, zip the contents of the rda directory and transfer and extract to a machine which has a browser. 

The explanation of the integration goes a little deeper. If you want to know more, read My Oracle Support document:

Understanding RDA and FMW 11g Diagnostic Framework Integration [Document 1503644.1]

Monday Sep 10, 2012

Resolve SRs Faster Using RDA - Find the Right Profile


Remote Diagnostic Agent (RDA) is an excellent command-line data collection tool that can aid troubleshooting / problem solving. The tool covers the majority of Oracle's vast product range, and its data collection capability is comprehensive. RDA collects data about

  • the operating system and environment, including
    • environment variable, kernel settings
    • network
    • o/s performance
    • o/s patches
    • and much more
  • the Oracle Products installed, including
    • patches
    • logs and debug
    • metrics
    • configuration
    • and much more

In effect, RDA can obtain a snapshot of an Oracle Product and its environment. Oracle Support encourages the use of RDA because it greatly reduces service request resolution time by minimizing the number of requests from Oracle Support for more information. RDA is designed to be as unobtrusive as possible; it does not modify systems in any way. It collects useful data for Oracle Support only and a security filter is provided if required.

RDA can be downloaded via this My Oracle Support document

Remote Diagnostic Agent (RDA) 4 - Getting Started [ID 314422.1]

Find and Use the Right RDA Profile

One problem of any tool / utility, which covers a large range of products, is knowing how to target it against only the products you wish to troubleshoot. RDA does not have a GUI. Nor does RDA have an intelligent mechanism for detecting and automatically collecting data only for those Oracle products installed. Instead, you have to tell RDA what to do.

There is a mind boggling large number of RDA data collection modules which you can configure RDA to use. It is easier, however, to setup RDA to use a "Profile". A profile consists of a list of data collection modules and predefined settings. As such profiles can be used to diagnose a problem with a particular product or combination of products.

How to run RDA with a profile?

( <rda> represents the command you selected to run RDA (for example,, rda.cmd,, and perl

1. Use the embedded spreadsheet to find the RDA profile which is appropriate for your problem / chosen Oracle Fusion Middleware products.

2. Use the following command to perform the setup

<rda> -S -p <profile_name> 

3. Run the data collection


Run the data collection. If you want to perform setup and run in one go, then use a command such as the following:

<rda> -vnSCRP -p <profile name>

For more information, refer to:

Remote Diagnostic Agent (RDA) 4 - Profile Manual Pages [ID 391983.1]

Additional Hints / Tips:

1. Be careful! Profile names are case sensitive.

2. When profiles are not used, RDA considers all existing modules by default. For example, if you have downloaded RDA for the first time and run the command

<rda> -S

you will see prompts for every RDA collection module many of which will be of no interest to you. Also, you may, in your haste to work through all the questions, forget to say "Yes" to the collection of data that is pertinent to your particular problem or product. Profiles avoid such tedium and help ensure the right data is collected at the first time of asking.

3. RDA has a security filter which removes potentially sensitive data such as

  • Domain names
  • Group names
  • Host names
  • IPv4 and IPv6 addresses
  • LDAP domain components
  • Network masks
  • User names

You can switch on at RDA setup by appending "-Security" to the profile value

<rda> -vnSCRP -p <profile name>-Security


<rda> -vnSCRP -p FM11g_WlsWebTier-Security

If you already have a setup.cfg, you can enable the security filter by running the command

<rda> -X Filter enable 


This is the blog of the Oracle Fusion Middleware Proactive Support Delivery Team. Here we will provide information about our activities, publications, product related information and more. Feedback welcome.

Follow OracleMWSupport on Twitter


« March 2015