Quick introduction of what and why of Oracle Database Edition Based Redefinition

Availability is a highly desirable aspect of Fusion Middleware application. Planned downtime therefore sounds quite silly. However, the introduction of changes to applications has typically been associated with the roll out and redeployment of the application causing disruption of service – through loss of existing conversations and unavailability during the deployment process. Several approaches and mechanisms are available in the Oracle stack that will help substantially reduce the loss of uptime because of changes to applications.

First of all, many types of changes may be implemented through run time configuration, rather than software change requiring redeployment of application artifacts. This approach requires good design of aspects of applications that may require modification and the construction of run time mechanisms for applying and processing such changes. The design time at run time capabilities of several Fusion Middleware products go a long way in supporting this approach.

Additionally, several FMW components support short or even long term co-existence of different versions of applications. This means that existing conversations can complete even when a new version has been made available. It also means that there does not need to be any time during deployment at which the application is not available. BPM and SOA Suite have multi versioning capabilities that allow prolonged co-existence of two or many more versions of composite applications. BPM also supports instance migration – allowing running process instances to be upgraded to a new process definition. WebLogic supports production redeployment, which allows Web applications and Web Services to temporarily – just until all current sessions have been taken care – have two co-existing versions.

Keeping in step with the middleware’s capabilities for downtime free application upgrades, Oracle has introduced Edition Based Redefinition in the 11gR2 release of the database. This mechanism too supports prolonged co-existence of different versions of (the database objects supporting) applications. By associating specific versions of middleware application components with specific editions in the database, it becomes straightforward to have parallel versions of an application and consequently interruption free upgrades.

For the 11g release of the database Oracle went beyond the reduction of downtime and the ability to redefine database objects with a minimum of unavailability. It implemented in the database a mechanism that is very similar to WebLogic’s production redeployment: the ability to have two versions of the application (or in this case: a coherent set of database objects) live at the same time, the old version servicing longer running sessions that started before the new version went live. This mechanism is called Edition Based Redefinition. It is illustrated in the next figure: the two versions 1 and 2 of Application X – temporarily running in parallel on WebLogic just after production redeployment – have need different versions of the database objects. Version 1 relies on the base release of the database objects while version 2 of the application uses the versions of database objects shipped in Release 2, complemented with the objects from version 1 that were not changed for version 2.

The notion of a ‘release of database objects’ was introduced in Oracle Database 11gR2 and is called ‘an edition’. Editions are almost parallel universes in which the same database objects – such as views, packages, types – from the same schema can exist in with different definitions. For example: package SALARY_MANAGEMENT in Schema SCOTT can exist multiple times – for example once in the Base Edition, once in Edition Release 2 and once in Edition Release 4.

Through Edition Based Redefinition (EBR), we can build up the database objects for a new release in its own edition in parallel with and insulated from the versions of those objects that are currently live. Only when we make the new edition available for new sessions created against the database will the new versions of the database objects get accessed. The edition to use is determined at session level, using a simple ALTER SESSION statement that can for example be executed in a LOGON trigger. Obviously, it is important to synchronize the version of the application with the edition in the database that contains the corresponding versions of database objects. Note: a default edition is always indicated; any session not explicitly setting the target edition will use this default.

In the example shown in the figure above, we can build instructions into application X to explicitly set the database edition after establishing the connection to the database. Version 1 would set the Base Edition and version 2 would set the Release 2 Edition. Alternatively, a trick I heard from the product manager for EBR (Bryn Llewellyn), the applications can make use of different JDBC Data Sources on the application server that connect through different database services to the same database schema. A LOGON trigger detects the name of the database service used to connect and selects the session’s edition accordingly.

Edition Based Redefinition was introduced in 11gR2 and will be further refined in the upcoming 12c release. It is a mechanism included with all editions (SE One, SE, XE, EE) of the database. It allows a new version of the database side of applications to be deployed, compiled, tested in isolation – without any impact on the live environment. Then this new version can be exposed to [selected] new database sessions. Unlike production redeployment on WebLogic, it is possible to keep various editions around for a long time – not only until all current sessions have completed. It is also possible to have more than two editions; in fact I am not sure there even is a limited to the supported number of editions. Depending on the logic that governs the selection of the edition for a session, many different edition can be in use for different users and their sessions at the same time.

Using EBR, zero downtime upgrade of the database objects that go with FMW applications has become possible. No more planned unavailability need to be suffered because of the compilation of changed packages or the invalid status somewhere halfway during the execution of DDL scripts upgrading the application’s database schema.

Resources

Continuous Database Application Evolution with Oracle Database 11gR2 – Lucas Jellema, ODTUG Kaleidoscope 2009 – Presentation on Edition Based Redefinition – http://www.slideshare.net/lucasjellema/edition-based-redefinition-continuous-database-application-evolution-with-oracle-database-11g-release-2

Using Data Guard for minimizing downtime through database upgrades -Oracle technical marketing presentation http://www.oracle.com/technetwork/database/features/availability/311390-133499.pdf

Maximum Availability Architecture (MAA) Best Practices for Planned Maintenance: Online Patching and Rolling Upgrades with Oracle Database –http://www.oracle.com/technetwork/database/features/availability/maa-planmaint-131050.pdf

An Oracle White paper: Zero-Downtime Database Upgrades Using Oracle GoldenGate http://www.oracle.com/technetwork/middleware/goldengate/overview/ggzerodowntimedatabaseupgrades-174928.pdf

Oracle 11gR2 On Line Documentation on Edition Based Redefinition – http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10471/adfns_editions.htm