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_nameEditions 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.
From Oracle Database 23ai onwards, online DDL operations that were previously blocked can be performed. This provides additional flexibility for Oracle Application Upgrades that are done with Edition Based Redefinition (EBR). See Using Edition-Based Redefinition in the Oracle Database Development Guide for details.
Oracle GoldenGate Extract and Replicat are also able to manage replication for such DDL operations so that changes from Oracle Application Upgrades are replicated correctly. In addition, you'll be able to DROP unused columns online from tables where ACDR is removed.