Can E-Business Users Apply Database Patch Set Updates?

[Nov. 29, 2010 update: For a list of overlay patches required to address conflicts between database PSUs and EBS patch requirements, see Note 1147107.1]

[Aug 11, 2009 update: fixed typo and replaced Note 584428.1 references with correct Note 854428.1]


The Oracle Server Technologies' division introduced a new release vehicle in late July 2009:  Patch Set Updates (PSU).  Patch Set Updates are cumulative patches containing between 50 to 100 recommended bug fixes for the Oracle Database.  Patch Set Updates include:
  • Field-tested fixes for critical technical issues that may affect a large number of customers
  • Critical Patch Update fixes

db10204_download_screenshot.png

Patch Set Updates will be released on the same quarterly schedule as Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October.  Also notable is that PSU patches do not include:
  • Changes that require re-certification (e.g. fixes that cause optimizer plan changes)
  • Fixes that require configuration changes
Patch Set Updates are identified by the fifth digit of the database version number.  For example the initial PSU for the 10gR2 10.2.0.4 Database is 10.2.0.4.1.  The next PSU will be 10.2.0.4.2.

More details about Patch Set Updates are described here:
Safe to Apply to E-Business Environments?

Yes.  Database Patch Set Updates may safely be applied to Oracle E-Business Suite Release 11i and 12 environments. 

We explicitly run certification tests with E-Business Suite products against major database releases such as 10gR2 version 10.2.0.4 and 11gR1 version 11.1.0.7.  We do not perform formal EBS certification testing for individual interim, emergency, or "one-off" patchsets for the Oracle database, but consider them to be fully compatible and supported for use with the E-Business Suite. 

Patch Set Updates (e.g. 10.2.0.4.1) are simply bundles of interim or emergency patches released on top of major database releases.  Therefore, Patch Set Updates are also fully compatible and supported for use with the E-Business Suite.

Will EBS Ever Formally Certify PSU Content?

Yes, but only indirectly.  Future major database releases are expected to include all released PSU patches.  For example, if the Server Technologies division ever releases a 10.2.0.5 update, then I would expect it to include PSU 10.2.0.4.1, 10.2.0.4.2, and so on.  If 10.2.0.5 is ever released, it would be certified with the E-Business Suite, thus certifying all of the previously-released PSU patches in the process.

Note that I am speaking strictly hypothetically and illustratively about 10.2.0.5 -- I haven't heard any confirmed plans around any future major releases on the 10gR2 database codeline.

What's the Support Process for Patch Set Updates?

The support process is the same for PSUs as it is for other emergency or "one-off" database patches: formal Service Requests logged using My Oracle Support (formerly Metalink).  If the Server Technologies team finds that there's a problem with a particular PSU, they will issue a fix for it.  If the Server Technologies team finds that the underlying problem is with the E-Business Suite, they will transfer the issue to the E-Business Suite division for us to investigate in an Apps environment. 

Your feedback is welcome

Just like all of the other topics we cover on this blog, your feedback about the usefulness of Patch Set Updates in your E-Business Suite environments is welcome.  Please feel free to drop me a line or post your comments here about your experiences with these PSUs.

Related
Comments:

Hi Steven,
Thanks for all these useful/techie posts in past few months.

I think Note number is 854428.1 instead of 584428.1
Introduction to Database Patch Set Updates (Note 584428.1)

Regards
Atul Kumar
http://onlineAppsDBA.com

Posted by Atul Kuma on August 10, 2009 at 08:11 PM PDT #

the two patches in conflict are required for 10.2.0.4 -

Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
7014646, 8576156, 6600051

Following patches are not required, as they are subset of the patches in Oracle Home or subset of the patches in the given list :
6870937

Following patches will be rolled back from Oracle Home on application of the patches in the given list :
7014646, 6870937, 6600051

Conflicts/Supersets for each patch are:

Patch : 8576156

Conflict with 7014646
Conflict details:
/u612/bmree/tech_st/10.2.0/lib/libserver10.a:/vop.o

Bug Superset of 6870937
Super set bugs are:
6870937

Conflict with 6600051
Conflict details:
/u612/bmree/tech_st/10.2.0/rdbms/admin/prvtaqds.plb
/u612/bmree/tech_st/10.2.0/lib/libserver10.a:/kwqmn.o

OPatch succeeded

