DB2(v ruštině se vyslovuje „dibi dva“, pauzovací papír z angličtiny „dibi tu“ je také běžný) - rodina softwarových produktů v oboru Information Management ve společnosti IBM.

Nejčastěji, když se odkazuje na DB2, mají na mysli systém správy relačních databází DB2 Universal Database (DB2 UDB), vyvinutý a vydaný IBM.

Pravopis "DB/2" je někdy vidět, ale tento pravopis je nesprávný: v zápisu IBM znamená číslo ve jmenovateli zlomku platformu a "/2" znamená produkt pro operační systém OS/2 (resp. řada počítačů PS/2). Například verze DB2 pro OS/2 byla označena jako "DB2/2".

Implementace

DB2 DBMS je aktuálně dostupný na následujících platformách:

• DB2 pro Linux, UNIX a Windows v9 pro platformy AIX, HP-UX, Linux, Solaris, Windows a beta pro platformu Mac OS X
• DB2 pro z/OS v9 pro platformy z/OS a OS/390
• Server DB2 pro VSE & VM v7 pro platformy z/VM a z/VSE
• DB2 pro i pro platformu IBM i (integrované do systému na úrovni hardwaru a softwaru)

V minulosti byly vydány verze databázového serveru DB2 pro OS/2, UnixWare, PTX.

DB2 DBMS klienti kromě uvedených platforem vycházejí nebo byli vydáni v různých verzích také pro SINIX, IRIX, klasický Mac OS a pro MS-DOS, jakož i v mobilní verze DB2 Everyplace pro Windows CE, Palm OS, Symbian OS, Neutrino a virtuální stroj Jáva.

V současné době IBM kromě komerčních produktů rodiny distribuuje také bezplatnou distribuci DB2 Express-C pro platformy Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 beta). Bezplatná verze má omezení na použití nejvýše jednoho dvoujádrového procesoru a 2 GB pro provoz DBMS paměť s náhodným přístupem(celkový počet procesorů a paměti v systému může být libovolný, ale zdroje nad zadané limity nebudou DBMS využívány).

Příběh

DB2 má dlouhou historii a někteří jej považují za první DBMS používající SQL.

Od roku 1975 do roku 1982 byl prototyp DB2 vyvíjen v IBM pod názvem System Relational nebo System R. Jazyk SQL byl poprvé implementován v IBM System R, ale tento systém byl výzkumné povahy a komerční produkt, včetně SQL, byl poprvé uveden na trh společností Oracle v roce 1979.

DB2 získalo své jméno v roce 1982 s prvním komerčním vydáním pro SQL/DS a poté pro MVS s názvem DB2. Dlouhou dobu se spolu s "DB2" používala varianta "Database 2", také ochranná známka IBM. Zřejmě se mělo jednat o druhou vlajkovou loď IBM DBMS po staré hierarchické IMS DBMS.

Vývoj DB2 sahá až do počátku 70. let, kdy doktor E. F. Codd, který pracoval pro IBM, vyvinul teorii relačních databází a v červnu 1970 zveřejnil model manipulace s daty. Pro implementaci tohoto modelu vyvinul jazyk relační databáze a nazval jej Alpha. IBM se rozhodla zadávat další vývoj skupině programátorů mimo kontrolu Dr. Codda. Porušili některé principy relačního modelu a implementovali jej jako „strukturovaný anglický jazykžádosti“, zkráceně SEQUEL. Vzhledem k tomu, že SEQUEL již byla registrovaná ochranná známka, byl název zkrácen na SQL – „Structured Query Language“ a zůstal tak dodnes.

Historicky se tedy DB2 vyvinul z DB2 pro MVS (jehož je potomkem DB2 for z/OS) a jeho sesterského SQL/DS pro VM (jehož potomkem je DB2 Server pro VSE & VM). Později další tým vývojářů v IBM implementoval server OS/2 EE Database Manager, který se později vyvinul v DB2 v2 pro OS/2, AIX a poté Windows a poté v DB2 UDB (jeho potomek je DB2 pro Linux, UNIX a Windows ). Další tým dokončil integraci architektury DB2 s vestavěnou databází AS/400 (potomek - DB2 for i). IBM postupně směřuje k integraci všech těchto větví.

Zvláštnosti

Mezi charakteristické rysy DB2 patří dialekt jazyk SQL, který až na vzácné výjimky určuje čistě deklarativní význam jazykových konstrukcí, a výkonný vícefázový optimalizátor, který na základě těchto deklarativních konstrukcí sestaví efektivní plán provádění dotazů. Na rozdíl od jiných dialektů SQL nemá dialekt DB2 SQL pro optimalizátor prakticky žádné rady, je špatně vyvinutý (a na dlouhou dobu obecně chyběl) jazyk uložených procedur, a proto je vše zaměřeno na zachování deklarativního stylu psaní dotazů. Jazyk DB2 SQL je přitom výpočetně kompletní, to znamená, že potenciálně umožňuje definovat jakékoli vyčíslitelné korespondence mezi zdrojovými daty a výsledkem v deklarativní podobě. Toho je dosaženo mimo jiné použitím tabulkových výrazů, rekurze a dalších pokročilých mechanismů manipulace s daty.

Vzhledem k zaměření IBM na relační vývoj a pozici firmy v počítačovém průmyslu má dialekt DB2 SQL významný dopad na standardy ANSI/ISO SQL.

Uložené procedury se v DB2 příliš nepoužívají a pro zápis uložených procedur se tradičně používají běžné programovací jazyky na vysoké úrovni (C, Java, PL/I, Cobol atd.), což umožňuje programátorovi snadno formátovat stejný kód buď jako součást aplikace, nebo jako uložená procedura, podle toho, zda je vhodnější ji spustit na klientovi nebo na serveru. DB2 také v současné době implementuje procedurální rozšíření SQL pro uložené procedury v souladu se standardem ANSI SQL/PSM.

Optimalizátor DB2 široce využívá statistiky distribuce tabulek (pokud proces sběru dat prováděl DBA), takže stejný dotaz SQL lze přeložit do zcela odlišných plánů provádění v závislosti na statistických charakteristikách dat, která zpracovává.

Vzhledem k tomu, že se DB2 historicky vyvinul z víceuživatelských systémů na sálových počítačích, je v architektuře DB2 věnována velká pozornost otázkám zabezpečení a rozdělení rolí specialistů spravujících DB2. Konkrétně, na rozdíl od mnoha jiných DBMS, DB2 má samostatné role pro správce DBMS (odpovědný za konfiguraci softwarové komponenty DB2 a jejich optimální provedení v počítačový systém) a správce databáze (odpovědný za správu dat v konkrétní databázi).

V případě potřeby použití statického SQL v programech a koncepce balíčků umožňuje, na rozdíl od většiny ostatních DBMS, implementaci takového bezpečnostního modelu, kdy práva k provádění určitých operací mohou být udělena aplikačním programům bez takových práv. pro uživatele pracující s těmito programy. V tomto případě to umožňuje zaručit nemožnost práce uživatele s databází obejít aplikační program, pokud má uživatel pouze práva ke spuštění programu, nikoli však k samostatné manipulaci s daty.

V rámci konceptu zvyšování úrovně integrace bezpečnostních nástrojů v počítačovém systému nemá DB2 vlastní prostředky pro ověřování uživatelů, integraci s nástroji operačního systému nebo specializovanými bezpečnostními servery. V rámci DB2 jsou autorizováni pouze uživatelé ověření systémem.

DB2 je jediným obecným relačním DBMS, který má implementace na úrovni hardwaru/softwaru (systém IBM i; podpora DB2 je implementována také na hardwaru sálových počítačů IBM System z).

Moderní verze DB2 poskytují rozšířenou podporu pro používání XML dat, včetně operací s jednotlivými prvky XML dokumentů.

Chyba při zpracování

Užitečnou funkcí DB2 SQL Server je jeho schopnost zpracovávat chyby. K tomuto účelu se používá struktura SQLCA. Komunikační oblast SQL- Oblast odkazů SQL), která vrací informace o chybě do aplikačního programu po každém provedení příkazu SQL.

Pole struktury SQLCODE a jejich hodnoty

Hlavní, ale ne vždy užitečná diagnostika chyb je obsažena v terénu SQLCODE(datový typ - celé číslo) uvnitř bloku SQLCA. Může nabývat následujících hodnot:

• 0 znamená úspěch.
• Kladné číslo znamená úspěch s jedním nebo více varováními. Například +100 znamená, že nebyly nalezeny žádné sloupce.
• Záporné číslo znamená selhání s chybou. Například −911 znamená detekovaný interval čekání na zámek (nebo uváznutí), který spouští sekvenční vrácení zpět.

SQLERRM(datový typ - řetězec 71 znaků). Obsahuje textový řetězec s popisem chyby, pokud je pole SQLCODE menší než nula.

SQLERRD(datový typ - pole, 6 celých čísel). Popisuje výsledek provedení posledního příkazu SQL:

• 1 prvek - interní informace;
• 2. prvek - obsahuje hodnotu pole typu SERIAL vygenerovanou serverem pro příkaz INSERT nebo dodatečný chybový kód;
• 3. prvek - roven počtu zpracovaných záznamů;
• 4. prvek - přibližné náklady na provedení tohoto operátoru;
• 5. prvek - offset chyby v textovém záznamu SQL příkazu;
• 6. prvek - interní informace.

Poznámky

Odkazy

• Stránka programu na webu IBM
• DB2 na developerWorks - DB2 články a školení
• PlanetDB2 – blogy DB2

Literatura

• Datum K. Příručka DB2 Relational DBMS. - M.: Finance a statistika, 1988. - 320 s. - ISBN 5-279-00063-9
• Zikopoulos P.K., Baklarz J., deRus D., Mělník R.B. DB2 verze 8: Oficiální příručka = DB2 verze 8: Oficiální příručka. - M.: KUDITS-OBRAZ, 2004. - 400 s. - ISBN 5-9579-0031-1
• Smirnov S.N. Práce s IBM DB2: Výukový program. - M.: Helios, 2001. - 304 s. - ISBN 5-85438-007-2 (doporučeno univerzitami UMO v regionu informační bezpečnost jako učební pomůcka v oborech "Integrovaná informační bezpečnost automatizovaných systémů" a "Počítačová bezpečnost")
• Susan Visser, Bill Wong. Naučte se DB2 Universal Database za 21 dní = Sams Naučte se DB2 Universal Database za 21 dní. - 2. vyd. - M.: Williams, 2004. - 528 s. - ISBN 0-672-32582-9
• Hook J., Harbus R., Snow D. Universal Guide to DB2 for Windows NT®. - New Jersey: Prentice Hall PTR, 1999. - S. 504. - ISBN 0-13-099723-4

Nadace Wikimedia. 2010 .

Podívejte se, co je "IBM DB2" v jiných slovnících:

IBM DB2- Vývojáři IBM První vydání 1983 (1983) ... Wikipedie

IBM DB2- DB2 je kommerzielles relations Datenbank Management System (RDBMS) der Firma IBM, dessen Ursprünge auf das System R and grundlagen von E. F. Codd z IBM Research aus dem Jahr 1970 zurückgeht. Inhaltsverzeichnis 1 Eigenschaften 1.1… … Deutsch Wikipedia

IBM DB2- Verze Développeur IBM Dernière ... Wikipedia en Français

IBM DB2 Commonstore- Archivační software DB2 CommonStore od IBM pro správu e-mailových zpráv nebo dat SAP ERP. Část portfolia IBM Information Management, které staví na databázové platformě DB2. DB2 CommonStore je jedním z několika produktů, které jsou… … Wikipedie

V práci jsem se nějakou dobu musel potýkat s IBM DB2 DBMS. Protože Vzhledem k tomu, že systém je komerční, není na internetu mnoho informací v ruštině, proto jsem se rozhodl popsat některé funkce tohoto DBMS.

Místo vstupu

Začněme vstupním bodem v DBMS. V SQL SERVER koncový bod je instance, ve které samozřejmě mohou existovat samostatné databáze, ale konfigurace a bezpečnostní model jsou pro celou instanci stejné. V DB2 vypadá vstupní bod takto - instance (která odpovídá konkrétnímu portu) - databáze. Zároveň existuje konfigurace pro celou instanci a pro samostatnou databázi.

Konfiguraci instance můžete zobrazit buď pomocí příkazu db2:

Konfigurace správce databáze

Typ uzlu = Enterprise Server Edition s místními a vzdálenými klienty

