DB2(oroszul „dibi two”-nak ejtik, szintén gyakori fordítás az angol „dibi tu”-ból) - család szoftver termékek az IBM információkezelésében.

A DB2-re hivatkozva leggyakrabban az IBM által kifejlesztett és kiadott DB2 Universal Database (DB2 UDB) relációs adatbázis-kezelő rendszert értik.

Néha látja a "DB/2" elírást, de ez az írásmód hibás: az IBM jelölésében a tört nevezőjében lévő szám a platformot jelenti, a "/2" pedig az OS/2 operációs rendszer termékét (vagy a PS/2 sorozatú számítógépek). Például a DB2 OS/2 verzióját "DB2/2"-nek nevezték el.

Megvalósítások

Jelenleg a DB2 DBMS a következő platformokon érhető el verziókban:

  • DB2 for Linux, UNIX és Windows v9 AIX, HP-UX, Linux, Solaris, Windows platformokhoz és béta Mac OS X platformhoz
  • DB2 for z/OS v9 z/OS és OS/390 platformokhoz
  • DB2 Server for VSE & VM v7 z/VM és z/VSE platformokhoz
  • DB2 for i IBM i platformhoz (a rendszerbe beépítve hardver és szoftver szinten)

Korábban a DB2 DBMS kiszolgáló verziói megjelentek OS/2, UnixWare és PTX rendszerekhez.

A DB2 DBMS kliensek a felsorolt ​​platformokon kívül SINIX, IRIX, klasszikus Mac OS és MS-DOS, valamint mobil verzió DB2 Everyplace Windows CE, Palm OS, Symbian OS, Neutrino és Virtuális gép Jáva.

Jelenleg a család kereskedelmi termékei mellett az IBM ingyenes disztribúciós készletet is forgalmaz DB2 Express-C Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 béta) platformokhoz. Ingyenes verzió korlátozások vonatkoznak arra, hogy legfeljebb egy kétmagos processzort és 2 GB-ot használjon a DBMS működéséhez véletlen hozzáférésű memória(a processzorok és a memória teljes száma a rendszerben tetszőleges lehet, de a megadott határokon túli erőforrásokat a DBMS nem használja fel).

Sztori

A DB2 hosszú múltra tekint vissza, és egyesek szerint ez az első SQL-t használó adatbázis-kezelő rendszer.

1975 és 1982 között az IBM-nél kifejlesztették a DB2 prototípusát System Relational vagy System R néven. Az SQL nyelvet először az IBM System R-ben implementálták, de ez a rendszer kutatási jellegű volt, és az Oracle volt az első, aki 1979-ben kiadott egy kereskedelmi terméket, beleértve az SQL-t is.

A DB2 nevét 1982-ben kapta, amikor megjelent az első kereskedelmi kiadás az SQL/DS-hez, majd az MVS-hez készült kiadás, DB2 néven. Hosszú ideig a „DB2” mellett a „Database 2” változatot használták, amely szintén az IBM védjegye. Nyilvánvalóan azt akarták mondani, hogy ez az IBM második zászlóshajója a régi hierarchikus IMS DBMS után.

A DB2 fejlesztése az 1970-es évek elejére nyúlik vissza, amikor az IBM-nek dolgozó Dr. E. F. Codd kidolgozta a relációs adatbázisok elméletét, és 1970 júniusában közzétett egy adatmanipulációs modellt. Ennek a modellnek a megvalósításához kifejlesztett egy relációs adatbázis-nyelvet, és Alfának nevezte el. Az IBM úgy döntött, hogy a további fejlesztést egy olyan programozói csoportra bízza, akik nem tartoznak Dr. Codd irányítása alá. A relációs modell egyes alapelveit megsértve „strukturált angol nyelv lekérdezések", a SEQUEL rövidítése. Mivel a SEQUEL már bejegyzett védjegy volt, a név lerövidült SQL-re – "Structured Query Language", és ez a mai napig így maradt.

Így a történelem során a DB2 a DB2 for MVS-ből (amely a DB2 for z/OS leszármazottja) és a testvére SQL/DS for VM-ből (amely a DB2 Server for VSE és VM leszármazottja) fejlődött ki. Ezt követően az IBM egy másik fejlesztői csapata megvalósította az OS/2 EE Database Manager kiszolgálót, amely ezt követően DB2 v2 for OS/2, AIX, majd Windows, majd DB2 UDB-vé (annak leszármazottja DB2 for Linux, UNIX és Windows) lett. . Egy másik csapat integrálta a DB2 architektúrát a beágyazott AS/400 adatbázisba (annak leszármazottja a DB2 for i). Az IBM fokozatosan halad ezen ágak integrálása felé.

Sajátosságok

NAK NEK megkülönböztető jellegzetességek A DB2 nyelvjárásra utal SQL nyelv, amely ritka kivételektől eltekintve meghatározza a nyelvi konstrukciók tisztán deklaratív jelentését, és egy hatékony többfázisú optimalizáló, amely hatékony lekérdezés-végrehajtási tervet készít ezekre a deklaratív konstrukciókra alapozva. Más SQL dialektusokkal ellentétben a DB2 SQL dialektusnak gyakorlatilag nincsenek optimalizáló tippjei, és gyengén fejlett (és hosszú ideje egyáltalán nem volt tárolt eljárásnyelv, így minden a lekérdezések deklaratív írási stílusának fenntartására irányult. A DB2 SQL nyelv számításilag teljes, azaz potenciálisan lehetővé teszi, hogy deklaratív formában meghatározza a forrásadatok és az eredmény közötti bármilyen kiszámítható megfelelést. Ez többek között táblakifejezések, rekurzió és egyéb fejlett adatkezelési mechanizmusok használatával érhető el.

Az IBM prioritása miatt a relációelmélet fejlesztésében és a cég számítástechnikai iparban elfoglalt pozíciója miatt a DB2 SQL dialektus jelentős befolyást gyakorol az ANSI/ISO SQL szabványokra.

A tárolt eljárásokat nem használják széles körben a DB2-ben, és hagyományos programozási nyelveket használnak a tárolt eljárások írásához magas szint(C, Java, PL/I, Cobol stb.), ez lehetővé teszi a programozó számára, hogy könnyen formázza ugyanazt a kódot akár egy alkalmazás részeként, akár egy tárolt eljárásként, attól függően, hogy célszerűbb-e végrehajtani a kliensen. vagy szerver. A DB2 mostantól az ANSI SQL/PSM szabvány szerinti eljárási SQL-bővítést is megvalósítja a tárolt eljárásokhoz.

A DB2 optimalizáló széleskörűen felhasználja az adatok táblákban való eloszlására vonatkozó statisztikákat (ha az összegyűjtési folyamatot az adatbázis-adminisztrátor végezte), így ugyanaz az SQL lekérdezés teljesen más végrehajtási tervekké fordítható le a statisztikai jellemzőktől függően. általa feldolgozott adatok.

Mivel a DB2 történelmileg a nagyszámítógépeken lévő többfelhasználós rendszerekből fejlődött ki, a DB2 architektúrában nagy figyelmet fordítanak a biztonsági kérdésekre és a DB2-specialisták szerepköreinek elosztására. Különösen sok más DBMS-től eltérően a DB2-nek külön szerepei vannak a DBMS rendszergazdának (a konfigurálásért felelős szoftver komponensek DB2 és azok optimális végrehajtása számítógépes rendszer) és egy adatbázis-adminisztrátor (egy adott adatbázisban lévő adatok kezeléséért felelős).

A statikus SQL használata és a csomagok koncepciója a programokban, ha szükséges, lehetővé teszi a legtöbb más DBMS-től eltérően egy olyan biztonsági modell megvalósítását, ahol bizonyos műveletek végrehajtására jogosítványokat lehet adni az alkalmazási programoknak ilyen jogok hiányában a dolgozó felhasználók számára. ezekkel a programokkal. Ebben az esetben ez lehetővé teszi annak biztosítását, hogy a felhasználó ne dolgozhasson az adatbázissal az alkalmazásprogramot megkerülve, ha csak a program futtatására van jogosultsága, de az adatok önálló manipulálására nincs jogosult.

A számítógépes rendszerek biztonsági integrációjának növelésére irányuló koncepció részeként a DB2 nem rendelkezik saját felhasználói hitelesítési eszközzel, amely integrálható az operációs rendszer eszközeivel vagy speciális biztonsági kiszolgálókkal. A DB2 csak a rendszer által hitelesített felhasználókat engedélyezi.

A DB2 az egyetlen általános célú relációs DBMS, amely hardver/szoftver implementációkkal rendelkezik (IBM i; az IBM System z nagyszámítógépes hardvere is megvalósítja a DB2 támogatást).

A DB2 modern verziói továbbfejlesztett támogatást nyújtanak az XML adatok használatához, beleértve az egyes XML dokumentumelemeken végzett műveleteket is.

Hiba a feldolgozásban

A DB2 SQL Server hasznos funkciója a hibakezelési képesség. Erre a célra az SQLCA struktúrát használjuk. SQL kommunikációs terület- SQL kommunikációs terület), amely az SQL kifejezés minden egyes végrehajtása után hibainformációt ad vissza az alkalmazásnak.

SQLCODE szerkezeti mezők és jelentésük

A hiba alapvető, de nem mindig hasznos diagnózisa a terepen található SQLCODE(adattípus - egész szám) egy SQLCA blokkon belül. A következő értékeket veheti fel:

  • A 0 sikert jelent.
  • A pozitív szám sikert jelent egy vagy több figyelmeztetéssel. Például a +100 azt jelenti, hogy nem található oszlop.
  • A negatív szám hibával járó sikertelenséget jelent. Például a −911 azt jelenti, hogy a rendszer lejárt zárolási időtúllépést (vagy holtpontot) észlel, ami visszaállítási szekvenciát vált ki.

SQLERRM(adattípus - 71 karakteres karakterlánc). Tartalmaz szöveges karakterlánc a hiba leírásával, ha az SQLCODE mező nullánál kisebb.

SQLERRD(adattípus - tömb, 6 egész szám). Leírja az utolsó SQL utasítás eredményét:

  • 1 elem - belső információ;
  • 2 elem - tartalmazza az INSERT utasítás SERIAL típusú mezőjének szerver által generált értékét, vagy egy további hibakódot;
  • 3 elem - egyenlő a feldolgozott rekordok számával;
  • 4. elem - az operátor végrehajtásának hozzávetőleges költsége;
  • 5. elem - hibaeltolás az SQL utasítás szöveges rekordjában;
  • 6. elem - belső információ.

Megjegyzések

Linkek

  • Programoldal az IBM webhelyén
  • DB2 on developerWorks – DB2 cikkek és oktatás
  • PlanetDB2 – DB2 blogok

