EDITION & TARGET EDITION & Edition-Based Redefinition (EBR) in Oracle
0 likes80 views
The document explains Oracle's edition-based redefinition (EBR) feature that allows for online application upgrades without downtime by enabling both pre- and post-upgrade applications to run simultaneously. It details the process of utilizing editions within an Oracle database, including how to create, manage, and utilize editioning views and crossedition triggers for data management. EBR significantly enhances application availability by allowing seamless transitions between application versions while user sessions continue without interruption.
![$ sqlplus / as sysdba
SQL> GRANT CREATE ANY EDITION, DROP ANY EDITION to user1;
SQL> alter user user1 enable editions;
SQL> grant create any view to user1;
SQL> select USERNAME,EDITIONS_ENABLED from dba_users where USERNAME='USER1';
USERNAME E
--------------- ---------
USER1 Y
2: Check the current & new edition in User1
$ sqlplus test1/pass
SQL> create edition e2;
--creating new edition
SQL> SELECT SYS_CONTEXT('userenv', 'current_edition_name') FROM DUAL;
-- check the current edition
SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME')
---------------------
ORA$BASE
SQL> create editioning view ed_emp_view_orabase as select EMPNO,ENAME from emp;
SQL> desc ed_emp_view_orabase
Name Null? Type
----------------- -------- -------- -------
EMPNO NUMBER(4)
ENAME VARCHAR2(10)
SQL> alter session set edition=e2;
---moving to new edition
SQL> SELECT SYS_CONTEXT('userenv', 'current_edition_name') FROM DUAL;
SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME')
----------------------------
E2
SQL> CREATE or replace EDITIONING VIEW ed_emp_view as
select EMPNO,ENAME,SAL from emp;
SQL> desc ed_emp_view
Name Null? Type
------------------------ -------- ---------
EMPNO NUMBER(4)
ENAME VARCHAR2(10)
SAL NUMBER(7,2)
3: Take the export
$ expdp dump
fi
le=test.dmp schemas=test include=view directory=dir1 source_edition=e2
4: drop the view from any edition
[oracle@ ~]$ sqlplus test/test](https://image.slidesharecdn.com/editiontargeteditionedition-basedredefinitionebrinoracle-240507202611-7437cf40/85/EDITION-TARGET-EDITION-Edition-Based-Redefinition-EBR-in-Oracle-3-320.jpg)
EDITION & TARGET EDITION & Edition-Based Redefinition (EBR) in Oracle
- 1. ♨ EDITION & TARGET EDITION & Edition-Based Rede fi nition (EBR) in Oracle database Overview: Large mission-critical applications may experience downtime for tens of hours, or even longer, while the application’s database components are updated during an application upgrade. Oracle Database introduced Edition-Based Rede fi nition (EBR), a revolutionary capability that allows online application upgrades with uninterrupted application availability. EBR functions by maintaining two versions of the application simultaneously. 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 using the pre-upgrade application until its user decides to end it; all new sessions can use the post- upgrade application. The pre-upgrade application can be retired after all sessions have disconnected from it. In other words, the application as a whole enjoys a hot rollover1 from the pre-upgrade version to the post-upgrade version. The application’s database backend must be enabled to use EBR by making one-time schema changes to take advantage of the capability. Also, the script that performs the application upgrade must be written in such a way as to use EBR’s features. Therefore, EBR adoption and subsequent use is the prerogative of the development shop. Oracle Edition concept: First I would like to explain what do you mean by edition . Simple de fi nition is same object name you can store multiple times. This will useful during upgradation or versioning control of ddls. For example, as per your not sure whether object is required extra structure or not, in this case create same object name with di ff erent edition. Once you fi nalised then you can drop the unused object name . Editions are nonschema objects; as such, they do not have owners. Editions are created in a single namespace, and multiple editions can coexist in the database. The database must have at least one edition. Every newly created or upgraded Oracle Database starts with one edition named ora$base. Edition-based rede fi nition enables you to upgrade the database component of an application while it is in use, thereby minimizing or eliminating down time. To upgrade an application while it is in use, you copy the database objects that comprise the application and rede fi ne the copied objects in isolation. Your changes do not a ff ect users of the application—they continue to run the unchanged application. When you are sure that your changes are correct, you make the upgraded application available to all users. Using edition-based rede fi nition means using one or more of its component features. The features you use, and the down time, depend on these factors: 📍 What kind of database objects you rede fi ne 📍 How available the database objects must be to users while you are rede fi ning them 📍 Whether you make the upgraded application available to some users while others continue to use the older version of the application
- 2. You always use the edition feature to copy the database objects and rede fi ne the copied objects in isolation; that is why the procedure that this chapter describes for upgrading applications online is called edition-based rede fi nition. If the object type of every object you will rede fi ne is editionable, the edition is the only feature you use. Table is not an editionable type. If you change the structure of one or more tables, you also use the editioning view feature. If other users must be able to change data in the tables while you are changing their structure, you also use forward crossedition triggers. If the pre- and post-upgrade applications will be in ordinary use at the same time (hot rollover), you also use reverse crossedition triggers. Crossedition triggers are not a permanent part of the application—you drop them when all users are using the post-upgrade application. An editioned object is a schema object that has both an editionable type and an editions- enabled owner. (A schema object that has an editionable type but not an editions-enabled owner is potentially editioned.) An edition can have its own copy of an editioned object, in which case only the copy is visible to the edition. A noneditioned object is a schema object that has a noneditionable type. An edition cannot have its own copy of a noneditioned object. A noneditioned object is identical in, and visible to, all editions. The objects are limited to some set of objects which is not having the storage. Editionable and Noneditionable Schema Object Types: These schema objects types are editionable: • SYNONYM • VIEW • All PL/SQL object types: ◦ FUNCTION ◦ LIBRARY ◦ PACKAGE and PACKAGE BODY ◦ PROCEDURE ◦ TRIGGER ◦ TYPE and TYPE BODY All other schema object typeare noneditionable. Table is an example of an noneditionable type. A schema object of an editionable type is editioned if its owner is editions-enabled; otherwise, it is potentially editioned. A schema object of a noneditionable type is always noneditioned, even if its owner is editions- enabled. A table is an example of an noneditioned object. 1: Enabling Editions for a User To enable editions for a user, use the ENABLE EDITIONS clause of either the CREATE USER or ALTER USER statement. The EDITIONS_ENABLED column of the static data dictionary view DBA_USERS or USER_USERS shows which users have editions enabled.
- 3. $ sqlplus / as sysdba SQL> GRANT CREATE ANY EDITION, DROP ANY EDITION to user1; SQL> alter user user1 enable editions; SQL> grant create any view to user1; SQL> select USERNAME,EDITIONS_ENABLED from dba_users where USERNAME='USER1'; USERNAME E --------------- --------- USER1 Y 2: Check the current & new edition in User1 $ sqlplus test1/pass SQL> create edition e2; --creating new edition SQL> SELECT SYS_CONTEXT('userenv', 'current_edition_name') FROM DUAL; -- check the current edition SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME') --------------------- ORA$BASE SQL> create editioning view ed_emp_view_orabase as select EMPNO,ENAME from emp; SQL> desc ed_emp_view_orabase Name Null? Type ----------------- -------- -------- ------- EMPNO NUMBER(4) ENAME VARCHAR2(10) SQL> alter session set edition=e2; ---moving to new edition SQL> SELECT SYS_CONTEXT('userenv', 'current_edition_name') FROM DUAL; SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME') ---------------------------- E2 SQL> CREATE or replace EDITIONING VIEW ed_emp_view as select EMPNO,ENAME,SAL from emp; SQL> desc ed_emp_view Name Null? Type ------------------------ -------- --------- EMPNO NUMBER(4) ENAME VARCHAR2(10) SAL NUMBER(7,2) 3: Take the export $ expdp dump fi le=test.dmp schemas=test include=view directory=dir1 source_edition=e2 4: drop the view from any edition [oracle@ ~]$ sqlplus test/test
- 4. SQL> alter session set edition=ORA$BASE; SQL> desc ed_emp_view_orabase Name Null? Type ------------------------ -------- ----- EMPNO NUMBER(4) ENAME VARCHAR2(10) SQL> drop view ed_emp_view_orabase; Now you lost object in ORA$BASE edition. Now we have dump fi le backup but its in new edition. 5: IMPORT THE DUMPFILE $ impdp dump fi le=test.dmp directory=dir1 target_edition=ORA$BASE 6: Verify it $ sqlplus test1/pass SQL> ALTER SESSION SET EDITION =ORA$BASE; SQL> desc ed_emp_view_orabase Name Null? Type ---------------------- --------- --------- EMPNO NUMBER(4) ENAME VARCHAR2(10) SAL NUMBER(7,2) Note: Now you got the object from dump fi le which is target edition dump fi le. Now source edition and target edition objects are same. AS CHILD OF Clause If you use this clause, then the new edition is created as a child of parent_edition. If you omit this clause, then the new edition is created as a child of the leaf edition. At the time of its creation, the new edition inherits all editioned objects from its parent edition. Restriction on Editions An edition can have only one child edition. If you specify for parent_edition an edition that already has a child edition, then an error is returned. Sample: The following very simple examples are intended to show the syntax for creating and working with an edition. In the following statements, the user HR is given the privileges needed to create and use an edition: SQL> GRANT CREATE ANY EDITION, DROP ANY EDITION to HR; Grant succeeded. SQL>ALTER USER hr ENABLE EDITIONS; User altered. HR creates a new edition TEST_ED for testing purposes: SQL>CREATE EDITION test_ed;
- 5. HR then creates an editioning view ed_view in the default edition ORA$BASE for testing purposes, fi rst verifying that the current edition is the default edition: SQL>SELECT SYS_CONTEXT('userenv', 'current_edition_name') FROM DUAL; SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME') ---------------------------------- ORA$BASE 1 row selected. SQL> CREATE EDITIONING VIEW e_view AS SELECT last_name, fi rst_name, email FROM employees; View created. DESCRIBE e_view Name Null? Type -------------- -------- ------------- LAST_NAME NOT NULL VARCHAR2(25) FIRST_NAME VARCHAR2(20) EMAIL NOT NULL VARCHAR2(25) The view is then actualized in the TEST_ED edition when HR uses the TEST_ED edition and re- creates the view in a di ff erent form: SQL>ALTER SESSION SET EDITION = TEST_ED; Session altered. SQL>CREATE OR REPLACE EDITIONING VIEW e_view AS SELECT last_name, fi rst_name, email, salary FROM employees; View created. The view in the TEST_ED edition has an additional column: DESCRIBE e_view Name Null? Type ------------------ -------- --------------- LAST_NAME NOT NULL VARCHAR2(25) FIRST_NAME VARCHAR2(20) EMAIL NOT NULL VARCHAR2(25) SALARY NUMBER(8,2) The view in the ORA$BASE edition remains isolated from the test environment: SQL>ALTER SESSION SET EDITION = ora$base; Session altered. DESCRIBE e_view; Name Null? Type ----------- -------- -------------- LAST_NAME NOT NULL VARCHAR2(25) FIRST_NAME VARCHAR2(20) EMAIL NOT NULL VARCHAR2(25) Even if the view is dropped in the test environment, it remains in the ORA$BASE edition: SQL>ALTER SESSION SET EDITION = TEST_ED; Session altered.
- 6. SQL>DROP VIEW e_view; View dropped. ALTER SESSION SET EDITION = ORA$BASE; Session altered. DESCRIBE e_view; Name Null? Type ---------------- -------- ------------------ LAST_NAME NOT NULL VARCHAR2(25) FIRST_NAME VARCHAR2(20) EMAIL NOT NULL VARCHAR2(25) When the testing of upgrade that necessitated the TEST_ED edition is complete, the edition can be dropped: SQL>DROP EDITION TEST_ED; Making an Edition Available to Some Users As the creator of the edition, you automatically have the USE privilege WITH GRANT OPTION on it. To grant the USE privilege on the edition to other users, use the SQL statement GRANT USE ON EDITION. Making an Edition Available to All Users To make an edition available to all users, either: • Grant the USE privilege on the edition to PUBLIC: SQL> GRANT USE ON EDITION edition_name TO PUBLIC • Make the edition the database default edition: SQL>ALTER DATABASE DEFAULT EDITION = edition_name • This has the side e ff ect of allowing all users to use the edition, because it e ff ectively grants the USE privilege on edition_nameto PUBLIC. Edition-Based Rede fi nition (EBR) Edition-based rede fi nition (EBR) enables online application upgrade with uninterrupted availability of the application. When the installation of an 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 its user decides to end it; and all new sessions can use the post-upgrade application. When there are no longer any sessions using the pre-upgrade application, it can be retired. In this way, EBR allows hot rollover from from the pre- upgrade version to the post-upgrade version, with zero downtime. EBR enables online application upgrades in the following manner: • Code changes are installed in the privacy of a new edition. • Data changes are made safely by writing only to new columns or new tables not seen by the old edition. An editioning view exposes a di ff erent projection of a table into each edition to allow each to see just its own columns. • Crossedition triggers propagate data changes made by the old edition into the new edition’s columns, or (in hot-rollover) vice-versa. EBR is available for use in all editions of Oracle Database without the need to license it. Oracle data pump option for Edition: TARGET_EDITION=name If you specify TARGET_EDITION=name, then Data Pump Import creates all of the objects found in the dump fi le. Objects that are not editionable are created in all editions.
- 7. For example, tables are not editionable, so if there is a table in the dump fi le, then the table is created, and all editions see it. Objects in the dump fi le that are editionable, such as procedures, are created only in the speci fi ed target edition. If this parameter is not speci fi ed, then Import uses the default edition on the target database, even if an edition was speci fi ed in the export job. If the speci fi ed edition does not exist, or is not usable, then an error message is returned. Restrictions This parameter is only useful if there are two or more versions of the same versionable objects in the database. The following is an example of using the TARGET_EDITION parameter: # impdp hr DIRECTORY=dpump_dir1 DUMPFILE=exp_dat.dmp TARGET_EDITION=exp_edition This example assumes the existence of an edition named exp_edition on the system to which objects are being imported. Because no import mode is speci fi ed, the default of schema mode will be used. More info: https://docs.oracle.com/en/database/oracle/oracle-database/19/adfns/editions.html https://docs.oracle.com/en/database/oracle/oracle-database/23/adfns/editions.html https://www.oracle.com/docs/tech/ebr-technical-deep-dive-overview.pdf Alireza Kamrani Database Box is a technical group on LinkedIn.