Revisiting Magic ingredient EBR in E-Business Suite R12.2’s ADOP
September 17, 2012 Leave a comment
As Oracle EBS R12.2 just become a GA, an interesting metaphor is reducing downtime for planned software maintenance. As enough said on ADOP here http://oracletechnologistblog.wordpress.com/2012/06/20/oracle-ebs-r12-2-online-patching-via-adop/
http://oracletechnologistblog.wordpress.com/2012/01/17/r12-2-key-features/ and elsewhere, there is less information on the revolutionary 11gR2 database feature Edition-Based Redefinition, which is essential to ADOP.
If you are an Oracle E-Business Suite customer, multi-tier patching is inevitable. EBS R12.2’s ADOP is certainly a revolutionary feature that comprehensively provides minimal definable downtime. Complexity in R12.2’s ADOP feature resides in the database. Magical ingredient here is Edition-Based Redefinition (EBR) feature within the database.
Lets briefly dig into the recent evolution of minimizing downtime features in Oracle database and more. Over the years, Oracle database team has developed several key capabilities such as online index rebuild, non-blocking nature of ALTER TABLE DDLs, eliminating object invalidations due to logical changes, that continue to reduce downtime along with costly endeavors such as schema clones and log-based replication, still you are left with noticeable downtimes. That changes with EBR, which provides three features such as edition, edition view and crossedition trigger that helps online application patching and upgrades. Lets take a look at these three features in detail.
Edition: Edition’s principal objective is to provide isolation mechanism and is considered as a non-schema object type. It permits same object to occur multiple times in same database yet maintain unalike or different editions. Furthermore, all the database objects fall under two types of editions such as editionable and non-editionable types.
whats editionable object type: Code type objects such as PL/SQL, views, types, synonyms, triggers and editioning views supports edition. Nonetheless, it prevents changes in one edition of the object to impact other editions of same object. Especially in ADOP where the instance has to maintain multiple copies of the code objects, edition feature come in handy to accomplish the online patching capability.
Whats non-editionable object type: So what about storage objects? Will that provide any editioning? Short answer is no. Here are the details. Storage objects such as tables, indexes, materialized views and also sequences do not support editioning and are categorized as non-editionable types.
In edition world, there is a potential to have multiple editioned table data. With editioning view capabilities, it’s truly possible. Editioning view allows several versions of table’s data by logical representations, where a physical table cannot be editioned. In other words, a table can store data related to multiple editions but its the editioning view that provides the accurate subsection of data from underlying table.
On a side note, Oracle highly recommends that in preparation for R12.2, its vital to not to have any of your customizations refer to base tables directly as EBS data model now provides a cover layer via editioning views. It is extremely important that you refer the cover layer to access EBS data model instead of physical layer to prevent any integrity issues. The reason behind this requirement is to prevent any code accessing outdated columns in physical layer. In R12.2 world, Oracle strongly recommends that all code should access the data model only via apps synonym as it internally points to editioning view. Nonetheless, editioning views allow triggers to be defined on them along with hint reference.
Oracle 11.2 introduced a special kind of editionable object type trigger called crossedition trigger. Lets assume the patch process need to change the structure of an OLTP table. ADOP to work properly a mechanism that can keep up the pace with changes that user makes to the pre-patch state of the data yet transform the data into postpatch state. Pre-patch will continue to see the running edition of the table while the post-patch would see the new structure. This is possible due to crossedition trigger that uses advanced synchronization mechanism to ensure the values of the pre-patch transactional data is in sync with what could be post-patch transactional data inspite of structural changes to the table.
Within crossedition trigger, Oracle introduced two types of triggers that are forward corssedition trigger and reverse crossedition trigger.
Simply put, forward Crossedition trigger is instrumental for bringing the pre-patch column values to the post-patch values and reverse Crossedition trigger exactly does the contrary.
EBR re-definition lifecycle in ADOP process would have similar pattern
- Virgin state of the database will have only one edition, prepatch
- During the patching process, the database will have two editions called prepatch and its child edition called postpatch.
- When you have successfully executed the ‘cutover’ stage of the ADOP cycle which is at the stage where you no longer need prepatch edition, it will be retired and postpatch will now become parent edition and thus will have one edition.
MOS: Example of Edition-Based Redefinition using Cross-Edition Triggers [ID 845667.1]