Date post: | 27-Nov-2014 |
Category: |
Technology |
Upload: | lucas-jellema |
View: | 2,750 times |
Download: | 7 times |
Introducing and Demonstrating Oracle Database 11gR2's Killer Feature
Edition- Based Redefinition for Developers and DBAs
ODTUG Kaleidoscope 2010Lucas Jellema
AMIS, The Netherlands
Base ReleaseRelease 2 Release 3
The Book Application - Version 1
Application Version 1 on Database Edition Release 2
Database Upgrade Base release to Release 2
• Authors– New columns COUNTRY and BIOGRAPHY
• Books– Drop column NUM_OF_PAGES– Modified column ISBN (10 to 20 characters)– New columns LANGUAGE and PUBLICATION_YEAR
Application Version 2 (on Database Edition Release 2)
Application Version 2 on Base Edition in the Database
ALS Schema
Base ReleaseRelease 2
Availability
• Availability = Performance * (Up or Down)• Up = !Down• Down = Unplanned Down + Planned Down• Planned Down???
– System Maintenance• Power-supply, Hardware & Network, O/S upgrade• Database patching & Upgrade
– Application Upgrades
Maximum Availability Architecture
Application Upgrade• Creation of new objects• Changing existing objects
(alter and create or replace)– Add, Modify or Drop columns
or constraints– Change packages and stored procedures– Recompile
• Drop redundant objects• Convert or migrate data• Resume normal operations
Application is D
OW
N
Compare with road maintenance
Restructuring A12
• Build new road next to current one (A12-B)– Same “functionality” as
the old road• At the cut-over moment
– Open new A12-B: • Newly arriving traffic
travels on temporary road
– Close A12 (original)• Cars already on old road keep going
11gR2 Editioning is similar
Application Upgrade:• Prepare new release
– Construct the release in parallel to the existing– Operations in existing application ‘edition’
continue normally• From the cut-over point:
– Have new sessions operate on new release– Existing sessions can continue to run on existing
release
11gR2 Editions introduces a new dimension in the database
Base Release
Release 2
Release 3
Editions introduce or inherit versions of objects
Base ReleaseRelease 2 Release 3
Editions are parallel universes• Database Objects
are identified by– Object Type– Schema– Object 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
Database sessions run in a specific edition –one version of each object
Base Release Release 2 Release 3
The database as seen by a sessionrunning in the context of Release 3
B
2
3
33
3
2
2
2
ALS Schema
Base ReleaseRelease 2
Parallel Application Versions
Base ReleaseRelease 2 Release 3
Application XVERSION 1
Application XVERSION 2
The end of the big bang
• After the release of a new edition – there is no reason why you cannot keep the previous one going for some time– And multiple previous ones!
• That means – END OF THE BIG BANG upgrade!– Multiple versions of the application can continue
running to support various user groups (e.g. SaaS)• Without data migration and additional downtime upon
later move over of user groups
Demo of Database Editions• Existing base application, in base edition• Create new edition – release_2
– Create and Alter database objects– Base application
continues running• Cut-over point
– New sessions run in release_2 edition
– Current sessions continue in base
CONNECT SYS/ORACLE as SYSDBACREATE EDITION release_2;CREATE EDITION release_3 AS CHILD OF release_2;SELECT * FROM DBA_EDITIONS;
CREATE USER SCOTTY identified by tiger;ALTER USER SCOTTY ENABLE EDITIONS FORCEGRANT USE ON EDITION release_2 TO SCOTTY
CONNECT SCOTTY/TIGERALTER SESSION SET EDITION = ORA$BASECREATE OR REPLACE FUNCTION HELLO_WORLD
ALTER SESSION SET EDITION = RELEASE_2CREATE OR REPLACE FUNCTION HELLO_WORLD
ALTER SESSION SET EDITION = RELEASE_3DROP FUNCTION HELLO_WORLD
Base Release
Release
2Release
3
1 2 X
Some Rules for EBR (Edition Based Redefinition)
• EBR acts on packages, functions, triggers, procedures, views, types and synonyms
• EBR does not apply to tables– Data is not versioned, cloned, migrated– Different incarnations of a table are suggested
through editioning views – there is only one table– Applications should never access tables directly!
Editions and Tables• Tables cannot be versioned:
there is only one definition of a table across all Editions– Data is not versioned: a record exists once and only once
• The solution for managing changes to Tables: Editioning Views and Cross Edition Triggers– Editioning 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
Editions and TablesApplication A Application B
Table EMP
ENAMEJOB MGR SAL COMMHIREDATE
Editioning View EMP
Editions and TablesApplication A Application B
Table EMP_BASE
ENAMEJOB MGR SAL COMMHIREDATE
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
Migrate to Editioning Views• Rename Table (for example to <old table name>_BASE)
– Constraints continue to refer to the table
• Create the Editioning View with the old table name– Using the ‘CREATE OR REPLACE EDITIONING VIEW <view name>’ statement
• Reroute privileges – grant on view rather than table• Recompile the triggers on the table
– These now become triggers on the Editioning View
• Recompile all invalid PL/SQL program units and Views– They now refer to the Editioning View instead of the table
• VPD policies are reassigned to the View– Regular auditing and FGA is on the table
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>.trg
Rem recompile invalid Views and PL/SQL units
Editioning View EMP
Multiple versions of Editioning View Application A Application B
Table EMP_BASE
ENAMEJOB MGR SAL COMMHIREDATE
Editioning View EMP
Edition R2Edition R1
View EMP (1.0)
Multiple versions of Editioning View Application A Application B
Table EMP_BASE
ENAMEJOB MGR SAL COMMHIREDATE
View EMP (1.1)…* Language
Edition R2Edition R1
LANGUAGE
Forward Crossedition Trigger
DemoCREATE EDITION R2 AS CHILD OF R1;
ALTER SESSION SET EDITION R2;
SHOW EDITION
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;
DemoRem Create Forward Crossedition TriggerRem Applies to DML operations on EMP_BASE from Rem Earlier Editions
CREATE 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 TRIGGER EMP_1_1_Fwd_Xed ENABLE;
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;
Upgrade Table Definition
• Make desired changes to the table– Add columns, modify Columns, … (online redefinition)
• (Create Edition,) Set target Edition for session• Modify the Editioning View in the Edition
– To reflect the table as its latest version should look– Perhaps 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
Cross Edition Triggers• If you remove a (mandatory) column from the current
Editioning View…– a Reverse Crossedition Trigger ensures that new records get
some value in that (invisible) column
• If 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
View EMP (1.0)
Multiple versions of Editioning View Application A Application B
Table EMP_BASE
ENAMEJOB MGR SAL COMMHIREDATE
View EMP (1.1)…* Language
Edition R2Edition R1
LANGUAGE
Forward Crossedition Trigger
FIRSTNAMELASTNAME
View EMP (1.1)… (minus ENAME)* Languageo FIRST_NAME* LAST_NAME
Edition R3
Reverse Crossedition Trigger
“Suggested (best) Practices”
• Every application (release) sets the Edition it requires when it connects to a session– At the same time it calls dbms_application_info– And sets other Context details– Note: you could use multiple database service
definitions to access the same database• For example: ORCL_BASE, ORCL_R2, ORCL_R3• JEE data sources can be configured for a specific service• A logon trigger can read the service name used to
connect to the database and set edition accordingly
“Suggested (best) Practices”
• Applications should never access tables – all access should be through views– Only through views can the data structure itself be
Editioned– Even triggers should
be on the Editioning View
• Except cross edition triggers
Editioning View APP_DATA
Replacement Table PatternApplication A Application B
Table APPLICATION_METADATA
KEY VALUEUSER ORGID Default
Edition R2Edition R1
Editioning View APP_DATA
APPLICATION_METADATA_R2
KEY VALUEUSER ORGID Default
View DATA
Alternative Approach for Data Versioning
Application A Application B
Table EDITIONED_DATA
Edition R2Edition R1
* as_of_edition* until_edition… normal columns
select *from EDITIONED_DATAwhere <current_edition> between as_of_edition and until_edition
Interesting EBR Tid-Bits• Drop Object in an Edition stops the inheritance from
previous Edition. Object no longer is carried forward• Edition can have only one child – no branches (yet)• DBMS_SQL.PARSE can be executed in a specific Edition
– Use parameter edition to specify other than current edition
• If no explicit edition is set for a session, the default edition is used– ALTER DATABASE DEFAULT EDITION = edition_name;
• Hints in queries against Editionable Views are understood in terms of the underlying table– Logical EV column references are correctly mapped
Interesting EBR Tid-Bits• DB Links & Materialized Views currently not editionable• Objects of an editionable type are not editionable when
used by a non-editionable object– PL/SQL Function used in Function Based Index or the definition
of a Materialized View– ADT used as the base type for a column in a table
• Data Dictionary Views– DBA_/ALL_EDITIONS – editions in the database– DBA_/ALL_OBJECTS – objects (inherited) in current edition– DBA_/ALL_OBJECTS_AE – actual objects across all editions
Summary• 11gR2 Editions are parallel, co-existing
universes with incarnations of database objects– The new release can be constructed, tested and run
in a new edition– The old edition can be switched off at cut-over
• Editions also allow long time co-existence of multiple releases of an application
• Application Upgrade no longer needs to disrupt the operation through planned downtime
• By the way: EBR is available in all DB editions
Conclusion• See our blog for Oracle Database 11gR2
articles (other topics as well)– http://technology.amis.nl/blog– This presentation and the demo scripts are on the
blog too• Contact me: