Continuous Database Application Evolution with Oracle ... · Continuous Database Application...

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)



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


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)



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


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


Table APPLICATION_METADATA

K

E

Y

VA

L

U

E

U

S

E

R

O

R

G

I

D

Default


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


Table EDITIONED_DATA


* 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]

http://technology.amis.nl/blog

Continuous Database Application Evolution with Oracle ... · Continuous Database Application...

Documents

Transcript of Continuous Database Application Evolution with Oracle ... · Continuous Database Application...