As Oracle EBS R12.2 gearing up to enhance HA capabilities, 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 emphasis 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.
Editioning View:
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.
Crossedition Trigger
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.
Reference:
http://www.oracle.com/technetwork/database/features/availability/edition-based-redefinition-1-133045.pdf
http://docs.oracle.com/cd/E11882_01/appdev.112/e10471/adfns_editions.htm
http://www.oracle.com/webfolder/technetwork/tutorials/obe/ebs/ebs121/atg/OnlinePatching.pdf
MOS: Example of Edition-Based Redefinition using Cross-Edition Triggers [ID 845667.1]
If you work directly with any of your Oracle accounts team members,
they will highly ‘recommend or encourage’ you to attend ES sessions.
