Database-aanpassingen met minimale downtime

Database-aanpassingen met minimale downtime

Gepubliceerd: Categorie: Oracle

Het leven van een DBA heeft altijd een merkwaardige tegenstelling. Enerzijds zal de DBA altijd streven naar een zo hoog mogelijke beschikbaarheid van database en applicaties, maar de grootste bedreiging voor die beschikbaarheid is een van de taken van de DBA: het doorvoeren van applicatie-aanpassingen. Tijdens het doorvoeren van de aanpassingen is de applicatie niet beschikbaar, en als er wat fout gaat kan het veel tijd kosten om de situatie te herstellen.

Traditioneel was het zo dat applicatie-aanpassingen dus worden doorgevoerd op een moment dat een korte downtime acceptabel was, vaak op een moment buiten de normale werktijden.

Edition-Based Redefinition

Om de downtime en risico’s te verkleinen heeft Oracle Database sinds versie 11.2 Edition-Based Redefinition. Door deze feature is het mogelijk om een nieuwe versie van applicatie-software in de database te installeren naast de oude versie. Pas als de installatie afgerond en getest is wordt deze vrijgegeven aan de gebruikers. De enige downtime voor de gebruiker bestaat uit even opnieuw inloggen!

Om database-aanpassingen door te voeren met Edition-Based Redefinition zal eerst een nieuwe edition moeten worden aangemaakt. Iedere edition heeft een parent edition. Alle objecten uit de parent edition zijn ook zichtbaar in de nieuwe child edition. Alleen de aangepaste objecten worden binnen de nieuwe edition aangemaakt.

Voor het doorvoeren van de aanpassingen zal de nieuwe edition binnen een sessie worden geselecteerd. De aanpassingen worden pas zichtbaar in andere sessies als deze ook de nieuwe edition binnen hun sessie hebben geselecteerd.

Doorvoeren aanpassingen

Als voorbeeld een eenvoudige applicatie met een tabel en een view:

  1. CREATE TABLE t_person
  2. (name varchar2(10)
  3. ,city varchar2(10)
  4. )
  5. ;
  6. CREATE OR REPLACE VIEW v_person
  7. AS
  8. SELECT name
  9. FROM t_person
  10. ;

Release 2 van de applicatie bestaat uit een aanpassing op de view, ook de kolom City moet zichtbaar worden.

Om dit online te installeren zal er eerst een nieuwe edition moeten worden aangemaakt en geselecteerd.

  1. CREATE edition release_2 ;
  2. ALTER SESSION SET edition = release_2;

Release 2 is een Child van de vorige release, in dit geval de default release ORA$BASE. Dat betekent dat alle objecten van de Parent-release ook hier zichtbaar zijn. Alleen de aangepaste objecten worden binnen release 2 zelf aangemaakt.

Vervolgens wordt de view aangepast:

  1. CREATE OR REPLACE VIEW v_person
  2. AS
  3. SELECT name
  4. , city
  5. FROM t_person
  6. ;

De verschillende versies zijn zichtbaar in de dictionary. Van de view zijn nu twee versies zichtbaar in:

  1. USER_OBJECTS_EA :
  2. SELECT SELECT object_name, object_type, edition_name
  3. FROM user_objects_ae
  4. ORDER BY object_name;
  5. OBJECT_NAME OBJECT_TYPE EDITION_NAME
  6. ------------ ------------------ ---------------------
  7. T_PERSON TABLE
  8. V_PERSON VIEW RELEASE_2
  9. V_PERSON VIEW ORA$BASE

De aloude view USER_OBJECTS is uiteraard ook nog aanwezig, daar staan alleen de objecten en versies die in de huidige sessie actief zijn. In deze view is wel een extra colomn EDITION_NAME opgenomen, daarin staat de edition die op dat moment voor die sessie actief is.

Release test

De nieuwe view is nu aangemaakt in de database, maar nog steeds niet zichtbaar voor de gebruikers. Om een gebruiker Larry te laten testen kunnen we deze rechten geven op de nieuwe edition:

  1. GRANT USE ON edition release_2 TO larry ;

