Amikor HA (High Availability - Magas Rendelkezésre Állás) megoldásokról beszélünk, általában elsoké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 mukö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étezo 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 rendelkezo 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ülendo 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 egyszeru 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 muködjön, minden érintett tábla elé el kell készíteni az editioning nézetet és a megfelelo crossedition triggereket. Ezeket használva az alkalmazás két vagy több különbözo verzió képes ugyanazon adatbázison párhuzamosan futni, és ha megtörtént a verzióváltás, akkor még mindig egyszeru 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ímu whitepaper-ben találhatók.