Posted by tflatley on August 11, 2009 at 01:42 AM PDT #

Hi, Atul,

Quite right -- that was a typo. Thanks for catching that error so quickly! Article corrected.

Regards,
Steven

Posted by Steven Chan on August 11, 2009 at 03:18 AM PDT #

Hi, Tflatley,

I'm afraid that this blog isn't well-equipped to provide support for issues like this. Your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our specialists engaged.

Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.

Regards,
Steven

Posted by Steven Chan on August 11, 2009 at 03:21 AM PDT #

Steven,

I think these database patch set updates are a great idea. I don't see any information in the note on Metalink regarding what DST update is bundled in the patch (if any). Don't know if I'm the only one who does these updates, but not knowing what comes with this patch reduces its value significantly... I'd hate to revert to an older version on accident-

Posted by Kevin Kempf on August 11, 2009 at 04:25 AM PDT #

Hi, Kevin,

Thanks for your comment. I just looked over the README (for the Linux port) of patch 8576156. Section 5 contains a comprehensive listing of all fixes included in the PSU. I don't see any references to timezones, so I would conclude that this PSU doesn't have any impact on DST at all.

Regards,
Steven

Posted by Steven Chan on August 11, 2009 at 04:51 AM PDT #

Windows users have had this for ages, good to see Unix now has it as well.

Posted by Cameron Hodge on August 11, 2009 at 10:36 AM PDT #

thanks for the response Steven - i had a tar on this already and noticed your post - the analyst notes the following bug

There is Bug 8781458
10.2.0.4.1 - MISSING PSE 7014646 FOR LINUX PLATFORM

thanks again

Posted by tflatley on August 12, 2009 at 01:20 AM PDT #

Hello,

I manage the process of database upgrades and migrations for a hosting company. Currently, I have a list of important bug fixes for 10.2.0.4 and 11.1.0.7 that I use for most of our customers. Moreover, I constantly add new bugs (patches) as our customers hit them.
After reading the notes on patch 8576156, I ran opatch in 'report' mode and It came back with fourteen conclicting patches. It is rather difficult for me create create merged-patches request on already merged patches as development will ask for an actual customer justification and the process can drive on for days. So, is there a way to have these patches merged by your team?

--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OUI-67012:Interim Patch 8576156 has Conflict with patch(es) [ 8478284 7563669 7505440 7476591 7149863 6809093 6512622 6324944 6024730 5890312 5251842 4726401 4486516 ] in OH /tabl3i/oracle/product/102
2) OUI-67078:Interim patch 8576156 is a superset of the patch(es) [ 7552082 7552067 7123643 6327692 7196894 7039896 7033630 7008262 6994160 6972843 6954829 6926448 6870937 6679303 6645719 6455659 6392076 6374297 6145177 6084232 6051177 5895190 5879114 5868257 5756769 5747462 5348308 4695511 ] in OH /tabl3i/oracle/product/102
--------------------------------------------------------------------------------
OPatch Session completed with warnings.

OPatch completed with warnings.
$

Posted by Carlo Ciuffoli on August 12, 2009 at 02:19 AM PDT #

Hello, Carlo,

Unfortunately, I'm part of the E-Business Suite division and do not have the ability to merge ST patches. Your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our database specialists engaged. They should be able to assist with this.

Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.

Regards,
Steven

Posted by Steven Chan on August 12, 2009 at 04:02 AM PDT #

Hi Steven,

When I first heard of PSUs, I thought they were a good candidate for quarterly release patching recommended by us for every ERP in our environment. However, when I read about them in Metalink note 854428.1 section 6:

Patch Set Updates and Critical Patch Updates (CPUs)

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.

This means once a PSU is applied, you have to keep applying PSUs instead of CPUs. Every time we apply a CPU, a row is inserted in registry$history table and we are able to check what is the current CPU of an instance. If we apply a PSU, we'll not be able to record whether a CPU is applied on an instance.

E-Business Suite doesn't record the details of CPU patches applied to other technology components like Forms, Reports, IAS_HOME, Developer patchsets etc. As a practice, we apply all CPU patches or none of them. Because of this, when we check registry$history we know that all technology component CPU patches are applied.

This won't be possible if we start applying PSUs.

Your comments.

- Vikram

Posted by Vikram Das on August 14, 2009 at 03:54 AM PDT #

Hi, Vikram,

