Home › Discussions › Questions & Answers › Oracle E-Business Suite 12.2.9 upgrade to version 12.2.10
Oracle E-Business Suite 12.2.9 upgrade to version 12.2.10
Customer · · Questions & Answers · 11 replies
When upgrading EBS (e.g., to 12.2.10), is it feasible to combine all critical patching components—Maintenance Tool Kit (MTT), AD/TXK deltas, and the 12.2.10 RUP—into a single ADOP cycle? We are concerned that running everything together might introduce excessive complexity and make troubleshooting difficult.
11 replies
That is a valid concern regarding combining the MTT + AD TXK patches + RUP (like 12.2.10 patchset) in one ADOP cycle, as it can make troubleshooting complex if something goes wrong. A more conservative approach, and often recommended in Oracle Notes, is dividing the patching: running MTT + AD TXK deltas in one cycle, and then the RUP (e.g., 12.2.10 cycle) separately.
If we proceed with separate ADOP cycles, how can we efficiently verify the status of the AD/TXK delta patches before starting the final RUP application?
You should use a Blitz Report that leverages the AD_PATCH.IS_PATCH_APPLIED database function. This allows you to quickly query specific patch numbers (like 28840822, 29965377, or 29781255 for critical TXK patches) to ensure they are explicitly marked as ‘APPLIED’ before moving to the next cycle.
If an ADOP application phase hangs or fails silently, what is the initial diagnostic focus for the DBA team?
If an ADOP phase (like `fs_clone`) is stuck , the DBA should immediately run diagnostics on the configuration of the Application Tier nodes. Specifically, query `apps.fnd_nodes` to check for correct service names, webhost, and domain configurations, as misalignments can cause silent failures.
We need to ensure all custom reports remain fully functional after the upgrade, especially high-volume financial extracts. How can we quickly identify potential issues with data access or performance post-upgrade?
Include running your critical, saved Blitz Reports in your smoke test plan. Blitz Report provides speed and reduced processing overhead for financial reports , allowing quick validation of data integrity, especially for complex structures like GL Account Analysis and YTD calculations.
Our security team requires confirmation that all EBS Java Archives (Jar Files) are properly signed after the patching to maintain code integrity.
The patching process often modifies JAR files, necessitating re-signing. You can locate the list of files modified after patching within the ADOP log subdirectories. Ensure the process adheres to your policies, especially if using a Hardware Security Module (HSM) for Signing EBS Jar Files.
If we were migrating from 12.2.8 to 12.2.9, would similar steps apply?
Yes, major EBS version upgrades (like 12.2.7 to 12.2.8 or 12.2.8 to 12.2.9 ) follow similar technical protocols, requiring careful RUP application, AD/TXK patching, and environmental verification using tools like SQL diagnostic reports.
- You must be logged in to reply to this post.
Sign in with LinkedIn or Google to take part.