In May 2022, DSP, the UK's Leading Oracle Partner acquired Claremont to further expand their Oracle expertise. 
The NT uses Oracle E-Business Suite as its CRM System to manage member transactions. Our Managed Services team reduced the support backlog of incidents, problems, and changes in the NT’s CRM system.
Claremont has provided a solution capable of booking, managing, maintaining and analysing Unite Students’ complete property portfolio, allowing them to significantly differentiate themselves from their competitors.
Stonewater chose DSP to consolidate and migrate their assets to Oracle Cloud Infrastructure with an Oracle EBS Cloud Deployment, leading to a significantly reduced TCO.Contents
In September 2013, Oracle announced the general release of the latest version of Oracle E-Business Suite, 12.2. The previous 12.1 version was released May 2009 so it has been a long 4 and half year wait!
As with any major product version there are a very large number of technology and functional changes included in 12.2, but here we will focus on one of the more exciting and significant – online patching.
Applying E-Business Suite patches pre-12.2
For all previous versions of eBusiness Suite, applying a patch always meant downtime and the amount of downtime that would be required was directly related to the time it would take to apply the patch.
For small, one-off patches, downtime could be as little as 15 minutes, but for Family Pack upgrades or Maintenance Packs this could last for several hours or even days.
For true 24/7 businesses where little or no downtime can be tolerated this would either result in a loss of revenue for the time period in which the system was unavailable or a general reluctance to apply any patch or upgrade which would incur a significant amount of downtime.
During the testing phase, the prime focus of the Oracle DBA would be to tweak the running order of patches or adjusting various runtime options to make the patches go through as speedily as possible and to make the best use of hardware resources, and project time would have to be allowed for this activity.
Finally, downtime can only normally be arranged outside of normal working hours at evenings and weekends which can incur overtime costs.
Online Patching in 12.2 with (virtually!) no downtime
A paradigm shift occurs with E-Business Suite patching in 12.2. Patches can be applied with the system up and running and as such critical business operations are not interrupted. E-Business Suite will remain available during patching operations (for example: tax year end patches can be applied during a payroll run or expense reports can be entered while a Payables patch is applied).
The only downtime that is required is the time it takes to stop and restart the application tier to propagate the changes and perform cutover – thus whether you are applying an online patch or a major upgrade, the amount of downtime will always be the same. This makes downtime predictable and measureable in minutes rather than hours or days.
Previously where the prime concern when applying a patch was to maximise server resources to allow the patch to complete as quickly as possible, now the prime concern is that the patch does not consume too many resources to impact on the performance of the running application. The new 12.2 online patching tools automatically adjust the number of parallel workers and workload to ensure that this is the case. Patches can therefore be expected to take longer to complete, but this can now be done during the online day with the application up and running.
How does it work?
At Database Level
A new feature was introduced in Oracle Database 11gR2 called Edition-Based Redefinition. This feature is available to any business that has Oracle Database 11gR2 or later (whether they have E-Business Suite or not) but it was commissioned specifically by the Oracle Applications Division to support the online patching feature of 12.2.
In a nutshell, it provides a mechanism that allows for multiple versions (or ‘editions’) of schema objects to exist concurrently in the database, a ‘run’ edition and a ‘patch’ edition.
When an online patch is applied the running application is not affected because the changes are made to a separate ‘edition’ of the database objects and the application will always choose to connect to the ‘run’ edition. The database will automatically manage the copies of these objects during patching. At cutover, the ‘patch’ edition objects are propagated to the ‘run’ edition.
Edition-Based Redefinition is supported for all metadata objects (such as packages, procedures, views, triggers, synonyms and triggers) but not for data objects (such as tables and indexes).
To manage these objects, new “Editioning Views” have been implemented in 12.2 which isolates the running application from changes to the data model, while cross edition triggers ensure that new transactions entered into the system are upgraded in place
In this example, the APPS.WF_ITEMS synonym points to the new WF_ITEMS# Editioning view rather than to the APPLSYS.WF_ITEMS table as it would have done in previous versions.
At Application Level
When 12.2 is installed or an existing system upgraded to 12.2, a second copy of the application filesystem is created. All patches are automatically applied against the secondary copy of the filesystem while the running application continues to point to the non-patched, primary copy.
Two complete filesystems are always present:
- The Run copy, used by the current application.
- The Patch copy, which is either actively being patched or waiting for the next patching cycle.
Synchronisation between the two filesystem copies is automatically handled by the patching tools.
During cutover, the application is shutdown and pointed to the patched copy which them becomes the primary, so the two file systems are rotated during each patch cycle.