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.
Comments
Post a Comment