Irodalom

  • Dátum K. DB2 Relational Database kézikönyv. - M.: Pénzügy és Statisztika, 1988. - 320 p. - ISBN 5-279-00063-9
  • Zikopoulos P.K., Backlarz J., deRus D., Melnick R.B. DB2 8-as verzió: A hivatalos útmutató. - M.: KUDITS-OBRAZ, 2004. - 400 p. - ISBN 5-9579-0031-1
  • Szmirnov S. N. Az IBM DB2 használata: oktatóanyag. - M.: Helios, 2001. - 304 p. - ISBN 5-85438-007-2 (a régió egyetemeinek oktatási intézményei ajánlják információ biztonság oktatási segédanyagként az „Automatizált rendszerek információbiztonságának átfogó biztosítása” és a „Számítógépes biztonság” szakokon.
  • Susan Visser, Bill Wong. Sams Tanítsd meg magad DB2 univerzális adatbázissal 21 nap alatt. - 2. kiadás - M.: Williams, 2004. - 528 p. - ISBN 0-672-32582-9
  • Hook J., Harbus R., Snow D. Univerzális útmutató a DB2 for Windows NT® rendszerhez. - New Jersey: Prentice Hall PTR, 1999. - P. 504. - ISBN 0-13-099723-4

Wikimédia Alapítvány. 2010.

Nézze meg, mi az "IBM DB2" más szótárakban:

    IBM DB2- Fejlesztő(k) IBM Kezdeti kiadás 1983 (1983) ... Wikipédia

    IBM DB2- A DB2 ist ein kommerzielles relációs Datenbank Management System (RDBMS) az IBM cégtől, az Ursprünge auf das System R und die Grundlagen von E. F. Codd vom IBM Research aus dem Jahr 1970 zurückgeht. Inhaltsverzeichnis 1 Eigenschaften 1.1… … Deutsch Wikipedia

    IBM DB2- Développeur IBM Dernière version … Wikipédia en Français

    IBM DB2 Commonstore- Az IBM által gyártott DB2 CommonStore Archiving szoftver e-mail üzenetek vagy SAP ERP adatok kezelésére. Az IBM Information Management portfólió része, amely a DB2 adatbázisplatformra épül. A DB2 CommonStore egyike azon termékeknek, amelyek... ... Wikipédia

A munkahelyemen egy ideig az IBM DB2 DBMS-sel kellett foglalkoznom. Mert Mivel a rendszer kereskedelmi jellegű, nem sok információ található oroszul az interneten, ezért úgy döntöttem, hogy leírom ennek a DBMS-nek néhány funkcióját.

Belépési pont

Kezdjük a DBMS belépési pontjával. SQL SZERVERBEN végpont egy példány, amely természetesen rendelkezhet külön adatbázisokkal, de a konfiguráció és a biztonsági modell ugyanaz a teljes példányra vonatkozóan. A DB2-ben a belépési pont így néz ki - egy példány (amely egy adott portnak felel meg) - egy adatbázis. Ebben az esetben a konfiguráció a teljes példányra és egy külön adatbázisra is elérhető.

A példány konfigurációját a db2 paranccsal tekintheti meg:

Adatbáziskezelő konfigurációja

Csomópont típusa = Enterprise Server Edition helyi és távoli ügyfelekkel

Adatbázis-kezelő konfigurációs kiadási szintje = 0x0b00

CPU-sebesség (ezredmásodperc/utasítás) (CPUSPEED) = 2,912790e-07
Kommunikációs sávszélesség (MB/s) (COMM_BANDWIDTH) = 1,000000e+02

Az egyidejűleg aktív adatbázisok maximális száma (NUMDB) = 8
Federated Database System Support (FEDERATED) = IGEN
Tranzakciófeldolgozó figyelő neve (TP_MON_NAME) =

Alapértelmezett visszaterhelési számla (DFT_ACCOUNT_STR) =

Java Development Kit telepítési útvonala (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Diagnosztikai hibarögzítési szint (DIAGLEVEL) = 3
Értesítési szint (NOTIFYLEVEL) = 3
Diagnosztikai adatok könyvtár elérési útja (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Alapértelmezett adatbázis-figyelő kapcsolók
Puffertár (DFT_MON_BUFPOOL) = KI

Ahol a paraméterek, jelentésük és értelmezésük feltüntetésre kerül. Rövidített változat is lehetséges:

szerezd be a dbm cfg-t

Vagy használja a kérést:

Válasszon nevet, értéket a sysibmadm.dbmcfg fájlból

Tól től fontos paramétereket megjegyezheti:

  • hitelesítés típusa (AUTHENTICATION)
  • alapértelmezett útvonal új adatbázisok létrehozásához (DFTDBPATH)
  • szerver felfedezés a hálózaton keresztül (DISCOVER)
Egy adott adatbázis beállításait így tekintheti meg:

csatlakozzon a mintához(minta - adatbázis neve)

lekérni az adatbáziskezelő konfigurációját

Vagy nagyjából ugyanazzal a kéréssel, mint korábban:

válasszon nevet, értéket a sysibmadm.dbcfg fájlból

Hitelesítés

A nagy különbség a DB2 és a többi DBMS között a hitelesítési modellje. Nincsenek belső felhasználók, mint az SQL Serverben vagy a MySQL-ben. Minden hitelesítés a DBMS-en kívüli eszközökkel (dinamikusan betöltött beépülő modulok) – operációs rendszer eszközeivel vagy külső beépülő modulokkal (Kerberos, GSS API) történik. A hitelesítés típusát az adatbázis-kezelő konfiguráció AUTHENTICATION paramétere határozza meg. Az alapértelmezett érték a SZERVER – a felhasználónév és a jelszó tiszta szövegben kerül továbbításra, és ennek a párnak a helyességét az operációs rendszer segítségével ellenőrzik. Ha a felhasználónév és a jelszó helyes, akkor a CONNECT jogosultság ellenőrzésre kerül a felhasználó vagy a hozzá tartozó csoportok esetében (beleértve a speciális NYILVÁNOS csoportot, amely magában foglalja az összes jogosult felhasználót). Ezek a jogosultságok a SYSCAT.DBAUTH táblában tekinthetők meg:

válassza a GRANTEE lehetőséget a SYSCAT.DBAUTH-ból, ahol CONNECTAUTH = "Y"

A beállítás során nagy hiba az KLIENS hitelesítési típus engedélyezése. Ebben az esetben a DB2 bízik a csatlakozó ügyfélben a hitelesítés végrehajtásában, és ha a PUBLIC rendelkezik CONNECT jogosultsággal, akkor bármely felhasználó csatlakozhat az adatbázishoz, és hozzáférhet a PUBLIC összes adatához. A felhasználónév az operációs rendszerből származik. Vagyis ha rendszergazdaként csatlakozunk a Data Studión keresztül, akkor a rendelkezésére álló összes jogosultság adott felhasználó. És ebben az esetben nem mindegy, hogy melyik számítógépről történt a hozzáférés. Ez a típus Javasoljuk, hogy csak akkor engedélyezze a hitelesítést, ha biztonságos csatorna van a kiszolgáló és az ügyfél között, és más ügyfelek nem tudnak csatlakozni a DBMS-hez.

Engedélyezés

A példányspecifikus jogosultságok az adatbázis-kezelő konfigurációjában vannak megadva. Ezek a következő jogosultságok:

  • SYSADM
  • SYSCTRL
  • SYSMAINT
  • SYSMON
Ezeket a jogosultságokat úgy állítják be, hogy megadják a csoportot, amelyhez a felhasználó tartozni fog. A dbmcfg-ben ezek a SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP és SYSMON_GROUP paraméterek.

Ezután vannak adatbázis-specifikus jogosultságok. Ezek olyan jogosultságok, mint az adatbázis elérése (CONNECTAUTH), táblák létrehozása (CREATETABAUTH), szubrutinok létrehozása (EXTERNALROUTINEAUTH) stb. Ezek a jogosultságok a SYSCAT.DBAUTH nézetben tekinthetők meg

És végül, hozzáférési jogosultságok bizonyos adatokhoz - táblákhoz, szubrutinokhoz stb. Itt minden meglehetősen triviális, de bizonyos sajátosságokkal is.

A tábla-hozzáférési jogosultságok a SYSCAT.TABAUTH nézetben tekinthetők meg. A megadott jogosultság típusát a rendszer külön oszlopokban tárolja, magától a jogosultságtól függően (SELECTAUTH, DELETEAUTH stb.). Amikor a GRANT paranccsal ad ki jogosultságot a REFERENCES és UPDATE jogosultságokhoz, megadhatja azoknak az oszlopoknak a nevét is, amelyekre ezek a jogosultságok vonatkozni fognak. Ebben az esetben az ezzel kapcsolatos információk a SYSCAT.COLAUTH nézetben tekinthetők meg

A rutinok (függvények, eljárások és metódusok) jogosultságai a SYSCAT.ROUTINEAUTH-ban tekinthetők meg. Itt minden nem teljesen triviális, a SPECIFICNAME és TYPENAME mezőktől függően egy adott séma összes alprogramjához jogosultság adható.

Ha az olvasóknak tetszik a cikk, akkor készen állok beszélni a DB2 adatvédelméről a címkealapú hozzáférés-vezérlés használatával

Alapfogalmak áttekintése és Általános leírása IBM DB2 DBMS architektúrák Linux, Unix és Windows platformokhoz

Tartalom sorozat:

Ez a tartalom a DB2 LUW áttekintése című cikk # sorozatának # része

http://www.?q=%D0%9E%D0%B1%D0%B7%D0%BE%D1%80+DB2+LUW&co=ru&lo=ru&ibm-submit.x=11&ibm-submit.y=13&sn= mh&lang=ru&cc=RU&en=utf&hpp=

Maradjon velünk a sorozat új cikkeivel kapcsolatban.

Forrásanyagokés elérhetőségei

Külön köszönet Mark Barinshteinnek a cikkek lektorálására fordított idejéért, a részletekre való odafigyeléséért és az értékes megjegyzéseiért.

A cikk anyagának nagy része szabad értelmezés hivatalos dokumentáció DB2. A bemutatott információkat átstrukturálták és újrafogalmazták, hogy tömörek és egyben a lehető legvilágosabbak legyenek. A felhasznált forrásokra mutató hivatkozások minden esetben megtalálhatók a cikkek szövegében és a „Források” részben.

Egy cikksorozat részeként a tervek szerint a következő kérdéseket tekintjük át:

  1. (az éppen olvasott cikk);
  2. (telepítés, konfiguráció, diagnosztika, biztonsági mentésés helyreállítás);
  3. fejlett adminisztrációs eljárások (információtovábbítás, teljesítményoptimalizálás, végrehajtási prioritások kezelése);
  4. eszközök analitikai adattárházak építéséhez;
  5. memórián belüli elemzési technológiák - DB2 BLU;
  6. masszívan párhuzamos analitikai adatfeldolgozás DB2 DPF-fel (adatbázis-particionálási szolgáltatás);
  7. elosztott adatbázisok (hibatűrő konfigurációk, adatreplikáció és egyesített adathozzáférés);
  8. A DB2 pureScale fürt konfigurációs képességei a hibatűrés és a méretezhetőség érdekében.

A sorozat cikkei a vonatkozó anyagok elkészítésekor jelennek meg.

DB2 termékcsalád

A „DB2” nevet az IBM egy egész termékcsaládra használja, amelyek mind a hardver- és szoftverplatformok összetételében, mind a funkcionalitásban, az architektúrában és a technológiai jellemzőkben különböznek egymástól. Ezek a különbségek a legtöbb képességekkel rendelkező DB2 termékcsalád szoros integrációjából fakadnak operációs rendszer amelyben működnek, valamint ezen operációs rendszerek sajátosságait.

A DB2 termékcsalád jelenleg a következőket tartalmazza:

  • DB2 for Linux, Unix és Windows, vagy DB2 LUW – egy adatbázis-kezelő rendszer Linux operációs rendszerrel (RedHat, SuSE, Ubuntu), UNIX-szal (AIX, HP-UX, Solaris) és Microsoft Windows rendszerrel, amely ennek a cikknek és a sorozat más cikkeinek tárgya;
  • DB2 for z/OS- DBMS az IBM System z nagyszámítógépeken használt z/OS operációs rendszerhez;
  • DB2 Server for VSE & VM- DBMS az operatív z/VM és z/VSE számára, IBM System z nagyszámítógépeken használatos;
  • DB2 for i- DBMS az IBM Power platformon használt System i operációs rendszerhez.

A felsorolt ​​DBMS-ek mindegyike architekturálisan a megfelelő operációs rendszerek leghatékonyabb működéséhez van igazítva, és saját speciális eszköz- és adminisztrációs eszközkészletet tartalmaz.

A dokumentációban a különböző DB2 család DBMS-eihez használt terminológia nem egységes, és a DB2 különböző verzióihoz ugyanazok a kifejezések eltérő jelentéssel használhatók: például az „adatbázis” és a „táblaterület” kifejezések eltérő jelentéssel bírnak a DB2 LUW és DB2 for z/OS, ami az ilyen típusú DBMS-ek közötti architekturális különbségeknek köszönhető.

Ezért, amikor a DB2-vel kapcsolatos információs erőforrásokkal dolgozik, fontos egyértelműen megkülönböztetni, hogy a család melyik termékéről van szó, hogy elkerülje a félreértéseket és az esetleges hibákat.

Elavult DB2 LUW funkciók

A DB2 LUW termék ilyen vagy olyan formában 1989 óta van a piacon (az OS/2 1.10 Extended Edition operációs rendszer kiadásának éve, amely magában foglalta a Database Manager komponenst - vagyis a relációs DBMS-t, amely az alapját képezte DB2 LUW).

A termék hosszú fejlesztése során az eredetileg kifejlesztett funkciók egy részét újragondolták és más megvalósításra cserélték, vagy szükségtelenség miatt teljesen kizárták a termékből. Ezért, ha a DB2 régebbi verzióihoz (például a 9.7-es verzióhoz) készített anyagokkal dolgozik, vegye figyelembe, hogy az ezekben az anyagokban leírt funkciók némelyike ​​lecserélhető a DB2 újabb verzióira (például 10.5 és 11.1). A kizárt és lecserélt funkciókról részletes információ található.

A rendszergazdák és fejlesztők számára leginkább észrevehető változások a következők:

  • elavult grafikus kezelőeszközök „Control Center”, „Task Center” és számos más cseréje a szabadon terjesztett IBM Data Studio csomag funkcióival, valamint az IBM Data ingyenes kiadásában található eszközök funkcióival Server Manager termék;
  • A régi adminisztrációs eszközök futtatásához szükséges DB2 Administration Server (DAS) megszüntetése;
  • a munkaterhelések kezelésére szolgáló DB2 Governor és Query Patroller eszközök cseréje a DB2 Workload Manager (DB2 WLM) funkcióival.

A cikksorozat elkészítésének célja

Az IBM DB2-ről szóló áttekintő cikksorozat megírásának fő célja az e témával kapcsolatos orosz nyelvű anyagok hiányának pótlása. Valójában annak ellenére, hogy a dokumentáció jelentős részének elérhető orosz nyelvű fordítása és a DB2-ről elérhető könyvek, még mindig hiányoznak az olyan áttekintő információk, amelyek lehetővé tennék az érdeklődő olvasók számára, hogy képet kapjanak a DB2 beépített képességeiről. a funkcionalitás és az adminisztráció sajátosságaiban.

A szerző nem kíván áttekintést adni az összes DB2 termékcsaládról (lásd a "DB2 termékcsalád" oldalsávot), ehelyett a DB2 működési területére kíván összpontosítani. Linux rendszerek, Unix és Windows - pl. a DB2 LUW terméken.

Az érdeklődő olvasóknak gyakorlati útmutató A DB2 használatának megkezdéséhez azt javaslom, hogy forduljon az orosz nyelvre lefordított "" szabadon terjesztett könyvhöz. Ez a könyv számos példát mutat be a gyakori DB2 szoftverműveletekre, megkönnyítve ezzel a könyvben ismertetett DB2 9.7-es verziójával és az újabb DB2-verziókkal (10.5-ös és 11.1-es) való kezdést. Amikor a jelenlegi verziókkal dolgozik szoftver A DB2-nek tisztában kell lennie azzal, hogy a 9.7-es verzió egyes funkciói elavultak, és a termék újabb verziói nem támogatják (lásd az „Elavult DB2 LUW-szolgáltatások” oldalsávot).

DB2 LUW funkció

Az IBM DB2 a jelenleg elfogadottat használja kliens-szerver architektúra relációs DBMS, információ tárolásával a kiszolgálón és ügyfélalkalmazások adatbázisokhoz való csatlakozásával helyileg vagy hálózaton keresztül.

Az egyidejűleg futó alkalmazások adataihoz való egyidejű hozzáférés biztosítása érdekében a DB2 zároláson és tranzakciónaplózáson alapuló tranzakciós motort használ, és szabványos ACID (atomosság, konzisztencia, izoláció, tartósság) garanciákat biztosít. Ez a mechanizmus hosszú fejlődésen ment keresztül, hogy biztosítsa a maximális teljesítményt, megbízhatóságot és minimalizálja az alkalmazás-végrehajtási késéseket.

A DB2 támogatja az összes általános iparági szabványt az alkalmazások adathozzáférésére vonatkozóan, beleértve a szabványos nyelvet is SQL lekérdezések, ODBC és JDBC interfészek, szabványos szövegtábla formátumokkal való munka stb. Ezenkívül a DB2 fejlett képességekkel rendelkezik a félig strukturált adatok tárolására és kezelésére XML formátumok, JSON/BSON. A DB2 számos eljárási nyelvet támogat a tárolt eljárások fejlesztéséhez, beleértve:

  • DB2 szabványos SQL PL nyelv,
  • az Oracle DBMS-ben használt SQL/PL nyelv,
  • „külső” tárolt eljárások fejlesztésének képessége Java, C, C++ és COBOL nyelven.

A DB2 megkülönböztető jellemzői a következők:

  • méretezhetőség, amelyet csak a rendelkezésre álló számítási erőforrások korlátoznak, és a számítási erőforrások leggazdaságosabb felhasználása;
  • hatékony beépített hozzáférés-vezérlési és hozzáférés-vezérlő eszközök, amelyek lehetővé teszik az információkhoz való hozzáférés részletes korlátozását az objektumok (táblázatok, nézetek) kontextusában, valamint kötelező hozzáférés-vezérlési modell megvalósítását;
  • integrált adatmentési és helyreállítási rendszer fejlesztése;
  • a technológia teljes készletének rendelkezésre állása a „klasszikus” analitikai adattárházak felépítéséhez (táblák szakaszokra osztása, materializált nézetek, adatgyorsítótárazás, táblák és indexek optimalizálása, „belső” párhuzamosság összetett lekérdezések végrehajtásában stb.);
  • támogatja a tömegesen párhuzamos analitikai adatfeldolgozás (MPP) konfigurációinak létrehozását több kommunikációs hálózaton keresztül csatlakoztatott szerverről, a DB2 Database Partitioning Feature (DB2 DPF) alapján;
  • A DB2 pureScale fürtkonfigurációk maximális hibatűrése és közel lineáris skálázása megosztott lemezeken tárolt adatokkal;
  • DB2 BLU technológia, amely az adatbázis-struktúra manuális optimalizálása nélkül valósítja meg a modern, memórián belüli „oszlop alapú” elemzést.

Az alkalmazások más típusú DBMS-ekből (elsősorban Oracle Database) történő áttelepítésének megkönnyítése érdekében a DB2 fejlett kompatibilitási eszközöket biztosít, beleértve a szükséges adattípusok, tárolt eljárások és szabványos rendszernézetek támogatását.

A DB2 LUW terméknek több kiadása is létezik, amelyeket egyetlen alapvető funkciókészlet egyesít, és a használt számítási erőforrásokra vonatkozó korlátozások és a fejlett funkciók támogatása tekintetében különböznek egymástól. Az ingyenesen elérhető DB2 Express-C kiadással kipróbálható a termék, felfedezhető, és akár kisebb termelési konfigurációk is üzembe helyezhetők. A DB2 LUW különféle kiadásainak funkcionalitását és erőforrás-korlátait a "" cikk részletesen ismerteti.

Adatbázis szerver struktúra

A DB2 adatbázis-kiszolgáló olyan számítógép, amelyre a DB2 kiszolgálószoftver (DB2 motor) telepítve van, és amely strukturált információkezelési szolgáltatásokat nyújt.

A DB2 szolgáltatásokhoz való alkalmazás-hozzáférést a DB2 ügyfélszoftver (IBM Data Server Driver Package) biztosítja, amely támogatott alkalmazáscsatlakozási módok (ideértve az ODBC, JDBC, OLE DB, ADO, CLI és egyéb módszerek) használatával kommunikál a DB2 kiszolgálóval. A legtöbb esetben a szükséges ügyfélszoftver a DB2 kiszolgálóval együtt telepítve van, így az adatbázis-kiszolgálón közvetlenül tárolt alkalmazások csatlakozhatnak a DB2 kiszolgálóhoz.

A DB2 adatbázis-kiszolgáló a DB2 szoftver több példányát is tárolhatja, a szoftververzióktól és a telepítési könyvtáraktól függően. A DB2 szoftver több példánya is tárolható egymástól függetlenül ugyanazon a kiszolgálón mindaddig, amíg nincsenek erőforrás-ütközések közöttük (beleértve az elegendő kiszolgáló számítási erőforrást és az operációs rendszer logikai erőforrásaival kapcsolatos ütközéseket, mint például a hálózatnevek, portszámok, fájlrendszer-könyvtárak stb. . ).

A DBMS szolgáltatások közvetlen biztosítását a DB2 adatbázis-kezelő (DB2 DBM) összetevő biztosítja. Minden másolat tartalmazhatja a DB2 adatbázis-kezelő több példányát, vagy rövidebben: DB2 példányokat. A példány egy független környezet, amelyben adatbázisok hozhatók létre és alkalmazások futhatnak. Minden DB2-példány saját konfigurációval rendelkezik, és hozzáférést biztosít egy adott adatbázis-készlethez. A DB2 példányok függetlenek abban az értelemben, hogy az egyik példányon végrehajtott műveletek nincsenek hatással a többire, kivéve azokat az erőforrás-korlátozásokat, amelyeket több példány futtatása okoz ugyanazon a fizikai vagy virtuális kiszolgálón.

A DB2 szolgáltatások indítása és leállítása példány szinten történik, azaz. Minden DB2 példány lehet futó vagy leállított állapotban. A DB2 példány paraméterei meghatározhatják az erőforrás-korlátozásokat (például a memóriahasználatot). A DB2 példány erőforrásait a példányon belüli meglévő adatbázisok karbantartására használják.

Az adatbázis olyan objektumok gyűjteménye, amelyek egyetlen információs tömböt alkotnak (táblázatok, nézetek, indexek stb.). Az adatbázisok független egységek, és ennek megfelelően általában nem osztanak meg objektumokat más adatbázisokkal (kivételt képezhetnek az elosztott adatbázis-konfigurációk, amelyek adatelérési összevonási mechanizmusokat használnak).

Az ábrán látható egy sematikus példa az adatbázis-kiszolgáló felépítésére.


A DB2 adatbázis-kiszolgáló sok esetben a DB2 egyetlen példányát tartalmazza, egyetlen példányban, amely egyetlen adatbázist szolgál ki. Ezzel a konfigurációval az adatbázis-kiszolgáló összes erőforrása egyetlen DB2 adatbázis támogatására szolgál.

Az adatbázis-kiszolgáló oldalon a csatlakoztatott alkalmazásoktól érkező kiszolgálási kéréseket úgynevezett DB2 ügynökök hajtják végre. Minden csatlakoztatott alkalmazáshoz egy DB2-példány egy koordinátor (elsődleges) ügynököt futtat, amely szükség szerint több további (másodlagos) ügynököt is futtathat. Technikailag minden ügynök külön végrehajtási szál, vagy (a DB2 régebbi verzióinál) egy külön operációs rendszer-folyamat, a futtatásához szükséges erőforrásokkal.

DB2 konfigurációs beállítások

A DB2 kiszolgáló négy különböző szinten konfigurálható:

  • Környezeti változók;
  • DB2 profilnyilvántartás;
  • adatbázis-kezelő konfigurációs fájl (DBM CFG);
  • adatbázis konfigurációs fájl (DB CFG).

A környezeti változók beállítása a szerver operációs rendszer szintjén és az operációs rendszer eszközei szerint történik. Windows operációs rendszer esetén ezek a változók valójában globálisak a kiszolgáló számára; a Unix és a Linux család operációs rendszerei esetében minden példány saját környezeti változó-beállításokkal rendelkezhet.

A DB2 profilnyilvántartási beállításai az operációs rendszer szintjén (globálisan) vagy példányszinten állíthatók be, a példányszintű beállítások felülírják az operációs rendszer szintjén meghatározott értékeket. A db2set paranccsal megtekintheti és beállíthatja a DB2 profil regisztrációs paramétereit.

Az adatbázis-kezelő konfigurációs fájl paraméterei a példány szintjén, az adatbázis konfigurációs paraméterei pedig az adatbázis szintjén vannak meghatározva.

Sok paraméter dinamikus, azaz a végrehajtott változtatások azonnal életbe lépnek; azonban vannak olyan beállítások, amelyek megváltoztatásához le kell állítani és elindítani a példányt. Ez megtehető a parancssorban a db2stop és db2start paranccsal. A példány leállítása előtt minden alkalmazást le kell tiltani. Egy példány leállítására a db2stop force parancs használható.

Az adatbázis-kezelő konfigurációs fájlja olyan beállításokat tartalmaz, amelyek hatással vannak a példányra és a benne lévő összes adatbázisra. Az adatbázis-kezelő konfigurációs fájlja megtekinthető vagy módosítható a segítségével parancs sor(a GET DBM CFG és az UPDATE DBM CFG parancsok használatával), valamint az IBM Data Studio eszközök használatával.

Az adatbázis-konfigurációs fájl olyan beállításokat tartalmaz, amelyek egy adott adatbázist érintenek. Az adatbázis konfigurációs fájl megtekinthető vagy módosítható a parancssor (GET DB CFG és UPDATE DB CFG parancsok) és az IBM Data Studio eszközök használatával.

A támogatottak részletes leírása a hivatalos DB2 dokumentációban is megtalálható.

Adattárolás szervezése

A DB2 legkisebb fizikai tárolóegysége az oldalon. Az elfogadható oldalméretek: 4 KB, 8 KB, 16 KB és 32 KB. Az adatbázis-objektum-információk (például táblarekordok és indexbejegyzések) az oldalakon kerülnek elhelyezésre.

A további adattárhely lefoglalását a megnevezett oldalcsoportok foglalják le kiterjedések. További területfoglalási műveletek kiterjedési szinten történő végrehajtása javítja a rekordbeszúrási és -frissítési műveletek teljesítményét.

A DB2 adatbázisok információkat tárolnak a meghívott objektumokban asztalterek. A táblaterület az adatbázis-kiszolgáló fájlrendszerén található információk tárolására szolgáló, elnevezett konténerek halmaza.

Minden asztalterülethez egy vagy több konténerek(fájlok vagy könyvtárak a fájlrendszerben) az információk tárolására, valamint beállítja az oldalméretet és az adatgyorsítótárazás területét (pufferkészlet, lásd alább), valamint számos egyéb paramétert.

A következő típusú táblaterületek léteznek:

  • rendes: felhasználói táblák és indexek tárolására szolgál;
  • nagy: Egyéni táblák és indexek, valamint nagy objektum (LOB) adatok és XML adatok tárolására szolgál. A DB2 modern verzióiban alapértelmezés szerint nagy táblaterületek használatosak a normál táblaterületek helyett;
  • ideiglenes: Ideiglenes információk tárolására szolgál a lekérdezés végrehajtásához (rendszerbeli ideiglenes táblaterületek) és alkalmazás által meghatározott ideiglenes táblákhoz (felhasználói ideiglenes táblaterületek).

A táblaterület típusát a létrehozáskor adják meg, és csak a táblaterület törlésével és újbóli létrehozásával módosítható.

A táblaterületek a táblaterület létrehozásakor telepített vezérlő típusa szerint is osztályozhatók:

  • rendszer által kezelt táblaterületek (SMS, System Managed Storage) – a könyvtárakat táblaterület-tárolóként használják; adatfájlok jönnek létre a tárolóobjektumok könyvtárakba helyezésére. A terület nincs előre lefoglalva, és a fájlok dinamikusan nőnek. Ha definiálják, a konténerek a létrehozáskor rögzítve vannak;
  • adatbázis-felügyelt táblaterületek (DMS, Database Managed Storage) – előre lefoglalt fájlok táblaterület-tárolóként használhatók, tárolók hozzáadhatók, törölhetők vagy módosíthatók;
  • automatikusan kezelt táblaterületek (automatikus tárhely) – egy konténer típusának és elhelyezésének automatikus meghatározása a táblaterület típusától függően (DMS normál és nagy táblaterületekhez, SMS ideiglenes táblaterületekhez). A táblaterület létrehozásakor nincsenek megadva konkrét tárolódefiníciók, a szükséges tárolók automatikusan létrejönnek. A meglévő tárolók növekedését és az új tárolók hozzáadását teljes mértékben a DB2 kezeli.

Az automatikus táblaterület-kezelés engedélyezéséhez először létre kell hoznia egy adatbázist, amelyben engedélyezve van az automatikus tárolás (alapértelmezett), és hozzá kell társítania a tárolási útvonalakat.

Alapértelmezés szerint a DB2 szekvenciális írásokat hajt végre a tárolók közötti sávozással. Például, ha van egy táblaterülete 4 KB oldalmérettel és 8 oldal terjedelmű, és 3 közvetlen konténer van a DMS típusú táblaterületen, ez azt jelenti, hogy 32 KB adat (terjedelemenként 4 KB x 8 oldal). = 32 KB) egy lemezre íródik, mielőtt a következőn elkezdődik.

A DB2 10.1-es verziójától kezdve egy új koncepciót vezettek be a tárolókezelés egyszerűsítésére - tárolási csoport(tároló csoport). Az adattároló csoport a DBMS-kiszolgáló fájlrendszerében található útvonalak elnevezett gyűjteménye, amely adatok tárolására használható. Az adatbázisban lévő tárolócsoportok összetétele általában meghatározza az információ tárolására rendelkezésre álló tárolóeszközök típusát. Amikor létrehoz egy adatbázist, abban mindig automatikusan létrejön egy alapértelmezett tárolócsoport.

Minden automatikusan kezelt táblaterület hozzá van rendelve az egyik létrehozott tárolócsoporthoz, amely meghatározza a megfelelő táblaterületeken tárolt adatok fizikai helyét. Lehetőség van egy táblaterület áthelyezésére egyik tárolócsoportból a másikba az ALTER TABLESPACE ... USING STOGROUP ... paranccsal.

Tranzakciónaplózás

Az IBM DB2 LUW a legtöbb más modern relációs DBMS-hez hasonlóan, amely ACID garanciákat nyújt, a tranzakciós naplót használja e követelmények megvalósításának egyik fő mechanizmusaként.

A DB2 által végrehajtott adatmódosítási műveletek naplóbejegyzések sorozataként kerülnek rögzítésre a tranzakciós naplóban. Minden adatbázis saját tranzakciós naplót vezet, amely a lemezen lévő fájlok sorozata. Egyetlen fájl méretét a LOGFILSIZ paraméter, a száma határozza meg létrehozott fájlokat a LOGPRIMARY paraméter határozza meg. Ha szükséges, a DB2 létrehozhat további fájlok log, a létrehozott fájlok maximális számát a LOGSECOND paraméter szabályozza.

Az információkat a tranzakciós naplóban rögzítik a RAM-ban található speciális puffer segítségével. A puffer tartalma a lemezre (tranzakciós naplófájlokba) kerül kiürítésre a puffer feltöltésekor, valamint a tranzakciók megerősítése és törlése esetén (alkalmazásparancs vagy az alkalmazáshoz fűződő kapcsolat váratlanul megszakadásakor).

A hiba utáni adatok helyreállításához szükséges tranzakciós naplófájlt aktív naplófájlnak nevezzük. Az aktív tranzakciós naplófájloknak mindig elérhetőnek kell lenniük a DB2 adatbázis-kezelő számára. Mivel a tranzakciós naplófájlok elérhetősége kritikus fontosságú a DBMS működőképességének biztosításához, egy mechanizmus biztosított a tranzakciós naplók tükörtárolására két részben. fájlrendszerek(a LOGMIRROR paraméterrel konfigurálva).

Ha a tranzakciós naplófájlok mérete és száma helytelenül van kiválasztva, és nem felel meg az aktuális terhelés szintjének, a tranzakciós napló túlcsordulása lehetséges a létrehozáshoz nem elegendő számú naplófájl vagy az elérhető fájlok hiánya miatt. lemez terület. Az adatbázis-beállításoktól függően (lásd a BLK_LOG_DSK_FUL paramétert) előfordulhat, hogy az alkalmazások hibaüzenetet küldenek vissza, vagy a feldolgozás felfüggeszthető, amíg a rendszergazda meg nem oldja a helyzetet.

Olyan helyzetek is előfordulhatnak, amikor a tranzakciós napló megtelt, olyan régóta futó tranzakciók esetén, amelyek adatmódosítási műveleteket hajtanak végre. Még ha egy ilyen régóta futó tranzakció egyetlen apró változtatást is végrehajt az adatbázisban, amely hosszú ideig nem véglegesít, a megfelelő tranzakciós naplófájl aktív marad, és nem használható fel újra.

A DB2 tranzakciós naplóval való munka két fő módja van: körkörös naplózás és archív naplózás. Körkörös naplózási módban a DB2 végigfut a tranzakciós naplófájlok generált készletén. Archív naplózási módban a DB2 emellett a tranzakciós naplófájlokat is átmásolja az archívumba a LOGARCHMETH1 és LOGARCHMETH2 paraméterek által meghatározott metódusokkal.

A ciklikus naplózási mód biztosítja az adatbázis integritásának visszaállítását DBMS-kiszolgáló összeomlása esetén. Egy ilyen adatbázis biztonsági mentése csak az összes alkalmazás letiltása (azaz a felhasználói hozzáférés felfüggesztése) után lehetséges. Adatok helyreállítása innen biztonsági másolat Ez csak akkor lehetséges, ha visszaállítja az adatbázist a biztonsági mentés időpontjában volt állapotba.

Az archív naplózási mód biztosítja az adatbázis integritásának visszaállítását DBMS-kiszolgáló összeomlása esetén is. Ezenkívül biztonsági másolatot készíthet az adatbázisról a felhasználói hozzáférés megszakítása nélkül, és az aktív naplófájlokat (az adatok integritásának visszaállításához szükséges) is belefoglalhatja a biztonsági mentésbe. Az adatok biztonsági mentésből történő visszaállítása kiegészíthető a biztonsági mentés után az adatbázisban végrehajtott módosítások alkalmazásával, és az adatbázisnak a múltban kiválasztott időpontban (de legkorábban a biztonsági mentés készítésének pillanatában) történő állapotba hozásával.

Az archiválási naplózási mód további erőforrásokat igényel az archiválási műveletek végrehajtásához, beleértve a megnövelt I/O műveleteket és a további lemezterületet az archivált tranzakciós naplófájlok tárolására.

Adatgyorsítótár szervezése

A végrehajtott I/O műveletek számának csökkentése érdekében a DB2, más modern relációs DBMS-ekhez hasonlóan, gyorsítótárazza a táblaterületeken végrehajtott olvasásokat és írásokat. A gyorsítótárazás a RAM pufferkészleteknek nevezett területeinek használatával történik. A DB2 több különböző puffertárat tud meghatározni (a CREATE BUFFERPOOL paranccsal létrehozva), meghatározva az oldal méretét, méretét és azt, hogy a méret automatikusan szabályozható-e. Minden táblaterület egy adott puffertárhoz van hozzárendelve, és egy puffertár megosztható több táblaterület között.

Olvasási művelet végrehajtásakor a puffertárban először megkeresi a kívánt adatlapot. Ha megtalálja a kívánt oldalt, a rendszer beolvassa az adatokat a puffertárból, ellenkező esetben az oldal betöltődik a lemezről a puffertárba. Az oldalak aszinkron előzetes letöltésére szolgáló mechanizmust biztosítanak a puffertárba, ha az oldal-hozzáférés lineáris (megjósolható) jellegét észleli. Az előzetes letöltési mechanizmus sok esetben lehetővé teszi a szükséges adatok lemezről történő olvasási műveleteinek várakozási idejének csökkentését az olvasás aszinkron módban történő végrehajtásával.

Írási művelet végrehajtásakor az oldalfrissítések közvetlenül a puffertárban történnek. Ebben az esetben az oldal nem szinkron módban kerül lemezre, és az adatbiztonságról a tranzakciónaplózási mechanizmus gondoskodik. A változó táblaterület-oldalak aszinkron módon, a háttérben íródnak a lemezre, és ésszerűen minimalizálják az adatbázis állapotának visszaállításához szükséges munkát vészhelyzeti (helytelen) bezárás esetén. Az adatbázis helyes bezárása (például a DBMS-kiszolgáló normál leállítása során) biztosítja, hogy az összes pufferkészlet összes módosított oldala a lemezre kerüljön.

RAM használat

A DB2 memóriamodell a következőkből áll különböző területeken memória a DB2 példány, adatbázis, alkalmazás és ügynök szintjén.

A DB2 memóriaterületek részletes leírását az alábbiakban mutatjuk be Rövid leírás célpontok különböző területekre.

A fő DB2 memóriaterületek listája az alábbi ábrán látható (eredetileg innen származik).

A DBMS-példány által használt megosztott memória a következőket tartalmazza:

  • Monitor Heap – memóriaterület a műveletek és állapot figyelésére, a méretet a MON_HEAP_SZ paraméter szabályozza;
  • FCM pufferek – memóriaterület a koordináló ügynök és al-agensei közötti interakcióhoz, valamint a particionált adatbázisok belső interakcióinak biztosításához;
  • Audit Buffer – egy memóriaterület, amelybe az ellenőrzési rekordok kerülnek, mielőtt kiürítik őket a naplóba.

Az adatbázis szintjén szokás megkülönböztetni:

  • egy globális adatbázis-terület, amelyet gyakran "Teljesítménymemóriának" neveznek, amely különféle gyorsítótárazási területeket és zárolási területet foglal magában;
  • Az alkalmazásadat-terület, amelyet gyakran "Funkcionális memóriaként" is emlegetnek, amely magában foglalja az adatbázis-kapcsolatokat kiszolgáló ügynökök különböző munkamemória-területeit.

A globális adatbázis terület a következő fő összetevőkből áll:

  • Buffer pools – puffer poolok, azaz területek a táblaterületi adatok gyorsítótárazásához;
  • Zárlista – a zárakkal kapcsolatos információk tárolására szolgáló terület, amelyek méretét a LOCKLIST paraméter szabályozza;
  • Csomaggyorsítótár – a lekérdezés-végrehajtási tervek gyorsítótárazására szolgáló terület, a méretet a PCKCACHESZ paraméter szabályozza;
  • Katalógus gyorsítótár – a rendszerkatalógus gyorsítótárazására szolgáló terület, amely tartalmazza az összes adatbázis-objektum leírását, a méretet a CATALOGCACHE_SZ paraméter szabályozza;
  • Utility heap – RAM adatbázis-karbantartási műveletek végrehajtásához (beleértve a biztonsági mentési és visszaállítási műveleteket is), a méretet az UTIL_HEAP_SZ paraméter szabályozza;
  • Adatbázis kupac - RAM az adatbázis-műveletek kiszolgálásához (beleértve a tranzakciónapló-puffert és a gyorsítótárat a rendszerkönyvtárhoz való hozzáférés felgyorsítására, valamint az adatbázis szintű audit puffert), a méretet a DBHEAP paraméter szabályozza.

A globális adatbázis-terület teljes méretét a DATABASE_MEMORY paraméter korlátozza.

Az alkalmazás adatterülete a következőket tartalmazza:

  • Alkalmazás globális memória – általános memóriaterületek az alkalmazáskérések feldolgozásakor, a maximális mennyiséget az APPL_MEMORY paraméter szabályozza;
  • Agent Private Memory – a csatlakoztatott alkalmazásokat kiszolgáló egyedi ügynökök működésére használt privát memóriaterületek.

Ezenkívül lefoglalhat olyan memóriaterületeket, amelyek a DB2 illesztőprogram alkalmazásoldali futtatásához vannak lefoglalva. A helyi alkalmazások esetében (amelyek a folyamatközi kommunikációs protokollt használják az adatbázis-kezelőhöz való csatlakozáshoz, nem pedig a hálózati hozzáférést) a DB2 konfigurált beállításai szabályozzák a lefoglalt RAM mennyiségét (elsősorban az ASLHEAPSZ paramétert).

RAM kezelése rendezési műveletek végrehajtásakor

Sokféle DBMS-művelet végrehajtásakor szükséges az adatok rendezése, ezért kiemelt figyelmet fordítanak a rendezéshez használt RAM kezelésére.

Ha nem lehet a teljes rendezési területet elhelyezni a RAM-ban, akkor a rendezéshez szükséges adatok a rendszer ideiglenes táblaterületére kerülnek. Az ilyen nagy rendezési műveleteket igénylő lekérdezések teljesítménye jelentősen leromolhat.

Paraméterek, amelyek szabályozzák a RAM kiosztását a rendezéshez:

  • SORTHEAP – memóriakorlát a rendezési művelethez;
  • SHEAPTHRES – az ügynök rendezési művelethez lefoglalt privát memóriaterületének maximális mérete;
  • SHEAPTHRES_SHR – a teljes RAM maximális mennyisége, amely egy adott időpontban rendezési műveletek végrehajtására használható (teljesen az összes fogyasztó által).

A DB2 három fő rendezési memóriakezelési modellt támogat:

  • Alapértelmezés szerint a megosztott rendezési terület modellt használják, és a SHEAPTHRES paramétert 0-ra kell állítani. A rendezéshez szükséges RAM a globális adatbázis-területről van lefoglalva.
  • Privát rendezési terület modell – akkor használatos, ha a SHEAPTHRES paraméter értéke nem nulla, és nincs konfigurálva megosztott memória válogatás. A rendezéshez szükséges RAM-ot az alkalmazás adatterületéről (pontosabban az ügynökök tulajdonában lévő privát területekről) foglalják le.
  • Hibrid rendezési modell – akkor használatos, ha a SHEAPTHRES paraméter értéke nem nulla, és van konfigurált megosztott rendezési memória. A megosztott rendezési memória használatát igénylő műveletek a globális adatbázis-területen, a többi rendezési művelet memóriafoglalással a privát ügynök területeken történik.

A megosztott (globális) memória használata a rendezési műveletek végrehajtásához számos fontos előnnyel jár:

  • a RAM rugalmasabb kezelése lekérdezések végrehajtásakor, ami lehetővé teszi a RAM használatának hatékonyságának növelését;
  • a rendezési algoritmus párhuzamos verziójának használatának képessége, mivel a koordináló ügynök és az alárendelt DB2-alügynökök egyidejűleg hozzáférnek a rendezési memóriaterülethez.

Ha engedélyezni szeretné a megosztott memória használatát a rendezési műveletek végrehajtásakor, használja a következő beállítások egyikét:

  • engedélyezte a megosztott rendezési terület modelljét a SHEAPTHRES paraméter 0-ra állításával;
  • A műveletek végrehajtásának párhuzamossága az INTRA_PARALLEL paraméter YES-re állításával aktiválható;
  • A DB2_WORKLOAD változó értéke ANALYTICS;
  • A DB2 Connection Concentrator szolgáltatás aktiválva van (általában a DB2 for z/OS és a DB2 for i adatbázisokhoz való hozzáférés szervezésekor használatos, lásd a szolgáltatás leírását itt: ).

Automatikus memóriafoglalás-kezelés

A sok különböző RAM-terület és a bennük lévő memória mennyiségét szabályozó paraméterek miatt sok erőfeszítést igényel a DB2 kiszolgáló manuális konfigurálása. Ezért a 9-es verziótól kezdve az IBM DB2 támogatja a RAM különböző területek közötti elosztásának automatikus kezelését egy önhangoló memóriakezelő (STMM, Self-Tuning Memory Manager) segítségével.

Ha a rendszerindítás engedélyezve van, az STMM dinamikusan lefoglalja a rendelkezésre álló memória-erőforrásokat az adatbázisban lévő memóriafogyasztók között. Az STMM a teljesítmény optimalizálása érdekében a memóriakonfigurációs beállítások és a puffertár méretének módosításával reagál a terhelési jellemzők változásaira. Az STMM engedélyezéséhez a SELF_TUNING_MEM adatbázis-konfigurációs paramétert ON-ra kell állítani.

Az automatikus memóriafoglalás-vezérlés azon memóriaterületeken történik, amelyekre ez kifejezetten engedélyezett. Ha konfigurációs paraméterértéket állít be az UPDATE DBM CFG és UPDATE DB CFG paranccsal, akkor az STMM használatához az AUTOMATIC kulcsszó kerül megadásra a paraméterérték után. Az ebben az esetben megadott paraméter számértéke a kezdeti érték, majd az STMM időszakosan módosítja az értékeket az aktuális terhelés figyelembevételével, újraelosztva a RAM-ot a különböző fogyasztók között.

Az STMM-eszközök automatikus kezelése a következő paramétereknél támogatott:

  • INSTANCE_MEMORY – a DB2 példány RAM-jának teljes mennyisége;
  • DATABASE_MEMORY – globális adatbázis-területek;
  • DBHEAP – az adatbázis-műveletek kiszolgálására szolgáló terület;
  • LOCKLIST – terület a zárak adatainak karbantartására;
  • MAXLOCKS – az egyik alkalmazás zárolásai által elfoglalt memória százalékos aránya a zárolás eszkalációjára való váltáshoz;
  • PCKCACHESZ – terület a lekérdezés-végrehajtási tervek gyorsítótárazásához;
  • SHEAPTHRES_SHR – általános rendezési terület;
  • SORTHEAP – a rendezési terület mérete egy művelethez;
  • APPL_MEMORY – funkcionális memóriaterület;
  • APPLHEAPSZ – egy ügynök által felhasznált privát memória maximális mennyisége;
  • STMTHEAP – az SQL és XQuery lekérdezésfordító által használt terület méretének korlátozása (lekérdezésenként);
  • STAT_HEAP_SZ – a RUNSTATS segédprogram által épületstatisztikákhoz lefoglalt és a funkcionális memóriaterületről lefoglalt RAM maximális mennyisége.

Az adatbázis-objektumok típusai

Ez a szakasz áttekintést nyújt a DB2 adatbázis-objektumok típusairól. A DB2 adatbázis-objektumok típusainak teljes listája és az egyes objektumok típusaira vonatkozó részletes információk a DB2 dokumentációban találhatók:

Rendszer

A sémák névterek az adatbázis-objektumok gyűjtésére. A sémákat elsősorban a következőkre használják:

  • az objektumok vagy társítások kizárólagos használatának jelzése egy alkalmazással;
  • a kapcsolódó objektumok logikai csoportosítása.

Minden DB2 adatbázis-objektum (a gyakori szinonimák kivételével) teljesen minősített kétrészes névvel rendelkezik; A séma ennek a névnek az első része:<имя_схемы>.<имя_объекта>

A teljesen minősített objektumnévnek egyedinek kell lennie. Ha csatlakozik egy adatbázishoz, és séma megadása nélkül hoz létre vagy ér el egy objektumot, a DB2 az adatbázishoz csatlakozó felhasználói azonosítót használja sémanévként. A SET SCHEMA utasítással is beállíthatja az aktuális munkamenet sémáját.

A séma létrehozása történhet explicit módon, a CREATE SCHEMA utasítás meghívásával, vagy implicit módon úgy, hogy először megkísérel létrehozni egy objektumot sémanév megadása nélkül. Ez utóbbi esetben a felhasználónak meg kell adni az IMPLICIT_SCHEMA engedélyt a séma sikeres létrehozásához.

A legtöbb típusú adatbázis-objektumhoz szinonimák hozhatók létre, lehetővé téve az eredeti objektumok más néven való elérését (talán más sémában). A szinonimák a CREATE SYNONYM / CREATE ALIAS utasítással jönnek létre. Támogatja továbbá a nyilvános szinonimák használatát, amelyek nincsenek egy adott sémához kötve. A nyilvános szinonimák séma megadása nélkül érhetők el, függetlenül az aktuális munkamenet-sémakészlettől. A nyilvános szinonimák a CREATE PUBLIC SYNONYM / CREATE PUBLIC ALIAS paranccsal hozhatók létre.

Táblázatok

A táblázat a kapcsolódó adatok gyűjteménye, logikusan oszlopokba és sorokba rendezve.

A táblázat minden sora azonos elnevezett oszlopokból áll. Táblázat létrehozásakor minden oszlophoz hozzárendelnek egy adattípust, amely korlátozza az oszlop megengedett értékeit a táblázat soraiban (adatbázis rekordok), és meghatározza a megfelelő értékekkel végzett lehetséges műveletek szemantikáját (beleértve az összehasonlítást, a rendezést és a számítási műveleteket). tevékenységek).

A CREATE TABLE paranccsal egy táblázat jön létre, és a DROP TABLE paranccsal törlődik. A tábla leírásának módosítása az ALTER TABLE paranccsal támogatott, beleértve az oszlopok hozzáadását és törlését, valamint az oszlop adattípusainak módosítását. A tábla leírásának módosításához szükséges műveletek elvégzése után újra kell szervezni (át kell strukturálni a tábla fizikai tárolóját az optimális hozzáférés érdekében) a REORG paranccsal.

A táblázatoszlopok meghatározásához használható beépített DB2 adattípusok osztályozása az alábbi ábrán látható.

Az egyik mellett elfogadható értékeket támogatott adattípus, az oszlopértékek üresek lehetnek, pl. üres (NULL) érték. Az oszlopok üres értékek tárolására való képességét a táblázat létrehozásakor határozzák meg.

Az ábrán felsorolt ​​adattípusok többségének közvetlen analógja van más modern relációs DBMS-ekben, és részletes leírásuk a DB2 dokumentációjában található. Az alábbiakban az adattípusok jellemzőinek rövid leírása található, amelyek specifikusak a DB2-re, vagy amelyek használatuk során nehézségeket okozhatnak.

Amikor karakterláncadatokkal dolgozik, más típusú DBMS-ekkel ellentétben a DB2 különbséget tesz egy üres karakterlánc (nulla hosszúságú karakterlánc) és egy NULL karakterlánc-érték között. Ez a funkció befolyásolja a keresési sorrendet (az egyenlőség predikátum használata az IS NULL kifejezés helyett) és a megengedett oszlopértékek összetételét (ha a NULL értékek oszlopban való tárolása tilos, üres karakterlánc tárolható).

A GRAPHIC, VARGRAPHIC és DBCLOB típusok karakterlánc-értékei abban különböznek a többi karakterlánc-típustól, hogy mindig UTF-16 kódolásban vannak tárolva. Amikor az ügyfélalkalmazásból hozzáfér a megfelelő oszlopokhoz, a DBMS biztosítja, hogy az adatokat az ügyfélalkalmazás által használt kódolásra konvertálja.

A DATE típusú oszlopok alapértelmezés szerint nem tartalmaznak időbélyeget. Az Oracle Database kompatibilitási módban a DB2 emellett támogatja az időattribútumok (óra, perc, másodperc) DÁTUM oszlopokban való tárolását.

Ha hatékonyan kell dolgozni a tört részt is tartalmazó, pontos decimális számokkal (például pénzügyi alkalmazásokban), akkor célszerű a DECFLOAT adattípust használni, amely a DECIMAL értékek pontos megjelenítését kombinálja a hatékony számítási lehetőségekkel. FLOAT értékek.

A BLOB adattípus lehetővé teszi strukturálatlan bináris információk (például képek vagy irodai formátumú dokumentumok) adatbázisban való tárolását. A BLOB típusú értékek a rekord többi mezőjével együtt (ha méretük lehetővé teszi, hogy kellően kompaktan elhelyezhetők), vagy külön-külön, egy speciális tárolóobjektumban tárolhatók. Ez utóbbi esetben a bejegyzés magára az érték helyett a tárolt BLOB értékre hivatkozik. A CLOB és DBCLOB típusok értékeinek tárolása hasonló módon szerveződik.

Az XML adattípus strukturált hierarchikus XML dokumentumok tárolását teszi lehetővé táblamezőkben. A tárolt XML-dokumentumok esetében támogatottak az attribútum-hozzáférési műveletek (az XML-dokumentum elemzése nélkül), az egyedi attribútumok indexelése és egyéb lehetőségek.

A beépített adattípusokon kívül a DB2 támogatja a felhasználó által definiált adattípusokat, amelyek a beépített típusok alapján vannak meghatározva. A felhasználó által definiált adattípusokkal való munkavégzést a DB2 dokumentáció írja le.

Táblázat készítésekor lehetőség van az oszlopértékek automatikus kitöltésére vonatkozó szabályok megadására. Az automatikusan kitöltött oszlopok speciális esetei az identitásoszlopok, amelyek olyan numerikus oszlopok, amelyek automatikusan egyedi numerikus értéket generálnak minden beszúrt sorhoz. Az automatikus feltöltés kétféle módban hajtható végre:

  • MINDIG LÉTREHOZOTT – az értéket mindig a DB2 kiszolgáló állítja be, és az alkalmazás nem állítható be kifejezetten;
  • ALAPÉRTELMEZETT LÉTREHOZOTT – Az értéket a DB2 kiszolgáló állítja be, ha az alkalmazás nem adott meg kifejezetten hozzárendelendő értéket a rekord beszúrásakor.

A táblázat szintjén olyan korlátozások is meghatározhatók, amelyek korlátozzák az attribútumértékek összetételét. A következő típusú korlátozások támogatottak:

  • elsődleges kulcs (PRIMARY KEY) – egy oszlopkészlet egyediségi megszorítása, amelyet elsősorban egyetlen rekord keresésére használnak; egy táblának csak egy elsődleges kulcsa lehet;
  • egyediségi megszorítás (UNIQUE) – további egyediségi megszorítás egy oszlopkészletre;
  • idegen kulcs (FOREIGN KEY) – hivatkozás oszlopértékkészlet formájában, amely egy másik tábla oszlopainak kombinációjára mutat, amelyhez idegen kulcs vagy egyedi megszorítás van meghatározva;
  • check (CHECK) – logikai feltétel, amely korlátozza lehetséges értékek egy vagy több oszlopot a felvételen.

A megszorító mechanizmus olyan eszközöket valósít meg, amelyek automatikusan figyelik és biztosítják az adatbázis integritását, beleértve az adatok hivatkozási integritását (figyeli a „szülő” táblában azon rekordok jelenlétét, amelyekre idegen kulcsokon keresztül hivatkoznak a „gyermek” táblák rekordjaiban). A korlátozások megfelelő alkalmazása lehetővé teszi az adatbázis kitöltésének formai helyességének garantálását, és bizonyos mértékig védelmet az alkalmazási és felhasználói hibák ellen az adatok módosítása során.

Mivel a kényszerítő mechanizmus további számítási terhelést jelent az adatok bevitele és javítása során, bizonyos esetekben szándékosan elhagyják a használatát, így az alkalmazásra hárul a felelősség az adatbázis megfelelő karbantartásáért. Ugyanakkor a DB2 integritáskényszer-definíciókat használ a táblák közötti kapcsolatok meghatározására és a leghatékonyabb lekérdezés-végrehajtási terv meghatározására.

Ideiglenes asztalok

Az ideiglenes alkalmazásadatok tárolására a DB2 egy ideiglenes táblamechanizmust biztosít, amely a táblázatos adatokkal való munkavégzéshez a függvények teljes készletét biztosítja, de az aktuális felhasználói munkamenet összefüggésében.

Az ideiglenes táblákhoz való hozzáférés jelentősen javítja a teljesítményt, mivel a rendszerkatalógus-hozzáférési ütközések minimalizálódnak vagy megszűnnek, és nincs szükség sorzárolásra, naplózásra (opcionális, a tábla létrehozási módjától függően) vagy engedélyek ellenőrzésére.

Az ideiglenes táblák az indexeket is támogatják, ami azt jelenti, hogy bármely szabványos index létrehozható egy ideiglenes táblán. Ezekről a táblákról statisztikákat is gyűjthet (a RUNSTATS paranccsal) a lekérdezésoptimalizáló számára szükséges információk megszerzéséhez.

Az ideiglenes táblák a felhasználói ideiglenes táblaterületen találhatók, amelyet létrehozásuk előtt meg kell határozni.

Az ideiglenes tábláknak két fő típusa van a DB2-ben:

  • deklarált ideiglenes táblák (DGTT – Declared Global Temporary Tables);
  • globális ideiglenes táblákat hozott létre (CGTT – Created Global Temporary Tables).

A deklarált ideiglenes táblák a memóriában létrehozott táblák, amelyeket az alkalmazás használ, és amelyeket az alkalmazás kilépésekor automatikusan eldobnak. Ezeket a táblákat csak az azokat létrehozó alkalmazás érheti el, és a DB2 rendszerkatalógus tábláiban sem tárolódnak.

Minden deklarált ideiglenes tábla rendelkezik egy SESSION sémával; ezt a diagramot arra hivatkozva kell jelezni. Az ideiglenes táblák deklarálásához használt felhasználói azonosító teljes jogosultsággal rendelkezik ezeken a táblákon. Minden ideiglenes táblát deklaráló alkalmazásnak saját másolata lesz a tábláról.

Bár a DGTT-k lehetővé teszik egy ideiglenes tábla deklarálását, egy ilyen tábla meghatározása nem osztható meg kapcsolatok vagy munkamenetek között. Minden munkamenet indításakor ki kell adnia a DECLARE GLOBAL TEMPORARY TABLE utasítást.

Létrehozott globális ideiglenes táblák (CGTT) használatakor az ideiglenes tábladefiníciót csak egyszer kell létrehozni, mert az a DB2 rendszerkatalógusban van tárolva. Ez azt jelenti, hogy más kapcsolatok használhatják a tábladefiníciót ahelyett, hogy újra létre kellene hozniuk.

Bár a CGTT táblaszerkezet azonnal használható, a különböző kapcsolatokból származó adatok függetlenek egymástól, és a kapcsolat lezárásakor elvesznek.

Indexek

Az index kulcsok rendezett halmaza, amelyek mindegyike egy táblázat egy sorára mutat. Az indexek biztosítják a sorok egyediségét (vagyis megvalósítják az előző részben tárgyalt egyediségi megszorításokat) és javítják a teljesítményt. Az alábbiakban néhány jellemzőt ismertetünk, amelyek az indexekhez definiálhatók:

  • az indexek az oszlopértékek növekvő vagy csökkenő sorrendjében építhetők fel;
  • az indexkulcsok lehetnek egyediek vagy nem egyediek;
  • az indexek több oszlopra is építhetők (az ilyen indexeket kombináltnak nevezzük);
  • ha az index és a táblázat adatai ugyanabban az indexsorozatban vannak csoportosítva, az indexet CLUSTERED INDEX-nek nevezzük.

Az indexek létrehozását a CREATE INDEX operátor, az eltávolítást a DROP INDEX operátor biztosítja. Az index létrehozásakor megjelenik annak típusa (egyedi / nem egyedi) és az index felépítéséhez szükséges oszlopok összetétele.

A DB2 eszközöket biztosít az indexek automatikus kiválasztását a lekérdezés teljesítményének optimalizálása érdekében. Ezekkel az eszközökkel a legkényelmesebb az IBM Data Studio.

Sorozatok

Bár a sorozatobjektumok függetlenek a táblázatoktól, az azonosságoszlopokhoz hasonlóan működnek, és lehetővé teszik egyedi numerikus sorozatok létrehozását. A szekvenciák és az identitásoszlopok közötti különbség az, hogy az identitásoszlopok egyedi számokat generálnak szigorúan egy megadott táblázatoszlopban, míg a szekvenciaobjektumok használhatók szekvenciális numerikus értékek generálására, amelyek használati logikáját az alkalmazás határozza meg.

A sorozatok létrehozását a CREATE SEQUENCE parancs biztosítja, a következő és aktuális fogadott értékekhez való hozzáférés a NEXT VALUE FOR és PREVIOUS VALUE FOR operátorokkal történik. Az Oracle adatbázissal való kompatibilitás érdekében a szekvenciaértékek „NEXTVAL” és „CURRVAL” pszeudooszlopokon keresztüli elérésének szintaxisa is támogatott.

Reprezentáció

A nézet az adatok táblázatokban való megjelenítése. A nézetek adatait a rendszer nem tárolja külön, hanem a nézet futtatásakor kéri le őket. A beágyazott nézetek támogatottak, vagyis a más nézetekből létrehozott nézetek.

A nézetek a CREATE VIEW paranccsal jönnek létre, és a DROP VIEW paranccsal törlődnek. A nézetek frissítésének (cseréjének) megkönnyítése érdekében rendelkezésre áll a NÉZET LÉTREHOZÁSA VAGY CSERÉJE szintaxis, amely új nézetet hoz létre (ha még nem létezik), vagy egy meglévő nézetet új definícióra cserél (ha egy nézet a megadott névvel). már korábban létrehozták).

