Using Edition-Based Redefinition
Oracle GoldenGate supports the use of Edition-based Redefinition (EBR) with Oracle Databases enabling you to upgrade the database component of an application while it is in use, thereby minimizing or eliminating down time.
Editions are non-schema objects that Editioned objects belong to.
Editions can be thought of as owning editioned objects or as a namespace. Every
database starts with one edition named, ORA$BASE
; this includes
upgraded databases. More than one edition can exist in a database and each can only
have one child. For example, if you create three editions in succession, edition1,
edition2, edition3, then edition1 is the parent of edition2 which is the parent of
edition3. This is irrespective of the user or database session that creates them or
which edition was current when the new one is created. When you create an edition,
it inherits all the editioned objects of its parent. To use editions with Oracle
GoldenGate, you must create them.
An object is considered editioned if it is an editionable type, it is
created with the EDITIONABLE
attribute, and the schema is enabled
for editioning of that object type. When you create, alter, or drop an editioned
object, the redo log will contain the name of the edition in which it belongs. In a
container database, editions belong to the container and each container has its own
default edition.
The CREATE | DROP EDITION
DDLs are captured for all
Extract configurations. They fall into the OTHER
category and
assigned an OBJTYPE
option value of EDITION
. The
OBJTYPE
option can be used for filtering, for example:
DDL EXCLUDE OBJTYPE EDITION
DDL EXCLUDE OBJTYPE EDITION OPTYPE CREATE
DDL EXCLUDE OBJTYPE EDITION OPTYPE DROP
DDL EXCLUDE OBJTYPE EDITION OPTYPE DROP ALLOWEMPTYOWNER OBJNAME edition_name
You must use the following syntax to exclude an edition from Extract or Replicat:
EXCLUDE OBJTYPE EDITION, ALLOWEMPTYOWNER OBJNAME edition_name
Editions fall into the OTHER
category so no mapping is
performed on the edition name. When applied, the USE
permission is
automatically granted to the Replicat user. Replicat will also perform a
grant use on edition
name
with
grant option
to the original creating user if that user exists on the
target database. Because editions are not mappable operations, they do not have
owners so the standard EXCLUDE
statement does not work.
The DDLs used to create or alter editions do not enable the user for
editions, rather they enable the schema for editions. This is an important
distinction because it means that the Replicat user does not need to be enabled for
editions to apply DDLs to editioned objects. When Replicat applies a CREATE
EDITION
DDL, it grants the original creating user permission to
USE
it, if the original user exists on the target database. For
any unreplicated CREATE EDITION
statements, you must issue a
USE WITH GRANT OPTION
grant to the Replicat user.
Whether or not an editionable objects becomes editioned is controlled by the schema it is applied in. Replicat switches its current session Edition before applying a DDL if the edition name attribute exists in the trail file and it is not empty.
Container database environments are supported for both Extract and Replicat. No additional configuration is necessary. The Replicat user's schema can not be enabled for editions if it is a common user. The Replicat user's schema does not need to be enabled for editions when applying DDLs to editioned objects in other schemas.