This document provides an overview of EBR (Edition-Based Redefinition) usage in EBS 12.2 for online patching. It introduces the key concepts of ADOP (Oracle's online patching utility), editions, editioning views, and cross-edition triggers which enable applying patches while the system remains available. The document then explains the different phases of the ADOP cycle (Prepare, Apply, Cutover, Cleanup, Abort) and how EBR works together with ADOP to allow patching with zero downtime. Customization considerations for moving code and files during the patching process are also covered.

1. EBR Usage in EBS - 12.2
Ram Narayan Reddy
Skynous Software Services
2/09/2015 SKYNOUS SOFTWARE SERVICES PVT LTD 1

2. Agenda
• What Made It Possible
• Introduction to ADOP
• Introduction to EBR
• Objects that made EBR Possible
• ADOP Cycle along with Edition
• Conclusion
2/09/2015 2

3. What Made It Possible?
Online Patching/Code Changes when system is in use ::
• Dual File System
• Introduced in 12.2
• RUN Base and Patch Base
• EBR(Edition-Based Redefinition)
• Introduced in 11gR2
2/09/2015 3

4. Introduction to ADOP(Online Patching Utility)
• Introduction to ADOP
• Oracle E-Business R12.2 introduced new patching mechanism that allow the
application of patches while your environment is up and running which is
called as Online patch.
• Multiple File systems
• RUN Base and Patch Base
• Different Phases of ADOP
• Downtime Requirement (Required for cutover phase)
2/09/2015 4

5. Introduction To EBR
• Edition-based redefinition (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 are able to 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. When used in this manner, EBR enables hot rollover from the
pre-upgrade version to the post-upgrade version, with zero
downtime.
2/09/2015 5

6. Objects that Made EBR Possible
• Edition-Based Redefinition depends upon three new kinds of object
• Edition : If the application upgrade will change only views, synonyms, and
PL/SQL objects, then the edition alone is sufficient to allow these changes to
be made while the application remains on line. new workflows are required.
• Editioning View : changes to table data or structure are restricted to only
those tables that are not changed via the ordinary end-user interfaces, then
the edition together with the editioning view are sufficient to allow these
changes to be made while the application remains on line.
• Cross edition Trigger : If changes to table data or structure are required for
those tables that are changed routinely by the end-user, then the edition, the
editioning view, and the cross edition trigger must be used in concert to allow
these changes to be made while the application remains on line.
2/09/2015 6

7. Edition
• An edition is a new, nonschema object type, uniquely identified,
therefore, by just its name.
• Views (and therefore editioning views), synonyms, and all the kinds of
PL/SQL objects type (and therefore crossedition triggers) are
editionable object types
• An editioned object is uniquely identified by its owner, name,
namespace and the value of current edition that issued the SQL
statement that created or changed it.
2/09/2015 7

8. Edition Example
2/09/2015 8

9. Edition examples
2/09/2015 9
SQL> ALTER USER RAM ENABLE EDITIONS;
SQL> SELECT * FROM dba_editions;
EDITION_NAME PARENT_EDITION_NAME USA
------------------------------ ------------------------------ ---
ORA$BASE YES
EDITION_TEST ORA$BASE YES
EDITION_TEST1 EDITION_TEST YES
EDITION_TEST2 EDITION_TEST1 YES
SQL> GRANT USE ON EDITION EDITION_TEST to RAM;
SQL> conn ram/***;
Connected.
SQL> SELECT SYS_CONTEXT('USERENV','SESSION_EDITION_NAME') ASeditionFROM dual ;
EDITION
--------------------------------------------------------------------------------
ORA$BASE

10. Edition examples
2/09/2015 10
SQL> ALTER SESSION SET EDITION =EDITION_TEST;
SQL> SELECT SYS_CONTEXT('USERENV','SESSION_EDITION_NAME') ASeditionFROM dual;
EDITION
--------------------------------------------------------------------------------
EDITION_TEST
SQL> SELECT object_name,object_type,edition_name FROM user_objects_ae ORDER BY object_name;
OBJECT_NAME OBJECT_TYPE EDITION_NAME
-------------------- ------------------- ------------------------------
EMP TABLE
EV VIEW EDITION_TEST
HELLO PROCEDURE EDITION_TEST
HELLO PROCEDURE ORA$BASE
• How to tell your Edition:
selectad_zd.GET_EDITION_TYPE, ad_zd.GET_EDITION from dual;
•Set Editionat EBS
ad_zd.SET_EDITION(‘RUN’) or ad_zd.SET_EDITION(‘PATCH’)

11. Editioning Views
2/09/2015 11
• Not All objects are Editionable
• Code Objects – Editionable(PL/SQL Blocks)
• Data Objects – Non Editionable(Tables and Indexes)
• Editioning View
• An editioning view, as a special kind of view, is editionable. It might help to
think that while the physical table cannot be editioned, the editioning view
allows different occurrencesof its logical projection to be presented in
different editions.

12. Editioning Views Example
2/09/2015 12

13. Crossedition Triggers
• Assume that we want to modify a column in a table if this is modified
directly we will create invalids in applications and application might mis-
behave depending on the change we do.
• The solution is to create an edition view and cross edition trigger.
• We create an edition view in current edition for the table and alter the
table definition to add new column that has the modification needed.
• We create a new edition from the existing edition and create a new edition
view for the table with new column. Please note that edition view wont
get replaced as it is a editionable object
• Now we create a crossedition trigger, this will populate the changes across
editions
2/09/2015 13

14. Crossedition Triggers Example
2/09/2015 14

15. CrossEdition Triggers Example
2/09/2015 15

16. ADOP and EBS Working Together
2/09/2015 16
ADOP EBR
Prepare New Editionis Created
Apply – File system changes implemented
on Patch Base
Changes are appliedto Newly Created
Edition
Cutover – RUN Base switches New EditionIs made as defaultedition
Abort Newly created Editionis dropped
Cleanup Objects created during online upgrade
are dropped

17. ADOP PHASE=PREPARE
• Application Side
• Peform Validatations such as Ports
• Sycn the Patch Edition With Run
Edition
• Database Side
• Create edition V_20150718_0941
• Grant use on edition
V_20150718_0941 to public
2/09/2015 17

18. ADOP PHASE=APPLY
• Application Side
• Perform validation if prepare
completed successfully and if there
are any failed patches
• Applies the patches to patch file
system
• DatabaseSide
• Connect to the Newly Created Patch
edition which in our case is
V_20150718_0941
• We can identify thw new objects
created using dba_objects with
edition_name
2/09/2015 18

19. ADOP PHASE=FINALIZE
• Validates any failed or
incomplete patching sessions
• Compiles all objects in the
edition
• Prepares the System for the Next
Phase Cutover
• This can be skipped as cutover
will run this if we explicitly run
this.
2/09/2015 19

20. ADOP PHASE=CUTOVER
• Application Side
• File Base will be changing. Patch
Edition will now become run edition
and vice versa
• Application Outage will happen as
services needs to be started from
new file system
• You will observe that the all managed
servers along with admin server are
started using different port. Oracle
took care that login URL remains
same
• If Logged into the session you will be
prompted with a message to reset
the env
2/09/2015 20

21. ADOP PHASE=CUTOVER
• Database Side
• The new child version will become
the default version, there by
bringing all the modifications
online
• alter database default edition =
V_20150818_0942
• revoke use on edition
V_20150814_1900 from PUBLIC
• If you are connected existing run
edition your connection will be
terminated
2/09/2015 21

22. ADOP PHASE=CLEANUP
• Disable and Drop Cross Edition
Triggers
• Clean-up unused seed data
editions
• This will not drop the old edition
2/09/2015 22

23. ADOP PHASE=ABORT
• revoke use on edition
V_20150816_2311 from PUBLIC
• drop edition V_20150816_2311
cascade
• Inserts the Messages into the
APPLSYS.ad_zd_logs
2/09/2015 23

24. Customizations
• Best process would be not to perform any custom code movement during
the systemis in patching cycle
• If customizations needed to be moved during the prepare phase make sure
that plsql blocks are compiled on both patch and run editions
• If any files need to be moved to the file system(Such as rdf, shell scripts)
please move them to both the file systems.If these are moved before
prepare, prepare will copy all the files from run file systemto patch file
system.If prepare is already in progress we need to copy to both the file
systems
• Keep your Run and Patch File Systemsin sync with fs_clone
2/09/2015 24

25. References
• Oracle Manuals
• Google.com
• Tracing adop cycle
2/09/2015 25

26. Further Questions
Reach us at -ram@skynous.com
Thank You