Migráció V.

Oracle Relational Migration Maps

Az Oracle Relational Migration Maps (röviden: Migration Maps) az Oracle által használt módszertan egy meglévő adatbázis Oracle adatbáziskezelőre migrálásához.

Nem tudom, hogy ez mennyire aktuális, ugyanis a honlapja jól láthatóan egy régebbi design-ba illeszkedik, viszont az OTN-ről jelenleg is elérhető, ezért én úgy veszem, hogy az ott leírtak még ma is tükrözik az Oracle álláspontját :) De igazából nem is a konkrét részletek az érdekesek, hanem az eddig leírt részletes technikai problémák és megoldási javaslatok helyett három lépést hátralépve madártávlatból is megnézzük egy migráció folyamatát.

A folyamatban négy fő szerepkör lett definiálva:
  • Ügyfél
  • Migrációs projekt menedzser
  • Adatbázis migrációs mérnök
  • Alkalmazás migrációs mérnök

Az ügyfél feladata, hogy technikai segítséget nyújtson a migráció során az alkalmazással kapcsolatban felmerülő kérdésekben, ugyanis ebben a módszertanban a migrációt alapvetően az Oracle szakemberei végzik az ügyfél aktív közreműködésével. Ezen kívül a projekt elején ki kell tölteni egy úgynevezett Assessment Questionnaire-t, aminek célja az alapvető követelmények meghatározása, a szükséges erőforrások felbecsülése, a jelenlegi alkalmazás bemutatása. A kérdőívben olyan kérdések szerepelnek, mint például: "What business problems does your application system solve?" vagy "What is the timeframe for your current migration project?". Talán a "Select all of the technologies and languages used in your application system." kérdésre adható válaszlehetőségekből is látszik, hogy ezt a kérdőívet bizony nem ma írták, ugyanis a listában nem szerepel a C# .NET, sőt, a .NET egyedül ASP.NET kontextusban merül fel.

Az általános kérdések közé becsempésztek pár igen komoly - technológiai különbségekre utaló - kérdést is, ezek:
  • "Does your database or application system require any precision past seconds in the DATETIME column?": ez azért érdekes, mert az Oracle DATETIME adattípusa csak másodperc pontossággal képes az időt tárolni, míg SQL Serverben ez 3.33 ms.
  • "Does your database or application system evaluate empty strings ('') and NULLs as the same?": ugyanis Oracle alatt az üres string az NULL.

A kitöltött kérdőíven felül el kell küldenie az alkalmazás forráskódját is a migrációs projekt menedzsernek.

Igazából ezek egyszerű igen/nem kérdéseknek tűnnek, de ha mondjuk nekem kéne megválaszolnom őket, nem tudom, hány napig tartana a helyes válasz kiderítése.. Persze, ha valakinek olyan rendszerrel van dolga, ahol a legutolsó kis részlet is végletekig dokumentálva van, akkor más a helyzet.

A migrációs projekt menedzser áll a középpontban, ő biztosítja a magas minőségű munkát az Oracle részéről, illetve kezeli az ügyfél igényeit. Rajta keresztül zajlik a kommunikáció, ő tervezi meg a feladatokat, illetve azok időzítését. Magyarul ő a projekt menedzser, ennek minden feladatával és felelősségével együtt :)

Az adatbázis migrációs mérnök az Oracle Migration Workbench segítségével (akkor, amikor ezt a módszertant készítették, a Migration Workbench még egy különálló alkalmazás volt, most már az SQL Developer-be integrálták) migrálja a forrás adatbázist, és teszteli, hogy valóban úgy működik, mint az eredeti verzió.

Ehhez hasonlóan, az alkalmazás migrációs mérnök az alkalmazás megfelelő módosításaiért felelős.

A migráció 6 fő lépésből áll, melyeket az alábbi ábra szemléltet:


A definíciós fázisban kell elvégezni a meglévő rendszer részletes vizsgálatát, felmérni a feladat komplexitását, hogy meg lehessen becsülni a migrációs feladatokat, azok időtartamát.

Az analízis fázisban kezdődik az igazi munka. Egyeztetni kell az ügyféllel a definíciós fázisban felderített kérdéseket, problémákat, javaslatokat. Egy migráció során nem triviális, hogy az ügyfél mennyire ismeri a célrendszert, annak sajátosságait, a forrásrendszerrel szembeni különbségeit, ezért fontos feladat az oktatás. Az analízis fázisban kell meghatározni, hogy az ügyfélnek milyen témákban van szüksége oktatásra.

Ezen felül szükséges még az adatbázis biztonsági, adminisztrációs követelményeinek illetve biztonsági mentések és visszaállítások stratégiájának vizsgálata.

A tervezési fázis arról szól, hogy a definíciós és analízis fázis során szerzett ismeretek alapján megtervezzük a felmerült feladatok, problémák megoldását, azaz elkészítjük az oktatási tervet, a célrendszer hardver, hálózati és szoftver architektúráját, a felmerült architektúrális problémákra a megoldási terveket (például: ideiglenes táblák, séma-objektum nevekben történő változások, stb.), az adatok migrációjának a stratégiáját, átállási stratégiát, stb.

A migrációs fázis célja, hogy tömör, megbízható script-ek és riportok álljanak az ügyfél rendelkezésére, amikből felépítheti a célrendszer alatt az adatbázis sémát. Ebben a fázisban történik a tesztelés is.

Az átállás fázis - mint ahogy a nevéből is következik - az átállást hivatott megvalósítani, azaz a migrált rendszer feltelepítését, ügyfél általi tesztelését, adatkonverziót illetve élesbe állást.

Az utolsó, üzemeltetési fázisban szükség lehet, hogy a már feltelepített, éles rendszerben kell támogatást nyújtani az ügyfélnek.

3 megjegyzés:

    Szia!

    Lassan érdemes lenne a blog címét is megváltoztatni, hiszen egyre kevésbé írsz BI témákról :-)

    Lajos

     

    Nem! :)

    Igazából már gondolkozok a 48, de minimum 36 órás napok megszavazásán, nagyon kevés ez a 24 :)

    Rengeteg igen érdekes doksit bespájzoltam adattárházakkal kapcsolatos témákban, de eddig összvissz az egyik bitmap indexekről szólót sikerült félig elolvasnom, ennek az eredménye a legutolsó DW-s bejegyzés.

    És igazából nem csak azért nem hagynám annyiba a BI & DW témakört, mert érdekel, hanem mert az előző féléves önálló laboromat sem sikerült még befejeznem, aminek a témája meg pont az adattárházak tervezése, építése..

    Az mondjuk tény, hogy arra rájöttem, hogy a prezentációs réteg érdekel a legkevésbé, engem nem nyűgöznek le a grafikonok ;)

     

    OK, azzal semmi gondom, ha írsz BI és DW témáról is, de a blogod már ennél többről szól. Ami egyébként nagyon rendben van!