E-business Suite R12.2 – No More Downtime
Posted by Kashif Manzoor on June 18th, 2012
The takeout from last ATG Live Webcast June 14 was ‘no more downtime’ in Oracle EBS R12.2 for patching and transformation of term ‘Downtime’ to ‘Cut Over’. In R12.2 downtime will be measured in minutes not hours or days. It is a customary thought process to wait for suitable time when to apply new patch, how to get approval for business applications downtime and usually you will get a slot on weekend nights.
Let’s review how we will be going to get possibility of ‘no more downtime’ in R12.2. we all know EBS downtime is a major concern and this outages interfere with core business activity:
– Reluctance to upgrade to take advantage of new feature
– Barrier to staying current with recommended patches
Now let’s understand commonly what force us to go for production down time; 1-Major Release upgrades, 2-Maintenance Rollups (RUPs), 3-Critical Patch Updates (CPUs). 4-Legislative and Regulatory updates
EBS will remain online during patching through Online Patching; refer earlier post to get basic idea. In 12.2 all patching operations are online so its mean – EBS will remain available to users during patching operations, – HR Legislative updates can be applied during a payroll run & Users can enter expense reports while Payables is being patched
Online patching will use the latest features of Oracle’s Integrated Stack like – Edition Based Redefinition (EBR) & – Web Logic Server
Patches will be applied to a Copy of Production
EBS will use both the file system and the database to store the code and data that make up the application – Copy the Code, NOT the Data
– Where is Code
- Stored both on the File system & In the Database
- Any code object changed in a patch is copied
– Where is Data
- Stored both on the File system & In the Database
- Application data is NOT copied by a patch
“Downtime” will be redefined as “Cutover”. Cutover is the time taken to switch users from the production system to the newly patched copy.
-Cutover changes the unit of measure for downtime & will be measured in minutes NOT hours or days.
-Cutover time is very predictable & the time taken to bounce the Middle Tiers
Downtime Limited to Short Cutover
Patching Occurs on a Copy of following:
File system: a-All patches are applied to the secondary file system b-Synchronization of the file systems is managed by the patching tools
Database: A separate copy is maintained of all database code objects that are changed by a patch
Downtime Patches
– No online Users
– Wall clock time very important
– Consumes all resources
– Upgrade designed to run as fast as possible
Online Patches
– Users remain online
– Wall clock time is no longer an overriding concern
– Online Users share resources
– Data upgrades designed to not affect the running application
In 12.1.3 Single File System – Patches applied while system is down & another method is Optional staged APPL_TOP
– Patches applied to staged file system while the system is online
– System is off line to apply database updates
– Staged APPL_TOP provided the basis for the 12.2 design
You can refer My Oracle Support note for further details (Using a Staged Applications System (APPL_TOP) to Reduce Patching Downtime in Oracle E-Business Suite Release 12 [ID 734025.1])
EBS 12.2 will be installed with 3 file systems
– FS-1 (Production file system) – Used by the current users of the system
– FS-2 (Copy of Production file system) – Used by the patching tools
– FS-NE (Non Editioned file system) – Stores data that is stored on the file system (Data import and export files, Report output & Log files)
All three file systems serve a single database. The file system in use by the running application is never patched. All patches are applied to secondary file system
Edition-Based Redefinition (EBR) 11g R2
What it will do?
Enables the online upgrade of the database tier and allows an application to efficiently store multiple copies of its application definition in the same database. It will also provide an isolation mechanism that allows pre-upgrade and post-upgrade schemas to co-exist.
– Changes to database objects are made in the isolation of an “Edition”
– Changes to database objects do not effect the running Application
You can also refer earlier post to get more info about Edition Based Redefinition.
What is Database Editions?
Our code chooses The Edition that it connects to, if it will connect to Run Edition (1-Used by Online Users, 2-Never changed by a Patch). Patch Edition (1-Used by the Patching Tools 2-Changes do no affect the running Application)
Online Patching will Interacts with 3 different Edition Types
Run Edition
– The edition currently in use by the running application
– This is always the default database edition
Patch Edition
– The edition currently in use by the patching tools
– This edition is only present when patching is in progress
– Always the direct child of the Run Edition.
Old Edition(s)
– There maybe zero or more Old Editions
– When the Patch Edition is promoted to production the previous Run Edition is now regarded as an Old Edition
– Only retained until a full cleanup operation is run
Other posts on Oracle E-business suite R12.2:
A Journey from Oracle E-Business Suite R12.1 to R12.2
