Oracle E-Business Suite Technology

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

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

Hi, Atul,

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

Regards,
Steven

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

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-

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

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

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

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.
$

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

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

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

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).

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.

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

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

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

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

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?

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

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

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.

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

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

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

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

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.

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