Applying O/S Patches to Apps Environments

Operating system (O/S) vendors often recommend applying latest patches or a specific patch to fix a specific issue you are facing, so you may wonder if these O/S patches could possibly have a negative impact on your E-Business Suite environment.

Unfortunately, it is not unknown for an O/S patch to have an impact on Oracle software.  For example, see:

So, how do you identify and mitigate potential risks?

E-Business Suite Certified with Top Level O/S Versions

In general, Apps 11i performs certifications with only the top level operating system version (Solaris 9 or AIX 5.3 for example).  Specific operating system requirements such as kernel settings or O/S patch requirements are documented in:

  • The platform specific release notes
  • Certify
  • Metalink notes relating to eBiz itself or the technology components
Oracle Support would not normally discourage customers from applying any additional O/S patches recommended by O/S vendors unless specific issues have been found and documented that affects Oracle software.

Test Thoroughly Prior to Production Rollouts

As with any patching activity, Oracle recommends that you perform sufficient testing in a representative TEST system prior to implementing in PRODUCTION, to ensure there are no issues introduced by any such changes. 

Minimizing O/S Patching Risks

So, what proactive steps can you take to minimize the risk?   Before applying an O/S patch:
  1. Search Metalink for any known issues. 
  2. If you have any specific concerns, pose the question in the Oracle Forums to see if your peers have any experiences they can share.
  3. Search your O/S vendor's knowledge base and forums for any reported issues.

It is also prudent to have a tested emergency rollout strategy
in place to allow you to recover if an issue is only found once
implemented in the PRODUCTION environment.

Getting Help with O/S Patch Problems

If you are unfortunate enough to experience problems after applying an O/S patch (hopefully in your TEST environment), raise a Service Request with the appropriate Oracle Support team to get help with identifying the root cause of your issue.   Oracle Support will likely expect you to work primarily with your O/S vendor in the initial stages of such an investigation, so you should certainly be engaging your O/S vendor support team as part of the problem resolution process

In conclusion, any change introduces risks as well as the benefits.   Planning, research, a healthy dose of paranoia -- and as much testing as possible -- will allow you to minimize and mitigate the risks involved with applying O/S patches, giving the best chance of a successful implementation.


"In general, Apps 11i performs certifications with only the top level operating system version (Solaris 9 or AIX 5.3 for example). "

really? A quick check on metalink shows that Apps 11.5.8 thru are all certified on Solaris 2.6, 8 and 9 - and those have been out for YEARS.

Same with the case with Apps 11.5.8 thru on Linux X86 - RedHat 2.1 is still listed and it's a few years old (RH 4 quarterly update 5 I believe is current)

Having said all that, and spent about a month working a TAR where Support didn't clearly document all the issues with going from RH2.1 to 4, I'd agree with you that testing is very very necessary, as I don't feel support adaquetely tests out various supported platforms.

Posted by jay Weinshenker on September 26, 2006 at 08:34 AM PDT #

An added topic such as what steps need to be done in an Apps env. after an OS patch has been applied (relinking) would be helpful.

Posted by Chris Bittakis on September 26, 2006 at 09:29 AM PDT #

Hi Jay,

Apologies for not being clear in my introduction, I was meaning Oracle do not certify at any particular patch bundle level within the operating system version, for example we certify Solaris 9 but do not re-certify every time Sun bring out a patch bundle for Solaris 9. Similarly for Redhat, Redhat 4 is certified, but there is no re-certification for every SP that is released.

This is a only general rule however, so always check Certify, the installation notes, platform specific release notes and search Metalink for the latest updates



Posted by Mike Shaw on September 26, 2006 at 06:54 PM PDT #


You have raised a good point, and as you say this is a good place to discuss it.

Strictly speaking, there are no mandatory requirement within eBiz or Oracle Technology to relink after apply *any* O/S patch, as it depends on what the O/S patch is delivering.

There will be cases where you will need to relink as you say, which will either be identified during your testing or you could potentially take the stance to pro-actively relink for all O/S patching activity.

The reasoning behind this is :-
a) if there are problems with relinking of Oracle binaries because of the O/S patch, this is the time you want to find and solve them. You will still have the opportunity to restore the previous versions if the relinking problems cannot be overcome.
b) Oracle is using O/S calls which might have been changed so relinking will resolve conflicts and ensure they are used optimally
c) References to libraries will be replaced by the new ones

Metalink Note 131321.1 "How to Relink Oracle Database Software on UNIX" also discusses this issue, small extract below.
Relinking Oracle manually is suggested under these circumstances
- A change has been made to the OS system libraries



Posted by Mike Shaw on September 26, 2006 at 07:52 PM PDT #

For Sun Solaris, there is one metalink document# 152373.1
"Veritas, Oracle, Sun Product Certification Matrix", which also includes the specific versions and maintenance pack details that are certified.
Certifications for individual patches is not included, so this article is applicable for all those individual patches.

Posted by Rama Nalam on September 26, 2006 at 09:42 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« July 2016