This is correct. Note 854428.1 is very clear about the implications of applying PSUs instead of CPUs. You need to determine which release vehicle meets your requirements better. Different customers will choose different release vehicles, depending upon their needs for tracking granular patches, downtime windows, and other customer-specific factors.

Regards,
Steven

Posted by Steven Chan on August 14, 2009 at 04:31 AM PDT #

Kevin Kempf wrote: "I don't see any information in the note on Metalink regarding what DST update is bundled in the patch (if any). "

At this time, PSUs will not contain any DST updates for two reasons:

1. DST updates are not RAC-rolling-installable, so do not meet a very important requirement to be included in a PSU.

2. Customers should ensure that all Database DST data files in their interoperating systems (ie servers and clients) are the same version. In other words if you are running with timezone file V10, it needs to be the same on ALL systems that exchange data. We would not want a customer to get a different version without knowing it, so will not include DST updates in any patch set or bundle if we can help it. For this reason we issue DST updates for the Oracle Database as standalone patches every June and December (in time to install with the next PSU if you like).

Posted by Roger Knopf on August 26, 2009 at 08:37 AM PDT #

We are currently upgrading our 10203 system to 10204 and require some clarrification on what we need to apply. As the PSU is recommended by the DB team we think this may be the best way to go.

I have a SR, 21718950.6, asking for clarification on patches that need to be applied, those referenced in the metalink note are 10204 specific and I want to know what if any are needed for the PSU.
The response said applying the PSU was recommended but when I asked for details of which patches still need to be applied I was told to not follow the PSU route!

There needs to be a definitive statement of support for the PSU and e-business suite identifying which patches are required as well as these are likely to be different to those required for 10204.

Posted by Jim Allman on September 10, 2009 at 08:16 PM PDT #

Hello, Jim,

I can appreciate your frustration with what might seem to be mixed messages here.

Unfortunately, every customer's patching baseline is unique, since everyone has applied a different set of database patches on top of the ones we minimally require for the E-Business Suite. This complicates the process of making generic recommendations that apply to everyone's environments.

The best team suited for resolving conflicts between your current set of database patches, your upgrade requirements, and PSU 10.2.0.4.1 is Oracle Database Support. They should be able to do an analysis of the different patches needed and come up with recommendations. This analysis is likely to be complex and time-consuming, though, given that you're coming from 10.2.0.3 (I'm inferring that your environment is currently in some transitionary state).

If I were in your shoes, I would attempt to simplify the analysis by completing the upgrade of your EBS environment from 10.2.0.3 to 10.2.0.4 following our certified upgrade path (Note 362203.1). Once that upgrade is done, then the task of assessing the differences between 10.2.0.4 and 10.2.0.4.1 will be much easier. I know that 10.2.0.4.1 does not include specific interop patches required for EBS compatibility. The Database Support team can provide a patchset rollup that includes those patches along with the 10.2.0.4.1 fixes, too.

Please let me know if your Database Support SR gets stuck in the support process for some reason.

Regards,
Steven

Posted by Steven Chan on September 11, 2009 at 06:14 AM PDT #

Hi Steve
Can I have a 11.1.0.7 clusterware install but an RDBMS and ASM instance that is running on 11.1.0.7 PSU1.
We are having issues bringing up ASM in such a configuration. While we are working on the issue, I want to understand if the above combination will be an issue in itself.

Thank you
Kumar

Posted by Kumar Madduri on November 16, 2009 at 10:09 PM PST #

Hi, Kumar,

I'm not a Clusterware specialist, but my impression is that it's best to keep the Clusterware, ASM, and RDBMS versions at the same level. That's just my impression though, and not an authoritative recommendation.

Your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our Clusterware specialists engaged. They should be able to give you the final word on this.

Regards,
Steven

Posted by Steven Chan on November 17, 2009 at 04:07 AM PST #

The official answer is as long as the first 4 number match you should be ok.
plus rereading the blog one of the key points in psu is that it does not require recertification. So yes this combination should work.

Thank you Steven for your prompt response

Kumar

Posted by Kumar Madduri on November 20, 2009 at 01:10 AM PST #

If my understanding is correct (more than likely not the case), one of the main benefits for 11i (PSU wise) is PSUs are cumulative and CPUs aren't.? Meaning I wouldn't have to apply previous PSUs before applying the current PSU. Am I totally confused?

