Edition Based Redefinition is a new feature introduced in 11gR2, to achieve zero downtime when you perform your Application upgrade. EBR is Oracle’s recommended solution for online application upgrades. Edition Based Redefinition plays an important role in R12.2 Online Patching that allows the E-Business Suite to be updated while the system is still running.
In this blog we will be covering:
- What is Edition Based Redefinition?
- Benefits of Edition Based Redefinition
- Components of EBR
- FAQs
- Conclusion
Let’s get into an in-depth explanation of EBR.
What is Edition Based Redefinition(EBR)? ^
High availability is one of the must-have features when you are planning for the Application upgrade. You can achieve high availability using RAC & Dataguard. So the organizations purchase RAC & Datagaurd even though it’s costly to protect systems from downtime as a result of some disaster but they cannot safeguard against an organization’s own change management or applications upgrade processes. So, there is a strong need for zero downtime and Edition Based Redefinition can be helpful to achieve this goal.
So, the main goal of releasing Edition Based Redefinition in the 11gR2 database was to make the application upgrades more streamlined, untroubled, and with almost zero downtime. Edition Based Redefinition came into more effect in Oracle E-Business Suite R12.2 as a new feature to support Online patching when Oracle released R12.2.
Benefits of Edition Based Redefinition ^
- Edition-based redefinition allows multiple versions of PL/SQL objects, views, and synonyms in a single schema, which makes it possible to perform upgrades of database applications with zero downtime.
- Edition-based redefinition is a single technology that provides high availability during upgrades.
- It is available from Oracle Database 11gR2
- It seamlessly rolls changes forward and backward
- It is safe, secure, free, and fully supported by Oracle
Components of EBR ^
Edition Based Redefinition has several components & using one or more of those components simply means you are using edition-based redefinition.
Edition feature of the EBR enables you to copy the database object and redefine the copied objects in private. this is why your online Application upgrade is known as Edition Based Redefinition.
Below are the main components of EBR.
- Editions
- Editioning Views
- Cross Edition Triggers
Editions
Editions are a built-in feature of the Oracle Database which are non-schema object types that do not have any owner. Any database must have at least one edition which is called the base edition (i.e. ora$base) and any new edition created is a child of an existing one, and each edition can only have one child edition. Every database session uses the base edition. You can change its edition using alter session command.
As part of EBR, Editions can be used to perform,
- In the privacy of a new edition, it installs code changes
- By writing to new columns/tables, it makes the data changes safely.
- It masks the changes that are not seen by another edition or old edition.
Read More: About Oracle EBS Vision Instance. Click here
Editioning Views
Let’s first understand what is editioned and non-editioned objects before knowing editioning views. The several objects supported in the Oracle Database can be classified in 2 ways.
- Editioned Objects
- Non Editioned Objects
Editioned objects
- These are attached to both a schema as well as an edition.
- Synonyms, views, and all the kinds of PL/SQL objects such as triggers, functions, libraries, packages and package bodies, procedures, types, and type bodies come under editioned object types.
- The remaining object types come under non-editioned.
Non-Editioned objects
- Tare visible to all editions and are not attached to a particular edition.
- Examples are tables and indexes.
An editioning view is an editioned object with a special kind of view.
It selects a subset of the columns from a single base table and, optionally, provides aliases for them. The editioning view maps physical column names (used by the base table) to logical column names (used by the application) in providing aliases. Think of the editioning view as an API for a table.
Since editioning views can be editioned, they let you treat their base tables as if the base tables were editioned themselves and allow different occurrences of its logical projection to be presented in different editions.
As part of EBR, Editioning views can be used to perform,
- Expose a different projection of a table into each edition
- Allow each user to see just its own columns
Also Read: Our blog post on Oracle EBS 12.2 Upgrade. Click here
Cross Edition Triggers
Basically, there are 2 types of triggers. cross edition & non-cross edition triggers. these 2 are differentiable in how they interact with editions.
A cross edition trigger is visible only in the edition in which it is actual, never in a descendent edition, and is temporary i.e., you drop them after you have made the restructured tables available to all users.
Two types of cross edition triggers are:
- Forward Cross Edition Triggers
- Reverse Cross Edition Triggers
Forward cross edition triggers move data from columns used by the old edition to columns used by the new edition; reverse cross edition triggers do the reverse.
Forward cross-edition triggers:
- Ensures data consistency by copying data changes made in any old edition into the new edition.
- It usually fires when DML statements are issued by sessions connecting to the pre-upgrade edition of the application.
Reverse cross-edition triggers:
- Ensures data consistency by copying data changes made in any new child edition into the old edition.
- It usually fires when DML statements are issued by sessions connecting to the post-upgrade edition of the application
As part of EBR, Cross Edition Triggers can be used to perform,
- Propagate data changes made by any old edition into the new edition’s columns by using forward cross-edition triggers. This is the most common use case.
- Propagate data changes made by any new child edition into old edition’s columns by using reverse cross-edition triggers.
Also Read: Our blog post on Oracle EBS Upgrade. Click here
FAQs
Q1: What is EBR in EBS?
Ans: We know EBS 12.2 uses EBR(Edition Based Redefinition) to support the online patching mechanism in the database tier. EBS 12.2 online patching uses Cross Edition Triggers, editioned objects, VPDs, and Editioned Views to supply the online patching in the DB Tier.
Q2. What are Oracle Database editions?
Ans: Oracle Database Enterprise Edition Oracle Database Enterprise Edition provides the performance, availability, scalability, and security required for mission-critical applications such as high-volume online transaction processing (OLTP) applications, query-intensive data warehouses, and demanding Internet applications.
Q3. What is enable editions in Oracle?
Ans: Edition Based Redefinition in Oracle Database 11g Release 2. Edition-based redefinition allows multiple versions of PL/SQL objects, views, and synonyms in a single schema, which makes it possible to perform upgrades of database applications with zero downtime.
Ans: Edition-based redefinition (EBR) enables online application upgrades with uninterrupted availability of the application. Therefore, an existing session can continue to use the pre-upgrade application until its user decides to end it, and all new sessions can use the post-upgrade application.
Read More: About Oracle Apps DBA R12. Click here
Conclusion ^
In this blog, we have covered in detail Edition Based Redefinition(EBR). EBR can greatly reduce application downtime if implemented properly. Oracle E-Business Suite 12.2 is a good example of an application that uses EBR to reduce patching and upgrade downtime.
Check the below articles to know more about EBR.
Related/Further Readings
- ADOP ( R12.2 Online Patching ) in Oracle EBS (R12)
- Edition-Based Redefinition – A solution for zero-downtime application upgrades
- Edition-Based Redefinition
- Oracle Database 19c: Everything You Must Know
- EBS R12.2 Upgrade High-Level Overview/Steps
- Oracle E-Business Suite (EBS) R12.2 Supported O.S. & Version
- File System in Oracle E-Business Suite R12.2
- Update on EBS Certifications
- Phases for ADOP in detail
- Oracle EBS R12.2 Upgrade Frequently Asked Questions Part – III
Next Task For You
We cover Oracle E-Business R12.2 Architecture & concepts in our Oracle Apps DBA For Beginners Training along with the Installation, Patching, Cloning, and Troubleshooting and also, Database upgrade to 19c and much more including the hands-on labs you must perform to upgrade your skills and get a good job with a high package.
Begin your journey towards becoming an Apps DBA by joining our FREE Masterclass on How To Learn Oracle Apps DBA (R12) & It’s New Features.
Pratyusa says
Could you please help me understand why cant we revert after cutover phase(switching from RUN Edition to PATCH Edition) ??
Surbhi Sharma says
Hi Pratyusa,
This is not EBR limitation but a limitation made by the EBS team as it will impact data integrity on account of how EBS applications are designed.
Regards,
Team K21
Pratyusa says
Thank you Surbhi for the update..!!
Could you please share some more technical insight about the limitation of EBS that restricts us from reverting from PATCH edition back to RUN Edition after cutover(or when cutover fails), as technically the changes introduced by the patch gets applied to PATCH Edition in isolation and when we cutover to PATCH edition, the older RUN edition remains untouched in the database.