Kiváltók

A trigger olyan objektum, amely automatikusan végrehajt egy műveletet egy táblázaton vagy nézeten. Egy adott művelet egy objektumon, amelyhez trigger van meghatározva, az eseményindítót aktiválja. Az eseményindítót általában nem tekintik alkalmazásobjektumnak; Ennek megfelelően a triggereket jellemzően nem a fejlesztők, hanem az adatbázis-adminisztrátorok hozzák létre.

Tárolt eljárások és funkciók

A tárolt eljárások olyan adatbázis-objektumok, amelyek SQL utasításokat és üzleti logikát tartalmaznak. Az alkalmazáslogika egy részének az adatbázisban való tárolása javítja a teljesítményt, mivel csökkenti az alkalmazás és az adatbázis közötti forgalmat. Ezenkívül a tárolt eljárások központi helyet biztosítanak a tároláshoz programkód, és ennek megfelelően más alkalmazások is használhatják ugyanazokat a tárolt eljárásokat. Tárolt eljárás hívásához használja a CALL utasítást.

A felhasználói függvények (UDF) olyan adatbázis-objektumok, amelyek lehetővé teszik a felhasználók számára, hogy saját logikájukkal bővítsék az SQL nyelvet. A függvény mindig egy értéket vagy értékeket ad vissza, általában a függvényben szereplő üzleti logika eredményeként. Egy függvény meghívásához használja egy SQL utasítás részeként vagy a VALUES utasítással együtt.

