Online Application Upgrade

Amikor HA (High Availability - Magas Rendelkezésre Állás) megoldásokról beszélünk, általában elsőként a klaszterek, redundáns megoldások jutnak eszünkbe. Pedig nem csak a hardver hibákra kell gondolni, hanem a tervezett leállásokkal is érdemes foglalkozni. Az egyik talán legkevésbé megoldott probléma az, ha egy alkalmazás verzió váltást kell végrehajtani úgy, hogy közben változik az adatstruktúra is. Ez nyilván azt eredményezi, hogy le kell állítani az adatbázist is, és az átszervezéseket, akár adat átalakításokkal együtt végre kell hajtani. De a legnagyobb probléma talán az, hogy amennyiben valami rosszul sül el, és vissza kell állni a kiinduló állapotra, akkor az adatbázis mentést is vissza kell tölteni, hiszen átmenetileg minden felhasználó aki épp használatba vette az új alkalmazás verziót már egy új adatstruktúrába kezdett dolgozni.

Az Oracle Database Online Application Upgrade képessége, vagy pontosabb nevén az Edition Based Redefinition pontosan ezt a problémát célozza meg. Az Edition Based Redefinition 3 alap objektummal működik, ezek: edition, editioning view és crossedition trigger. Az edition egy új nonschema objektum típus. 11gR2 verziótól minden adatbázis rendelkezik legalább egy edition-nel, melynek neve Ora$Base. Minden új edition egy már létező gyermeke kell, hogy legyen. Amikor kapcsolódunk az adatbázishoz, meghatározható, hogy melyik edition-höz kapcsolódjunk. Kizárólag nézetek, szinonímák és PL/SQL ojektum típusoknak lehet több edíciója (ezek metadat típusú objektumok, nem tartalmaznak adatokat). Azok az objektumok, melyek több edícióval rendelkeznek egyedileg csak úgy azonosíthatók, ha az owner, name, namespace mellett az edition-t is megnevezzük. Azaz két vagy több példánya is létezhet egy adatbázison belül ugyanazzal az owner, name és namespace azonosítókkal rendelkező objektumnak, amennyiben használjuk az edition-based redefinition-t. Egy új objektum típus, az editioning view is edicionálható. Mivel a fizikai tábla nem edicionálható (elkerülendő az adatok többszörös tárolását és teljesítmény gondokat), ezért az editioning view feladata egy adott tábla egyszerű leképezése egy nézet formájában, ami már több edition-ben is létezhet, és képes elfedni a tábla módosításait. Amennyiben a tábla módosítások olyan táblákat érintenek, amelyek tartalmát  az alkalmazás felhasználók módosítják, szükség van olyan triggerekre, amelyek az egyes editioning view-k között a módosításokat karbantartják. Ezek a crossedition triggerek.

Természetesen ahhoz, hogy az online application upgrade működjön, minden érintett tábla elé el kell készíteni az editioning nézetet és a megfelelő crossedition triggereket. Ezeket használva az alkalmazás két vagy több különböző verzió képes ugyanazon adatbázison párhuzamosan futni, és ha megtörtént a verzióváltás, akkor még mindig egyszerű visszaállni a régi verzióra egészen addig, amíg a régi edition eldobásra nem kerül.

További információk az Edition-Based Redefinition című whitepaper-ben találhatók.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About


Sárecz Lajos vagyok, 2003 óta dolgozok az Oracle Hungary Kft-nél értékesítési tanácsadóként. Szakterületem az Oracle Engineered Systems, azaz olyan szerverek, amelyek hardver és szoftver komponensek előre optimalizált konfigurációja.
A blogon publikált vélemények a saját nézeteimet tükrözik, nem feltétlenül egyeznek meg az Oracle álláspontjával.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
View Lajos Sárecz's LinkedIn profileView Lajos Sárecz's profile

Search

Archives
« április 2014
HKSzeCsPSzoV
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today