Tales from a Parallel Universe: Using Oracle 11gR2's Edition Based Redefinition in combination with APEX

Editor's Notes

• #4: 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
• #8: 7 years!
• #11: 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.
• #13: 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
• #17: 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
• #24: 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”
• #28: 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’
• #30: Update in base ReleasefiresForwardCrossEditionTrigger in Release 2Update in Release 2FiresReverseCrossEditionTrigger in Release 2Update in Release 3FiresReverseCrossEditionTrigger in Release 2
• #32: 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
• #33: 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.
• #36: 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
• #39: 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
• #40: * = ALL, USER or DBA
• #41: 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)
• #42: 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!!
• #43: 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!