A DB2-ben tárolt eljárások és felhasználó által definiált függvények többféle programozási nyelven fejleszthetők, beleértve a PL/SQL-t, SQL PL-t, Java-t, C-t, C++-t, COBOL-t.

Rendszerkatalógus

Az egyik alapvető információs források A DBMS egy rendszerkönyvtár, amely az adatbázis szerkezetére vonatkozó információkat tárol, és hozzáférést biztosít azokhoz, beleértve:

  • táblázatok, oszlopok és indexek leírása;
  • nézetek, triggerek és tárolt eljárások leírása és szövege;
  • Táblázatterületekre és adatok tárolására szolgáló tárolókra vonatkozó információk;
  • létrehozott engedélyek az adatbázis-objektumok eléréséhez;
  • egyéb adatbázis metainformáció.

A rendszerkatalógus elérése számos feladathoz szükséges, beleértve az adatbázis-adminisztrációs és -karbantartási feladatok automatizálását, az alkalmazásfejlesztést és még sok mást.

A leggyakrabban használt táblázatok (valójában nézetek) a rendszerkatalógusban találhatók:

  • SYSCAT.SCHEMAS – adatbázissémák leírása;
  • SYSCAT.TABLES – adatbázis táblák leírása;
  • SYSCAT.COLUMNS – táblázat oszlopainak leírása;
  • SYSCAT.INDEXES – indexek leírása.