Posted by Michael Mathes on December 02, 2009 at 02:59 AM PST #

Hi, Michael,

I can sympathize -- this is a confusing area (even for me). Database CPUs and PSUs are both cumulative.

The difference is that Critical Patchset Updates (CPU) contain only security-related fixes, and of those, only the most important ("critical") security fixes.

Patch Set Updates (PSU) contain those security fixes, as well as other fixes for stability and performance that the database division considers important enough to release before the next major database release.

The CPUs and PSUs are both released quarterly, and at the same time. If you apply a given quarterly PSU, you don't need to apply the CPU (since its security fixes are already included in the PSU).

Does that help?

Regards,
Steven

Posted by Steven Chan on December 02, 2009 at 06:12 AM PST #

Hello Steven. Thanks for the quick response!

Let say I have an 10.2.0.4.0 DB backending 11.5.10.2 (RUP7). Instead of me having to figure out which CPU (DB Tier Only) I'm on, then apply all the CPUs up to the current CPU. I could just apply the Database PSU 10.2.0.4.2 and it should contain the CPUs content that I'm missing from 10.2.0.4.0, right?

I thought CPUs weren't cumulative for 11.5.10.2 environments. Am I mistaken?

Thanks Steven for helping me get this clear!

Regards
Michael

Posted by Michael Mathes on December 02, 2009 at 06:42 AM PST #

Hi Steven,

We apply CPU quarterly for AS10g infrastructure, EM, EBS databases. We use a different note for EBS CPU, which sometimes contains additional database patches for EBS only. If PSU also includes the EBS specific database patches, we may consider applying PSU instead of CPU quarterly against all our databases.

Thanks in advance for your confirmation.
Jennifer.

Posted by Jennifer Chen on December 02, 2009 at 07:05 AM PST #

Jennifer, Michael,

I'm checking with our Patch Set Update owners on your questions. I'll post their replies here as soon as I get them.

Regards,
Steven

Posted by Steven Chan on December 03, 2009 at 07:10 AM PST #

Steven,

Thanks for taking the time to help me clarify. I think that 10.2.0.4.0 has the CPU starting point of CPUApr2008. So, I would first have to apply the CPUs up to CPUApr2009 before I could apply PSU2. I think I'm just confused at to what the cumulative vs non-cumulative is referring. If I'm running E-Business Suite 11.5.10.2 (ATG RUP7) is non-cumulative just the middle tier (Application Server, Developer 6i Suite) not the DB tier (10.2.0.4.0)? Or is it all non-cumulative...Thanks again Steven.

Regards,
Michael

Posted by Michael Mathes on December 04, 2009 at 03:50 AM PST #

Michael,

Like you, I'm trying to interpret the Database division's policies around their PSU content. This is my interpretation only; the Database division really is the only group that can authoritatively answer your questions.

So, with that disclaimer, here's my interpretation:

The 10.2.0.4.1 PSU includes whatever interim database patches that the Database team considers important for security, stability, and performance. This includes the database content included in a specific CPU.

Database CPUs are also cumulative, so my interpretation is that you wouldn't need need to apply any prior database CPUs. However, there is one big catch: there may be EBS-specific database patches in the CPU that are *not* included in the Database PSU. I'll leave it to the Database team to justify that, but suffice to say that there may be some EBS-specific database patches in the CPU that do not meet the criteria for inclusion in the Database PSU.

The 10.2.0.4.2 PSU includes everything released in 10.2.0.4.1 PSU, and new database patches -- including the new CPU security patches for the database released since 10.2.0.4.2 that the Database team opts to include in that PSU.

The Database PSU doesn't contain any application tier code -- not surprising, since it's a Database PSU, issued by the Database division rather than the Fusion Middleware division. In other words, the Database PSU doesn't include any E-Business Suite application tier code or Oracle Application Server 10g fixes. The Database PSU contains only database fixes.

I am not optimistic that I've cleared this up. My challenge is that the criteria for including a given patch in the Database PSUs is a bit opaque to me, compounded by the fact that I'm not really permitted to talk about certain internal policies on this blog.

As a customer, you actually have more options than I do for getting these types of packaging/policy questions answered. If you really need a definitive and authoritative answer to what's included (or excluded) in a given PSU, rather than my speculations, I think that your best bet would be to log a formal Service Request with the Database Support team to get one of them engaged.

