2000 októberétől lehetett hallani, illetve az interneten több helyen olvasni, hogy az IBM a DB2 adatbázis kezelőjét szeretné használhatóbbá, több, főként UNIX-os környezetből jobban elérhetővé tenni és ezáltal nagyobb piaci részesedéshez jutni. Kézenfekvőnek mutatkozott az Informix IDS motorjának megvásárlása. Egyrészt mert technológiailag ez állt legközelebb (közös gyökerek) az IBM DB2-jéhez. Másrészt, mert az Informix IDS adatbázis motorjában van néhány olyan fejlesztés, ami hatékony és az IBM-nek akkor nem volt ilyen technológiája. Beszélhetünk itt például a DataBlade-ekről, amelyekben létrehozott felhasználói adat típusok ugyanolyan hatékonysággal futnak, mint az egyszerű gyári adat típusok (pl. integer). Továbbá fontos tulajdonsága az Informix IDS-nek, hogy főként UNIX platformokon terjedt el és az utóbbi időben is vállalta a technológiai vezető szerepet. Más kérdés, hogy nem volt más választása, hiszen sokáig az adatbázis motor mellett nem készített alkalmazásokat, mint pl. az ORACLE.Néhány hónapra múlva a kósza hírek után kiderült, hogy az IBM ténylegesen felvásárolja az Informix-et.
Ennek egyrészt az lett a következménye, hogy az IBM tudhatja jelenleg magáénak a világ legnagyobb adatbázis piaci részesedését. Továbbá felmerült az a kérdés, hogy ténylegesen mi lesz az Informix termékeivel.
Természetesen a párhuzamos termékek már az elején kihaltak. Ilyen pl. a Java alapú Cloudscape, amit hajdanán még a SUN kezdett fejleszteni, majd később felvásárolta az Informix.
Az első kellemes meglepetés, hogy az IBM a 7-es verziójú IDS-t még további minimum 5 évig fejleszti. Ez azért érdekes, mert az Informix már fontolgatta a megszüntetését. A 9-es IDS verziót még minimum 10 évig fejleszti.
Miután az első kósza hírektől eltelt majdnem 2 év, ezért a figyelem mégis egyértelműen az új DB2 verzió megjelenésére összpontosult.
Az új főverzió kapcsán a következő főbb kérdések merültek fel:
* Az IBM DB2 termékével felvállalja-e a technológiai vezető szerepet, vagy sem?
* Mely funkciók voltak fontosak, amit az Informix termékeiből az IBM hasznosítani akart?
* Mennyire vállalja fel az IBM ezt a termék egyesítést?
Az IBM 2002 július 23-án jelentette be a DB2 objektum relációs adatbázis kezelő legújabb főverziójának, a 8-asnak a megjelenését. Kereskedelmi verzió IBM szokás szerint a 8.1-es, amelynek teszt változatát letölthetjük az IBM web oldalairól (http://www-3.ibm.com/software/data/db2/udb/v8beta.html).
A javításokat, továbbfejlesztéseket az IBM a következő képen csoportosította:
* Menedzselhetőség
* Teljesítmény javítás
* Elérhetőség
* Skálázhatóság
* Használhatóság
* Szervizelhetőség
* Replikáció
* Adattárház
* Alkalmazás fejlesztés
* Egyesített rendszerek
* Üzleti intelligencia
* DB2 család továbbfejlesztései
Ha a továbbfejlesztések mennyiségét nézzük, akkor a legtöbb változás sorrendben a menedzselhetőségben, az alkalmazás fejlesztésében, használhatóságban és a replikációban történt.
Következő csoportosítás lehet:
* Új fejlesztés
* Eredeti IBM javítás, továbbfejlesztés
* Informixből átvett javítás, továbbfejlesztés
Bár meg kell jegyeznem, hogy az Informixtól átvett fejlesztéseket többszörösen továbbfejlesztették. Ilyen például a drill-down módszerrel dolgozó grafikus monitorozó program, melynek érdekes továbbfejlesztése, hogy figyelmeztetést, hibaüzenetet csipogóra is el lehet küldeni.
Az újdonságok listája és azok rövid IBM szerinti leírása meglehetősen terjedelmes, ezért lássunk néhány érdekes példát a menedzselhetőség témaköréből, (A teljes anyag letölthető a következő címről: http://www-3.ibm.com/software/data/db2/udb/pdfs/db2q0.pdf ) illetve hogy az IBM DB2 termékei között el tudjunk igazodni, nézzük meg hogyan alakulnak a termék elnevezések:
Terméknév változások a 8-as verziójú DB2 Univerzal Database (DB2 UDB)-ben
A DB2 UDB Enterprise Edition (EE) és a DB2 UDB Enterprise-Extended Edition (EEE) termékeket egyesítették egyetlen termékbe, a DB2 UDB Enterprise Server Edition-ba (ESE). A képesség, hogy létrehozhatunk és üzemeltethetünk többszörös adatbázis partíciót része az ESE terméknek. Ha akarunk, létrehozhatunk többszörös adatbázis partíciót egy SMP szerveren vagy megtehetjük ugyanezt több fizikai szerveren keresztül (ahogyan a klaszterelt hardver konfigurációban). Ehhez csak ?separate database partitioning" típusú licencet kell vásárolnunk.
A DB2 UDB Workgroup Edition új neve DB2 UDB Workgroup Server Edition.
A DB2 UDB Satellite Edition 6-os verziója bekerült a DB2 UDB Personal Edition 8-as verziójába.
A DB2 OLAP Starter Kit megszünt, illetve funkcionalitása beépült a 8-as DB2 UDB verzióba.
További komponens helyettesítések és névcserék
A "Client Configuration Assistant" új neve "Configuration Assistant", mely egyben fontos további funkciókkal egészült ki.
A "Development Center" helyett a ?Stored Procedure Builder"-t használhatjuk. A ?Development Center" beolvadt a "Stored Procedure Builder"-be.
A "Performance Configuration" varázsló átnevezésre került. Az új neve "Configuration Advisor" és a "Workload Performance" varázsló új neve a "Design Advisor".
Nemzeti nyelvi támogatás
A kódlapok között megjelent a Unicode 3.1-es verziója és érdekes még, hogy az alapértelmezés szerinti valuta az Euro lett. Természetesen elérhetők a nem Euro-sított kódlapok, melyeket az IBM web lapjairól kell letölteni.
Betöltés kiterjesztések
A 8-as verziójú load segédprogramban történt néhány továbbfejlesztés, kiegészítés. Az új funkcionalitás egyszerűbbé teszik a betöltés folyamatát mind az egyszerű partíciókba, mind a több partíciós adatbázis környezetekbe.
A betöltési folyamatok most már áthelyeződtek a tábla szintjére, ami gyakorlatilag annyit jelent, hogy a load segédprogramnak nincs szüksége kizáró hozzáférési jogosultságra a tábla térhez és konkurens jogosultságra más tábla objektumokhoz azonos tábla téren belül a betöltés ideje alatt. A jövőben nincs szükség a betöltéshez az egy felhasználós rendszergazdai üzemmódhoz.
Következő új tulajdonság, hogy lehetőség nyílik betöltés alatt a már részlegesen betöltött adatok is részt vegyenek a lekérdezésben. Ezt a LOAD utasítás READ ACCESS opciójával tudjuk beállítani.
A LOCK WITH FORCE opció ebben a verzióban került bevezetésre. Amely egyrészt lehetővé teszi, hogy az alkalmazás erőszakosan vegye le a zárjait (lock) az adott tábláról, illetve a load művelet használhasson zárakat, ha szükséges.
Most már be tudjuk tölteni adatainkat partícionált és nem partícionált környezetben is azonos parancsokkal (LOAD, db2load) és API-k (db2load, db2LoadQuery) használatával. A továbbiakban nincs szükség az AutoLoader segédprogram és az AutoLoader kontroll fájl használatára.
Az új CURSOR fájl típus használatával be lehet tölteni az SQL utasítás eredményét az adatbázisba, anélkül, hogy az adatainkat először adat fájlba exportáltuk volna.
Tár menedzsment programok
A Storage Management már elérhető a Control Center segítségével. Ezzel az eszközzel pillanatfelvétel jellegű információkat kaphatunk az egyedi adatbázisról, az adatbázis partíciós csoportjáról vagy a tábla térről.
A statisztikai információkat periódikusan össze tudjuk gyűjteni és megjelenteni, attól függően, hogy mely objektumot választottuk ki:
* Tábla tér, az információ a rendszer katalógusból származik és monitorozhatók a táblák, az indexek és minden más elem, melyet az adott táblatérben definiáltak.
* Adatbázis vagy adatbázis partíciós csoport, információ elérhető az összes táblatérről, mely az adott adatbázishoz vagy adatbázis partíciós csoporthoz tartozik.
* Adatbázis információ az adatbázison belül az összes adatbázis partíciós csoportból.
A Storage Management-ben beállíthatunk a monitorozást segítő küszöb értékeket az eltérő adatokhoz, a használt területek és indexek kapcsán. A figyelmeztetés vagy hiba flag megjelenik, ha a rendszer eléri vagy meghaladja az adott küszöböt.
XBSA támogatás
A backup rendelkezik XBSA szabványos interfésszel, ezáltal lehetővé téve a különféle tárolási módszerek használatát.
A rendszer helyreállítása eltérő kód lappal
Lehetővé vált. Pl. a 819-es eredeti kód lap helyet 850-es kódlappal végezhetünk helyreállítást.
Tranzakció kezelés kiterjesztései
A korlátlan aktív tranzakciós log használata új a 8-as verzióban. Megengedi, hogy az elsődleges tranzakciós logok és az archív logok nagyon közel kerüljenek egymáshoz és így egy tranzakció korlátlan log fájl használhasson. A korlátlan aktív log nélkül a tranzakciós log az elsődleges tranzakciós log határáig nyújtózhat. A korlátlan aktív logot akkor célszerű használni, ha a kezelt adatmennyiség óriási és a szükséges log terület nagyobb, mint a lefoglalható maximális elsődleges log.
Több szerviz port használata UNIX-ban
A párhuzamos szerviz szintek támogatás biztosítja:
* Az új szerviz szint tesztelését, amíg egy eredeti szerviz szint folytatja a termék környezetének támogatását. Miután a szerviz tesztje befejeződött, az alkalmazás környezete átkapcsolható az új szerviz szintre.
* Különböző csoportok tudnak megosztani egy rendszert különböző kód szintekkel. Pl.: az egyik csoport folytatja az alkalmazás fejlesztését a DB2-ön, míg egy másik csoport egy új projektbe kezd a legutolsó szerviz szint használatával.
Csomagok verzió azonosítása
Ennek az opciónak az a célja, hogy meg tudják osztani a csomagok a sémát és a csomag azonosítót a meglévő rendszer katalógusban. Ez az opció biztosítja egy új csomag tesztelését és bevezetését, anélkül, hogy a felhasználók ezt érzékelnék. Tehát a végfelhasználói tevékenység megszakítása nélkül lehetséges a csomagok cseréje ezzel az opcióval.
Adatbázis karbantartási üzemmódja: QUIESCE
Az új QUIESCE parancs segítségével a felhasználókat gyorsan kiléptethetjük a példányból vagy adatbázisból és a quiesced módban elvégezhetjük a főbb karbantartási műveleteket.
A QUIESCE parancs kizáró hozzáférést biztosít a példányhoz vagy az adatbázishoz. És lezárja a felhasználók kapcsolatait anélkül, hogy az adatbázison kívülről meg kellene tennünk azt. (pl.: az összes tranzakciós menedzser leállítása).
A felhasználók csak korrekt hitelesítéssel kapcsolódhatnak az adatbázishoz. Az elcsendesített időtartamban rendszerkarbantartást végezhetünk a példányban vagy az adatbázisban. Adminisztrálás után az eredeti állapot helyreállítható az UNQUIESCE paranccsal és a felhasználók ismét kapcsolódhatnak a rendszerhez anélkül, hogy az adatbázist, példányt leállítottuk és újraindítottuk volna.
Monitorozó eszközök
A 8-as verzióval a DB2 bevezet 2 új eszközt, mely segít monitorozni a DB2-t. Ezek:
* Health Monitor és a
* Health Center
Ezek az eszközök kivétel kezelést biztosítanak a DB2 UDB hibakezeléséhez az egészséges rendszer potenciális megjelenésében. Ez a lehetővé teszi a gyanús állapotok jelzését, mielőtt a tényleges hiba megjelenjen és érintse a rendszer teljesítményét.
A Health Monitor szerver oldali eszköz, amely folyamatosan képes ellenőrizni, kivéve, ha a felhasználó megszakítja azt. Ha a Health MONITOR érzékeli a megadott küszöb elérését (pl.: az elérhető log terület nem elegendő) vagy előfordul egy objektum nem normális állapota (pl.: egy példány leáll), akkor a Health Monitor küld egy hiba üzenetet.
Két dolog történhet, amikor egy hiba előfordul:
* A hiba üzenet megjelenhet e-mail-ben vagy a rendszergazda csipogójának (pager) címén és ezzel lehetőséget biztosítva a rendszergazda beavatkozására.
* Végrehajthat előre definiált akciót. Pl.: futtat egy szkriptet vagy egy taszkot (megvalósítása a Task Center-ben).
A Health Center nyújt egy grafikus interfészt a Health Monitorhoz. A Health Center biztosítja a Health Monitor konfigurálását és megtekinthető a példányaink és adatbázis objektumaink előző hiba állapotai. A Healt Monitor drill-down módszere segítségével a megnyíló ablakokban részletesebb hibaüzeneteket kaphatunk illetve, hogy az egyes hibákat hogyan lehet lekezelni.
Ha követjük a hiba előfordulását és ennek kapcsán létrejönne egy adatbázis vagy paraméter változás az adatbázis menedzserben, akkor a rendszer felkínálja ezeknek a létrehozását, cseréjét, amelyet egyetlen gomb megnyomásával aktivizálhatunk. Egyéb esetben javasolja a probléma tanulmányozását egy figyelő eszközzel, mint pl.: a CLP-vel vagy az új Memory Visualizer felhasználásával.
A 8-as verzióban találunk egy új Web Health Center-t, melynek segítségével a Health Monitor információi elérhetők bármelyik Web browser segítségével vagy PDA-val.
Fájl vagy cső (pipe) helyet már SQL táblába is képes írni az esemény monitor.
A DB2 és a Tivoli integrációja
Amikor a DB2 8-as verzióját installáljuk, a Tivolihoz szükséges fájlok is létrehozásra kerülnek és így a Tivoli Inventory és a Discovery képes megvizsgálni a gépet és megkeresni a DB2-t.
A DB2 Tivoli Manager használható menedzselési célokra, beleértve a következőket:
* Minden szerver komponens elindítása és leállítása.
* Minden szerver komponens helyreállítása.
* Minden szerver komponens folyamat monitorozása.
* Ha egy alkalmazás gyűjt vagy küld eseményeket vagy hibákat egy esemény adapternek.
* Az összes desktop komponens szoftver disztribúciós fájl csomagjai.
* Az összes komponens leltári aláírása.
* A Tivoli Global Enterprise Manager (GEM) összehangolása (3-as szint) az összes alkalmazás szerver komponensel, hogy kapcsolatba léphessenek más alkalmazással.
* XPM (X Pixmap) formátumú ikon az alkalmazáshoz.
2-es típusú indexek
A 8-as verzió támogatja a 2-es típusú indexek használatát. A 2-es típusú indexek elsődleges használatának előnye:
* Javítja a párhuzamos felhasználást, mert a következő kulcs zárolás minimalizálva van. A legtöbb helyen a következő kulcs zárolást nem használják, mert az index lapról történő fizikai törlés helyet csak logikailag kerülnek törlésre.
* Az index lehet olyan oszlopokon, ahol a mező hossza nagyobb, mint 255 byte.
* A tábla csak 2-es indexszel rendelkezhet, mielőtt a táblát online átszervezzük és a táblába online módon akár többször nagy mennyiségű adat betöltést végzünk.
* Az új több dimenziós klaszter tulajdonsághoz szükség van a 2-es típusú indexre.
Átnevezett indexek
A DB2 megengedi, hogy indexeket átnevezzünk, amely mentéssel jár együtt. Az index átnevezés lehetővé teszi, hogy újraindexelés esetén először létrehozzuk az új indexet egy ideiglenes néven, majd a régi indexet töröljük és az új ideiglenes nevű indexet átnevezzük, melynek eredményeként a felhasználók nem veszik észre a teljesítmény csökkenést.
Összefoglalás
Nos, ami a termék egyesítést érinti, az IBM teljes egészében magára vállalja. Amilyen újdonságok vannak a 8-as verzióban című anyagban erre több helyen találunk utalást, illetve egyértelmű jelzést. Tehát nem véletlen, hogy az IBM az integrációt tűzte a zászlajára.
A technológiai vezető szerepben annyit mindenesetre tudunk, hogy az IBM-nél 4 ezer ember foglalkozott adatbázis fejlesztéssel. Ehhez csatlakozott az Informix 2 ezer fejlesztője. Tehát létszámban mindenképpen a világ jelenlegi legnagyobb adatbázis fejlesztő csoportját tudhatja magáénak az IBM.
Forrás www.ibm.com