A fenti és a rendszerkatalógus egyéb táblázataihoz tartozó oszlopok részletes leírása és összetétele a következő helyen található:

Párhuzamos tranzakciófeldolgozás szervezése

Tranzakciók

Egy tranzakció (vagy munkaegység) egy vagy több SQL-utasításból áll, amelyeket a rendszer végrehajtáskor külön egységként kezel; vagyis ha egy tranzakcióban egy utasítás meghiúsul, az egész tranzakció meghiúsul, és a kudarcig végrehajtott összes utasítás visszakerül.

A tranzakció COMMIT utasítással zárul. A tranzakció zárulhat ROLLBACK nyilatkozattal vagy az alkalmazás vészleállításával is, amely után az alkalmazás által az adatbázisban végrehajtott összes módosítás törlődik. A tranzakció kezdete az első végrehajtott utasítás, miután az alkalmazás kapcsolatot nyit az adatbázissal, vagy miután az előző tranzakció befejeződött. Minden alkalmazás-kapcsolat az adatbázishoz legfeljebb egy aktív tranzakcióval rendelkezhet.

Mint korábban említettük, az adatbázis változásait a tranzakciós napló rögzíti. Annak érdekében, hogy a visszavont tranzakciók által végrehajtott módosítások visszaállíthatók legyenek, a tranzakciós határok is rögzítésre kerülnek a tranzakciós naplóban. Azon tranzakcióknál azonban, amelyek csak adatolvasási műveleteket hajtanak végre, nem történik bejegyzés a tranzakciónaplóban. A tranzakció kezdetére vonatkozó információk az első (egy adott tranzakcióra vonatkozó) adatírási utasítás végrehajtása előtt kerülnek a tranzakciós naplóba.

