What Is Edition-Based Redefinition and Why EBS R12.2 Online Patching Works
Every EBS R12.2 DBA uses ADOP. Very few can explain why it works. When someone asks you in an interview or a team meeting — how does EBS R12.2 allow patching while users are online? — the answer is Edition-Based Redefinition, also known as EBR.
EBR is the Oracle database feature introduced in Oracle Database 11gR2 that makes the entire online patching model possible. Without EBR, R12.2 online patching does not exist. Understanding it makes you a better EBS DBA — you will troubleshoot patching issues faster, understand error messages more clearly, and explain the architecture to your team with confidence.
This post explains EBR in plain language — no marketing language, no jargon without explanation. By the end you will understand what an edition is, what the three edition types in EBS mean, what editioned and non-editioned objects are, and exactly how all of this maps to the ADOP phases you run every quarter.
The Problem EBR Solves
Before R12.2, patching Oracle EBS required a complete application shutdown. The reason was simple: when you apply a patch, you are changing database objects — packages, procedures, views, triggers. If users are connected and actively calling those objects while you are redefining them, the results are unpredictable. Applications crash, data gets corrupted, sessions error out.
The traditional solution was to bring the system down, apply the patch, bring it back up. For large environments this meant 4 to 12 hours of downtime every quarter. Multiply that by four CPU cycles per year and you have a significant availability problem.
Oracle's answer was Edition-Based Redefinition — a way to have two versions of the same database objects exist simultaneously in the same database, visible to different sessions, without conflict.
EBR was introduced in Oracle Database 11g Release 2 (11.2.0.1) in 2009. Oracle EBS R12.2 was the first major Oracle application to adopt EBR as its core patching mechanism when it was released in 2013.
What Is a Database Edition?
The simplest way to think of an edition is as a private namespace for database code objects. An edition is a named container that holds a version of your PL/SQL packages, procedures, functions, views, and synonyms. Different sessions can connect to different editions and each session sees only the objects belonging to its edition.
Think of it like two parallel rooms in the same building. Room A has the current version of your code — users are working in there right now. Room B is a private copy of Room A where you are free to make changes. Users in Room A cannot see what you are doing in Room B and are completely unaffected by it. When you finish your changes, you open the door, users move to Room B, and Room A becomes available for the next round of changes.
That is exactly what EBR does — except the rooms are database editions and the move from one room to the other is the ADOP cutover phase.
sqlplus / as sysdba <<EOF -- List all editions in the database SELECT edition_name, status, created FROM dba_editions ORDER BY created; -- Check which edition the current session is using SELECT sys_context('USERENV','SESSION_EDITION_NAME') AS current_edition FROM dual; EOF
The Three Edition Types in EBS R12.2
EBS R12.2 uses three specific edition types throughout the ADOP patching cycle. Understanding what each one is and when it exists removes all confusion about what ADOP is actually doing at each phase.
| Edition Type | Who Connects to It | When It Exists |
|---|---|---|
| Run Edition | All online users — the default edition for all application sessions | Always — it never goes away. This is what users see at all times. |
| Patch Edition | ADOP patching tools only — users never connect to it | Only during an active patching cycle — from prepare to cutover or abort |
| Old Edition | Nobody — no connections allowed | After cutover, the previous run edition becomes the old edition. Removed during cleanup. |
The patch edition is always a child of the run edition. It inherits all the objects from the run edition when it is created. Objects that are not changed by the patch remain inherited from the parent — they are not duplicated. Only objects that the patch actually modifies are stored separately in the patch edition.
This is why online patching is efficient. Oracle does not create a full duplicate copy of every database object for the patch edition. It uses inheritance — the patch edition only stores what is different from the run edition. Everything else is shared.
Editioned Objects vs Non-Editioned Objects
Not all database objects can be editioned. This distinction is fundamental to understanding why some patches require downtime mode and why EBR has limits.
Editioned objects — can exist in multiple editions simultaneously
- PL/SQL packages and package bodies
- Procedures and functions
- Triggers
- Views (when defined as editioning views)
- Synonyms
- Types and type bodies
Non-editioned objects — exist in a single copy shared by all editions
- Tables — the physical storage is always shared
- Sequences
- Materialized views
- Certain synonyms that point to non-editioned objects
- Database links
- Queues
This is the direct reason why patches that modify non-editioned objects — particularly tables — require downtime mode. You cannot safely change a table structure while users in the run edition are actively reading and writing to it, because the table is shared between editions. There is only one physical copy.
When you see apply_mode=downtime in a patch README, it almost always means the patch modifies a table or other non-editioned object. The downtime mode bypasses the edition-based cycle entirely and applies the change directly to the shared object with all services down.
How EBS Handles Table Changes During Online Patching
Since tables cannot be editioned, Oracle EBS uses a clever workaround involving editioning views and cross-edition triggers to make table changes appear editioned even though the underlying table is shared.
Editioning views
In EBS R12.2, application code does not access base tables directly. Instead, it accesses them through editioning views — views that sit on top of the physical table and present a specific set of columns to each edition.
When a patch adds a new column to a table, the base table gets the new column immediately — but the run edition's editioning view does not expose it. Users in the run edition cannot see the new column. Only the patch edition's editioning view exposes it. This gives the appearance of two different table structures while there is only one physical table.
Cross-edition triggers
When a user in the run edition inserts or updates a row, that data must also be reflected correctly when the patch edition takes over at cutover. Cross-edition triggers handle this synchronisation automatically.
A forward cross-edition trigger fires on DML in the run edition and copies data into the new columns that the patch edition expects. A reverse cross-edition trigger does the opposite — it keeps the run edition's data consistent if the patch edition writes to the new columns before cutover.
This is why ADOP cutover is never truly instant even for small patches. During cutover, Oracle must fire and resolve any pending cross-edition triggers, ensure data consistency between editions, and then switch the default edition. The more active DML was happening during the patch cycle, the more work cutover has to do.
Seed data and ZD_EDITION_NAME
EBS seed data — rows in application setup tables like FND_LOOKUP_VALUES — is also versioned per edition. Each seed data table has a column called ZD_EDITION_NAME. During the apply phase, new seed data rows written by the patch are tagged with the patch edition name. Users in the run edition see only rows tagged with the run edition. At cutover, the default edition switches and users begin seeing the patch edition's seed data automatically.
The Three Filesystems and How They Map to Editions
EBR handles the database tier. The application tier has its own parallel structure based on three filesystems. Understanding how they map together completes the picture.
| Filesystem | Also Known As | Maps to DB Edition | Contents |
|---|---|---|---|
| Run filesystem | fs1 or fs2 — whichever is active | Run edition | Forms, reports, libraries, configuration serving users right now |
| Patch filesystem | fs1 or fs2 — whichever is inactive | Patch edition | Where ADOP applies patch files during the apply phase |
| Non-editioned filesystem | fs_ne | Neither — shared by both | ADOP logs, patch directories, shared configuration that does not change per edition |
fs1 and fs2 alternate roles with every cutover. If fs1 is the run filesystem today, it becomes the patch filesystem after the next cutover. fs2 becomes the new run filesystem. This is why you never hardcode fs1 or fs2 in your scripts — always use the environment variables $APPL_TOP (run) and source the correct environment file.
How EBR Maps to Every ADOP Phase
With EBR understood, the five ADOP phases make complete sense. Here is exactly what is happening at the EBR level during each phase.
| ADOP Phase | What Happens at the EBR Level |
|---|---|
| Prepare | A new patch edition is created as a child of the run edition in the database. The patch filesystem is synchronised with the run filesystem. Cross-edition triggers are put in place to keep data consistent during the patch cycle. |
| Apply | All database object changes — packages, procedures, views — are written to the patch edition only. Users in the run edition are completely unaffected. New seed data rows are written with ZD_EDITION_NAME set to the patch edition name. |
| Finalize | Invalid objects in the patch edition are compiled. Editioning views in the patch edition are updated to expose any new table columns added by the patch. Cross-edition triggers are validated. |
| Cutover | The database default edition is switched from run to patch. All new sessions now connect to the new run edition. The old run edition becomes the old edition. The patch filesystem becomes the new run filesystem. Services are briefly restarted. |
| Cleanup | The old edition is dropped from the database. Cross-edition triggers used during the patch cycle are removed. Obsolete code objects and seed data from the old edition are purged. The old patch filesystem is reset for the next cycle. |
What Users Actually Experience During Each Phase
| ADOP Phase | User Experience | Any Impact? |
|---|---|---|
| Prepare | No change — fully connected to run edition | None |
| Apply | No change — patch edition is invisible to users | None |
| Finalize | No change — compilation happens in patch edition | None |
| Cutover | Brief disconnection while services restart — 10 to 30 minutes | Yes — this is the only user-facing downtime |
| Cleanup | No change — fully connected to new run edition | Minor — cleanup may cause brief I/O spikes on large environments |
Edition-Enabled Schemas in EBS
For EBR to work on a schema, that schema must be edition-enabled. In EBS R12.2, the APPS schema and all application product schemas are edition-enabled out of the box. This was done as part of the R12.2 upgrade process and cannot be reversed once enabled.
Custom schemas: If you have custom application schemas in EBS R12.2, they must also be edition-enabled for online patching to work correctly with custom code. If a custom schema is not edition-enabled, custom PL/SQL objects in that schema will not be visible correctly across editions. Use ALTER USER <custom_schema> ENABLE EDITIONS — but note this cannot be undone.
Useful EBR Queries for EBS DBAs
Common Questions About EBR in EBS R12.2
| Question | Answer |
|---|---|
| Can I connect to the patch edition as a DBA? | Yes, but only while a patching cycle is in progress. Use ALTER SESSION SET EDITION = <patch_edition_name> after prepare and before cutover. |
| Why does cutover take 10 to 30 minutes if editions already exist? | Cutover must flush shared pool, resolve cross-edition triggers, switch the default edition, restart application services, and re-establish connections. The database switch itself is fast — the service bounce takes most of the time. |
| What happens if I skip cleanup? | The old edition remains in the database. Over many patch cycles, old editions accumulate and consume space. ADOP will run a quick cleanup automatically on the next prepare, but this delays the prepare phase. |
| Why do some patches still require downtime? | Those patches modify non-editioned objects — typically tables — that cannot be versioned by EBR. The change must be made to the single shared physical object, which requires all users to be disconnected first. |
| Can EBR be used for non-EBS applications? | Yes. EBR is a standard Oracle Database feature available to any application. EBS R12.2 is simply the most prominent example of an application built on top of it. |
| Does EBR require Oracle Enterprise Edition? | Yes. EBR is only available in Oracle Database Enterprise Edition. It is not available in Standard Edition. |
Summary — The Five Things to Remember
- EBR allows two versions of database code objects to exist simultaneously in the same database — the run edition for users and the patch edition for patching
- Editioned objects — packages, procedures, views, triggers — can exist separately per edition. Non-editioned objects — tables, sequences — are shared by all editions and cannot be changed online
- Editioning views and cross-edition triggers are how EBS makes table changes appear editioned even though the physical table is shared
- The three filesystems — run, patch, and non-editioned — mirror the database edition structure on the application tier. fs1 and fs2 alternate roles at every cutover
- Cutover is the only user-facing downtime because it is the only moment when the default database edition switches and services restart. Everything before cutover happens in the invisible patch edition
No comments:
Post a Comment