Úroveň vydání konfigurace správce databáze = 0x0b00

Rychlost CPU (milisekundy/instrukce) (CPUSPEED) = 2,912790e-07
Šířka komunikačního pásma (MB/s) (COMM_BANDWIDTH) = 1,000000e+02

Maximální počet současně aktivních databází (NUMDB) = 8
Podpora federovaného databázového systému (FEDERATED) = ANO
Název monitoru transakčního procesoru (TP_MON_NAME) =

Výchozí účet pro zpětné zúčtování (DFT_ACCOUNT_STR) =

Instalační cesta Java Development Kit (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Úroveň zachycení diagnostických chyb (DIAGLEVEL) = 3
Úroveň oznámení (NOTIFYLEVEL) = 3
Cesta k adresáři diagnostických dat (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Výchozí přepínače monitoru databáze
Fond vyrovnávací paměti (DFT_MON_BUFPOOL) = VYPNUTO

Kde budou parametry specifikovány, jejich význam a dekódování. Je možná i zkrácená verze:

získat dbm cfg

Nebo s dotazem:

Vyberte název, hodnotu z sysibmadm.dbmcfg

Z důležité parametry můžete poznamenat:

• typ ověření (AUTHENTICATION)
• výchozí cesta pro vytváření nových databází (DFTDBPATH)
• zjišťování síťového serveru (DISCOVER)

Nastavení pro konkrétní databázi můžete zobrazit takto:

připojit ke vzorku(ukázka - název databáze)

získat konfiguraci správce databází

Nebo s přibližně stejným požadavkem jako dříve:

vyberte název, hodnotu ze sysibmadm.dbcfg

Autentizace

Velký rozdíl mezi DB2 a ostatními DBMS spočívá v autentizačním modelu. Neexistují žádní interní uživatelé jako v SQL Server nebo MySQL. Veškerá autentizace se provádí pomocí externích prostředků k DBMS (dynamicky načítané pluginy) - pomocí operačního systému nebo externích pluginů (Kerberos, GSS API). Typ ověřování se nastavuje v parametru AUTHENTICATION konfigurace správce databází. Ve výchozím nastavení je nastavena hodnota SERVER - uživatelské jméno a heslo jsou přenášeny jako prostý text a správnost této dvojice je kontrolována pomocí operačního systému. Pokud je uživatelské jméno a heslo správné, pak se zkontroluje oprávnění CONNECT pro uživatele nebo skupiny, kterých je členem (včetně speciální skupiny PUBLIC, která zahrnuje všechny oprávněné uživatele). Tato oprávnění lze zobrazit v tabulce SYSCAT.DBAUTH:

vyberte GRANTEE ze SYSCAT.DBAUTH, kde CONNECTAUTH = "Y"

Velkou chybou konfigurace je zahrnutí typu autentizace KLIENT. V tomto případě DB2 důvěřuje autentizaci připojujícího se klienta, a pokud má PUBLIC oprávnění CONNECT, může se k databázi připojit jakýkoli uživatel a mít přístup ke všem datům, která má PUBLIC. Uživatelské jméno je převzato z operačního systému. To znamená, že pokud se připojíme přes Data Studio jako uživatel Administrator, pak všechna oprávnění, která tohoto uživatele. A v tomto případě není rozdíl, ze kterého počítače byl přístup proveden. Tenhle typ autentizaci se doporučuje povolit pouze v případě, že mezi serverem a klientem existuje zabezpečený kanál a ostatní klienti se nebudou moci připojit k DBMS.

Povolení

Oprávnění na úrovni instance jsou zapsána v konfiguraci správce databází. Jedná se o následující privilegia:

• SYSADM
• SYSCTRL
• SYSMAINT
• SYSMON

Tato oprávnění se nastavují určením skupiny, do které bude uživatel vstupovat. V dbmcfg jsou to volby SYSADM_GROUP , SYSCTRL_GROUP , SYSMAINT_GROUP a SYSMON_GROUP.

Dále jsou zde oprávnění specifická pro databázi. Jsou to oprávnění, jako je přístup k databázi (CONNECTAUTH), vytváření tabulek (CREATETABAUTH), vytváření rutiny (EXTERNALROUTINEAUTH) a tak dále. Tato oprávnění lze zobrazit v pohledu SYSCAT.DBAUTH

A konečně přístupová oprávnění ke konkrétním datům – tabulkám, podprogramům a tak dále. Vše je zde celkem triviální, ale také s některými zvláštnostmi.

Přístupová oprávnění k tabulce lze zobrazit v pohledu SYSCAT.TABAUTH. Typ uděleného oprávnění je uložen v samostatných sloupcích v závislosti na samotném oprávnění (SELECTAUTH, DELETEAUTH atd.). Při udělování oprávnění pomocí příkazu GRANT pro oprávnění REFERENCES a UPDATE můžete také zadat názvy sloupců, na které budou daná oprávnění rozšířena. V tomto případě lze informace o tomto zobrazit v pohledu SYSCAT.COLAUTH

Oprávnění pro rutiny (funkce, procedury a metody) lze zobrazit v SYSCAT.ROUTINEAUTH . Zde není vše triviální, v závislosti na polích SPECIFICNAME a TYPENAME lze udělit oprávnění všem podprogramům daného schématu.

Pokud se čtenářům článek líbí, pak jsem připraven mluvit o ochraně dat v DB2 pomocí Label-Based Access Control

Přehled základních pojmů a obecný popis Databázové architektury IBM DB2 pro platformy Linux, Unix a Windows

Obsahová řada:

Tento obsah je součástí # série # článků: Přehled DB2 LUW

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=

Zůstaňte naladěni na nové články v této sérii.

Suroviny a kontaktní informace

Zvláštní poděkování Marku Barinshteinovi za to, že si udělal čas na korekturu materiálu článků, pozornost k detailu a cenné komentáře.

Hlavní část materiálu článků tvoří volná interpretace oficiální dokumentace db2. Prezentované informace byly restrukturalizovány a přeformulovány tak, aby byly stručné a zároveň co nejjasnější. Odkazy na zdroje použité ve všech případech jsou uvedeny v textu článků a v sekci „Zdroje“.

V rámci série článků je plánováno přezkoumání následujících problémů:

1. (článek, který právě čtete)
2. (instalace, konfigurace, diagnostika, záloha a zotavení)
3. pokročilé administrativní postupy (přenos informací, optimalizace výkonu, řízení priorit realizace);
4. nástroje pro budování analytických datových skladů;
5. In-memory analytické technologie - DB2 BLU;
6. masivně paralelní zpracování analytických dat pomocí DB2 DPF (Database Partitioning Feature);
7. distribuované databáze (konfigurace převzetí služeb při selhání, replikace dat a federovaný přístup k datům);
8. Schopnosti klastrování DB2 pureScale pro odolnost proti chybám a škálovatelnost.

Články v seriálu budou publikovány, jakmile budou připraveny příslušné materiály.

produktová řada DB2

Název „DB2“ používá IBM pro celou rodinu produktů, které se od sebe liší jak skladbou hardwarových a softwarových platforem, na kterých jsou použity, tak funkčností, architekturou a technologickými vlastnostmi. Tyto rozdíly jsou způsobeny úzkou integrací většiny produktů řady DB2 s operační systémy ve kterých fungují, a také specifika těchto operačních systémů.

Rodina produktů DB2 aktuálně zahrnuje:

• DB2 pro Linux, Unix a Windows, nebo DB2 LUW - DBMS pro systémy se systémem Linux (RedHat, SuSE, Ubuntu), UNIX (AIX, HP-UX, Solaris) a Microsoft Windows, který je předmětem tohoto článku a dalších článků z této série;
• DB2 pro z/OS- DBMS pro operační systém z/OS používaný na sálových počítačích IBM System z;
• Server DB2 pro VSE & VM- DBMS pro provozování z/VM a z/VSE používané na sálových počítačích IBM System z;
• DB2 pro i- DBMS pro operační systém System i používaný na platformě IBM Power.

Každý z uvedených DBMS je architektonicky přizpůsoben pro co nejefektivnější fungování v odpovídajících operačních systémech a obsahuje vlastní specifickou sadu nástrojů a nástrojů pro správu.

Terminologie použitá v dokumentaci pro různé DBMS rodiny DB2 není jednotná a stejné termíny mohou mít pro různé varianty DB2 různé významy: například termíny „databáze“ a „tabulkový prostor“ mají pro DB2 LUW a DB2 různé významy. pro z/OS, kvůli architektonickým rozdílům mezi těmito typy DBMS.

Při práci s informačními zdroji věnovanými DB2 je tedy nutné jasně rozlišit, o kterém z produktů rodiny se diskutuje, aby nedocházelo k záměnám a případným chybám.

Zastaralé funkce DB2 LUW

V té či oné podobě je DB2 LUW na trhu již od roku 1989 (rok vydání OS/2 1.10 Extended Edition, který obsahoval komponentu Database Manager – tedy relační DBMS, která byla základem DB2 LUW).

V průběhu dlouhého vývoje produktu byly některé původně vyvinuté funkce přehodnoceny a nahrazeny jinou implementací nebo z produktu zcela vyloučeny pro jejich nepotřebnost. Při práci s materiály připravenými pro starší verze DB2 (například verze 9.7) si proto uvědomte, že některé funkce popsané v těchto materiálech mohou být nahrazeny v novějších verzích DB2 (například 10.5 a 11.1). Podrobné informace o zastaralých a nahrazených funkcích jsou uvedeny v .

Mezi nejvýznamnější změny pro administrátory a vývojáře patří:

• nahrazení zastaralých grafických nástrojů pro správu „Control Center“, „Task Center“ a řady dalších funkcí bezplatného balíčku IBM Data Studio a také funkcemi nástrojů obsažených v bezplatné edici IBM Data Server Manager produkt;
• ukončení podpory serveru DB2 Administration Server (DAS), který byl vyžadován pro spuštění starších nástrojů pro správu;
• nahrazení nástrojů pro správu zátěže DB2 Governor a Query Patroller funkcí DB2 Workload Manager (DB2 WLM).

Účel přípravy této série článků

Hlavním účelem napsání série přehledových článků o IBM DB2 je vyplnit nedostatek materiálů na toto téma v ruštině. Navzdory dostupnosti překladů významné části dokumentace do ruštiny a dostupných knih o DB2 je stále nedostatek dostupných přehledových informací, které by zainteresovaným čtenářům umožnily získat představu o funkcích DB2, vestavěných ve funkčnosti a specifikách administrace.

Záměrem autora však není připravit přehled všech produktů z rodiny DB2 (viz postranní panel „Rodina produktů DB2“), místo toho se plánuje zaměřit na variantu DB2 pro Linux, Unix, popř. Operační systémy Windows - tzn. na produktu DB2 LUW.

Zájem čtenářů praktický průvodce Chcete-li začít s DB2, doporučuji vám nahlédnout do volně distribuované knihy "", přeložené do ruštiny. Tato kniha poskytuje mnoho příkladů běžných operací se softwarem DB2, takže je snadné začít jak s verzí DB2 9.7 popsanou v knize, tak s novějšími verzemi DB2 (10.5 a 11.1). Při práci s aktuálními verzemi software DB2, mějte na paměti, že některé funkce ve verzi 9.7 byly zastaralé a nejsou podporovány v nových verzích produktu (viz postranní panel "Zastaralé funkce DB2 LUW").

Funkce DB2 LUW

IBM DB2 používá aktuálně akceptované architektura klient-server relační DBMS, s ukládáním informací na serveru a připojením klientských aplikací k databázím lokálně nebo přes síť.

K zajištění souběžného přístupu k datům z paralelních aplikací používá DB2 transakční mechanismus založený na zamykání a protokolování transakcí, aby poskytoval standardní ACID záruky (atomicita, konzistence, izolace, trvanlivost). Tento mechanismus prošel dlouhou cestou vývoje, aby zajistil maximální výkon, spolehlivost a minimalizoval zpoždění při provádění aplikací.

DB2 poskytuje podporu pro všechny běžné průmyslové standardy pro přístup k datům aplikací, včetně standardního jazyka SQL dotazy, rozhraní ODBC a JDBC, práce s typickými formáty textových tabulek atd. Kromě toho DB2 obsahuje pokročilé funkce pro ukládání a práci s polostrukturovanými daty XML formáty, JSON/BSON. Pro vývoj uložených procedur poskytuje DB2 podporu pro různé procedurální jazyky, včetně:

• standard pro jazyk DB2 SQL PL,
• jazyk SQL/PL používaný v DBMS společnosti Oracle,
• schopnost vyvíjet "externí" uložené procedury v Javě, C, C++ a COBOL.

Charakteristické rysy DB2 jsou:

• škálovatelnost, omezená pouze dostupnými výpočetními zdroji, a nejhospodárnější využití výpočetních zdrojů;
• výkonné vestavěné prostředky pro diferenciaci a řízení přístupu, které poskytují možnost granulárního omezení přístupu k informacím v kontextu objektů (tabulky, pohledy), jakož i implementaci modelu povinného řízení přístupu;
• pokročilý integrovaný systém zálohování a obnovy dat;
• dostupnost celé sady technologií pro budování „klasických“ analytických datových skladů (rozdělení tabulek do sekcí, materializované pohledy, optimalizace ukládání dat do mezipaměti a skenování tabulek a indexů, „interní“ paralelismus při provádění složitých dotazů atd.);
• podpora pro vytváření konfigurací masivně paralelního analytického zpracování dat (MPP) z více serverů připojených prostřednictvím komunikační sítě založené na funkci DB2 Database Partitioning Feature (DB2 DPF);
• maximální odolnost proti chybám a téměř lineární škálování konfigurací klastru DB2 pureScale s daty uloženými na sdílených discích;
• Technologie DB2 BLU, která implementuje podporu pro moderní in-memory "sloupcovou" analytiku bez použití ruční optimalizace struktury databáze.

Pro usnadnění migrace aplikací z jiných typů DBMS (především Oracle Database) poskytuje DB2 pokročilé nástroje kompatibility, včetně podpory nezbytných datových typů, uložených procedur a standardních systémových pohledů.

Existuje několik edic produktu DB2 LUW, které jsou sjednoceny jedinou sadou základních funkcí a liší se od sebe omezeními na použité výpočetní prostředky a podporou pokročilých funkcí. Edici DB2 Express-C, která je k dispozici zdarma, lze použít pro hodnocení produktů, učení a dokonce i malá produkční nasazení. Omezení funkčnosti a prostředků různých edic DB2 LUW jsou podrobně popsána v článku "".

Struktura databázového serveru

Databázový server DB2 je počítač, na kterém je nainstalován serverový software DB2 (jádro DB2) a který poskytuje služby správy strukturovaných informací.

Přístup aplikací ke službám DB2 zajišťuje klientský software DB2 (IBM Data Server Driver Package), který komunikuje se serverem DB2 v souladu s podporovanými metodami připojení aplikací (včetně ODBC, JDBC, OLE DB, ADO, CLI a dalších metod). . Ve většině případů se požadovaný klientský software instaluje se serverem DB2, což umožňuje aplikacím hostovaným přímo na databázovém serveru připojit se k serveru DB2.

Databázový server DB2 může hostit více kopií softwaru DB2 s různými verzemi softwaru a instalačními adresáři. Více kopií softwaru DB2 může být hostováno nezávisle na stejném serveru, pokud mezi nimi nedochází ke konfliktům prostředků (včetně dostatečných výpočetních zdrojů serveru a žádných konfliktů ohledně logických prostředků operačního systému: názvy sítí, čísla portů, adresáře systému souborů a tak dále.).

Přímé poskytování služeb DBMS zajišťuje komponenta správce databází DB2 (DB2 DBM). Každá kopie může mít více instancí správce databází DB2 nebo stručněji instance DB2. Instance je nezávislé prostředí, ve kterém lze vytvářet databáze a spouštět aplikace. Každá instance DB2 má svou vlastní konfiguraci a poskytuje přístup k určité sadě databází. Instance DB2 jsou nezávislé v tom smyslu, že provádění operací na jedné instanci neovlivňuje ostatní, s výjimkou omezení prostředků způsobených spuštěním více instancí na stejném fyzickém nebo virtuálním serveru.

Spouštění a zastavování služeb DB2 se provádí na úrovni instance, tzn. každá instance DB2 může být ve spuštěném nebo zastaveném stavu. Parametry instance DB2 mohou definovat její limity prostředků (například z hlediska využití paměti). Prostředky instance DB2 se používají k údržbě databází, které v instanci existují.

Databáze je kolekce objektů, které tvoří jediné informační pole (tabulky, pohledy, indexy atd.). Databáze jsou nezávislé entity, a proto obvykle nesdílejí objekty s jinými databázemi (výjimkou mohou být konfigurace distribuovaných databází, které využívají mechanismy federace přístupu k datům).

Schematický příklad struktury databázového serveru je znázorněn na obrázku.

V mnoha případech obsahuje databázový server DB2 jedinou instalaci DB2 s jednou vytvořenou instancí obsluhující jedinou databázi. Při této konfiguraci jsou všechny prostředky databázového serveru použity ke spuštění jedné databáze DB2.

Obsluhování požadavků z připojených aplikací na straně databázového serveru je prováděno tzv. agenty DB2. Pro každou připojenou aplikaci v rámci instance DB2 se spustí koordinační (primární) agent, který může podle potřeby spustit několik dalších (pomocných) agentů. Technicky vzato je každý agent samostatné spouštěcí vlákno nebo (u starších verzí DB2) samostatný proces operačního systému s přidruženými prostředky potřebnými k jeho spuštění.

Možnosti konfigurace DB2

Konfigurace serveru DB2 může být nastavena na čtyřech různých úrovních:

• Proměnné prostředí;
• registr profilu DB2;
• konfigurační soubor správce databází (DBM CFG);
• konfigurační soubor databáze (DB CFG).

Proměnné prostředí se nastavují na úrovni operačního systému serveru a pomocí operačního systému. Pro OS Windows jsou tyto proměnné pro server ve skutečnosti globální, pro rodiny operačních systémů Unix a Linux může mít každá instance své vlastní specifické nastavení proměnné prostředí.

Nastavení registru profilu DB2 lze nastavit na úrovni operačního systému (globálně) nebo na úrovni instance, přičemž nastavení na úrovni instance přepíší nastavení na úrovni operačního systému. Zobrazení a nastavení hodnot registru profilu DB2 se provádí pomocí příkazu db2set.

Volby konfiguračního souboru správce databází jsou definovány na úrovni instance, zatímco volby konfigurace databáze jsou definovány na úrovni databáze.

Mnoho parametrů je dynamických, tj. provedené změny se projeví okamžitě; existují však nastavení, která vyžadují, abyste zastavili a spustili instanci, aby se změnila. To lze provést na příkazovém řádku pomocí příkazů db2stop a db2start. Před zastavením instance se musí všechny aplikace vypnout. K vynucení zastavení instance můžete použít příkaz db2stop force.

Konfigurační soubor správce databází obsahuje nastavení, která ovlivňují instanci a všechny databáze, které obsahuje. Konfigurační soubor správce databází lze zobrazit nebo upravit pomocí příkazový řádek(pomocí příkazů GET DBM CFG a UPDATE DBM CFG) a také nástroje IBM Data Studio.

Konfigurační soubor databáze obsahuje volby, které ovlivňují konkrétní databázi. Konfigurační soubor databáze lze zobrazit nebo upravit pomocí příkazového řádku (příkazy GET DB CFG a UPDATE DB CFG) a IBM Data Studio.

Podrobný popis podporovaných , stejně jako je uveden v oficiální dokumentaci DB2.

Organizace ukládání dat

Nejmenší fyzická úložná jednotka v DB2 je strana. Povolené velikosti stránek jsou 4K, 8K, 16K a 32K. Informace o objektech databáze (jako jsou položky tabulky a položky rejstříku) jsou umístěny na stránkách.

Alokace dalšího prostoru pro ukládání dat je přidělována skupinami stránek, které se nazývají rozsahy. Provádění operací přidělování prostoru navíc na úrovni rozsahu zlepšuje výkon vkládání záznamů a aktualizací.

Ukládání informací v databázích DB2 je organizováno do objektů tzv tabulkové prostory. Tabulkový prostor je pojmenovaná sada kontejnerů pro ukládání informací umístěných v systému souborů databázového serveru.

Pro každý tabulkový prostor je vytvořen jeden nebo více tabulkových prostorů. kontejnery(soubory nebo adresáře v souborovém systému) k ukládání informací a také k nastavení velikosti stránky a oblasti pro ukládání dat do mezipaměti (buffer pool, viz níže), stejně jako řadu dalších parametrů.

Existují následující typy tabulkových prostorů:

• obyčejný: používá se k hostování uživatelských tabulek a indexů;
• velký: Používá se k hostování uživatelských tabulek a indexů, stejně jako dat velkých objektů (LOB) a dat XML. V moderních verzích DB2 se ve výchozím nastavení používají velké tabulkové prostory namísto běžných;
• dočasný: slouží k ukládání dočasných informací při provádění dotazů (systémové dočasné tabulkové prostory) a dočasných tabulek definovaných aplikacemi (uživatelské dočasné tabulkové prostory).

Typ tabulkového prostoru je specifikován při jeho vytvoření a nelze jej změnit, s výjimkou odstranění a opětovného vytvoření tabulkového prostoru.

Tabulkové prostory lze také klasifikovat podle typu ovládacího prvku, který je nastaven při vytváření tabulkového prostoru:

• systémově spravované tabulkové prostory (SMS, System Managed Storage) - adresáře se používají jako kontejnery tabulkových prostorů, vytvářejí se datové soubory pro umístění objektů úložiště do adresářů. Místo není předem přiděleno, soubory dynamicky rostou. Když jsou definovány, kontejnery jsou fixní v době, kdy jsou vytvořeny;
• tabulkové prostory spravované databází (DMS, Database Managed Storage) - předem alokované soubory se používají jako kontejnery tabulkového prostoru, kontejnery lze přidávat, mazat nebo měnit;
• automaticky spravované tabulkové prostory (automatické úložiště) - automatická detekce typu a umístění kontejneru v závislosti na typu tabulkového prostoru (DMS pro běžné a velké tabulkové prostory, SMS pro dočasné tabulkové prostory). Konkrétní definice kontejnerů se při vytváření tabulkového prostoru neuvádějí, potřebné kontejnery se vytvářejí automaticky. Růst stávajících kontejnerů a přidávání nových kontejnerů jsou plně řízeny DB2.

Chcete-li povolit automatickou správu tabulkového prostoru, musíte nejprve vytvořit databázi s povoleným automatickým úložištěm (což je výchozí nastavení) a svázat s ní sadu cest úložiště.

Ve výchozím nastavení DB2 zapisuje sekvenčně do oblastí, přičemž mezi kontejnery "odstraňuje". Pokud máte například tabulkový prostor o velikosti stránky 4 KB a velikosti oblasti 8 stránek a používáte 3 okamžité kontejnery v tabulkovém prostoru DMS, znamená to, že 32 KB dat (4 KB x 8 stránek v rozsah = 32 KB) bude zapsán na jeden disk před zahájením nahrávání na další.

Počínaje DB2 verze 10.1 byla zavedena nová koncepce, která zjednodušuje správu úložiště dat − skladovací skupina(úložná skupina). Skupina úložišť je pojmenovaná kolekce cest v souborovém systému serveru DBMS, kterou lze použít k ukládání dat. Složení úložných skupin v databázi obvykle definuje sadu typů úložných zařízení dostupných pro ukládání informací. Při vytvoření databáze se v databázi vždy automaticky vytvoří výchozí skupina úložiště.

Každý automaticky spravovaný tabulkový prostor je přidružen k jedné z vytvořených skupin úložišť, která určuje fyzické umístění dat uložených v odpovídajících tabulkových prostorech. Tabulkový prostor je možné přesunout z jedné skupiny úložišť do druhé pomocí příkazu ALTER TABLESPACE ... USING STOGROUP ....

Protokolování transakcí

IBM DB2 LUW, stejně jako většina ostatních moderních relačních DBMS, které poskytují záruky ACID, používá protokol transakcí jako jeden z primárních mechanismů k vynucení těchto požadavků.

Operace úpravy dat prováděné produktem DB2 jsou zaznamenány v protokolu transakcí jako série záznamů protokolu. Každá databáze udržuje svůj vlastní transakční protokol, což je sekvence souborů na disku. Velikost jednoho souboru je určena parametrem LOGFILSIZ, počet původně vytvořených souborů je určen parametrem LOGPRIMARY. V případě potřeby může DB2 vytvořit další soubory log, maximální počet vytvořených souborů je řízen parametrem LOGSECOND.

Informace se zapisují do transakčního protokolu pomocí speciální vyrovnávací paměti v RAM. Obsah vyrovnávací paměti se vyprázdní na disk (do souborů protokolu transakcí) při zaplnění vyrovnávací paměti a také při potvrzení nebo zrušení transakcí (na příkaz aplikace nebo při abnormálním uzavření spojení s aplikací).

Soubor protokolu transakcí, který je nutný k obnovení dat po havárii, se nazývá soubor aktivního protokolu. Aktivní soubory protokolu transakcí musí být správci databází DB2 neustále k dispozici. Vzhledem k tomu, že dostupnost souborů protokolu transakcí je zásadní pro zajištění výkonu DBMS, je k dispozici mechanismus pro zrcadlení protokolů transakcí ve dvou souborové systémy(konfigurovatelné pomocí parametru LOGMIRROR).

Pokud zvolíte špatnou velikost a počet souborů protokolu transakcí, které neodpovídají úrovni aktuálního zatížení, může dojít k přetečení protokolu transakcí kvůli nedostatečnému počtu souborů protokolu, které lze vytvořit, nebo nedostatku souborů protokolu. dostupný místo na disku. V závislosti na nastavení databáze (viz parametr BLK_LOG_DSK_FUL) může být aplikacím vrácena příslušná chybová zpráva nebo může být zpracování pozastaveno do doby, než bude situaci vyřešena administrátorem.

K situacím přetečení protokolu transakcí může také dojít, pokud existují dlouhotrvající transakce, které provádějí operace úpravy dat. I když takováto dlouhotrvající transakce provede jedinou malou změnu databáze, která se poté po dlouhou dobu nepotvrdí, příslušný soubor protokolu transakcí zůstane aktivní a nelze jej znovu použít.

Existují dva hlavní režimy provozu transakčního protokolování DB2: cyklické protokolování a protokolování archivu. V režimu cyklického protokolování produkt DB2 cyklicky prochází vygenerovanou sadou souborů protokolu transakcí. V režimu protokolování archivu DB2 volitelně zkopíruje soubory protokolu transakcí do archivu pomocí metod určených parametry LOGARCHMETH1 a LOGARCHMETH2.

Režim cyklického protokolování zajišťuje obnovení integrity databáze v případě havárie DBMS serveru. Zálohování takové databáze je možné až po vypnutí všech aplikací (tedy s pozastavením přístupu uživatele). Obnova dat z záloha možné pouze s uvedením databáze do stavu v době zálohování.

Režim protokolování archivu také zajišťuje obnovení integrity databáze, pokud dojde k selhání serveru DBMS. Kromě toho můžete zálohovat databázi bez přerušení přístupu uživatele a zahrnout do zálohy aktivní soubory protokolu (potřebné k obnovení integrity dat). Obnova dat ze zálohy může být doplněna aplikací změn provedených v databázi od pořízení zálohy a uvedením databáze do stavu ve zvoleném časovém okamžiku v minulosti (ale ne dříve než v době pořízení zálohy).

Režim protokolování archivu vyžaduje další prostředky k provádění operací archivace, včetně zvýšeného I/O a dodatečného místa na disku pro ukládání archivovaných souborů protokolu transakcí.

Organizace ukládání dat do mezipaměti

Aby se snížilo množství prováděných I/O, DB2, stejně jako jiné moderní relační DBMS, ukládá do mezipaměti čtení a zápisy prováděné v tabulkových prostorech. Ukládání do mezipaměti se provádí pomocí oblastí paměti RAM nazývaných fondy vyrovnávacích pamětí. V DB2 lze definovat několik různých oblastí vyrovnávacích pamětí (vytvořených příkazem CREATE BUFFERPOOL) s příznakem povolená velikost stránky, velikost a automatické řízení velikosti. Každý tabulkový prostor je mapován na určitou oblast vyrovnávacích pamětí a jednu oblast vyrovnávacích pamětí lze sdílet mezi více tabulkovými prostory.

Při provádění operace čtení nejprve hledá požadovanou stránku s daty ve fondu vyrovnávacích pamětí. Pokud je nalezena požadovaná stránka, jsou data načtena z fondu vyrovnávacích pamětí, jinak je stránka načtena z disku do fondu vyrovnávacích pamětí. Je poskytován mechanismus pro asynchronní předběžné načítání stránek do oblasti vyrovnávacích pamětí, když je detekován lineární (předvídatelný) charakter přístupů ke stránkám. Mechanismus předběžného načítání v mnoha případech zkracuje dobu čekání na operace čtení potřebných dat z disku prováděním čtení v asynchronním režimu.

Když se provádí operace zápisu, úprava stránky se provádí přímo ve společné oblasti vyrovnávacích pamětí. V tomto případě se stránka nezapisuje na disk v synchronním režimu a bezpečnost dat je zajištěna mechanismem transakčního protokolování. Stránky změněného tabulkového prostoru se zapisují na disk asynchronně na pozadí a poskytují přiměřenou minimalizaci množství práce, která může být vyžadována k obnovení stavu databáze, když je abnormálně (nesprávně) uzavřena. Správné uzavření databáze (například při pravidelném vypnutí serveru DBMS) zajistí, že všechny upravené stránky všech fondů vyrovnávacích pamětí budou zapsány na disk.

Využití RAM

Paměťový model DB2 se skládá z různé oblasti paměti na úrovni instance DB2, databáze, aplikace a agenta.

Podrobný popis úložných oblastí DB2 naleznete níže Stručný popis jmenování různých oblastí.

Seznam hlavních úložných oblastí DB2 je uveden na obrázku níže (původně převzato z ).

Celková paměť použitá instancí DBMS zahrnuje:

• Monitor Heap - paměťová oblast pro sledování operací a stavu, velikost je regulována parametrem MON_HEAP_SZ;
• Vyrovnávací paměti FCM - paměťová oblast pro interakci mezi koordinačním agentem a jeho podagenty a také pro poskytování vnitřních interakcí v rozdělených databázích;
• Audit Buffer je paměťová oblast, kam jsou umístěny auditní záznamy před vyprázdněním do auditního protokolu.

Na úrovni databáze je obvyklé rozlišovat mezi:

• oblast globální databáze, často označovaná jako oblast "Performance memory", která zahrnuje různé oblasti mezipaměti a oblast zamykání;
• oblast dat aplikace, často označovaná jako "funkční paměť", která zahrnuje různé oblasti pracovní paměti agentů, kteří udržují spojení s databází.

Oblast globální databáze se skládá z následujících hlavních komponent:

• Buffer pools - buffer pooly, tzn. oblasti pro ukládání dat tabulkového prostoru do mezipaměti;
• Seznam zámků - oblast pro ukládání informací o zámcích, jejichž velikost je řízena parametrem LOCKLIST;
• Package cache - oblast pro cachování plánů provádění dotazů, velikost je regulována parametrem PCKCACHESZ;
• Catalog cache - oblast pro cachování systémového katalogu, která obsahuje popisy všech databázových objektů, velikost je regulována parametrem CATALOGCACHE_SZ;
• Utility halda - RAM pro provádění operací údržby databáze (včetně operací zálohování a obnovy), velikost je regulována parametrem UTIL_HEAP_SZ;
• Databázová halda - RAM pro obsluhu databázových operací (včetně vyrovnávací paměti transakčních protokolů a mezipaměti pro urychlení přístupu k systémovému katalogu a také vyrovnávací paměti auditu na úrovni databáze), velikost je regulována parametrem DBHEAP.

Celková velikost oblasti globální databáze je omezena nastavením DATABASE_MEMORY.

Oblast dat aplikace zahrnuje:

• Globální paměť aplikací - společné oblasti paměti sdílené při zpracování požadavků aplikací, maximální množství je regulováno parametrem APPL_MEMORY;
• Agent Private Memory - privátní paměťové oblasti používané pro provoz jednotlivých agentů obsluhujících připojené aplikace.

Volitelně můžete alokovat oblasti paměti, které jsou přiděleny ovladači DB2 ke spuštění na straně aplikace. U lokálních aplikací (těch, které pro připojení ke správci databází používají IPC spíše než síťový přístup), nastavení DB2, které nastavíte, řídí, kolik paměti RAM je přiděleno (především nastavení ASLHEAPSZ).

Správa paměti RAM při provádění operací řazení

Mnoho typů operací DBMS vyžaduje třídění dat, takže správě paměti RAM používané pro třídění je věnována zvláštní pozornost.

Pokud není možné alokovat třídicí oblast celou v paměti RAM, data pro třídění se umístí do dočasného tabulkového prostoru systému. Výkon dotazů, které vyžadují tak rozsáhlé operace řazení, může být výrazně snížen.

Parametry, které řídí přidělení paměti RAM pro řazení:

• SORTHEAP - limit paměti pro operaci řazení;
• SHEAPTHRES - limit velikosti soukromé paměti agenta přidělené pro operaci řazení;
• SHEAPTHRES_SHR – limit množství celkové paměti RAM, kterou lze použít k provádění operací řazení (celkem všemi spotřebiteli) v daném okamžiku.

DB2 podporuje tři základní modely správy paměti řazení:

• Sdílený model řazení (sdílené řazení) – používá se ve výchozím nastavení, znamená nastavení parametru SHEAPTHRES na 0. Alokace RAM pro řazení se provádí z globální oblasti databáze.
• Soukromý model oblasti třídění (soukromé třídění) – používá se, když je parametr SHEAPTHRES nenulový a není nakonfigurován žádný sdílená paměť třídění. Přidělování paměti RAM pro třídění se provádí z oblasti dat aplikace (přesněji řečeno ze soukromých oblastí patřících agentům).
• Hybridní model řazení (hybridní řazení) - používá se, když je parametr SHEAPTHRES nenulový a existuje nakonfigurovaná sdílená třídicí paměť. Operace, které vyžadují použití sdílené paměti pro třídění, se provádějí s alokací paměti v globální oblasti databáze, ostatní operace řazení se provádějí s alokací paměti v soukromých oblastech agentů.

Použití sdílené (globální) paměti k provádění operací řazení poskytuje řadu důležitých výhod:

• flexibilnější správa paměti RAM při provádění dotazů, což vám umožní zvýšit efektivitu využití paměti RAM;
• možnost použití paralelní verze třídícího algoritmu díky současnému přístupu do oblasti třídicí paměti koordinačního agenta a jeho podřízených sub-agentů DB2.

Jedno z následujících nastavení lze použít k povolení používání sdílené paměti při provádění operací řazení:

• obecný model oblasti třídění se aktivuje nastavením parametru SHEAPTHRES na 0;
• paralelnost provádění operací je povolena nastavením parametru INTRA_PARALLEL na ANO;
• proměnná DB2_WORKLOAD je nastavena na ANALYTICS;
• je povolena funkce DB2 Connection Concentrator (obvykle se používá při přístupu k databázím DB2 for z/OS a DB2 for i, viz popis této funkce v ).

Automatická správa alokace paměti

Přítomnost velkého počtu různých oblastí paměti RAM a parametrů, které řídí jejich velikost, může vyžadovat značné úsilí pro ruční ladění serveru DB2. Počínaje verzí 9 proto IBM DB2 podporuje automatickou správu distribuce paměti RAM mezi různé oblasti pomocí samoladícího správce paměti (STMM, Self-Tuning Memory Manager).

Když je povoleno bootstrapping, STMM dynamicky přiděluje dostupné paměťové prostředky spotřebitelům paměti v databázi. STMM reaguje na změny v charakteristikách zátěže úpravou hodnot konfiguračních parametrů paměti a velikosti vyrovnávací paměti pro optimalizaci výkonu. Chcete-li povolit STMM, musíte nastavit konfigurační parametr databáze SELF_TUNING_MEM na hodnotu ON.

Automatická správa alokace paměti se provádí pro ty oblasti paměti, pro které to bylo výslovně povoleno. Při nastavování hodnoty konfiguračního parametru pomocí příkazů UPDATE DBM CFG a UPDATE DB CFG je pro použití STMM za hodnotou parametru uvedeno klíčové slovo AUTOMATIC. Číselná hodnota parametru zadaná v tomto případě se používá jako počáteční hodnota, poté STMM pravidelně upravuje hodnoty s ohledem na aktuální zatížení a přerozděluje RAM mezi různé spotřebitele.

Automatická správa STMM je podporována pro následující možnosti:

• INSTANCE_MEMORY je celkové množství paměti RAM v instanci DB2;
• DATABASE_MEMORY - oblasti globální databáze;
• DBHEAP - oblast pro obsluhu databázových operací;
• LOCKLIST – prostor pro uchování údajů o zámcích;
• MAXLOCKS - procento paměti obsazené zámky jedné aplikace pro přepnutí na eskalaci zámků;
• PCKCACHESZ - oblast mezipaměti pro plány provádění dotazů;
• SHEAPTHRES_SHR - obecná třídicí oblast;
• SORTHEAP - velikost oblasti třídění pro jednu operaci;
• APPL_MEMORY - oblast funkční paměti;
• APPLHEAPSZ - limit privátní paměti využívaný jedním agentem;
• STMTHEAP - omezení velikosti oblasti používané překladačem SQL a XQuery dotazů (na dotaz);
• STAT_HEAP_SZ je maximální množství paměti RAM přidělené pro vytváření statistik obslužným programem RUNSTATS a přidělené z oblasti funkční paměti.

Typy databázových objektů

Tato část poskytuje přehled typů databázových objektů DB2. Úplný seznam typů databázových objektů DB2 a podrobné informace o jednotlivých typech objektů naleznete v dokumentaci k produktu DB2:

Systém

Schémata jsou jmenné prostory pro shromažďování databázových objektů. Schémata se používají především pro:

• poskytování označení vlastnictví objektů nebo odkazů na aplikaci;
• logické seskupování souvisejících objektů.

Všechny databázové objekty DB2 (kromě generických synonym) mají plně kvalifikované dvoudílné názvy; schéma je první částí takového názvu:<имя_схемы>.<имя_объекта>

Plně kvalifikovaný název objektu musí být jedinečný. Pokud se připojíte k databázi a vytvoříte objekt nebo k němu přistoupíte bez zadání schématu, DB2 použije jako název schématu ID uživatele, který vytvořil připojení k databázi. K nastavení schématu pro aktuální relaci můžete také použít příkaz SET SCHEMA.

Vytvoření schématu lze provést explicitně voláním příkazu CREATE SCHEMA nebo implicitně při prvním pokusu o vytvoření objektu bez zadání názvu schématu. V druhém případě musí být uživateli uděleno oprávnění IMPLICIT_SCHEMA, aby bylo možné schéma úspěšně vytvořit.

Pro většinu typů databázových objektů lze vytvořit synonyma, což umožňuje odkazovat na původní objekty pod jiným názvem (možná umístit je do jiného schématu). Synonyma se vytvářejí pomocí příkazu CREATE SYNONYM / CREATE ALIAS. Podporuje také práci s veřejnými synonymy, která nejsou vázána na konkrétní schéma. Přístup k veřejným synonymům se provádí bez zadání schématu, bez ohledu na zavedené aktuální schéma relace. Veřejná synonyma se vytvářejí pomocí příkazu CREATE PUBLIC SYNONYM / CREATE PUBLIC ALIAS.

tabulky

Tabulka je kolekce souvisejících dat uspořádaných logicky do sloupců a řádků.

Každý řádek tabulky se skládá ze stejné sady pojmenovaných sloupců. Při vytváření tabulky je každému sloupci přiřazen datový typ, který omezuje povolené hodnoty sloupců v řádcích tabulky (databázové záznamy) a určuje sémantiku možných operací s odpovídajícími hodnotami (včetně porovnávání, řazení, výpočetních operací).

Tabulka se vytvoří pomocí příkazu CREATE TABLE a odstraní se příkazem DROP TABLE. Je podporována změna popisu tabulky pomocí příkazu ALTER TABLE, včetně přidávání a odstraňování sloupců, změny datových typů sloupců. Po provedení některých operací změny popisu tabulky je nutné provést její reorganizaci (restrukturalizaci fyzického úložiště tabulky pro optimální přístup k ní) pomocí příkazu REORG.

Klasifikace vestavěných datových typů DB2, které lze použít k definování sloupců tabulky, je znázorněna na obrázku níže.

Kromě jednoho z povolené hodnoty podporovaný datový typ, hodnoty sloupců mohou být prázdné, tzn. prázdnou hodnotu (NULL). Schopnost sloupce ukládat hodnoty null je určena při vytvoření tabulky.

Většina datových typů uvedených na obrázku má přímý protějšek v jiných moderních relačních DBMS a jsou podrobně popsány v dokumentaci k DB2. Následuje stručný popis funkcí datových typů, které jsou specifické pro DB2 nebo které mohou být obtížně použitelné.

Při práci s řetězcovými daty, na rozdíl od některých jiných typů DBMS, DB2 rozlišuje mezi prázdným řetězcem (řetězec nulové délky) a hodnotou NULL typu řetězec. Tato funkce ovlivňuje pořadí vyhledávání (použití predikátu rovnosti místo výrazu IS NULL) a složení povolených hodnot sloupce (pokud jsou zakázány hodnoty NULL, lze do sloupce uložit prázdný řetězec).

Hodnoty řetězců typů GRAPHIC, VARGRAPHIC a DBCLOB se liší od ostatních typů řetězců tím, že jsou vždy uloženy v kódování UTF-16. Při přístupu k odpovídajícím sloupcům ze strany klientské aplikace zajišťuje DBMS převod dat do kódování používaného klientskou aplikací.

Sloupce typu DATE (datum) standardně neobsahují časová razítka. V režimu kompatibility databáze Oracle DB2 navíc podporuje ukládání časových atributů (hodiny, minuty, sekundy) ve sloupcích DATE.

Pokud potřebujete efektivně pracovat s přesnými desetinnými čísly, která obsahují zlomkovou část (například ve finančních aplikacích), je vhodné použít datový typ DECFLOAT, který kombinuje přesnou reprezentaci DECIMAL hodnot a schopnost efektivně vypočítat hodnoty typu FLOAT.

Datový typ BLOB poskytuje možnost ukládat nestrukturované binární informace (jako jsou obrázky nebo kancelářské dokumenty) do databáze. Hodnoty BLOB lze ukládat společně s dalšími poli záznamu (pokud jejich velikost umožňuje, aby byly dostatečně kompaktní), nebo samostatně, ve speciálním úložném objektu. V druhém případě záznam obsahuje odkaz na uloženou hodnotu BLOB namísto hodnoty samotné. Ukládání hodnot typů CLOB a DBCLOB je organizováno podobným způsobem.

Datový typ XML poskytuje úložiště v polích tabulky strukturovaných hierarchických dokumentů XML. U uložených dokumentů XML jsou podporovány operace přístupu k atributům (bez nutnosti analyzovat dokument XML při přístupu), indexování jednotlivých atributů a další funkce.

Kromě vestavěných datových typů podporuje DB2 uživatelsky definované datové typy, které jsou definovány na základě vestavěných typů. Práce s uživatelsky definovanými datovými typy je popsána v dokumentaci k produktu DB2.

Při vytváření tabulky je možné určit pravidla pro automatické vyplňování jejich hodnot pro sloupce. Speciálním případem sloupců automatického doplňování jsou sloupce identity, což jsou číselné sloupce, které automaticky generují jedinečnou číselnou hodnotu pro každý vložený řádek. Automatické plnění lze provádět v jednom ze dvou režimů:

• GENERATED ALWAYS - Hodnota je vždy nastavena serverem DB2 a nemůže být explicitně nastavena aplikací;
• GENERATED BY DEFAULT - Hodnota je nastavena serverem DB2, pokud aplikace při vkládání záznamu neurčila explicitní hodnotu přiřazení.

Na úrovni tabulky lze také definovat omezení, která nastavují omezení na složení hodnot atributů. Jsou podporovány následující typy omezení:

• primární klíč (PRIMARY KEY) - omezení jedinečnosti na množině sloupců, používá se hlavně k hledání jednoho záznamu, v tabulce může být pouze jeden primární klíč;
• omezení jedinečnosti (UNIQUE) – další omezení jedinečnosti na množině sloupců;
• cizí klíč (FOREIGN KEY) – odkaz ve formě sady hodnot sloupců ukazující na kombinaci sloupců jiné tabulky, pro kterou je definován cizí klíč nebo jedinečné omezení;
• kontrola (CHECK) - logická podmínka, která omezuje možné hodnoty jeden nebo více sloupců v příspěvku.

Omezovací mechanismus implementuje prostředky automatického řízení a zajištění integrity databáze, včetně referenční integrity dat (kontrola přítomnosti záznamů v "nadřazené" tabulce, na které se odkazuje prostřednictvím cizích klíčů záznamů "podřízených" tabulek). Správné používání omezení umožňuje garantovat formální správnost naplnění databáze a do určité míry se chránit před aplikačními a uživatelskými chybami při opravách dat.

Vzhledem k tomu, že omezovací mechanismus vytváří další výpočetní zátěž při zadávání a aktualizaci dat, je v některých případech od jeho použití záměrně upuštěno a odpovědnost za správnou údržbu databáze je přenesena na aplikaci. DB2 zároveň používá popisy omezení integrity k určení vztahů mezi tabulkami a výběru nejúčinnějšího plánu provádění dotazů.

Dočasné tabulky

K ukládání dočasných dat aplikací poskytuje produkt DB2 dočasný tabulkový mechanismus, který poskytuje plnou funkčnost pro práci s tabulkovými daty, avšak v kontextu aktuální uživatelské relace.

Přístup k dočasným tabulkám výrazně zlepšuje výkon minimalizací nebo eliminací konfliktů přístupu k systémovému katalogu a eliminací zamykání řádků, protokolování (volitelné, v závislosti na režimu vytváření tabulky) a kontroly oprávnění.

Dočasné tabulky také podporují indexy, to znamená, že na dočasné tabulce lze vytvořit jakýkoli standardní index. Můžete také shromažďovat statistické údaje o takových tabulkách (pomocí příkazu RUNSTATS), abyste získali informace potřebné pro optimalizátor dotazů.

Dočasné tabulky jsou umístěny v uživatelském dočasném tabulkovém prostoru, který musí být definován před jejich vytvořením.

V DB2 existují dvě hlavní varianty dočasných tabulek:

• deklarované dočasné tabulky (DGTT - Declared Global Temporary Tables);
• vytvořené globální dočasné tabulky (CGTT - Created Global Temporary Tables).

Deklarované dočasné tabulky jsou tabulky v paměti používané aplikací a automaticky zrušené při jejím ukončení. K takovým tabulkám má přístup pouze aplikace, která je vytvořila, a nejsou uloženy v žádné z tabulek systémového katalogu DB2.

Každá deklarovaná dočasná tabulka má schéma SESSION; toto schéma musí být specifikováno odkazem na něj. ID uživatele použité k deklaraci dočasných tabulek bude mít k těmto tabulkám plná oprávnění. Každá aplikace, která deklaruje dočasnou tabulku, bude mít svou vlastní kopii této tabulky.

Zatímco DGTT umožňují deklarovat dočasnou tabulku, definici takové tabulky nelze sdílet mezi připojeními nebo relacemi. Při každém zahájení relace musíte vydat příkaz DECLARE GLOBAL TEMPORARY TABLE.

Při použití CGTT (Generated Global Temporary Tables) stačí vytvořit definici dočasné tabulky pouze jednou, protože je uložena v systémovém katalogu DB2. To znamená, že ostatní připojení mohou použít definici tabulky namísto jejího opětovného vytváření.

Přestože lze strukturu CGTT tabulky použít okamžitě, data z různých spojení jsou na sobě nezávislá a po uzavření spojení zmizí.

Indexy

Index je uspořádaná sada klíčů, z nichž každý ukazuje na řádek tabulky. Indexy vynucují jedinečnost řádku (to znamená implementují jedinečná omezení popsaná v předchozí části) a zlepšují výkon. Níže jsou popsány některé charakteristiky, které lze definovat pro indexy:

• indexy mohou být sestaveny ve vzestupném nebo sestupném pořadí hodnot sloupců;
• indexové klíče mohou být jedinečné nebo nejedinečné;
• indexy mohou být postaveny na několika sloupcích (takové indexy se nazývají kombinované);
• pokud jsou data indexu a tabulky seskupena ve stejné posloupnosti indexu, nazývá se takový index shlukovaný (CLUSTERED INDEX).

Vytváření indexu zajišťuje příkaz CREATE INDEX, mazání příkazem DROP INDEX. Při vytváření indexu se zadává jeho typ (unikátní / nejedinečný) a složení sloupců pro sestavení indexu.

DB2 poskytuje nástroje, které poskytují automatický výběr indexů pro optimalizaci provádění dotazů. Nejpohodlnější způsob práce s těmito nástroji je uspořádán v IBM Data Studio.

Sekvence

Přestože jsou sekvenční objekty nezávislé na tabulkách, fungují podobně jako sloupce identity a poskytují generování jedinečných číselných sekvencí. Rozdíl mezi sekvencemi a sloupci identity je v tom, že sloupce identity generují jedinečná čísla striktně v určeném sloupci tabulky, zatímco objekty sekvence lze použít ke generování sekvenčních číselných hodnot, jejichž logiku určuje aplikace.

Vytváření sekvencí zajišťuje příkaz CREATE SEQUENCE, k další a aktuální přijaté hodnotě se přistupuje pomocí operátorů NEXT VALUE FOR a PREVIOUS VALUE FOR. Pro kompatibilitu s databází Oracle je podporována také syntaxe pro přístup k sekvenčním hodnotám prostřednictvím pseudosloupců „NEXTVAL“ a „CURRVAL“.

Zastoupení

Pohled je zobrazení dat v tabulkách. Data pro pohledy se neukládají samostatně, načítají se při spuštění pohledu. Podporovány jsou vnořené pohledy, tj. pohledy vytvořené z jiných pohledů.

Pohledy se vytvářejí pomocí příkazu CREATE VIEW a odstraňují příkazem DROP VIEW. Pro usnadnění aktualizace (záměny) pohledů je k dispozici syntaxe CREATE OR REPLACE VIEW, která umožňuje vytvoření nového pohledu (pokud již neexistuje) nebo nahrazení stávajícího pohledu novou definicí (pokud pohled s příznakem zadaný název již byl vytvořen).

spouštěče

Spouštěč je objekt, který automaticky provádí operaci na tabulce nebo pohledu. Spuštění spouštěče způsobí konkrétní akce na objektu, pro který je definováno pravidlo. Spouštěč se obvykle nepovažuje za aplikační objekt; podle toho spouštěče obvykle nevytvářejí vývojáři, ale správci databází.

Uložené procedury a funkce

Uložené procedury jsou databázové objekty, které obsahují příkazy SQL a obchodní logiku. Uložení části aplikační logiky do databáze zlepšuje výkon snížením objemu provozu mezi aplikací a databází. Uložené procedury navíc poskytují centrální umístění pro ukládání programový kód, a podle toho mohou jiné aplikace používat stejné uložené procedury. Příkaz CALL se používá k volání uložené procedury.

Uživatelsky definované funkce (UDF) jsou databázové objekty, které uživatelům umožňují rozšířit jazyk SQL o vlastní logiku. Funkce vždy vrací hodnotu nebo hodnoty, obvykle jako výsledek obchodní logiky obsažené ve funkci. Chcete-li volat funkci, použijte ji jako součást příkazu SQL nebo s příkazem VALUES.

V DB2 lze uložené procedury a uživatelem definované funkce vyvíjet v několika programovacích jazycích, včetně PL/SQL, SQL PL, Java, C, C++, COBOL.

Systémový adresář

Jedna ze základních informační zdroje DBMS je systémový katalog, který ukládá a poskytuje přístup k informacím o struktuře databáze, včetně:

• popis tabulek, sloupců a indexů;
• popis a text pohledů, spouštěčů a uložených procedur;
• informace o tabulkových prostorech a kontejnerech pro ukládání dat;
• zavedená oprávnění pro přístup k databázovým objektům;
• další metainformace databáze.

Přístup k systémovému katalogu je vyžadován pro mnoho úloh, včetně automatizace úloh správy a údržby databází, vývoje aplikací a dalších.

Nejčastěji používané tabulky (opravdu pohledy), které jsou součástí systémového katalogu, jsou:

• SYSCAT.SCHEMAS - popis databázových schémat;
• SYSCAT.TABLES - popis databázových tabulek;
• SYSCAT.COLUMNS – popis sloupců tabulky;
• SYSCAT.INDEXES - popis indexů.

Podrobný popis a složení sloupců pro výše uvedené a další tabulky systémového katalogu je uvedeno v .

Organizace paralelního transakčního zpracování

Transakce

Transakce (nebo jednotka práce) se skládá z jednoho nebo více příkazů SQL, které jsou při provádění považovány za samostatnou jednotku; jinými slovy, selhání jednoho příkazu transakce způsobí selhání celé transakce, přičemž všechny příkazy provedené až do okamžiku selhání budou vráceny zpět.

Transakce končí příkazem COMMIT. Transakce může skončit i příkazem ROLLBACK nebo abnormálním (abnormálním) vypnutím aplikace, po kterém budou všechny změny provedené aplikací v databázi zrušeny. Začátek transakce je první příkaz provedený po otevření připojení aplikace k databázi nebo po dokončení předchozí transakce. Každé připojení aplikace k databázi může mít maximálně jednu aktivní transakci.

Jak již bylo zmíněno, změny v databázi se zaznamenávají do transakčního protokolu. Aby bylo zajištěno, že změny provedené vrácenou transakcí mohou být "vráceny zpět", jsou hranice transakcí také zaznamenány v protokolu transakcí. Do transakčního protokolu se zároveň nezapisují transakce, které provádějí pouze operace čtení dat. Informace o začátku transakce je umístěna do transakčního logu před zahájením provádění prvního (pro danou transakci) příkazu zápisu dat.

V případě chyby při provádění jednoho příkazu, který zapisuje data, budou všechny změny provedené tímto příkazem vráceny zpět pomocí dat protokolu transakcí. Aplikace po obdržení diagnostické zprávy o odmítnutí provedení příkazu může zrušit celou transakci (příkazem ROLLBACK) nebo provést některé další akce s databází a v důsledku toho potvrdit provedené změny (příkazem COMMIT ).

Aplikace může definovat další body vrácení v rámci transakce (pomocí příkazu SAVEPOINT) a vrátit zpět změny provedené po vytvoření bodu vrácení zpět (pomocí příkazu ROLLBACK TO). Použití bodů vrácení umožňuje aplikaci selektivně vrátit zpět akce provedené v rámci transakce, což může být užitečné při řešení chyb integrity dat a dalších scénářů.

Zámky

Paralelní použití znamená, že na stejných databázových objektech může pracovat více uživatelů současně. Přístup k datům musí být řádně koordinován, aby byla zajištěna integrita a konzistence dat.

K získání konzistentních výsledků paralelních transakcí je nutná kontrola nad paralelním využíváním sdílených zdrojů. Takové ovládání je založeno na použití zámků.

Pojmy zamykání a souběžnost spolu úzce souvisí. Zámek dočasně brání aplikacím v provádění jiných operací, dokud není aktuální operace dokončena. Čím aktivněji se zamykání v systému používá, tím méně příležitostí pro souběžnost zůstává. Na druhou stranu, čím méně často je zámek v systému aplikován, tím více možností pro souběžnost existuje.

Zámek se získá automaticky podle potřeby k udržení transakce a uvolní se, když je taková transakce přerušena (pomocí příkazu COMMIT nebo ROLLBACK). Zámky lze umístit na stoly nebo řady.

Existují dva hlavní typy blokování:

• Sdílený zámek (S) – Nastaví se, když aplikace čte data a brání jiným aplikacím provádět změny na stejném řádku.
• Exkluzivní zámek (X) – Nastavení, kdy aplikace aktualizuje, vkládá nebo odstraňuje řádek.

Pokud dvě nebo více aplikací potřebují provést operaci na stejném objektu, jedna z nich bude muset počkat, než získá požadovaný zámek. Ve výchozím nastavení bude aplikace čekat neomezeně dlouho. Časový limit uzamčení aplikace je řízen konfiguračním parametrem databáze LOCKTIMEOUT. Výchozí hodnota tohoto parametru je -1 (nekonečné čekání).

Proměnnou relace CURRENT LOCK TIMEOUT můžete použít k nastavení časového limitu uzamčení pro konkrétní připojení. Ve výchozím nastavení je tato proměnná nastavena na LOCKTIMEOUT. Tuto hodnotu můžete změnit pomocí příkazu SET LOCK TIMEOUT.

V případě, že dvě (nebo více) aplikací připojených ke stejné databázi nekonečně dlouho čekají na zdroje z důvodu nesprávného pořadí přístupu k těmto zdrojům, dojde k uváznutí. Časový limit nemůže vypršet, protože každá aplikace drží prostředek, který druhá aplikace potřebuje. Ve všech případech je problém uváznutí způsoben nesprávnou strukturou nebo logikou aplikace.

DB2 automaticky detekuje zablokování prováděním příslušných kontrol v intervalech určených parametrem DLCHKTIME. Když DB2 zjistí, že skutečně došlo k uváznutí, použije interní algoritmus k určení, která z těchto dvou transakcí by měla být vrácena zpět a která by měla pokračovat.

Úrovně izolace

Podrobná analýza problémů, které mohou nastat, pokud neexistuje kontrola souběžnosti, je uvedena v dokumentaci DB2 a také v literatuře o teorii fungování relačních DBMS. Mezi možné typy problémů patří:

• ztracená aktualizace (pokud je jeden datový blok změněn současně různými transakcemi, jedna ze změn je ztracena);
• nespolehlivé čtení (čtení dat přidaných nebo změněných transakcí, které nebudou následně potvrzeny);
• neopakující se čtení (při opakovaném čtení v rámci stejné transakce se změní dříve načtená data);
• fantomové čtení (stejné výběry v jedné transakci dávají různé sady řádků kvůli přidávání, mazání nebo změně řádků jinými transakcemi).

Řízení vestavěné ochrany DB2 proti výše uvedeným problémům na straně aplikace se provádí nastavením úrovně izolace, která se má použít. Úrovně izolace lze chápat jako zásady zamykání, kde v závislosti na zvolené úrovni izolace můžete dosáhnout různých způsobů, jak aplikace uzamkne databázi. Úroveň izolace vyžadovaná aplikací může být nastavena na úrovni relace a na úrovni jediného dotazu nebo dílčího požadavku, který se provádí.

DB2 poskytuje následující úrovně ochrany pro izolaci dat:

• nespolehlivé čtení (Uncommitted Read, UR);
• stabilita kurzoru (Cursor Stability, CS);
• stabilita čtení (Read Stability, RS);
• opakované čtení (Repeatable Read, RR).

Neautentické čtení také nazývané "špinavé". Toto je nejnižší možná úroveň izolace nejvyšší stupeň paralelní použití. Řádky nejsou uzamčeny během operací čtení, s výjimkou případů, kdy se jiná aplikace pokusí zrušit nebo upravit tabulku; operace aktualizace se provádějí stejným způsobem jako při použití další úrovně izolace, úrovně stability kurzoru.

Použití úrovně izolace Bad Read zabrání následujícím problémům:

• ztracená aktualizace.

Stabilita kurzoru je výchozí úroveň izolace. Poskytuje minimální stupeň blokování. Tato úroveň izolace uzamkne "aktuální" řádek kurzoru. Pokud je řádek pouze pro čtení, zámek se podrží, dokud nezadáte nový řádek nebo dokud se operace nedokončí. Pokud je řádek aktualizován, zámek se podrží, dokud se operace nedokončí.

Použití úrovně izolace stability kurzoru zabrání následujícím problémům:

• ztracená aktualizace;
• nesprávné čtení.

Před DB2 9.7, při použití úrovně izolace stability kurzoru, provedení zápisu (operace UPDATE) uzavřelo přístup pro čtení (operace SELECT) ke stejnému řádku. Logickým základem bylo, že jelikož operace zápisu provádí změny v řádku, čtení by mělo čekat na dokončení aktualizací, aby se získala konečná potvrzená hodnota.

DB2 9.7 standardně používá jiný přístup k úrovni izolace stability kurzoru pro nové databáze. Tento nový přístup je implementován pomocí sémantiky „aktuálně potvrzené“ (CC). Při použití sémantiky CC operace zápisu neuzavře přístup ke stejnému řádku pro operaci čtení. Dříve byl tento přístup možný pomocí úrovně izolace UR; rozdíl oproti současnému přístupu spočívá v tom, že u UR operace čtení přijímá neplatné hodnoty, zatímco u sémantiky CC přijímá hodnoty aktuálně akceptované. Aktuálně potvrzené hodnoty jsou hodnoty, které byly potvrzeny před zahájením operace zápisu.

Stabilita čtení poskytuje zámek na všech řádcích přijatých aplikací. Pro daný dotaz jsou blokovány všechny řádky, které odpovídají sadě výsledků. Použití tohoto režimu izolace tedy může vést k tomu, že aplikace získá velký počet zámků, a pokud je dosaženo nastavených limitů, eskaluje zámky z úrovně řádků na úroveň tabulky. Na úrovni izolace stability čtení však optimalizátor dotazů DB2 explicitně nezíská zámky na úrovni tabulky v plánu provádění dotazů, které provádí, i když výsledná sada obsahuje většinu záznamů v tabulce.

Použití úrovně izolace stability čtení zabrání následujícím problémům:

• ztracená aktualizace;
• nesprávné čtení;
• neopakovatelné čtení.

Opakované čtení je nejvyšší stupeň izolace. Poskytuje nejvyšší stupeň uzamčení a nejmenší míru souběžnosti. Zámek je umístěn na řádcích, které se zpracovávají za účelem vytvoření sady výsledků; jinými slovy, i řádky, které se nedostanou do konečného výsledného balíčku, mohou být zablokovány. Jiné aplikace nemohou aktualizovat, odstraňovat nebo vkládat řádky, které ovlivní sadu výsledků, dokud není probíhající operace dokončena. Opakované čtení zajišťuje, že stejný dotaz, vytvořený aplikací vícekrát v jedné operaci, pokaždé poskytne stejné výsledky.

Optimalizátor dotazů DB2 může při použití úrovně izolace opakovaného čtení zahrnout do plánu provádění dotazů explicitní operace nastavení zámků na úrovni tabulky, když odpovídající dotazy zahrnují skenování všech řádků tabulky (což znamená nutnost uzamknout každý řádek tabulky během provádění dotazu).

Použití úrovně izolace stability čtení zabrání všemu možné problémy konkurenční přístup, ale zároveň je co nejvíce omezena možná paralelnost provádění operací.

Závěr

V tomto článku byly zvažovány hlavní funkce IBM DB2 LUW DBMS, struktura databázového serveru, nastavení konfigurace a organizace ukládání dat. Kromě toho jsou zváženy základní principy serveru DB2, podporované typy databázových objektů a organizace paralelního transakčního zpracování DB2.

V práci jsem se nějakou dobu musel potýkat s IBM DB2 DBMS. Protože Vzhledem k tomu, že systém je komerční, není na internetu mnoho informací v ruštině, proto jsem se rozhodl popsat některé funkce tohoto DBMS.

Místo vstupu

Začněme vstupním bodem v DBMS. V SQL SERVER je koncovým bodem instance, která samozřejmě může mít samostatné databáze, ale konfigurační a bezpečnostní model je pro celou instanci stejný. V DB2 vypadá vstupní bod takto - instance (která odpovídá konkrétnímu portu) - databáze. Zároveň existuje konfigurace pro celou instanci a pro samostatnou databázi.

Konfiguraci instance můžete zobrazit buď pomocí příkazu db2:

Konfigurace správce databáze

Typ uzlu = Enterprise Server Edition s místními a vzdálenými klienty

Úroveň vydání konfigurace správce databáze = 0x0b00

Rychlost CPU (milisekundy/instrukce) (CPUSPEED) = 2,912790e-07
Šířka komunikačního pásma (MB/s) (COMM_BANDWIDTH) = 1,000000e+02

Maximální počet současně aktivních databází (NUMDB) = 8
Podpora federovaného databázového systému (FEDERATED) = ANO
Název monitoru transakčního procesoru (TP_MON_NAME) =

Výchozí účet pro zpětné zúčtování (DFT_ACCOUNT_STR) =

Instalační cesta Java Development Kit (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Úroveň zachycení diagnostických chyb (DIAGLEVEL) = 3
Úroveň oznámení (NOTIFYLEVEL) = 3
Cesta k adresáři diagnostických dat (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Výchozí přepínače monitoru databáze
Fond vyrovnávací paměti (DFT_MON_BUFPOOL) = VYPNUTO

Kde budou parametry specifikovány, jejich význam a dekódování. Je možná i zkrácená verze:

získat dbm cfg

Nebo s dotazem:

Vyberte název, hodnotu z sysibmadm.dbmcfg

Mezi důležité parametry patří:

• typ ověření (AUTHENTICATION)
• výchozí cesta pro vytváření nových databází (DFTDBPATH)
• zjišťování síťového serveru (DISCOVER)

Nastavení pro konkrétní databázi můžete zobrazit takto:

připojit ke vzorku(ukázka - název databáze)

získat konfiguraci správce databází

Nebo s přibližně stejným požadavkem jako dříve:

vyberte název, hodnotu ze sysibmadm.dbcfg

Autentizace

Velký rozdíl mezi DB2 a ostatními DBMS spočívá v autentizačním modelu. Neexistují žádní interní uživatelé jako v SQL Server nebo MySQL. Veškerá autentizace se provádí pomocí externích prostředků k DBMS (dynamicky načítané pluginy) - pomocí operačního systému nebo externích pluginů (Kerberos, GSS API). Typ ověřování se nastavuje v parametru AUTHENTICATION konfigurace správce databází. Ve výchozím nastavení je nastavena hodnota SERVER - uživatelské jméno a heslo jsou přenášeny jako prostý text a správnost této dvojice je kontrolována pomocí operačního systému. Pokud je uživatelské jméno a heslo správné, pak se zkontroluje oprávnění CONNECT pro uživatele nebo skupiny, kterých je členem (včetně speciální skupiny PUBLIC, která zahrnuje všechny oprávněné uživatele). Tato oprávnění lze zobrazit v tabulce SYSCAT.DBAUTH:

vyberte GRANTEE ze SYSCAT.DBAUTH, kde CONNECTAUTH = "Y"

Velkou chybou konfigurace je zahrnutí typu autentizace KLIENT. V tomto případě DB2 důvěřuje autentizaci připojujícího se klienta, a pokud má PUBLIC oprávnění CONNECT, může se k databázi připojit jakýkoli uživatel a mít přístup ke všem datům, která má PUBLIC. Uživatelské jméno je převzato z operačního systému. To znamená, že pokud se připojíme přes Data Studio jako uživatel Administrátor, budou mu udělena všechna oprávnění, která tento uživatel má. A v tomto případě není rozdíl, ze kterého počítače byl přístup proveden. Tento typ ověřování se doporučuje povolit pouze v případě, že mezi serverem a klientem existuje zabezpečený kanál a ostatní klienti se nebudou moci připojit k DBMS.

Povolení

Oprávnění na úrovni instance jsou zapsána v konfiguraci správce databází. Jedná se o následující privilegia:

• SYSADM
• SYSCTRL
• SYSMAINT
• SYSMON

Tato oprávnění se nastavují určením skupiny, do které bude uživatel vstupovat. V dbmcfg jsou to volby SYSADM_GROUP , SYSCTRL_GROUP , SYSMAINT_GROUP a SYSMON_GROUP.

Dále jsou zde oprávnění specifická pro databázi. Jsou to oprávnění, jako je přístup k databázi (CONNECTAUTH), vytváření tabulek (CREATETABAUTH), vytváření rutiny (EXTERNALROUTINEAUTH) a tak dále. Tato oprávnění lze zobrazit v pohledu SYSCAT.DBAUTH

A konečně přístupová oprávnění ke konkrétním datům – tabulkám, podprogramům a tak dále. Vše je zde celkem triviální, ale také s některými zvláštnostmi.

Přístupová oprávnění k tabulce lze zobrazit v pohledu SYSCAT.TABAUTH. Typ uděleného oprávnění je uložen v samostatných sloupcích v závislosti na samotném oprávnění (SELECTAUTH, DELETEAUTH atd.). Při udělování oprávnění pomocí příkazu GRANT pro oprávnění REFERENCES a UPDATE můžete také zadat názvy sloupců, na které budou daná oprávnění rozšířena. V tomto případě lze informace o tomto zobrazit v pohledu SYSCAT.COLAUTH

Oprávnění pro rutiny (funkce, procedury a metody) lze zobrazit v SYSCAT.ROUTINEAUTH . Zde není vše triviální, v závislosti na polích SPECIFICNAME a TYPENAME lze udělit oprávnění všem podprogramům daného schématu.

Pokud se čtenářům článek líbí, pak jsem připraven mluvit o ochraně dat v DB2 pomocí Label-Based Access Control

Relační databáze je sada vztahů, jejichž názvy se shodují s názvy schémat vztahů ve schématu databáze. Dnes je známo velké množství různých databázových serverů SQL. Zaměřme se na následující čtyři přední serverové DBMS - Oracle8i, IBM DB2, Microsoft SQL Server a Informix – a porovnejte je v provozu v každé z hlavních fází fungování.

Oracle8i. Balíček Oracle8i vybavený nejpokročilejší sadou funkcí pro práci s jazykem Java a přístup k datům přes internet, systém pro optimalizaci souběžného přístupu. Jedinou nevýhodou tohoto DBMS je složitost administrace, nicméně veškeré náklady na jeho implementaci a vývoj se později vrátí efektivní a spolehlivou prací. (složitost a vysoká cena jsou diskutabilní). Mezi hlavní vlastnosti Oracle DBMS je třeba poznamenat následující: Nejvyšší spolehlivost. Schopnost rozdělit velké databáze na sekce (velký databázový oddíl), což umožňuje efektivně spravovat gigantické gigabajtové databáze; Dostupnost univerzálních prostředků ochrany informací; Efektivní metody maximální zvýšení rychlost zpracování požadavku; indexování bitmap; Volné tabulky (v jiných DBMS jsou všechny tabulky vyplněny ihned po vytvoření); Paralelizace operací v dotazu. Dostupnost široké škály nástrojů pro vývoj, monitorování a správu. Zaměření na internetové technologie Řešení, která nejsou horší než vývoj Oracle, lze nalézt pouze v DB2 od IBM. Orientace na internetové technologie je hlavním mottem moderních produktů Oracle. V tomto ohledu lze zaznamenat balík interMedia, který zajišťuje zpracování dat v multimediálních formátech, a Jserver, vestavěný nástroj pro práci s jazykem Java, který kombinuje možnosti jazyka Java s možnostmi relačních databází. Enterprise JavaBeans jsou stavební bloky, které tvoří Java internetové aplikace. Oracle se drží zásady, že všechny důležité funkce musí být řízeny z jednoho centra, proto navrhovaný modul interMedia poskytuje uživatelům nejpokročilejší funkce pro práci s multimediálními objekty: Velmi pokročilé nástroje pro zpracování zvukových klipů; Statické obrazy; Videoklipy; Geografické údaje (s celou sadou funkcí souvisejících s určením polohy obsažené v modulu Lokátor). Oracle8i implementuje dnes nejlepší nástroje pro objektově orientovaný návrh databází, včetně tabulkových struktur, které umožňují dědění vlastností a metod jiných tabulkových databázových objektů, což zabrání chybám při sestavování databáze a usnadní jejich údržbu. Je třeba také poznamenat, že systém optimalizace souběžnosti multiverzí vyvinutý společností Oracle je jednou z nejdůležitějších charakteristik architektury Oracle (tato funkce je dostupná pouze v InterBase DBMS od InterBase od Inprise). Tato funkce umožňuje eliminovat situaci, kdy jeden uživatel musí čekat, až druhý dokončí změny obsahu databází (to znamená, že v Oracle nejsou žádné zámky čtení). Tato funkce umožňuje Oracle8i provádět více transakcí za sekundu na uživatele než jakákoli jiná databáze. Pokud jde o výkon při práci ve webovém prostředí pod LINUXem, zaujímá Oracle čestné druhé místo po DBMS MySQL, přičemž výrazně předčí všechny ostatní DBMS z hlediska spolehlivosti a bezpečnosti.

DBMS Microsoft SQL Server Nejdůležitější vlastnosti tohoto DBMS jsou: snadná administrace, možnost připojení k webu, rychlost a funkčnost mechanismu DBMS serveru, dostupnost nástrojů vzdálený přístup, Sada nástrojů pro správu DBMS obsahuje sadu speciálních průvodců a nástrojů pro automatické nastavení konfiguračních parametrů. Tato databáze je také vybavena vynikajícími replikačními nástroji, které umožňují synchronizovat data z PC s databázovými informacemi a naopak. Server OLAP, který je součástí balení, umožňuje ukládat a analyzovat všechna data, která má uživatel k dispozici. V zásadě je tato DBMS moderní plnohodnotná databáze, která je ideální pro malé a střední organizace. Je třeba poznamenat, že SQL Server je horší než ostatní uvažované DBMS ve dvou důležitých ukazatelích: programovatelnost a provozní prostředky. Při vývoji klientských databázových aplikací na bázi Java, HTML často nastává problém s nedostatečnými softwarovými nástroji SQL Serveru a použití tohoto DBMS bude obtížnější než u systémů DB2, Informix, Oracle nebo Sybase. Globálním trendem 21. století se stal téměř univerzální přechod na platformu LINUX a SQL Server funguje pouze v prostředí Windows. Proto je použití SQL Serveru vhodné pouze v případě, že se pro přístup k obsahu databáze používá výhradně standard ODBC, jinak je lepší použít jiné DBMS.

IBM DB2 IBM DB2 DBMS je výsledkem téměř 30 let vývoje a vývoje výzkumná práce od IBM. Nejnovější verze tohoto DBMS (6.x) obsahuje jednu z nejpropracovanějších sad nástrojů pro správu a optimalizaci a databázový stroj, který může vyrůst z notebooku s Windows 95 na celý cluster sálových počítačů S/390 s OS/390. Balíček DB2 je dostupný ve dvou edicích: DB2 Workgroup a DB2 Enterprise Edition. Tento DBMS implementuje všechny inovativní technologie databázových strojů známé z předchozích verzí DB2, jako je paralelní zpracování dotazů, úplná sada replikačních nástrojů, souhrnné tabulky dotazů pro zlepšení výkonu databáze, funkce objektově orientovaného návrhu databáze a funkce jazyka Java. Kromě toho je systém DB2 vybaven kompletní sadou multimediálních rozšíření, která umožňují ukládat a manipulovat s textovými, zvukovými a video fragmenty, obrázky a geografickými daty. Dá se říci, že pokud jde o škálovatelnost, technologie shlukování databází vyvinutá specialisty IBM nemá obdoby. Tato rozšíření značně usnadňují proces vývoje aplikací pro web, stejně jako programů obsahujících fotografické obrázky a objemné textové zprávy. Systém DB2 je také poměrně konkurenceschopný jako platforma pro vývoj aplikací, protože existuje nástroj Stored Procedure Builder, který automaticky převede příkaz SQL do příslušné třídy Java a zahrne jej do struktury databáze. V DB2 6.1 byla interoperabilita s ostatními DBMS výrazně vylepšena tím, že bylo umožněno použití specifikace OLE DB společnosti Microsoft, nového standardu pro přístup k databázi. Administrativní ovládací prvky DB2, které jsou nová verze přepsané v Javě a lze je získat z webu si zaslouží nejvyšší chválu. Hlavními nevýhodami tohoto DBMS jsou relativní složitost administrace a (zatím) nedostatek implementací pro oblíbené serverové operační systémy, jako je LINUX. V tomto DBMS je možné díky Index Smart-Guide provádět ladění, tvořící optimální indexy pro daný počet přístupů, který charakterizuje typické zatížení databáze. DB2 je jediný balíček, který umožňuje generovat kontingenční tabulky, což výrazně zlepšuje efektivitu DBMS jako datových skladů. Kontingenční tabulka je dočasný pracovní prostor používaný databází k ukládání odpovědí na často kladené dotazy. Model DB2 6.1 se ukazuje jako nákladově nejefektivnější vysoce výkonný systém. Administrativní nástroje této DBMS jsou zcela vhodné pro úroveň řešených úloh, navíc poskytují mimořádně široké možnosti pro práci s multimediálními daty a pro programování (což v Microsoft SQL Server zjevně chybí).

DBMS od společnosti Informix. V poslední době došlo k přechodu od relačních DBMS k objektově orientovaným (což je dobře vidět na příkladu Oracle). Informix také v souladu s tímto konceptem oznámil nové řešení Centaur DBMS založené na relační databázi Informix Dynamic Server 7.3 a objektově relační databázi Informix Universal Data Option a kombinující vysoký výkon Dynamic Server při práci s daty s univerzálností a multimediálními funkcemi Universal. Možnost dat. Tato implementace je určena pro vývoj internetových systémů. Očekává se, že tento DBMS bude mít flexibilní vývojové prostředí se škálovatelností, aby odpovídalo intenzivní pracovní zátěži charakteristické pro internet, a nástroje pro práci s novými typy dat, které se staly všudypřítomnými s rozvojem webu. Nástroje Java implementované v novém systému umožní vývojářům vytvářet uložené procedury, uživatelské programy a komponenty DataBlades v tomto jazyce, který Informix nazývá

vlastní databázová rozšíření. Z pohledu zákazníků Inforix jde o velký krok kupředu, protože doposud mohli při práci s DataBlades používat pouze C a SPL, interní jazyk Informixu pro psaní uložených procedur. Kromě toho bude balíček Centaur dodáván s vestavěnou manipulací s objekty ActiveX. To umožní například vytvářet databázové uložené procedury v jazyce Visual Basic; to však vyžaduje spuštění balíčku Centaur v prostředí Windows NT. Centaur bude doplňkem Informix Dynamic Server a bude pracovat s tradičním databázovým formátem pro tento balíček, takže uživatelé budou mít k dispozici všechny staré funkce a upgrade systému na novou verzi nebude příliš obtížný. Kromě toho si balíček Centaur zachová všechny možnosti návrhu a programování, díky kterým je systém Informix Universal Server vynikajícím technickým úspěchem. Nový systém bude vybaven zařízením pro objektově orientovaný návrh databází, tvorbu specializovaných tabulek a indexovacích programů; umožní uživatelům vkládat vlastní funkce do dotazů a nespoléhat se pouze na standardní prostředky SQL. Závěry. Po zvážení hlavních charakteristik architektur pro budování AIS, serverových operačních systémů a DBMS zvolíme v budoucnu jako architekturu AIS architekturu Internet / Intranet, jako OS serveru Linux, jako Oracle 8i DBMS.

2) Klauzule SQL SELECT. Vestavěné funkce.

SELECT sloupec FROM tabulka WHERE sloupec LIKE vzor

SELECT * FROM Store_Information WHERE store_name LIKE "%AN%";

SELECT název_sloupce FROM název_tabulky WHERE název_sloupce MEZI hodnota1 A hodnota2

SELECT * FROM Osoby WHERE Příjmení MEZI "Hansen" A "Pettersen";

SELECT * FROM Osoby, KDE PŘÍJMENÍ NENÍ MEZI "Hansen" A "Pettersen";

SELECT Company, OrderNumber FROM Orders ORDER BY( třídění ) Společnost;

SELECT Company, OrderNumber FROM Orders ORDER BY Company, OrderNumber;

SELECT Company, OrderNumber FROM Orders ORDER BY Company DESC( obrácené pořadí ) ;

SELECT Company, OrderNumber FROM Orders ORDER BY Company DESC , OrderNumber ASC(že jo . objednat ) ;

SELECT * FROM Persons WHERE FirstName="Tove" AND LastName="Svendson";

SELECT * FROM Osoby WHERE jméno="Tove" OR lastname="Svendson" ;

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

SELECT store_name FROM Store_Information WHERE Prodej > 1000 NEBO (prodeje< 500 AND Sales > 275);

FunkceVYBRATfunkce( sloupec) Zstůl AVG - průměrná hodnota ve sloupci; POČET - počet hodnot ve sloupci; MAX - nejvíce velká důležitost ve sloupci; MIN - nejmenší hodnota ve sloupci; SUM - součet hodnot podle sloupce

Příklady: VYBRAT AVG(Věk) OD Osoby; VYBRAT POČET(název_obchodu) FROM Store_Information; VYBRAT POČET(ODLIŠNÝ store_name) FROM Store_Information; VYBRAT MAX(Věk) OD Osoby VYBERTE SOUČET(Prodej) FROM Store_Information;

3) Serializace transakcí, konflikty operací. Metody serializace transakcí. Synchronizační gripy, granulární synchronizační gripy. Metody serializace transakcí. Predikátová synchronizace zachycuje. Serializace na základě časových razítek.

Aby bylo dosaženo izolace transakcí, musí DBMS používat metody k regulaci společného provádění transakcí. Je volán plán (metoda) pro provedení sady transakcí seriál pokud je výsledek společného provádění transakcí ekvivalentní výsledku nějakého postupného provádění stejných transakcí. Serializace transakcí- jedná se o mechanismus pro jejich realizaci podle nějakého sériového plánu. Poskytování takového mechanismu je hlavní funkcí komponenty DBMS odpovědné za správu transakcí. Systém, který podporuje serializaci transakcí, poskytuje skutečnou izolaci uživatelů. Hlavním problémem implementace je výběr metody pro serializaci sady transakcí, která příliš neomezuje jejich paralelismus. Triviálním řešením, které mě napadá, je skutečně sekvenční provádění transakcí. Existují však situace, kdy je možné provádět výpisy různých transakcí v libovolném pořadí při zachování sériovosti. Příklady zahrnují transakce pouze pro čtení a transakce, které nejsou v konfliktu s databázovými objekty. Mezi transakcemi mohou existovat následující typy konfliktů: W-W - transakce 2 se pokouší upravit objekt upravený transakcí 1, která neskončila; R-W - transakce 2 se pokusí upravit objekt čtený transakcí 1, která neskončila; W-R – Transakce 2 se pokouší číst objekt upravený neskončenou transakcí 1. Postupy serializace transakcí jsou založeny na těchto konfliktech.

Existovat dva základní přístupy k serializaci transakcí - založené na synchronizačních záchytech databázových objektů a na použití časových razítek. Podstatou obou přístupů je odhalovat transakční konflikty a eliminovat je. Nejběžnějším přístupem v centralizovaných DBMS (včetně systémů založených na architektuře „klient-server“) je přístup založený na dodržování dvoufázového protokolu synchronizačních záchytů databázové objekty. Obecně řečeno, protokol je takový, že před provedením jakékoli operace v transakci T na databázovém objektu r je jménem transakce T požadováno synchronizační zachycení objektu r v příslušném režimu (v závislosti na typu operace). Hlavní režimy synchronizačního zachycení jsou: společný režim - S (Shared), což znamená sdílené zachycení objektu a je nutné k provedení operace čtení objektu; exkluzivní režim - X (eXclusive), což znamená výhradní zachycení objektu a je nutný k provádění operací vkládání, mazání a úprav. Zachycení granulární synchronizace - přístup, který synchronizační zachycení lze požadovat na objektech různých úrovní: soubory, vztahy a n-tice. Požadovaná úroveň objektu je určena právě prováděnou operací (například k provedení operace odstranění na relaci musí být celý vztah objektem synchronizačního zachycení, ale k provedení operace odstranění n-tice musí být tato n-tice). Objekt jakékoli úrovně lze zachytit v režimu S nebo X. Zachytávání predikátové synchronizace- nejedná se o zachycení objektů, ale o podmínky (predikáty), které tyto objekty splňují Alternativní metoda serializace transakcí, která dobře funguje v podmínkách vzácných transakčních konfliktů a nevyžaduje konstrukci čekacího grafu transakce. na základě pomocí časových razítek. Hlavní myšlenka metody (jejichž existuje mnoho variant) je následující: pokud transakce T1 začala před transakcí T2, pak systém zajistí, že režim provádění je, jako by byl T1 kompletně proveden před začátkem T2.

K tomu je každé transakci T přiřazeno časové razítko t odpovídající počátečnímu času T. Při provádění operace na objektu r jej transakce T označí svým časovým razítkem a typem operace (přečtení nebo změna). Před provedením operace na objektu r provede transakce T1 následující akce: Zkontroluje, zda transakce T, která označila tento objekt, skončila. Pokud T skončilo, T1 označí objekt r a provede jeho operaci. Pokud transakce T nebyla dokončena, pak T1 zkontroluje, zda nejsou operace v konfliktu. Pokud jsou operace nekonfliktní, časové razítko s nižší hodnotou zůstane nebo je připojeno k objektu r a transakce T1 provede svou operaci. Pokud jsou operace T1 a T v konfliktu, pak je-li t(T) > t(T1) (to znamená, že transakce T je mladší než T), je T odvoláno a T1 pokračuje. Pokud t(T)< t(T1) (T "старше" T1), то T1 получает новую временную метку и начинается заново. К недостаткам метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования синхронизационных захватов. Это связано с тем, что конфликтность транзакций определяется более грубо. Кроме того, в распределенных системах не очень просто вырабатывать глобальные временные метки с отношением полного порядка.