Ha az egyetlen utasítás írási adatai meghiúsulnak, az adott utasítás által végrehajtott összes módosítást a rendszer visszaállítja a tranzakciós naplóadatok segítségével. Egy alkalmazás, miután kapott egy nyilatkozat végrehajtásának megtagadásáról szóló diagnosztikai üzenetet, törölheti a teljes tranzakciót (ROLLBACK utasítással), vagy egyéb műveleteket hajthat végre az adatbázissal, és végül megerősítheti a változtatásokat (COMMIT utasítással).

Egy alkalmazás további visszagörgetési pontokat határozhat meg egy tranzakción belül (a SAVEPOINT utasítás használatával), és visszaállíthatja a létrehozott visszagörgetési pont után végrehajtott módosításokat (a ROLLBACK TO utasítás használatával). A visszagörgetési pontok használatával az alkalmazás szelektíven visszavonhatja a tranzakción belül végrehajtott műveleteket, ami hasznos lehet az adatintegritási hibák és más forgatókönyvek kezelésekor.

Zárak

Az egyidejű használat azt jelenti, hogy több felhasználó is dolgozhat ugyanazon az adatbázis-objektumon egy időben. Az adatokhoz való hozzáférést megfelelően koordinálni kell az adatok integritásának és konzisztenciájának biztosítása érdekében.

A megosztott erőforrások egyidejűségének ellenőrzése szükséges ahhoz, hogy az egyidejű tranzakciókból következetes eredményeket kapjunk. Az ilyen vezérlés a zárak használatán alapul.

A blokkolás és a párhuzamosság fogalma szorosan összefügg. A blokkolás ideiglenesen megakadályozza, hogy az alkalmazások más műveleteket hajtsanak végre, amíg az aktuális művelet be nem fejeződik. Minél több zárat használnak egy rendszerben, annál kevesebb az egyidejű használat. Másrészt minél ritkábban alkalmazzák a zárolást egy rendszerben, annál több a párhuzamossági lehetőség.

A zárolás automatikusan megszerzésre kerül, ha a tranzakció támogatásához szükséges, és feloldódik, ha a tranzakció megszakad (COMMIT vagy ROLLBACK paranccsal). A zár asztalokra vagy sorokra helyezhető.

A blokkolásnak két fő típusa van:

  • Megosztott zárolás (S) – Annak beállítása, hogy egy alkalmazás mikor olvassa be az adatokat, és megakadályozza, hogy más alkalmazások módosítsanak ugyanabban a sorban.
  • Exkluzív zár (X) – Beállíthatja, amikor egy alkalmazás frissít, beszúr vagy töröl egy sort.

Ha két és több alkalmazás műveletet kell végrehajtania ugyanazon az objektumon, egyiküknek várnia kell a szükséges zár megszerzésére. Alapértelmezés szerint az alkalmazás határozatlan ideig várakozik. Az alkalmazás zárolási időtúllépését a LOCKTIMEOUT adatbázis-konfigurációs paraméter vezérli. Alapértelmezés szerint ez a paraméter -1 (végtelen várakozás).

A CURRENT LOCK TIMEOUT szekcióváltozóval beállíthatja a zárolási időt egy adott kapcsolaton. Alapértelmezés szerint ez a változó LOCKTIMEOUT. Ezt az értéket a SET LOCK TIMEOUT utasítással módosíthatja.

Amikor két (vagy több) ugyanahhoz az adatbázishoz kapcsolódó alkalmazás korlátlan ideig vár az erőforrásokra az erőforrásokhoz való hozzáférés helytelen sorrendje miatt, akkor patthelyzet lép fel. Az időtúllépési időszak nem érhet véget, mert minden alkalmazás egy másik alkalmazás számára szükséges erőforrást tartalmaz. A holtponti probléma minden esetben a helytelen alkalmazástervezés vagy logika következménye.

A DB2 automatikusan észleli a holtponti helyzeteket a DLCHKTIME paraméter által meghatározott időközönként végrehajtott holtpont-ellenőrzések végrehajtásával. Amikor a DB2 azt észleli, hogy valóban holtpont történt, egy belső algoritmus segítségével határozza meg, hogy a két tranzakció közül melyiket kell visszaállítani, és melyiket kell folytatni.

Szigetelési szintek

Az erőforrások egyidejű felhasználása feletti ellenőrzés hiányában felmerülő problémák részletes elemzését a DB2 dokumentációja, valamint a relációs DBMS-ek működésének elméletével foglalkozó szakirodalom tartalmazza. A problémák lehetséges típusai a következők:

  • elveszett frissítés (ha egy adatblokkot egyidejűleg különböző tranzakciók módosítanak, akkor az egyik módosítás elveszik);
  • érvénytelen olvasás (egy tranzakció által hozzáadott vagy módosított adatok olvasása, amelyeket utólag nem erősítenek meg);
  • nem ismétlődő olvasás (egy tranzakción belüli újraolvasáskor kiderül, hogy a korábban olvasott adatok megváltoztak);
  • fantomolvasás (azonos kijelölések egy tranzakcióban különböző sorkészleteket hoznak létre a sorok más tranzakciók általi hozzáadása, törlése vagy módosítása miatt).

Az alkalmazások a használt elkülönítési szint beállításával szabályozzák a DB2 beépített védelmét a fent felsorolt ​​problémákkal szemben. Az elkülönítési szinteket zárolási házirendeknek tekinthetjük, ahol a választott elkülönítési szinttől függően az alkalmazás eltérő adatbázis-zárolási viselkedést érhet el. Az alkalmazás által igényelt elkülönítési szint a munkamenet szintjén és a végrehajtott egyedi lekérdezés vagy allekérdezés szintjén állítható be.

A DB2 a következő szintű védelmet nyújtja az adatok elkülönítéséhez:

  • megbízhatatlan olvasás (Uncommitted Read, UR);
  • kurzorstabilitás (CS);
  • Olvasási stabilitás (RS);
  • ismételhető leolvasás (RR).

Érvénytelen olvasat"piszkosnak" is nevezik. Ez a legalacsonyabb szigetelési szint, amelyet lehetővé tesz legmagasabb fokozat párhuzamos használat. Az olvasási műveletek nem zárolják a sorokat, hacsak egy másik alkalmazás nem kísérli meg eldobni vagy módosítani a táblát; A frissítési műveletek ugyanúgy hajthatók végre, mint a következő elkülönítési szint, a kurzorstabilitási szint használatakor.

Az Érvénytelen olvasás elkülönítési szint használata megakadályozza a következő problémákat:

  • elveszett frissítés.

A kurzor stabilitása az alapértelmezett izolációs szint. Minimális fokú blokkolást biztosít. Ez az elkülönítési szint zárolja a kurzor "aktuális" sorát. Ha a sort csak olvassák, a zárolás a következőre való áttérésig megmarad új sor vagy a művelet befejezése. Ha a sor frissül, a zárolás a művelet befejezéséig megmarad.

A kurzorstabilitási szigetelési szint használata megakadályozza a következő problémákat:

  • elveszett frissítés;
  • érvénytelen olvasás.

A DB2 9.7 előtt a kurzorstabilitási elkülönítési szint használatakor az írási (UPDATE művelet) végrehajtása megtagadta az olvasási hozzáférést (SELECT művelet) ugyanahhoz a sorhoz. Az indoklás az volt, hogy mivel egy írási művelet módosít egy sort, az olvasási műveletnek meg kell várnia a frissítések befejeződését, hogy megkapja a végleges végleges értéket.

A DB2 9.7 a kurzorstabilitás elkülönítési szintjétől eltérő alapértelmezett megközelítést használ új adatbázisokhoz. Ezt az új megközelítést a jelenleg elkötelezett (CC) szemantika segítségével valósítják meg. CC szemantika használatakor az írási művelet nem tagadja meg a hozzáférést ugyanahhoz a sorhoz az olvasási művelethez. Korábban ez a megközelítés lehetséges volt az UR izolációs szint használatával; A különbség a jelenlegi megközelítéshez képest az, hogy az UR-val az olvasási művelet megbízhatatlan értékeket, a CC szemantikával pedig a jelenleg elfogadott értékeket kapja. A jelenleg elfogadott értékek az írási művelet megkezdése előtt rögzített értékek.

Olvasási stabilitás biztosítja, hogy az alkalmazás által kapott összes sor zárolva legyen. Egy adott lekérdezésnél az eredményhalmaznak megfelelő összes sor zárolva van. Így ennek az elkülönítési módnak a használata azt eredményezheti, hogy az alkalmazás nagyszámú zárolást szerez be, és ha a megadott határértékeket eléri, a zárolások sorszintről a táblázat szintjére lépnek fel. Az olvasási stabilitás elkülönítési szintjén azonban a DB2 lekérdezés-optimalizáló nem tartalmazza az explicit táblaszintű zárakszerzést a lekérdezés végrehajtási tervében, még akkor sem, ha a tábla rekordjainak többsége benne van az eredménykészletben.

Az olvasási stabilitás elszigetelési szint használata megakadályozza a következő problémákat:

  • elveszett frissítés;
  • megbízhatatlan olvasás;
  • nem ismétlődő olvasás.