Regards,
Steven

Posted by Steven Chan on December 04, 2009 at 06:56 AM PST #

Hi, Jennifer,

As you may have seen in my reply to Michael's latest question, there may be EBS-specific database patches in the CPU that are *not* included in the Database PSU. I'll leave it to the Database team to justify that, but suffice to say that there may be some EBS-specific database patches in the CPU that do not meet the criteria for inclusion in the Database PSU.

Regards,
Steven

Posted by Steven Chan on December 04, 2009 at 07:00 AM PST #

Hi Steven,

Thanks so much for the clarification. I was just thinking about how to streamline our maintenance processes further.

Appreciate your time and help.
Jennifer.

Posted by Jennifer Chen on December 06, 2009 at 09:25 AM PST #

Steven,

Thank you very much for taking the time to check into that for me. I 'll get in touch with support and post my findings.

Regards
Michael

Posted by Michael Mathes on December 07, 2009 at 12:03 AM PST #

Steven,

Sorry for jumping in on this late, but I would like to clarify an earlier comment you made in response to Michael and Jennifer. There may have been an exception but in general PSUs have 100% of the content of the CPU from the same quarter (ie January 2009 PSU has all of the fixes from the January 2009 CPU).

Both CPUs and PSUs are fully cumulative. For example if you are running 10.2.0.4 then the latest 10.2.0.4 PSU or CPU will have all fixes from all 10.2.0.4 PSU or CPU to date and you can skip the earlier ones.

Hope this helps,
Roger

Posted by Roger Knopf on April 02, 2010 at 07:33 AM PDT #

Roger,

Thank you very much for jumping in and clarifying that. This is very helpful.

[Readers: Roger is a key member of our Server Technologies team].

Regards,
Steven

Posted by Steven Chan on April 02, 2010 at 07:48 AM PDT #

Thank you Steven for the introduction! When 11i EBS CPU became cumulative for the first time back in January, I was helping a project catching up on CPUs due to a key DBA’s unexpected departure. The cumulative feature on both EBS and RDBMS saved me countless hours…

Hello Roger, Thank you for the follow-up and clarification. It has helped us a great deal in planning and performing maintenance when the Server Technologies team sets the release dates. We would like to go down the PSU path because of its efficiency and well-integrated and well-tested nature. But we have this dilemma: the requirement for us is to deploy the CPU in production three weeks after it is released. By applying PSU, it increases the scope of work. In the event that a conflict resolution patch is required, we are afraid there will not be enough turnaround time from Oracle. However, if we stick with the CPU path, we can never apply PSU according to the note 854428.1 (regarding PSU and CPU employ different patching mechanisms): “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.”

Do you have any comments or suggestions for our scenario?

Thank you both for keeping the channels of communication open and being connected to the issues at the ground level.

Best Regards,
Jennifer

Posted by Jennifer Chen on April 05, 2010 at 12:54 AM PDT #

Jennifer,

With only three weeks to apply the PSU, anyone would worry about getting a PSU overlay patch in time! The good news is that our patching organization understands this as well and has really shortened the time to get overlay patches to customers - I am told by one of my trusted field contacts that it is about a week now. In addition, use of the Patch Advisor on My Oracle Support can further reduce the lag time by automating the discovery of conflicts and requesting of the PSU overlay patches. If you do not use the Patch Advisor then my best recommendation is to IMMEDIATELY download the new PSU, check for conflicts, and get your request in right away.

Regarding the statement "However, if we stick with the CPU path, we can never apply PSU according to the note 854428.1" you have it backwards. It is very easy for customers who have been applying CPUs to go to PSUs - it is reverting from PSUs to CPUs that is difficult.

My suggestion (not one I would normally suggest but in your case seems quite justified) is to download the next PSU, check for conflicts, and see how long it takes to get the patches. You can find out how many conflicts you have to deal with and how long it takes you to get the overlay patches.

Best regards,
Roger Knopf
Customer Support Director, Product Release Readiness - Database

Posted by Roger Knopf on April 05, 2010 at 02:21 PM PDT #

Following up on Michael Mathes' post of December 3, I'd like to clear up a couple things:

First, when we say fully cumulative, we mean that any CPU (or PSU) built on top of a particular patch set (10.2.0.4 for example) will always have ALL of the content of earlier CPUs (or PSUs) built on the same patch set. The Jan 2010 CPU for 10.2.0.4 had all of the fixes in all earlier 10.2.0.4 CPUs plus the new fixes for Jan 2010.

