13. Planned Downtime Database Upgrade Streams Rolling Upgrade using Logical Standby Database Application Maintenance Online Index Rebuild Online Table Redefinition The Case
15. Planned Downtime Application Upgrade Create objects Replace objects Drop objects Recompilation The Case
16.
17. Keep the Shop open Prepare new Release Cut over Randall Version 2 2 Boo 1 Version 1 Sulley 1 + 2
18. Edition Schema Object Type Object Name Session runs in the context of an Edition Parallel Universes
19. SQL>ALTER USER HR ENABLE EDITIONS; USER ALTERED. SQL> ALTER USER HR DISABLE EDITIONS; ALTER USER HR DISABLE EDITIONS * ERROR at line 1: ORA-00922: missing or invalid option SQL>
20. SQL> select * from all_editions; EDITION_NAME PARENT_EDITION_NAME USA ------------ ------------------- --- ORA$BASE YES SQL>
21. SQL> CREATE EDITION HR_RELEASE2 AS CHILD OF ORA$BASE; Edition created. SQL> CREATE EDITION OE_RELEASE2 AS CHILD OF ORA$BASE; CREATE EDITION OE_RELEASE2 AS CHILD OF ORA$BASE; * ERROR at line 1: ORA-38807: Implementation restriction: an edition can have only one child
22. ORA$BASE HR OE HR_RELEASE2 HR’ OE_RELEASE2 OE’ One Child – One Parent
23. Editionable PL/SQL Objects Packages Procedures Functions Triggers Views Synonyms Types Not everything is editionable... Not Editionable Tables Materialized Views DB Links
24. Table X Table Y ORA$BASE PL/SQL (A) PL/SQL (B) HR_RELEASE2 PL/SQL (A) PL/SQL (B) PL/SQL (B’)
25. “Instead-of-table” Only one table in the from clause No expressions, only columns Can have “regular” table triggers Same execution plan Editioning Views are the new tables Editioning Views are Editionable.... Editioning View
26.
27. Editioning View Data is the same View is different Depends on your position / edition
29. Old situation : One column NAME New situation : FIRST_NAME / LAST_NAME Cross Edition Triggers Forward Reverse Only on a Table Editionable In the newedition! How to handle Table changes?
30. Cross Edition Triggers NAME FIRST_NAME LAST_NAME “split” “concat” RELEASE 2 ORA$BASE RELEASE 3 ForwardCrossEditionTrigger ReverseCrossEditionTrigger Session A Session B Session C
31. Chain of forward / reverse Xedition triggers in decendent / ancestor editions Forward Xedition DML fires Forward Xedition triggers only (not regular triggers) The same for Reverse Xedition DML Xedition DML fires only other Xedition trigger (in same edition) if there is an ordering (follows xxx clause) Advanced principles
32. Forward Xedition isn’t fired in own edition Fill FIRST_NAME / LAST_NAME from NAME Fire the Xedition trigger only Use dbms_utility.wait_on_pending_dml() to prevent “lost updates” Use applying_crossedition_trigger function to prevent “collision” Use IGNORE_ROW_ON_DUPKEY_INDEX / CHANGE_DUPKEY_ERROR_INDEX hint (mandate!) to prevent collision Apply changes - 1 DBMS_Sql.Parse( c => The_Cursor, Language_Flag => DBMS_Sql.Native, Statement => 'update emp set empno = empno', Apply_Crossedition_Trigger => 'Fwd_Xed');
33. Apply changes - 2 CREATE OR REPLACE TRIGGER trigger1 BEFORE INSERT OR UPDATE ON table1 FOR EACH ROW CROSSEDITION DECLARE row_already_present EXCEPTION; PRAGMA EXCEPTION_INIT(row_already_present, -38911); BEGIN IF APPLYING_CROSSEDITION_TRIGGER THEN /* Trigger is running because of serendipitous change. Insert new row into table2 unless it is already there. */ INSERT /*+ IGNORE_ROW_ON_DUPKEY_INDEX(table2(key)) */ INTO table2 VALUES(:new.key, :new.value, to_date('1900-01-01', 'YYYY-MM-DD')); ELSE /* Trigger is running because you are applying transform. If tranform has not yet inserted new row in table2, insert new row; otherwise, update new row. */ BEGIN INSERT /*+ CHANGE_DUPKEY_ERROR_INDEX(table2(key)) */ INTO table2 VALUES(:new.key, :new.value, SYSTIMESTAMP); EXCEPTION WHEN row_already_present THEN UPDATE table2 SET value = :new.value, last_updated = SYSTIMESTAMP WHERE key = :new.key; END; END IF; END;
34. Rename your Tables Create Editioning Views Reroute Privileges Recreate Triggers Recompile all PL/SQL Apply VPD Policies Prepare your Application Your last Planned Downtime
35. Prepare your Application 1 Renameyour tables 2 Createeditioning views 3 Reroute privileges Your last Planned Downtime 4 Recreatetriggers 5 Recompile PL/SQL 6 Apply VPD policies
36. grant use on edition to <user> alter database default edition=<x> alter session set edition=<x> dbms_session.set_edition_deferred( <x> ) sys.dbms_sys_sql.parse (_as_user) sys_context SQL*Plus : show edition Opening up an Edition
37. SQL>GRANT USE ON EDITION HR_RELEASE2 TO SCOTT; Grant succeeded. SQL> CONNECT SCOTT/TIGER Connected. SQL> select sys_context('userenv', 'current_edition_name') current_edition_name from dual; CURRENT_EDITION_NAME -------------------- ORA$BASE
38. SQL>ALTER SESSION SET EDITION=HR_RELEASE2; Session altered. SQL> select sys_context('userenv', 'current_edition_name') current_edition_name from dual; CURRENT_EDITION_NAME -------------------- HR_RELEASE2
39. Rolling back an upgrade Retiring an Edition Only the root or a leaf No objects are inherited (anymore) Not currently in use Not the DB default edition Recompile objects (reuse settings) Dropping an Edition
44. Build on – views on - Editioning Views Four (!) -tier architecture Edition your Views or PL/SQL Functions Use Authorization Schemes EBR and APEX - 3 UI / APEX (Regular) View Editioning View Table
47. Applications never nevernever access tables Application sets the edition Alter DAD’s edition (EPG only)! Be aware!! Dropping objects drops inheritance No branching Best Practices
48. Short time Long(er) time Only for a specific group SaaS environment Parallel Application Versions
49. Different versions in the same schema No more planned downtime! Ease of maintenance Less redo Less risk So saving $$$ Summary & conclusions
50. Edition-Based Redefinition: Testing Live Application Upgrades (Without Actually Being Live) - Ms Melanie Caffrey Today at 14:15 Other sessions @UKOUG
51. Tom Kyte column(s) in Oracle Magazine Jan/Feb 2010 (http://www.oracle.com/technology/oramag/oracle/10-jan/o10asktom.html) Bryn's Whitepaper "Edition-Based Redefinition a new capability in Oracle Database 11g Release 2 to support online application upgrade". July 2009 (http://www.oracle.com/technology/deploy/availability/pdf/edition_based_redefinition.pdf) Documentation in "Oracle Database Advanced Application Developer's Guide 11g Release 2" (http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10471/adfns_editions.htm). References
52. Question Time That’s all Folks! My blog : http://roelhartman.blogspot.com My e-mail : roel.hartman@logica.com
Notas do Editor
0:02 / 0:04Over 15 years experience in the Oracle field. Started with RDBMS v5, Oracle Case, Forms 2.3, RPT/RPF. All the way to the latest version of Designer, Developer, RDBMS (took part in the 11g beta test).Frequent contributor of Oracle APEX Forum – Not > 4000 posts, but I’ve got work to do.BloggerWorking for Logica for over 13 years now as a Software Architect, NL-Lead Technical Architect OracleI set op the model for our Factory for Automated Migration of Oracle (u) Software. A repeatable solution for the migrations of Oracle Designer and Oracle Forms from earlier version to the latest version.Not a native English speaker – as you might have noticed (or will notice)APEX Experience?Forms Experience?APEX 2 Forms conversion experience?APEX 3.2 Early Adopters Release: article in Oghvisie & Oracle Scene
7 years!
1. Physical Standby DatabaseStandby database is called “physical” if the physical structure of stand by exactly matches with stand by structure. Archived redo log transferred from primary database will be directly applied to the stand by database.2. Logical Standby DatabaseStand by database is called “logical”, the physical structure of both databases do not match and from the archived redo log we create SQL statements then these statements will be applied to stand by database.
Online Index Rebuild (9i):When the ONLINE keyword is used as part of the CREATE or ALTER syntax the current index is left intact while a new copy of the index is built, allowing DML to access the old index. Any alterations to the old index are recorded in a Index Organized Table known as a "journal table". Once the rebuild is complete the alterations from the journal table are merged into the new index. This may take several passes depending on the frequency of alterations to the index. The process will skip any locked rows and commit every 20 rows. Once the merge operation is complete the data dictionary is updated and the old index is dropped. DML access is only blocked during the data dictionary updates, which complete very quickly.Online Table Redefinition (9i):Prior to Oracle9i table redefinition was only possible using export/import which meant the table was offline during the process, or the move syntax which locked DML during the operation. Neither of these methods is suitable for large OLTP tables as the downtime can be considerable. To solve this problem Oracle9i has introduced Online Table Redefinitions using the DBMS_REDEFINITION package.The process is similar to online rebuilds of indexes in that the original table is left online while a new copy of the table is built. DML operations on the original table are stored in an temporary table for interim updates. Once the new table is complete the interim updates are merged into it and the names of the original and the new table are swapped in the data dictionary. This step requires a DML lock but it is only held for a short time. At this point all DML is processed against the new table. The interim updates are automatically discarded, but the original table, with it's new name, has to be discarded manually
While Boo is implementing Version2, Sulley continues working in Version 1When Boo is finished, Randall starts a new session in Version 2, while Sulley stills does his thing in Version 1
NotEditionedTables X and Y are noteditionable, sothoseobjectsaren’t part of anyeditionBase ReleasePL/SQL Object A reads/writes to Table X and calls PL/SQL Object BPL/SQL Object B reads/writes to Table YRelease 2PL/SQL Object B is replacedby B’. PL/SQL Object A calls PL/SQL Object B’ nowPL/SQL Object B’ reads/writes to Table YPL/SQL Object A is “virtually present”
NotEditionedFor Release 2 column C is redundant and columns D and E are added.To keep the base release running column C isn’tdropped (yet).Youcan drop column C eventuallywheneveryone is using Release 2.Base ReleasePL/SQL Object A reads/writes to Editioning View XPL/SQL Object B reads/writes to Editioning View YRelease 2Edition View Y is replacedby Y’, without column C, butwith columns D and EPL/SQL Object B is replacedby B’. PL/SQL Object A calls PL/SQL Object B’ nowPL/SQL Object B’ reads/writes to Edition View Y’
Update in base ReleasefiresForwardCrossEditionTrigger in Release 2Update in Release 2FiresReverseCrossEditionTrigger in Release 2Update in Release 3FiresReverseCrossEditionTrigger in Release 2
Forward Xedition isn’t fired in own editionSo how to create the “new” information => FIRST_NAME and LAST_NAME from NAMEIGNORE_ROW_ON_DUPKEY_INDEX : Sort of Merge statement.CHANGE_DUPKEY_ERROR_INDEX : Changes an Duplicate Key error from ORA-00001 to ORA-38911
Forward Xedition isn’t fired in own editionSo how to create the “new” information => FIRST_NAME and LAST_NAME from NAMEIGNORE_ROW_ON_DUPKEY_INDEX HintWhen a statement of the form INSERT INTO target subquery runs, a unique key for some rows to be inserted might collide with existing rows. Suppose that you want your application to ignore such collisions and insert the rows that do not collide with existing rows.Before Release 11.2, you had to write a PL/SQL program which, in a block with a NULL handler for the DUP_VAL_ON_INDEX exception, selected the source rows and then inserted them, one at a time, into the target.As of Release 11.2, you do not have to write a PL/SQL program. You can use the IGNORE_ROW_ON_DUPKEY_INDEX hint in an INSERT statement, which is easier to write and runs much faster.CHANGE_DUPKEY_ERROR_INDEX HintWhen an INSERT or UPDATE statement runs, a unique key might collide with existing rows.Before Release 11.2, the collision caused error ORA-00001. You could tell that a collision had occurred, but you could not tell where.As of Release 11.2, you can use the CHANGE_DUPKEY_ERROR_INDEX hint in an INSERT or UPDATE statement, specifying that when a unique key violation occurs for a specified index or set of columns, ORA-38911 is reported instead of ORA-00001. This hint is especially helpful when implementing crossedition triggers.
alter database default edition = <x> -> has as side effect : grant use on edition <x> to publicsys.dbms_sys_sql.parse(_as_user) has additional parameters: Editionapply_crossedition_triggerfire_apply_trigger
alter database default edition = <x> -> has as side effect : grant use on edition <x> to publicsys.dbms_sys_sql.parse(_as_user) has additional parameters: Editionapply_crossedition_triggerfire_apply_trigger
* = ALL, USER or DBA
ALTER SESSION SET EDITION doesn’t work. Must be a top-level SQL statement. We can’t do that in APEX.DBMS_SESSION.SET_EDITION_DEFERRED sets the edition of yourcurrentsession (mightbe different fromyournextsession) select owner, object_name, object_id from all_objects where object_type = 'EDITION'; select ses.sid, ses.username, ses.session_edition_id, obj.object_namefrom v_$sessionses, all_objectsobjwhere username in (‘ANONYMOUS’,’APEX_PUBLIC_USER’)And ses.session_edition_id = obj.object_id(ses_id.sql)
FAIL : /home/oracle/OraHome_1/Apache/Apache/bin/apachectl start: execinghttpdSyntax error on line 48 of /home/oracle/OraHome_1/Apache/modplsql/conf/dads.conf:Invalid command 'PlsqlDatabaseEdition', perhaps mis-spelled or defined by a module not included in the server configuration = BUG!!
That way we can separate the user-interface-layer (the way the information is rendered in the browser), the business-layer (what data is shown and what rules the input should comply to) and the data-layer (the editioning views and the tables itself). This way a three-tier-architecture is not sufficient: we even need a four-tier-architecture!