Ismételt olvasás- ez a legmagasabb szintű elszigeteltség. Ez biztosítja a legmagasabb fokú blokkolást és a legkevesebb párhuzamosságot. Az eredményhalmaz felépítéséhez feldolgozott sorokra zárolás kerül; más szóval, még azok a sorok is blokkolhatók, amelyek nem kerülnek a végeredmény kötegébe. Más alkalmazások nem frissíthetnek, törölhetnek vagy szúrhatnak be olyan sorokat, amelyek befolyásolják az eredménykészletet, amíg a folyamatban lévő művelet be nem fejeződik. Az ismételt olvasás biztosítja, hogy ugyanaz a lekérdezés, amelyet egy alkalmazás többször generál egyetlen műveletben, minden alkalommal ugyanazt az eredményt adja.

A DB2 Query Optimizer ismételhető olvasási elkülönítési szint használatakor belefoglalhat a lekérdezés végrehajtási tervébe explicit műveletek táblaszintű zárolások beállítása, amikor a megfelelő lekérdezések a tábla összes sorának vizsgálatát tartalmazzák (ami azt jelenti, hogy a tábla minden sorát zárolni kell a lekérdezés végrehajtása során).

Az olvasási stabilitás elkülönítési szint használatakor minden lehetséges problémákat párhuzamos hozzáférés, ugyanakkor a műveletek lehetséges párhuzamossága a lehető legnagyobb mértékben korlátozott.

Következtetés

Ez a cikk a fő szempontokat tárgyalta funkcionalitás IBM DB2 LUW DBMS, adatbázis-kiszolgáló szerkezet, konfigurációs beállítások és adattárolási szervezés. Ezen túlmenően a DB2 kiszolgáló működésének alapelvei, a támogatott adatbázis-objektumok típusai, valamint a párhuzamos tranzakciófeldolgozás megszervezése a DB2-ben kerül megvitatásra.

A munkahelyemen egy ideig az IBM DB2 DBMS-sel kellett foglalkoznom. Mert Mivel a rendszer kereskedelmi jellegű, nem sok információ található oroszul az interneten, ezért úgy döntöttem, hogy leírom ennek a DBMS-nek néhány funkcióját.

Belépési pont

Kezdjük a DBMS belépési pontjával. Az SQL SERVER-ben a végpont egy példány, amelynek természetesen lehetnek külön adatbázisai, de a konfiguráció és a biztonsági modell ugyanaz a teljes példányra vonatkozóan. A DB2-ben a belépési pont így néz ki - egy példány (amely egy adott portnak felel meg) - egy adatbázis. Ebben az esetben a konfiguráció a teljes példányra és egy külön adatbázisra is elérhető.

A példány konfigurációját a db2 paranccsal tekintheti meg:

Adatbáziskezelő konfigurációja

Csomópont típusa = Enterprise Server Edition helyi és távoli ügyfelekkel

Adatbázis-kezelő konfigurációs kiadási szintje = 0x0b00

CPU-sebesség (ezredmásodperc/utasítás) (CPUSPEED) = 2,912790e-07
Kommunikációs sávszélesség (MB/s) (COMM_BANDWIDTH) = 1,000000e+02

Az egyidejűleg aktív adatbázisok maximális száma (NUMDB) = 8
Federated Database System Support (FEDERATED) = IGEN
Tranzakciófeldolgozó figyelő neve (TP_MON_NAME) =

Alapértelmezett visszaterhelési számla (DFT_ACCOUNT_STR) =

Java Development Kit telepítési útvonala (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Diagnosztikai hibarögzítési szint (DIAGLEVEL) = 3
Értesítési szint (NOTIFYLEVEL) = 3
Diagnosztikai adatok könyvtár elérési útja (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Alapértelmezett adatbázis-figyelő kapcsolók
Puffertár (DFT_MON_BUFPOOL) = KI

Ahol a paraméterek, jelentésük és értelmezésük feltüntetésre kerül. Rövidített változat is lehetséges:

szerezd be a dbm cfg-t

Vagy használja a kérést:

Válasszon nevet, értéket a sysibmadm.dbmcfg fájlból

A fontos paraméterek a következők:

  • hitelesítés típusa (AUTHENTICATION)
  • alapértelmezett útvonal új adatbázisok létrehozásához (DFTDBPATH)
  • szerver felfedezés a hálózaton keresztül (DISCOVER)
Egy adott adatbázis beállításait így tekintheti meg:

csatlakozzon a mintához(minta - adatbázis neve)

lekérni az adatbáziskezelő konfigurációját

Vagy nagyjából ugyanazzal a kéréssel, mint korábban:

válasszon nevet, értéket a sysibmadm.dbcfg fájlból

Hitelesítés

A nagy különbség a DB2 és a többi DBMS között a hitelesítési modellje. Nincsenek belső felhasználók, mint az SQL Serverben vagy a MySQL-ben. Minden hitelesítés a DBMS-en kívüli eszközökkel (dinamikusan betöltött beépülő modulok) – operációs rendszer eszközeivel vagy külső beépülő modulokkal (Kerberos, GSS API) történik. A hitelesítés típusát az adatbázis-kezelő konfiguráció AUTHENTICATION paramétere határozza meg. Az alapértelmezett érték a SZERVER – a felhasználónév és a jelszó tiszta szövegben kerül továbbításra, és ennek a párnak a helyességét az operációs rendszer segítségével ellenőrzik. Ha a felhasználónév és a jelszó helyes, akkor a CONNECT jogosultság ellenőrzésre kerül a felhasználó vagy a hozzá tartozó csoportok esetében (beleértve a speciális NYILVÁNOS csoportot, amely magában foglalja az összes jogosult felhasználót). Ezek a jogosultságok a SYSCAT.DBAUTH táblában tekinthetők meg:

válassza a GRANTEE lehetőséget a SYSCAT.DBAUTH-ból, ahol CONNECTAUTH = "Y"

A beállítás során nagy hiba az KLIENS hitelesítési típus engedélyezése. Ebben az esetben a DB2 bízik a csatlakozó ügyfélben a hitelesítés végrehajtásában, és ha a PUBLIC rendelkezik CONNECT jogosultsággal, akkor bármely felhasználó csatlakozhat az adatbázishoz, és hozzáférhet a PUBLIC összes adatához. A felhasználónév az operációs rendszerből származik. Vagyis ha rendszergazdaként csatlakozunk a Data Studión keresztül, akkor a felhasználó minden jogosultsága megkapja. És ebben az esetben nem mindegy, hogy melyik számítógépről történt a hozzáférés. Ezt a fajta hitelesítést csak akkor javasolt engedélyezni, ha biztonságos csatorna van a kiszolgáló és az ügyfél között, és más ügyfelek nem tudnak csatlakozni a DBMS-hez.

Engedélyezés

A példányspecifikus jogosultságok az adatbázis-kezelő konfigurációjában vannak megadva. Ezek a következő jogosultságok:

  • SYSADM
  • SYSCTRL
  • SYSMAINT
  • SYSMON
Ezeket a jogosultságokat úgy állítják be, hogy megadják a csoportot, amelyhez a felhasználó tartozni fog. A dbmcfg-ben ezek a SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP és SYSMON_GROUP paraméterek.

Ezután vannak adatbázis-specifikus jogosultságok. Ezek olyan jogosultságok, mint az adatbázis elérése (CONNECTAUTH), táblák létrehozása (CREATETABAUTH), szubrutinok létrehozása (EXTERNALROUTINEAUTH) stb. Ezek a jogosultságok a SYSCAT.DBAUTH nézetben tekinthetők meg

És végül, hozzáférési jogosultságok bizonyos adatokhoz - táblákhoz, szubrutinokhoz stb. Itt minden meglehetősen triviális, de bizonyos sajátosságokkal is.

A tábla-hozzáférési jogosultságok a SYSCAT.TABAUTH nézetben tekinthetők meg. A megadott jogosultság típusát a rendszer külön oszlopokban tárolja, magától a jogosultságtól függően (SELECTAUTH, DELETEAUTH stb.). Amikor a GRANT paranccsal ad ki jogosultságot a REFERENCES és UPDATE jogosultságokhoz, megadhatja azoknak az oszlopoknak a nevét is, amelyekre ezek a jogosultságok vonatkozni fognak. Ebben az esetben az ezzel kapcsolatos információk a SYSCAT.COLAUTH nézetben tekinthetők meg

A rutinok (függvények, eljárások és metódusok) jogosultságai a SYSCAT.ROUTINEAUTH-ban tekinthetők meg. Itt minden nem teljesen triviális, a SPECIFICNAME és TYPENAME mezőktől függően egy adott séma összes alprogramjához jogosultság adható.

Ha az olvasóknak tetszik a cikk, akkor készen állok beszélni a DB2 adatvédelméről a címkealapú hozzáférés-vezérlés használatával

A relációs adatbázis kapcsolatok halmaza, amelyek neve megegyezik az adatbázissémában lévő kapcsolatsémák nevével. Ma már ismert nagy szám különféle SQL adatbázis-kiszolgálók. Nézzük a következő négy vezető kiszolgáló DBMS-t - Oracle8i, IBM DB2, Microsoft SQL Szerver és Informix - és hasonlítsa össze őket működés közben a működés minden fő szakaszában.

Oracle8i. Oracle8i csomag, amely a legfejlettebb funkciókkal rendelkezik a Java nyelvvel való munkavégzéshez és az adatok interneten keresztüli eléréséhez, valamint egy rendszerrel az egyidejű hozzáférés optimalizálására. Ennek az DBMS-nek egyetlen hátránya az adminisztráció bonyolultsága, azonban a megvalósítás és a fejlesztés minden költsége megtérül a hatékony és megbízható működés révén. (a bonyolultság és a magas költség vitatható). Az Oracle DBMS főbb tulajdonságai közül a következőket kell megjegyezni: Legmagasabb megbízhatóság. A nagy adatbázisok szekciókra bontásának lehetősége (nagy adatbázis-partíció), ami lehetővé teszi a gigantikus gigabájtos adatbázisok hatékony kezelését; Univerzális információbiztonsági eszközök elérhetősége; Hatékony módszerek maximális növekedés kérés feldolgozási sebessége; Bittérképes indexelés; Szabad táblák (más DBMS-ekben minden tábla a létrehozás után azonnal kitöltésre kerül); Műveletek párhuzamosítása kérésben. Fejlesztési, felügyeleti és adminisztrációs eszközök széles skálájának elérhetősége. Fókuszban az internetes technológiák Az Oracle fejlesztéseinél nem rosszabb megoldások csak az IBM DB2-jében találhatók. Az internetes technológiára való összpontosítás a modern Oracle termékek fő mottója. Ennek kapcsán kiemelhetjük a multimédiás formátumú adatfeldolgozást biztosító interMedia csomagokat és a Java nyelvvel való munkavégzéshez beépített Jservert, amely a Java nyelv képességeit ötvözi a relációs adatbázisok képességeivel. Az Enterprise JavaBeans összetevői azok az alapvető modulok, amelyek a Java nyelv internetes alkalmazásait alkotják. Az Oracle betartja azt az elvet, hogy minden fontos funkciót vezérelni kell egyetlen központ, ezért a javasolt interMedia modul a felhasználók számára a legfejlettebb lehetőségeket kínálja a multimédiás objektumokkal való munkavégzéshez: Nagyon fejlett eszközök hangklipek feldolgozásához; Állóképek; Videoklipek; Földrajzi adatok (a helymeghatározáshoz kapcsolódó funkciók egész sorával, amelyek a lokátor modulban találhatók). Az Oracle8i napjaink legjobb eszközeit valósítja meg az objektumorientált adatbázis-tervezéshez, beleértve a táblaszerkezeteket, amelyek lehetővé teszik más táblaadatbázis-objektumok tulajdonságainak és metódusainak öröklését, ami segít elkerülni a hibákat az adatbázisok felépítése során, és megkönnyíti azok karbantartását. Azt is meg kell jegyezni, hogy az Oracle által kifejlesztett többverziós párhuzamosság-optimalizáló rendszer az Oracle architektúra egyik legfontosabb jellemzője (hasonló funkció csak az InterBase DBMS-ben érhető el az InterBase-től az Inprise-től). Ez a funkció lehetővé teszi, hogy kiküszöbölje azt a helyzetet, amikor az egyik felhasználónak várnia kell a másikra, hogy befejezze az adatbázisok tartalmának módosítását (azaz az Oracle-ben nincsenek olvasási zárak). Ez a funkció lehetővé teszi az Oracle8i számára, hogy másodpercenként több tranzakciót hajtson végre felhasználónként, mint bármely más adatbázis. A LINUX alatti WEB-környezetben végzett munka teljesítményét tekintve az Oracle megtisztelő második helyet foglal el mögötte MySQL DBMS, miközben megbízhatóságban és biztonságban jelentősen felülmúlja az összes többi DBMS-t.

DBMS Microsoft SQL Server Ennek a DBMS-nek a legfontosabb jellemzői a következők: egyszerű adminisztráció, a webhez való csatlakozás képessége, a DBMS szerver mechanizmusának sebessége és funkcionalitása, az eszközök elérhetősége távoli hozzáférés Az ehhez a DBMS-hez tartozó adminisztrációs felügyeleti eszközök készlete speciális varázslók és konfigurációs paraméterek automatikus beállítására szolgáló eszközök egész készletét tartalmazza. Ezenkívül ez az adatbázis kiváló replikációs eszközökkel van felszerelve, amelyek lehetővé teszik a PC-adatok és az adatbázis-információk szinkronizálását, és fordítva. A mellékelt OLAP szerver lehetővé teszi a felhasználó számára elérhető összes adat mentését és elemzését. Ez a DBMS elvileg egy modern, teljesen működőképes adatbázis, amely ideális kis- és közepes méretű szervezetek számára. Meg kell jegyezni, hogy az SQL Server két fontos mutatóban alulmúlja a többi vizsgált DBMS-t: a programozhatóságot és az operációs eszközöket. Java és HTML nyelveken alapuló kliens adatbázis-alkalmazások fejlesztésekor gyakran felmerül az elégtelen SQL Server szoftver problémája, és ennek a DBMS-nek a használata nehezebb lesz, mint a DB2, Informix, Oracle vagy Sybase rendszerek esetében. A 21. század globális trendje szinte egyetemes átállássá vált a LINUX platformra, és az SQL Server csak Windows környezet. Ezért az SQL Server használata csak akkor tanácsos, ha az ODBC szabványt kizárólag az adatbázis-tartalmak elérésére használják; ellenkező esetben jobb, ha más DBMS-eket használ.

IBM DB2 Az IBM DB2 DBMS csaknem 30 fejlesztés eredménye és kutatómunka IBM cég. A DBMS legújabb verziója (6.x) az egyik legátgondoltabb felügyeleti és optimalizálási eszközkészlettel, valamint egy olyan adatbázis-motorral tűnik ki, amely lehetővé teszi a Windows 95 operációs rendszerű hordozható PC-ről S/390 nagyszámítógépek teljes fürtjére való bővítést. OS/390. A DB2 két kiadásban érhető el: DB2 Workgroup és DB2 Enterprise Edition. Ez a DBMS megvalósítja a DB2 korábbi verzióiból ismert összes innovatív adatbázismotor-technológiát, például a lekérdezésfeldolgozás párhuzamosítását, a replikációs eszközök teljes készletét, az adatbázis-teljesítményt javító lekérdezési összefoglaló táblákat, az objektumorientált adatbázis-tervezési képességeket és a Java nyelvi eszközöket. Ehhez hozzávesszük, hogy a DB2 rendszer a multimédiás bővítmények teljes skálájával van felszerelve, amelyek lehetővé teszik szövegek, hangok és videók, képek és földrajzi adatok tárolását és kezelését. Elmondhatjuk, hogy az IBM szakemberei által kifejlesztett adatbázis-fürtözési technológiának nincsenek analógjai a skálázási képességek tekintetében. Ezek a bővítmények nagymértékben megkönnyítik a webes alkalmazások, valamint a fényképeket és nagy szöveges jelentéseket tartalmazó programok fejlesztését. A DB2 rendszer az alkalmazásfejlesztés platformjaként is meglehetősen versenyképes, mert van egy Stored Procedure Builder eszköz, amely automatikusan konvertálja SQL utasítás a megfelelő Java osztályba, és beépítjük az adatbázis szerkezetébe. A DB2 6.1 jelentősen javítja az együttműködést más adatbázis-kezelő rendszerekkel azáltal, hogy lehetővé teszi a Microsoft OLE DB specifikációjának, egy új adatbázis-hozzáférési szabványnak a használatát. DB2 DBMS adminisztrációs vezérlők, amelyek új verzió Java nyelven átírva, és beszerezhető a weben, a legnagyobb dicséretet érdemlik. Ennek a DBMS-nek a fő hátránya az adminisztráció viszonylagos bonyolultsága és a népszerű szerver operációs rendszerek, például a LINUX megvalósításának (még) hiánya. Ebben a DBMS-ben az Index Smart-Guide-nak köszönhetően lehetőség van konfigurálni, adott számú találathoz optimális indexeket képezni, amelyek jellemzik az adatbázis tipikus terhelését. A DB2 az egyetlen olyan csomag, amely lehetővé teszi összefoglaló táblák létrehozását, ami jelentősen javítja a DBMS mint adattárház hatékonyságát. A pivot tábla egy ideiglenes munkaterület, amelyet az adatbázis használ a gyakran kapott lekérdezések válaszainak tárolására. A DB2 6.1 az elérhető legolcsóbb nagy teljesítményű rendszerré válik. Ennek a DBMS-nek adminisztratív menedzsment eszközei teljes mértékben összhangban vannak a megoldandó feladatok szintjével, emellett rendkívül széleskörű lehetőségeket biztosít a multimédiás adatokkal való munkavégzéshez és a programozáshoz (ami nyilvánvalóan hiányzik). Microsoft rendszer SQL szerver).

DBMS az Informix-től. Az utóbbi időben megtörtént az átállás a relációs DBMS-ről az objektum-orientáltakra (ami jól látható az Oracle példáján). Az Informix – szintén ezt a koncepciót követve – új Centaur DBMS megoldást jelentett be, amely az Informix Dynamic Server 7.3 relációs adatbázison és az Informix Universal Data Option objektumrelációs adatbázison alapul, és ötvözi a Dynamic Server nagy teljesítményét az adatokkal való munka során a sokoldalúsággal és multimédiával. az Universal Data Option funkciói. Ez a megvalósítás internetes rendszerek fejlesztésére szolgál. Ez a DBMS feltehetően rugalmas, az Internetre jellemző intenzív munkaterhelésnek megfelelő skálázhatósággal rendelkező fejlesztői környezettel, új típusú adatokkal való munkavégzéshez szükséges eszközökkel rendelkezik majd, amelyek a Web fejlődésével mindenhol elterjedtek. Az új rendszerben implementált Java eszközök segítségével a fejlesztők tárolt eljárásokat, felhasználói programokat és DataBlades komponenseket hozhatnak létre ezen a nyelven, amit az Informix hív meg.

egyéni adatbázis-bővítmények. Az Inforix ügyfelek szempontjából ez nagy előrelépés lesz, hiszen eddig a DataBlades-szel dolgozva csak C-t és SPL-t, az Informix belső nyelvét használhatták a tárolt eljárások írására. Emellett a Centaur beépített ActiveX objektumkezeléssel is rendelkezik majd. Ez lehetővé teszi például tárolt adatbázis-eljárások létrehozását a nyelven Visual Basic; Ehhez azonban az szükséges, hogy a Centaur csomagot Windows NT környezetben kell végrehajtani. A Centaur az Informix Dynamic Server kiegészítője lesz, és az ehhez a csomaghoz hagyományos adatbázis-formátummal fog működni, így a felhasználók továbbra is minden korábbi funkció rendelkezésükre állnak, és a rendszer frissítése az új verzió szintjére nem nagy nehézségekkel járhat együtt. Emellett a Centaur megőrzi mindazokat a tervezési és programozási képességeket, amelyek az Informix Universal Servert kiemelkedő műszaki vívmányokká tették. Az új rendszer objektumorientált adatbázis-tervezési, speciális táblák és indexelő programok készítésére szolgáló eszközökkel lesz felszerelve; lehetővé teszi a felhasználók számára, hogy saját függvényeiket lekérdezésekbe építsék, és ne csak azokra hagyatkozhassanak szabvány azt jelenti SQL. Következtetések. Az AIS, a szerver operációs rendszerek és a DBMS felépítéséhez szükséges architektúrák főbb jellemzőit figyelembe véve a jövőben az Internet/Intranet architektúrát választjuk AIS architektúrának, a Linuxot szerver operációs rendszernek, az Oracle 8i-t pedig DBMS-nek.

2) SQL SELECT záradék. Beépített funkciók.

