One High Availability challenge that is often overlooked is the application upgrade. An application upgrade involves any change made to the logical aspects of an application’s database objects. Large mission-critical applications cannot afford any downtime even for planned maintenance such as an application upgrade. Hence, there is a strong need for a zero-downtime application upgrade.
Edition-Based Redefinition (EBR), a feature built directly into the Oracle Database and included as part of Oracle Database Enterprise Edition, lets you upgrade the database component of an application in a separate “edition” while it is in use, thereby minimizing or eliminating downtime. In short, EBR is Oracle’s recommended solution for online application upgrades and part of Oracle’s Maximum Availability Architecture (MAA).
Why Use Edition-Based Redefinition (EBR)?
Modern applications today are required to “run forever”. This requirement extends from the hardware all the way up to the application. Thus, every maintenance must be online i.e. involve zero downtime. EBR provides the following key benefits to minimize downtime for an application upgrade:
Allow arbitrary changes to a set of artifacts implementing application’s database of record
Utilize both pre-upgrade and post-upgrade applications simultaneously (hot rollover)
Maintain uninterrupted availability of the application across editions (live operation)
Ensure no noticeable negative impact on performance.
Components of Edition-Based Redefinition (EBR)
Using EBR needs an understanding of the various components and their features. EBR depends on these components as below.
Editions are non-schema object types that do not have any owner and are a built-in feature of the Oracle Database. Any database must have at least one edition which is called the base edition (i.e. ora$base). 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. An alter session command allows the session to change its edition.
Administrators typically use editions as part of EBR to perform:
Install code changes in the privacy of a new edition
Make data changes safely by writing to new columns/tables
Mask changes that are not seen by the old edition or another edition
Before defining an editioning view, it is important to understand the concept of editioned vs non-editioned object types. The various objects supported in the Oracle Database can broadly be classified into two categories:
Editioned objects – are tied to both a schema as well as an edition. Views, synonyms, and all the kinds of PL/SQL objects such as triggers, functions, libraries, packages and package bodies, procedures, types, and type bodies are editioned object types. All other object types are non-editioned.
Non-Editioned objects – are visible to all editions and are not bound to a particular edition. Tables and indexes are examples of non-editioned object types.
An editioning view is a special kind of view and is an editioned object. An editioning view selects a subset of the columns from a single base table and, optionally, provides aliases for them. In providing aliases, the editioning view maps physical column names (used by the base table) to logical column names (used by the application). 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.
Administrators typically use editioning views as part of EBR to:
Expose a different projection of a table into each edition
Allow each user to see just its own columns
Unlike normal views (database object type) in which DML operations are restricted, editioning views can be both read-only as well as read-write. If you define cross-edition triggers on the base table, then make the editioning view read-write and not read-only. A cross-edition trigger is a special kind of trigger that is an editioned object type. A cross edition trigger must always be owned by an editions-enabled user and hence is always editioned. Cross-edition triggers are created directly on the base table and not on the editioning view. There are two kinds of cross-edition triggers as indicated below.
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 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
Administrators typically use cross-edition triggers as part of EBR to:
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.
Edition-Based Redefinition (EBR) Use Cases
Below are typical use cases in which EBR can be used to maintain application availability during an application upgrade. A one-time configuration step is needed to enable EBR for a database.
PL/SQL object changes
Table structure changes
Editions and Editioning Views
Table data changes
Editions, Editioning views and Cross-edition triggers
For more details on Edition-Based Redefinition refer to the official documentation here. To learn more about other high availability features for the Oracle Database, visit the Maximum Availability Architecture homepage. You can also follow us on Twitter at @OracleMAA for new updates.