Edition-Based Redefinition (EBR)

Concept

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 down time.

Large, mission critical applications built on Oracle Database 11g Release 1 and earlier versions are often unavailable for tens of hours while the application’s database objects are patched or upgraded. Oracle Database 11g Release 2 introduces edition-based redefinition, a revolutionary new capability that allows online application upgrades with uninterrupted availability of the application. When the installation of the upgrade is complete, the pre-upgrade application and the post-upgrade application can be used at the same time.

Therefore, an existing session can continue to use the pre-upgrade application until it's user decides to end it; and all new sessions can use the post-upgrade application. As soon as there are no longer any sessions using the pre-upgrade application, it can be retired.

In other words, the application as a whole enjoys hot rollover from the pre-upgrade version to the post-upgrade version.

Edition-based redefinition is single technology that provides high availability during upgrades.

• It is part of Oracle Database 11gR2
• It seamlessly rolls changes forward and backward
• It is safe
• It is secure
• It is fully supported by Oracle
• It is free (no extra licensing cost)

 

What is Edition?

An edition is like a workspace or private environment where database objects are redefined. When we are satisfied with the change that we have made, those changes in the edition can be then rolled out to all the application users. An edition is effectively a version label that can be assigned to all editionable objects in a schema. When a new edition is used by a schema, all editionable objects are inherited by the new edition from the previous edition. These objects can subsequently then be altered or dropped as desired, but doing so will stop the inheritance of that object.

 

Editionable Objects

 

The following objects are editionable:

• FUNCTION
• LIBRARY
• PACKAGE and PACKAGE BODY
• PROCEDURE
• TRIGGER
• TYPE and TYPE BODY
• SYNONYM
• VIEW

All other objects are noneditionable. Notice, that means tables cannot be editioned!

 

Rules for Editioned Objects

A noneditioned object cannot depend on an editioned object.

For example:

• A public synonym cannot refer to an editioned object.
• A function-based index cannot depend on an editioned function.
• A materialized view cannot depend on an editioned view.
• A table cannot have a column of a user-defined data type (collection or ADT) whose owner is editions-enabled.
• A noneditioned subprogram cannot have a static reference to a subprogram whose owner is editions-enabled.

For the reason for this rule, see "Actualizing Referenced Objects".

• An ADT cannot be both editioned and evolved.

For information about type evolution, see Oracle Database Object-Relational Developer's Guide.

• An editioned object cannot be the starting or ending point of a FOREIGN KEY constraint.

The only editioned object that this rule affects is an editioned view. An editioned view can be either an ordinary view or an editioning view.