Edition Based Redefinition - Continuous Database Application Evolution with Oracle Database 11g Release 2
13 likes4,826 views
The document discusses the concept of edition-based redefinition (EBR) in Oracle Database 11g Release 2, allowing applications to upgrade with minimal downtime by enabling parallel versions to coexist. It explains how database sessions can operate in specific editions, facilitating a seamless transition during application upgrades without disrupting ongoing operations. Additionally, it highlights the use of editioning views and triggers to manage changes and maintain data integrity across different application versions.
Edition Based Redefinition - Continuous Database Application Evolution with Oracle Database 11g Release 2
- 1. Release 2Release 3Base ReleaseContinuous Database Application Evolution with Oracle Database 11g Release 2 Lucas Jellema AMIS, The Netherlands
- 2. Introducing Oracle 11gR2 Edition Based Redefinitionthe story of the Parallel Application UniversesRelease 2Release 3Base ReleaseLucas Jellema AMIS, The Netherlands
- 3. AvailabilityAvailability = Performance * (Up or Down)Up = !DownDown = Unplanned Down + Planned DownPlanned Down???System MaintenancePower-supply, Hardware & Network, O/S upgradeDatabase patching & UpgradeApplication Upgrades
- 5. Application UpgradeCreation of new objectsChanging existing objects (alter and create or replace)Add, Modify or Drop columns or constraintsChange packages and stored proceduresRecompileDrop redundant objectsConvert or migrate dataResume normal operationsApplication is DOWN
- 6. Compare with road maintenance
- 7. Restructuring A12Build new road next to current one (A12-B)Same “functionality” as the old roadAt the cut-over momentOpen new A12-B: Newly arriving traffic travels on temporary roadClose A12 (original)Cars already on old road keep going
- 8. 11gR2 Editioning is similarApplication Upgrade:Prepare new releaseConstruct the release in parallel to the existingOperations in existing application ‘edition’ continue normallyFrom the cut-over point:Have new sessions operate on new releaseExisting sessions can continue to run on existing release
- 9. 11gR2 Editions introduces a new dimension in the databaseRelease 3Release 2Base Release
- 10. Editions introduce or inherit versions of objectsRelease 2Release 3Base Release
- 11. Editions are parallel universesDatabase Objects are identified byObject TypeSchemaObject Name…. Edition!(release, application version, stripe, parallel universe id)Database Sessions run in the context of a specific edition Using a specific collection of versions of objects
- 12. Database sessions run in a specific edition –one version of each objectRelease 2Release 3Base ReleaseThe database as seen by a sessionrunning in the context of Release 3323B22332
- 13. Demo of Application UpgradeExisting base application, in base editionCreate new editon – release_2Create and Alter database objectsBase application continues runningCut-over pointNew sessions run in release_2 editionCurrent sessions continue in base
- 14. Some Rules for EBR (Edition Based Redefinition)Editioning acts on packages, functions, triggers, procedures, views, types and synonymsEditioning does not apply to tablesData is not versionend, cloned, migratedDifferent incarnations of a table are suggested through editionable views – there is only one tableApplications should never access tables directly!
- 15. But wait, there is moreAfter the release of a new edition – there is no reason why you cannot keep the previous one going for some timeAnd multiple previous ones!That means – END OF THE BIG BANG upgrade!Multiple versions of the application can continue running to suport various user groups (e.g. SaaS)Without data migration and additional downtime upon later move over of user groups
- 16. Parallel Application VersionsApplication XVERSION 1Application XVERSION 2Release 2Release 3Base Release
- 17. Version 1 on Base Edition
- 18. Version 1 on Edition Release 2
- 19. Upgrade Base to Release 2AuthorsNew columns COUNTRY and BIOGRAPHYBooksDrop column NUM_OF_PAGESModified column ISBN (10 to 20 characters)New columns LANGUAGE and PUBLICATION_YEAR
- 20. Version 2 (on Edition Release 2)
- 21. Version 2 on Base Edition
- 22. Editions and TablesTables cannot be versioned: there is only one definition of a table across all EditionsData is not versioned: a record exists once and only onceThe solution for managing changes to Tables: Editioning Views and Cross Edition TriggersEditioning Views are defined on base table (no joins)Editioning Views can have DML triggers defined (just like base table)Using an editioning view in a query or DML statement does not impact the performance of the query or DML
- 23. Editions and TablesApplication AApplication BTable EMPSALMGRJOBENAMEHIREDATECOMM
- 24. Editions and TablesApplication AApplication BEditioning View EMP Table EMP_BASESALMGRJOBENAMEHIREDATECOMM
- 25. Oracle guarantees:The Execution Plan for a SQL query that uses an Editioning View is identical to that for the same query based directly on the table
- 26. Migrate to Editioning ViewsRename Table (for example to <old table name>_BASE)Constraints continue to refer to the tableCreate the Editioning View with the old table nameUsing the ‘CREATE OR REPLACE EDITIONING VIEW <view name>’ statementReroute privileges – grant on view rather than tableRecompile the triggers on the tableThese now become triggers on the Editioning ViewRecompile all invalid PL/SQL program units and ViewsThey now refer to the Editioning View instead of the tableVPD policies are reassigned to the ViewRegular auditing and FGA is on the table
- 27. DemoALTER TABLE EMP RENAME TO EMP_BASE;CREATE OR REPLACE EDITIONING VIEW EMPASSELECT ...FROM EMP_BASE/DROP TRIGGER EMP_BRI/Rem recreate trigger on Editioning View@<EMP_BRI>.trgRem recompile invalid Views and PL/SQL units
- 28. Multiple versions of Editioning View Application AApplication BEdition R2Edition R1Editioning View EMP Editioning View EMP Table EMP_BASESALMGRJOBENAMEHIREDATECOMM
- 29. Multiple versions of Editioning View Application AApplication BEdition R2Edition R1View EMP (1.1)…* Language View EMP (1.0)Table EMP_BASESALMGRJOBENAMELANGUAGEHIREDATECOMMForward CrosseditionTrigger
- 30. DemoCREATE EDITION R2 AS CHILD OF R1;ALTER SESSION SET EDITION R2;SELECT SYS_CONTEXT('Userenv', 'Current_Edition_Name') "Current_Edition" FROM DUAL;ALTER TABLE EMP_BASEADD (LANGUAGE VARCHAR2(2) NULL);Rem function for deriving value for languageCREATE OR REPLACE FUNCTION GET_LANGUAGE( p_job in varchar2) return varchar2isbegin return case p_job when 'MANAGER' then 'fr' else 'en' end;end;
- 31. DemoRem Create Forward Crossedition TriggerRem Applies to DML operations on EMP_BASE from Rem Earlier EditionsCREATE OR REPLACE TRIGGER EMP_1_1_Fwd_XedBEFORE INSERT OR UPDATE ON EMP_BASEFOR EACH ROWFORWARD CROSSEDITIONDISABLEBEGIN :new.language = get_language(:new.job);END EMP_1_1_Fwd_Xed; Rem Enable the Forward Crossedition TriggerALTER TRIGGEREMP_1_1_Fwd_Xed ENABLE;
- 32. DemoRem Use Forward Crossedition trigger toRem upgrade existing table records according to new tableRem version (for large # records use dbms_parallel_execute)DECLARE c NUMBER := DBMS_SQL.OPEN_CURSOR(); x NUMBER; BEGIN DBMS_SQL.PARSE ( c => c , Language_Flag => DBMS_SQL.NATIVE , Statement => 'UPDATE EMP_BASE SET EMPNO = EMPNO', Apply_Crossedition_Trigger => 'EMP_1_1_Fwd_Xed' ); x := DBMS_SQL.EXECUTE(c); DBMS_SQL.CLOSE_CURSOR(c); COMMIT; END;
- 33. Upgrade Table Definition(Create Edition,) Set target Edition for sessionMake desired changes to the tableAdd columns, modify Columns, … (online redefinition)Modify the Editioning View in the Edition To reflect the table as its latest version should lookPerhaps hiding columns you eventually want to drop(optional) Create Forward Crossedition Trigger on base table to have DML on previous Editions made valid(optional) Create Reverse Crossedition Trigger on base table to have DML on current Edition synch back
- 34. Cross Edition TriggersIf you remove a (mandatory) column from the current Editioning View…a Reverse Crossedition Trigger ensures that new records get some value in that (invisible) columnIf you add a (mandatory) column to the table (and the current Editioning View)…a Forward Crossedition Trigger ensures that records DMLed through previous Editioning View versions are made valid(optionally) Apply Forward Crossedition Trigger for all existing records (created in old edition of the table)Use DBMS_SQL.parse (with parameter Apply_Crossedition_Trigger set to name of trigger)Use DBMS_PARALLEL_EXECUTE
- 35. Multiple versions of Editioning View Application AApplication BEdition R3View EMP (1.1)… (minus ENAME)* Languageo FIRST_NAME* LAST_NAMEEdition R1Edition R2View EMP (1.1)…* Language View EMP (1.0)Table EMP_BASEReverse Crossedition TriggerSALMGRJOBENAMELANGUAGEFIRSTNAMELASTNAMEHIREDATECOMMForward CrosseditionTrigger
- 36. “Suggested (best) Practices”Every application (release) sets the Edition it requires when it connects to a sessionAt the same time it calls dbms_application_infoAnd sets other Context detailsApplications should never access tables – all access should be through viewsOnly through views can the data structure itself be EditionedEven triggers should be on the Editioning View
- 37. Interesting EBR Tid-BitsDrop Object in an Edition stops the inheritance from previous Edition. Object no longer is carried forwardEdition can have only one child – no branches (yet)DBMS_SQL.PARSE can be executed in a specific EditionUse parameter edition to specify other than current editionIf no explicit edition is set for a session, the default edition is usedALTER DATABASE DEFAULT EDITION = edition_name; Hints in queries against Editionable Views are understood in terms of the underlying tableLogical EV column references are correctly mapped
- 38. Interesting EBR Tid-BitsDB Links & Materialized Views currently not editionableObjects of an editionable type are not editionable when used by a non-editional objectPL/SQL Function used in Function Based Index or the definition of a Materialized ViewADT used as the base type for a column in a tableEBR (online upgrade) benefits from Online Table Redefinition and Fine Grained Dependency trackingData Dictionary ViewsDBA_/ALL_EDITIONS – editions in the databaseDBA_/ALL_OBJECTS – objects (inherited) in current editionDBA_/ALL_OBJECTS_AE – actual objects across all editions
- 39. Summary11gR2 Editions are parallel, co-existing universes with incarnations of database objectsThe new release can be constructed, tested and run in a new editionThe old edition can be switched off at cut-over Editions also allow long time co-existence of multiple releases of an applicationApplication Upgrade no longer needs to disrupt the operation through planned downtimeBy the way: EBR is available in all DB editions
- 40. ConclusionSee our blog for Oracle Database 11gR2 articles (other topics as well)http://technology.amis.nl/blogThis presentation and the demo scripts are on the blog tooContact me: [email protected]
Editor's Notes
- #37: Synonyms are editionableADT are not – though ADTs not used in (Editionable) Table may beAfter a drop you can recreate an object –the ancestry is based on name alone so the end result is the same as the starting pointEditions really is an extension of the Name Resolution mechanismIn addition to name and schema, the edition is taken into accountSQL Execution plans are the same for queries against the table and against the Editioning ViewWhen View 1 depends on View 2 – which version of View 2 is the one picked for view 1?The selection is made like this: whichever version of View 2 that is actual in the Edition where View 1 is createdFixed in 11g – DDL in parallel with running transactions against the same objects (?)Also/part of that: fine grained dependency trackingTools for comparing Editions?List of actual in Edition 2 and Edition 1Compare object levelDIYVPD and FGA work fine with Editionable Views