Continuous Database Application Evolution
with Oracle Database 11g Release 2
OGH DBA Day on High Availability
3 november 2009
Lucas Jellema AMIS, The Netherlands
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
Ap
plic
atio
n is
DO
WN
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
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
The database as seen by a session
running in the context of Release 3
Demo of Application Upgrade• Existing base application, in base edition
• Create new editon – 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
Some Rules for EBR (Edition Based Redefinition)
• Editioning acts on packages, functions, triggers, procedures, views, types and synonyms
• Editioning does not apply to tables
– Data is not versionend, cloned, migrated
– Different incarnations of a table are suggested through editionable views – there is only one table
– Applications should never access tables directly!
But wait, there is more
• 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 suport various user groups (e.g. SaaS)
• Without data migration and additional downtime upon later move over of user groups
Parallel Application Versions
Application XVERSION 1
Application X
VERSION 2
Version 1 on Base Edition
Version 1 on Edition Release 2
Upgrade Base 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
Version 2 (on Edition Release 2)
Version 2 on Base Edition
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
E
N
A
M
E
J
O
B
M
G
R
S
A
L
C
O
M
M
HIREDATE
EditioningView EMP
Editions and TablesApplication A Application B
Table EMP_BASE
E
N
A
M
E
J
O
B
M
G
R
S
A
L
C
O
M
M
HIREDATE
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 EMP
AS
SELECT ...
FROM EMP_BASE
/
DROP TRIGGER EMP_BRI
/
Rem recreate trigger on Editioning View
@<EMP_BRI>.trg
Rem recompile invalid Views and PL/SQL units
EditioningView EMP
Multiple versions of Editioning View
Application A Application B
Table EMP_BASE
E
N
A
M
E
J
O
B
M
G
R
S
A
L
C
O
M
M
HIREDATE
EditioningView EMP
Edition R2Edition R1
View EMP (1.0)
Multiple versions of Editioning View
Application A Application B
Table EMP_BASE
E
N
A
M
E
J
O
B
M
G
R
S
A
L
C
O
M
M
HIREDATE
View EMP (1.1)
…
* Language
Edition R2Edition R1
LANGUAGE
Forward Crossedition
Trigger
DemoCREATE EDITION R2 AS CHILD OF R1;
ALTER SESSION SET EDITION R2;
SELECT SYS_CONTEXT('Userenv', 'Current_Edition_Name')
"Current_Edition" FROM DUAL;
SHOW EDITION
ALTER TABLE EMP_BASE
ADD (LANGUAGE VARCHAR2(2) NULL);
Rem function for deriving value for language
CREATE OR REPLACE FUNCTION
GET_LANGUAGE( p_job in varchar2) return varchar2
is
begin
return case p_job when 'MANAGER' then 'fr'
else 'en' end;
end;
DemoRem Create Forward Crossedition Trigger
Rem Applies to DML operations on EMP_BASE from
Rem Earlier Editions
CREATE OR REPLACE TRIGGER EMP_1_1_Fwd_Xed
BEFORE INSERT OR UPDATE ON EMP_BASE
FOR EACH ROW
FORWARD CROSSEDITION
DISABLE
BEGIN
:new.language = get_language(:new.job);
END EMP_1_1_Fwd_Xed;
Rem Enable the Forward Crossedition Trigger
ALTER TRIGGER EMP_1_1_Fwd_Xed ENABLE;
DemoRem Use Forward Crossedition trigger to
Rem upgrade existing table records according to new table
Rem 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 DMLedthrough 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
E
N
A
M
E
J
O
B
M
G
R
S
A
L
C
O
M
M
HIREDATE
View EMP (1.1)
…
* Language
Edition R2Edition R1
LANGUAGE
Forward Crossedition
Trigger
FIRSTNAME
LASTNAME
View EMP (1.1)
… (minus ENAME)
* Language
o 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
• 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
EditioningView APP_DATA
Replacement Table Pattern
Application A Application B
Table APPLICATION_METADATA
K
E
Y
VA
L
U
E
U
S
E
R
O
R
G
I
D
Default
Edition R2Edition R1
EditioningView APP_DATA
APPLICATION_METADATA_R2
K
E
Y
VA
L
U
E
U
S
E
R
O
R
G
I
D
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_DATEwhere <current_edition>
betweenas_of_edition anduntil_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-editional 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
• EBR (online upgrade) benefits from Online Table Redefinition and Fine Grained Dependency tracking
• 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: [email protected]