Second, 100% of the content of CPUs are included in the PSU of the same date. So, the Jan 2010 PSU has all of the fixes included in the Jan 2010 CPU plus other non-security fixes. This means that if you wish to install a PSU you do not need to install ANY CPUs as a prerequisite - you will get all the fixes in the PSU.

Hope this helps!

Best regards,
Roger Knopf
Customer Support Director, Product Release Readiness - Database

Posted by Roger Knopf on April 05, 2010 at 02:31 PM PDT #

Hi Roger,

Thank you so much for your prompt response and correction. I meant to say if we stick with the CPU path, we will likely not be able to apply big bundled patchset but one-offs for non-security related bugs. That would be a significant disadvantage…

We’ll test out what you have suggested and let you know how it goes. It’s very encouraging to learn that turnaround time for overlay patches has been shortened.

Thanks again and really appreciate your time and help!

Best regards,
Jennifer

Posted by Jennifer Chen on April 06, 2010 at 02:34 AM PDT #

Jennifer,

The Patch Set Update is a lot smaller than a patch set - far closer in size to the CPU than to patch sets. A Database CPU has from 10 to 50 new fixes. PSU adds up to 50 in most cases. A patch set can include 3000+ fixes. We have also implemented controls on what is included in the PSU to limit risk. For example, we will never include anything that changes the optimizer, anything that changes architecture or key algorithms, and anything that changes API or user interface. Its designed to be safe.

Probably the one critical factor in deciding is if you have been installing other Database-related bundles such as RAC or the DB Generic bundle. The key benefit to the PSU is that it replaces up to 4 or 5 different download/test/integrate/maintenance outages with one. The secondary benefit is that we deal with all the integration issues by testing them all together before releasing to you.

I do understand you have a short window to install and so do not want to add any risk that you might not be able to get the security fixes installed. I do hope over time that the things we have done to make PSUs safe to install prove in your mind to be reliable.

Best,
Roger

Posted by Roger Knopf on April 06, 2010 at 04:29 AM PDT #

Hi Roger,

Thank you for your explanations on the "Patch Set" vs. "PSU", "CPU", and "one-offs".

At this point, we're comfortable with the quality and contents of the PSU, it's more about the process and the timeline. As a result, this will simply have to be something that we evaluate over the next couple of cycles in our development environment until the process matures.

Again, thanks very much for taking the time to thoroughly clarify the issues here.

Best regards,
Jennifer

Posted by Jennifer Chen on April 06, 2010 at 09:14 AM PDT #

Do we need to apply July 2010 CPU patch for E-Business suite 12.1.2 and Database 11.1.0.7.0? Or only for E-Business suite 12.1.2 is enough? Pls clarify. Regards, M. Mydeen

Posted by Mydeen on July 13, 2010 at 08:44 PM PDT #

Mydeen,

I'd recommend that you review the July 2010 CPU documentation carefully to determine which patches need to be applied to your environment. See this article for pointers to the latest CPU's documentation:

Critical Patch Update for July 2010 Now Available
http://blogs.oracle.com/stevenChan/2010/07/cpu_july_2010.html

Regards,
Steven

Posted by Steven Chan on July 14, 2010 at 03:53 AM PDT #

Hi Steven,

This is Arun. I need your help. We have upgraded our database to 11.2.0.2 and EBS to Release 12.1.3 and application server to 10.1.3.5. I wanted to know at present my instance has got which CPU/EBS/Application server patches already installed ?

I wanted to apply latest jan 2012 security patches and before that i wanted to know at which CPU patchset level that my instance got now after upgrading ? So that i can plan accordingly and apply security patches.

Thanks in advance

Regards
Arun

Posted by guest on February 08, 2012 at 09:20 PM PST #

Hi, Arun,

See this document:

Oracle E-Business Suite Release 12.1.3 Readme (Note 1080973.1)

It states that EBS 12.1.3 includes the July 2010 Critical Patch Update (CPU).

All CPUs are cumulative. If you apply the Jan 2012 CPU, you'll get all of the updates between the July 2010 CPU and the Jan 2012 CPU.

Regards,
Steven

Posted by Steven Chan on February 09, 2012 at 10:01 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today