SELECT oszlop FROM táblázat WHERE oszlop LIKE minta

SELECT * FROM Store_Information WHERE üzletnév LIKE "%AN% ‘;

SELECT oszlopnév FROM táblanév WHERE oszlopnév KÖZÖTT érték1 ÉS érték2

SELECT * FROM Személyek WHERE Vezetéknév "Hansen" ÉS "Pettersen" KÖZÖTT;

SELECT * FROM Személyek WHERE Vezetéknév NEM "Hansen" ÉS "Pettersen" KÖZÖTT;

VÁLLALAT KIVÁLASZTÁSA, Rendelési szám FROM Megrendelésekből ORDER BY( rendezés ) Társaság;

VÁLLALAT KIVÁLASZTÁSA, Rendelési szám FROM Megrendelésekből ORDER BY Company, OrderNumber;

VÁLLALAT KIVÁLASZTÁSA, Rendelési szám FROM Megrendelésekből ORDER BY Company DESC( fordított sorrendben ) ;

VÁLLALAT KIVÁLASZTÁSA, Rendelési szám FROM Megrendelések ORDER BY Cég szerint DESC , Rendelési szám ASC( jobb rendelés);

SELECT * FROM Személyek WHERE FirstName="Tove" AND LastName="Svendson";

SELECT * FROM Személyek WHERE keresztnév="Tove" OR vezetéknév="Svendson" ;

SELECT * FROM Személyek WHERE (FirstName="Tove" OR FirstName="Stephen") AND LastName="Svendson" ;

SELECT üzletnév FROM Store_Information WHERE Értékesítés > 1000 VAGY (Értékesítés< 500 AND Sales > 275);

FunkciókKIVÁLASZTÁSfunkció( oszlop) TÓL TŐLasztal AVG - átlagos érték az oszlopban; SZÁMOL - az értékek száma az oszlopban; MAX – a legtöbb nagyon fontos oszlopban; MIN - a legkisebb érték az oszlopban; SUM - az értékek összege oszloponként

Példák: KIVÁLASZTÁS AVG(Kor) FROM Személyek; KIVÁLASZTÁS SZÁMOL(store_name) FROM Store_Information; KIVÁLASZTÁS SZÁMOL(KÜLÖNBÖZŐ bolt_neve) FROM Store_Information; KIVÁLASZTÁS MAX(Kor) FROM Személyek SELECT ÖSSZEG(Értékesítés) FROM Store_Információ;

3) Tranzakciók sorozatosítása, műveleti konfliktusok. Tranzakciók sorozatosítási módszerei. Szinkronizáló fogantyúk, szemcsés szinkronizáló fogók. Tranzakciók sorozatosítási módszerei. Predikátum szinkronizálási rögzítések. Sorozatosítás időbélyegek alapján.

A tranzakciók elkülönítése érdekében a DBMS-nek olyan módszereket kell használnia, amelyek szabályozzák a tranzakciók közös végrehajtását. Meghívják a tranzakciók halmazának végrehajtásának tervét (módját). sorozatszám, ha a tranzakciók együttes végrehajtásának eredménye egyenértékű ugyanazon tranzakciók valamilyen szekvenciális végrehajtásának eredményével. Tranzakciók sorosítása- ez egy mechanizmus a megvalósításukhoz valamilyen sorozatos terv szerint. Egy ilyen mechanizmus biztosítása a tranzakciók kezeléséért felelős DBMS-komponens fő funkciója. A tranzakciók sorozatosítását támogató rendszer valós felhasználói elszigetelést biztosít. A fő megvalósítási probléma az, hogy olyan módszert válasszunk a tranzakciók sorozatának szerializálására, amely nem korlátozza túlságosan azok egyidejűségét. Egy triviális megoldás jut eszünkbe a tranzakciók tényleges végrehajtása egymás után. Vannak azonban olyan helyzetek, amikor a különböző tranzakciók utasításait bármilyen sorrendben végrehajthatja a sorozatosság megőrzése mellett. A példák közé tartoznak a csak olvasható tranzakciók, valamint azok a tranzakciók, amelyek nem ütköznek az adatbázis-objektumokkal. A következő típusú ütközések lehetnek a tranzakciók között: W-W - a 2. tranzakció egy olyan objektumot próbál módosítani, amelyet az 1. tranzakció módosított, és amely nem fejeződött be; R-W - a 2. tranzakció egy, az 1. tranzakció által beolvasott objektumot próbál módosítani, amely nem fejeződött be; W-R - A 2. tranzakció olyan objektumot próbál beolvasni, amelyet az 1. tranzakció módosított, és amely nem fejeződött be. A tranzakciók sorozatosításának gyakorlati módjai ezen ütközések figyelembevételén alapulnak.

Létezik két alapvető megközelítés a tranzakciók szerializálásához - adatbázis-objektumok szinkronizált rögzítésén és időbélyegek használatán alapul. Mindkét megközelítés lényege a tranzakciós konfliktusok észlelése és megoldása. A központosított DBMS-ekben (ideértve a kliens-szerver architektúrán alapuló rendszereket is) a leggyakoribb megközelítés a megfelel a kétfázisú szinkronizálási rögzítési protokollnak adatbázis objektumok. Általánosságban elmondható, hogy a protokoll az, hogy mielőtt bármilyen műveletet végrehajtana a T tranzakcióban egy r adatbázis-objektumon a T tranzakció nevében, az r objektum szinkronizálási rögzítését kérik a megfelelő módban (a művelet típusától függően). A szinkronizálási rögzítés főbb módjai a következők: egyesített mód - S (Shared), ami egy objektum megosztott rögzítését jelenti, és szükséges az objektumolvasási művelet végrehajtásához; exkluzív mód - X (eXclusive), ami egy objektum kizárólagos rögzítését jelenti, és szükséges a hozzáadási, törlési és módosítási műveletek végrehajtásához. Granulált időzítő markolat - olyan megközelítés, amelyben szinkronizálási rögzítések kérhetők az objektumoktól különböző szinteken: fájlok, relációk és sorok. A szükséges objektumszintet az határozza meg, hogy milyen műveletet hajtunk végre (például egy megsemmisítő reláció művelet végrehajtásához a teljes relációnak a szinkronizálási rögzítés tárgyának kell lennie, a sortörlés művelet végrehajtásához pedig ennek a leírónak a a szinkronizálás rögzítése). Bármilyen szintű objektum rögzíthető S vagy X módban. Predikátum időzítés rögzítése- ez nem az objektumok rögzítése, hanem azok a feltételek (predikátumok), amelyeket ezek az objektumok teljesítenek A tranzakció-szerializálás alternatív módszere, amely jól működik ritka tranzakciós konfliktusok körülményei között, és nem igényel tranzakcióváró gráf felépítését. alapján időbélyegek használatával. A módszer alapötlete (amelynek számos változata van) a következő: ha a T1 tranzakció a T2 tranzakció előtt kezdődött, akkor a rendszer ugyanazt a végrehajtási módot biztosítja, mintha T1 teljesen végrehajtódott volna a T2 megkezdése előtt.

Ehhez minden T tranzakcióhoz hozzárendelünk egy t időbélyeget, amely megfelel a T kezdő időpontjának. Amikor egy műveletet végrehajtunk egy r objektumon, a T tranzakció megjelöli az időbélyeggel és a művelet típusával (olvasás vagy módosítás). Mielőtt műveletet hajt végre egy r objektumon, a T1 tranzakció a következő műveleteket hajtja végre: Ellenőrzi, hogy az objektumot megjelölő T tranzakció befejeződött-e. Ha T véget ért, T1 megjelöli r objektumot és végrehajtja a műveletet. Ha a T tranzakció nem fejeződött be, akkor T1 ellenőrzi az ütköző műveleteket. Ha a műveletek nem ütköznek egymással, akkor az r objektumot hagyjuk, vagy alacsonyabb értékkel látjuk el, és a T1 tranzakció végrehajtja a műveletet. Ha a T1 és a T művelet ütközik, akkor ha t(T) > t(T1) (vagyis a T tranzakció fiatalabb, mint T), T visszagörgetésre kerül, és T1 folytatódik. Ha t(T)< t(T1) (T "старше" T1), то T1 получает новую временную метку и начинается заново. К недостаткам метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования синхронизационных захватов. Это связано с тем, что конфликтность транзакций определяется более грубо. Кроме того, в распределенных системах не очень просто вырабатывать глобальные временные метки с отношением полного порядка.