Introduction:
When it comes to managing Oracle E-Business Suite (EBS) R12.2, applying patches swiftly to tackle urgent issues is crucial. In the past, DBAs were used to the idea of “hot patching” in older EBS versions like 11i and 12.1.3.
But with R12.2, where the dual file system is crucial, we should not consider hot patching in R12.2 unless it is stated in patch readme or oracle support.
Challenges and Risks in Hot Patching R12.2
- Potential Runtime Failures: Hot patching can lead to runtime transaction failures due to various factors, including invalid objects and loss of PL/SQL package state.
- Inconsistencies in Application Code and Data: Temporary inconsistencies in application code and database objects are likely to arise, alongside potential discrepancies in patched tables and cached data within the application tier server memory.
- Execution Failures: Runtime processing may encounter long-term locks on code or data, causing execution failures and operational disruptions.
- Delayed Availability of Resources: Patches containing downloadable resources, such as Forms-related client JAR files, may necessitate Oracle WebLogic Server Managed Server restarts for resource activation.
Can hotpatch be aborted?
In the event of a hot patching failure, restoring and fixing is very limited. Unlike traditional patching cycles, hot patching cannot be aborted using the adop phase=abort command. Should a hot patch application failed, the only viable solution is to restore both the EBS database and middletiers from the backup.
An Alternative Approach: Mitigating Risks with Downtime Mode Patching
In light of these challenges, One such approach involves deploying patches directly to the run file system and run edition during emergencies, in downtime mode using ADOP special command (apply_mode=downtime). Key considerations for this approach include:
- Patching in Downtime Mode: The patch application process should be conducted using the adop downtime mode, ensuring a controlled environment for patch deployment.
- No Active Patching Cycle: No other patching cycles should be active during the application of patches in downtime mode to mitigate potential conflicts.
- Custom Synchronization: Directories housing code deployed to the application tier must be registered with a custom synchronization driver to facilitate seamless file system synchronization by the adop synchronization process.
Warning: Most Oracle E-Business suite patches are not tested in downtime or hotpatch mode. It is therefore important that this type of deployment is only used in an emergency, and not incorporated into standard maintenance practices.
