Understanding Editioning in Oracle EBS R12.2


The database utilizes the Edition-Based Redefinition (EBR) feature of the Oracle 11gR2 Database to support online patching.
Traditionally, applications such as Oracle E-Business Suite have had to be unavailable while their associated database objects are patched or upgraded. The EBR feature of the Oracle 11gR2 Database allows this downtime to be avoided. Every database has at least one edition, and can support multiple editions. A new edition is created as a child of an existing edition. The changes are made in the child edition, while the parent edition remains available for use. Changes to data (such as when a patch is applied) are made by writing only to new columns or new tables not seen by the old edition. This allows an application to efficiently store multiple copies of its application definition in the same database, and thereby enables online upgrade of the database tier. EBR allows an application's database objects to be changed without interrupting the application's availability.
For example, an Oracle E-Business Suite patch can be applied while users are logged in and active. This is accomplished by making the changes in the privacy of a new edition.

Check the available editions Please use below

select * from dba_editions;

Editioned objects


EBR automatically manages to version of objects that support editioning, such as code objects. Not all objects can be editioned.

Code objects support Editioning. The Database will automatically manage multiple copies of these types of objects.

• PLSQL objects
• Views
• Editioning views
• Triggers
• Types (used for user-defined types within PL/SQL packages)
• Synonyms

The non-editioned objects include:
Mostly the object that holds data cannot be editions. Then How they are managed. The advanced feature is used to manage these types of objects.

• Tables
• Indexes
• Materialized views
• Sequences


3 Types of Database Editions in EBS


In the database, the run and the patch editions do not swap roles back and forth as in the file system. The patch edition only comes into existence during a patching cycle, and becomes the new run edition at the end of the cycle. The former database run edition (the old edition) and the obsolete objects it contains are discarded at the end of an online patching cycle, and the space reclaimed during the cleanup phase.


1) Run
These are used by online users. The patch will not affect these.

2) Patch
This will get created when we run adop phase=prepare. Used by patching cycle. Changes will not be affecting the running EBS application.

3) Old
The obsolete ones are known as Old. We cannot connect to old editions. They would be cleaned up using a full cleanup.

The Edition Model


Editioning views can be thought of as providing a cover layer, or logical representation of the data, on top of the physical representation. Editioning views project different views of a table to the run and patch Editions if the data model of a table is patched.
All code (Oracle E-Business Suite, custom, or third-party) must access Oracle E-Business Suite data via the cover layer. Accessing the data model via the physical layer may result in obsolete data been returned.
Note: Editioning is explained in detail in the patching lessons. The implementation of EBR for Oracle E-Business Suite requires all code to access the data model via the APPS synonym (it acts as a gateway for the applications to access database objects residing under each of their module-specific schemas), which points to the editioning view (logical model).






Cross Edition Trigger

A new type of object, the cross edition trigger, is used to synchronize data as part of the online patching process. These triggers provide the logic to synchronize and transform data between the run edition and patch edition storage columns. The result is that new transactions entered into the system are patched in place.
More specifically, cross edition triggers allow the run edition to signal that a data update is required. They run in response to an insert into, delete from, or update of FND_TABLE. For example, suppose that a patch updates a column called DESCRIPTION from mixed case to upper case. Editioning views project different views of the table to the run and patch editions, so the running application still sees the column data as mixed case, while the patched application sees the column data as upper case. The updated column is maintained by a cross edition trigger. In summary, cross edition triggers are used to upgrade both existing data
and ongoing changes that occur while the run edition remains in use.



If you like please follow and comment