Larry zal nog steeds de oude versie van de view zien, totdat hij specifiek de nieuwe release selecteert in zijn sessie:

  1. SELECT sys_context('userenv', 'session_edition_name') AS edition
  2. FROM dual ;
  3. EDITION
  4. ---------------------
  5. ORA$BASE
  6. SELECT * FROM app_owner.v_person ;
  7. NAME
  8. ----------
  9. John Smith
  10. Jan Jansen

Binnen de sessie kan nu de gewenste edition worden geselecteerd:

  1. ALTER SESSION SET edition = release_2;

Een alternatief is om met het connect commando de gewenste edition te selecteren:

  1. CONNECT LARRY@mydb edition=release_2

Daarna zal de nieuwe versie van het object getoond worden:

  1. SELECT * FROM app_owner.v_person ;
  2. NAME CITY
  3. ---------- ----------
  4. John Smith London
  5. Jan Jansen Amsterdam

Release overgang

Als de implementatie helemaal afgerond en getest is kan deze worden vrijgegeven voor alle gebruikers. Het enige wat hiervoor hoeft te gebeuren is dat er binnen de sessie de juiste edition moet worden geselecteerd. Dat kan op verschillende manieren.

Binnen bestaande sessies kan de nieuwe release worden afgedwongen met het bovenstaande “alter session set edition” statement.

Nieuwe sessies zullen standaard connectie maken met de default edition van de database. Deze is simpel aan te passen op het moment van overgang naar de nieuwe release:

  1. ALTER DATABASE DEFAULT edition = release_2 ;

Een manier om het opnieuw inloggen af te dwingen voor alle gebruikers is een herstart van de database-instance. De totale downtime voor de release overgang blijft dan beperkt tot een paar minuten die nodig zijn voor de herstart.

Beperkingen

Van niet alle databasetypes kunnen meerder edities worden gemaakt. Edition-Based Redefinition kan gebruikt worden voor views en alle PL/SQL types, zoals procedures en triggers, maar het is niet mogelijk om meerdere edities van tabellen aan te maken.

Deze laatste beperking is te omzeilen door tabellen altijd alleen maar via views te benaderen. Deze schil van views bepalen de representatie van de tabellen naar de gebruikers en applicaties.

Tijdens de implementatie van een applicatie-change kan er bijvoorbeeld een kolom aan een tabel worden toegevoegd. Zolang deze niet is toegevoegd aan de huidige edition van de views is deze onzichtbaar voor de gebruikers. Er kan zelfs een complete nieuwe versie van de tabel naast de oude worden gemaakt, de tabellen kunnen dan tijdelijk door middel van triggers worden gesynchroniseerd.

Het ombouwen van gewone applicatie naar een edition based applicatie kan door het hernoemen van alle tabellen binnen en schema, en het aanmaken van views op iedere tabel, met als naam de oude tabelnaam. Alle bestaande triggers op de tabellen kunnen opnieuw worden aangemaakt op de views. Ook alle grants kunnen nu op de views worden gegeven, en niet meer op de onderliggende tabellen. Bestaande packages, functions en procedures hoeven niet te worden aangepast. De in deze objecten genoemde tabelnamen blijven onveranderd, alleen zullen ze nu verwijzen naar een view met de zelfde naam. Deze applicatie-aanpassing vergt een eenmalige downtime, maar daarna kunnen er dus edition based-aanpassingen op de applicatie worden doorgevoerd.

Zelf maakt Oracle ook gebruikt van deze upgrade methode. Zo is Online Patching, één van de nieuwe features in Oracle E-Business Suite 12.2 ook gebaseerd op Edition-Based Redefinition.

Links

http://docs.oracle.com/cd/E11882_01/appdev.112/e41502/adfns_editions.htm#ADFNS99915

Bastiaan Bak
Over auteur Bastiaan Bak

DBA met ruim 15 jaar ervaring. Ervaring in verschillende branches, met verschillende modules. Onder meer: Oracle Database, Oracle RAC, Oracle EBS en PL/SQL.

Meer posts van Bastiaan Bak
Reacties
Reactie plaatsen