Dnes se seznámíme s databází IBM DB2. Jedná se o nejméně známou databázi z trojky tří nejúspěšnějších komerčních databází podle obratu. Podle analýzy Garther 2008 má Oracle 48,9% a IBM 21,9%, Microsoft 18,5% procent trhu v relačních databázích; pro zajímavost MySQL má 0,2%. Ještě občas narazíme na zmínku o databázích Sybase nebo Terradata které mají dlouhodobě okolo tří procent a zaměřují se na specifickou oblast trhu.

Jsem rozhodně rád, že se počet SQL databází oproti letům minulým snížil protože to snižuje výrobní náklady na tvorbu aplikací. Javisté používají u databází jiný druh dělení: na databáze podprované Hibernate a ty ostatní. Jen bych si přál aby velmi oblíbená a všude protlačovaná MySQL uměla spolehlivě alespoň základní funkcionalitu kterou od databází očekávám: online backup, rollforward recovery a dvoufázové potvrzování. Postgresql toto umí od verze 8.0 z roku 2005 a neobsahovala při vydání bugy poškozující data nebo vracející chybné odpovědi. U verze 5.0 jich bylo zhruba 30 u verze 5.1 přibližně 50.

Databáze IBM DB2 je tu s námi již pěknou řádku let. Její první verze byla oznámena 7.6.1983 a tak DB2 nedávno oslavila 25. výročí. Ačkoliv databáze Oracle je služebně starší, první komerčně dostupná verze Oracle je z roku 1979 a nedávno slavila své 30. výročí, tak je IBM DB2 všeobecně považována za první databázi s dotazovacím jazykem SQL.

Číslice 2 v názvu databáze značí že se je jedná o druhou generaci IBM databází pro mainframy. DB2 je založena na dotazovacím jazyku SQL a relačním modelu dat, zatímco první databáze - IMS byla založena na hierarchickém modelu dat. IMS je legendární databáze, která je tu s nám již 40 let a používá se dodnes. IMS databáze běží pouze na IBM mainframech a zpracovává ze všech databází nejvíce transakcí za den, podle článku v Z/Journalu se jedná o denní objem 3 * 10^12 USD. Obvykle se používá na mainframech v kombinaci s DB2 která je použita na data warehousing, OLTP běží na IMS.

Historie vývoje DB2 je zajímavá, protože DB2 byla v mnoha ohledech na svou dobu inovativní a vlastně je inovativní i v současnosti. V krátkosti si proto projdeme její historii a podíváme se jak se SQL technologie za posledních 25 let vyvíjela a s jakými optimalizacemi při zpracovávání dat se přišlo.

Verze 1.0 byla oznámena 7.6.1983. Ačkoliv měla číslo verze 1.0 tak to byla vlastně jen beta verze určena pro testování u vybraných zákazníků, Plánovaná finální verze (GA) byla oznámena pro třetí čtvrtletí 1984. Vyšla pro 31-bitové architektury MVS/XA a MVS/370 a podporovala integraci se stávajícími systémy IMS a CICS. Používala dotazovací jazyk SQL v jeho obou variantách SQL DDL a SQL DML a byla to druhá databáze od IBM která používala relační model dat - první byl System R. Jméno produktu bylo IBM Database 2, zkráceně DB2.

Verze 1.1 byla vydána 2.4.1985 a byla to první verze pro všeobecné použití. Jak je vidět projekt se oproti původnímu plánu poněkud zpozdil. Obsahovala: Relační datový model, multiuživatelský přístup k datům, možnost vytvářet nové tabulky online (narozdíl od IMS), podporu pro SQL a interaktivní režim DB2I (taktéž novinka) a cost based SQL optimizer.

Verze 1.2 ze 4.2.1986 přinesla dost novinek které byly povětšinou založené na praktických zkušenostech uživatelů s verzí 1.1. V SQL narozdíl od hierarchické IMS generuje přístupový plán k datům optimalizátor SQL dotazů a nikoliv programátor. Přibyl příkaz EXPLAIN pro zobrazení přistupových plánů jednotlivých SQL příkazů. Prováděcí plány přiřazené k SQL příkazům v aplikačnímu programu byly rozděleny na 4KB bloky a dynamicky se nahrávaly podle potřeby. DB2 totiž preferovaně používá statické SQL. Statické SQL znamená že příkaz je znám již v době kompilace uživatelova programu. Výsledný přístupový plán je uložen do systémových tabulek. Tento mechanizmus zvyšuje výkon - není potřeba SQL příkazy posílané aplikací parsovat a optimalizovat a také umožňuje mechanismus propůjčené identifikace, protože při vykonávání programu se berou v potaz přístupová práva toho kdo jej kompiloval, nikoliv toho kdo jej spouští.

Velikost rezervovaného prostoru v datové stránce bylo možné nastavit ručně. Pokud používáme příkaz INSERT tak není vhodné zaplnit úplně celou databázovou stránku (obvyklá velikost stránky je 8KB) než začneme ukládat nová data do další. Při příkazu UPDATE může totiž docházet ke zvětšení velikosti záznamu pokud tabulka obsahuje sloupce o proměnné velikosti. Pro efektivní práci databáze je žádoucí aby se aktualizovaný záznam nacházel ve stejné stránce jako původní záznam - není totiž třeba aktualizovat indexy pokud se nezměnila hodnota obsažená v indexu. Pokud je potřeba přemístit záznam z jedné stránky do druhé protože se do původní stránky nevejde tak DB2 umístí do původní stránky odkaz na jeho nové umístění a indexy neaktualizuje - nechá je odkazovat na staré umístění. Reorganizace tabulky je doporučena pokud je takto relokováno více než 5 procent řádek. Pokud si rezervujete dostatečné množství místa - okolo 15 procent tak je relokace řádku poměrně vyjímečným jevem.

Další velmi důležitou vlastností DB2 1.2 byl sekvenční prefetch neboli načítání stránek v předstihu. Nejpomalejším místem v databázi je načítání stránek z disku. Pokud procházíme tabulku sekvenčně a nepřistupujeme k ní pomocí indexu tak musíme načíst postupně všechny její datové stránky. Sekvenční prefetch zajistí že během zpracovávání jedné stránky se již načítá z disku stránka další. Toto je jen zjednodušený popis v praxi se tabulky dělí na extenty a ty pak teprve na stránky. Pokud se zvětšuje tabulka, nový prostor se alokuje po extentech aby nedocházelo ke zbytečné fragmentaci. Doporučovaná velikost extentu závisí na konkrétní databázi v DB2 se používá velikost okolo 128 KB, kterou je silně doporučováno použít i na strip size RAID 5/0 diskových polí. Utilita LOAD, která se používá pro rychlé offline (direct) nahrávání dat získala přepínač REPLACE, který jí umožnil rychle smazat celou tabulku a nahradit ji nahrávánými daty. Toto se používalo přes dvacet let místo příkazu TRUNCATE TABLE.

Další významnou záležitostí bylo point in time (rollforward) recovery, umožňující obnovit databázi do zadaného časového okamžiku - kupříkladu před tím než administrátor omylem smazal důležitá data. Tento způsob zálohování a obnovy se také používá u velkých databází, protože místo denní zálohy veškerých dat kontinuálně zálohujete jen jejich změny.

Poslední velmi významnou změnou byla eskalace zámků. Zamykat data v databázi aby více uživatelů nemodifikovalo současně stejný řádek lze buďto na zapsáním zámku na disk nebo do paměti. DB2 používá druhý způsob. Na rozdíl od prvního způsobu, kde můžete mít prakticky neomezený počet zámků ale zase musíte generovat pomalé diskové io operace se jich do paměti vejde jen omezené množství. Eskalace zámků dovolí v případě nedostatku paměti nahradit zámky jednotlivých řádků zámkem stránky nebo tabulky. Uzamkne to sice více dat ostatním uživatelům, ale nebude nutné úlohu přerušit z důsledku vyčerpání paměti pro zámky. Při eskalaci zámků však často nastávají deadlocky a tak je třeba databázi nastavit tak, aby při běžné práci k eskalaci zámků docházelo co nejméně.

Verze 1.3 byla oznámena pátého května 1987. Přinesla podporu konstrukce UNION ALL a přibyly nové datové typy - datum, čas a časová značka. Utilita RUNSTATS pro získávání informací o tabulkách pro cost based optimizer šla nyní spustit i nad systémovým katalogem. Byla rozšířena podpora programovacích jazyků o DL/I Batch, VS COBOL II a rozhraní SAA.

Verze 1.3 byla již velmi schopnou databází, která překonává bez problémů feature set dnešní tak oblíbené kombinace MySQL/ISAM.

Verze 2.1 (2.0 nebyla) vyšla 23. září 1988. Jejím největším přínosem bylo zavedení referenční integrity (foreign keys). Touto vlastností předběhla konkurenci zhruba o pět let. Ostatně MySQL kdyby si nelicencovalo InnoDB engine tak by nemělo referenční integritu dodnes. Nově podporovanou architekturou se stala MVS/ESA a nově podporovaným jazykem pro tvorbu aplikací se stalo C. Přibyla podpora pro omezování CPU zdrojů jednotlivým uživatelům, což nemá většina databází dodnes. V oblasti zabezpečení přibyl auditu přístupu k datům a podpora sekundárních ID - jedno databázové spojení tak může mít přiřazeno několik uživatelských identifikací. Byly rozšířené utility REPORT, QUIESCE, RECOVER a LOAD (umožnila během nahrávání dat testovat unikátnost podle indexu).

Verze 2.2 vyšla 22. září 1989. Přišla s novinkou multiple index access. Vysvětlím stručně oč se jedná. Pokud chceme rychle najít hodnoty v tabulce, použijeme index nad sloupcem podle kterého vyhledáváme. Pokud vyhledáváme podle více sloupců musel doposud index obsahovat oba sloupce aby ho uměl optimalizátor SQL dotazů použít. Při použitití techniky multiple index access pokud vyhledáváme podle hodnot ve dvou sloupcích tak k tomu můžeme použít dva indexy - nad každým sloupcem jeden. Z každého indexu přečteme nalezené čísla řádků odpovídající vyhledávané hodnotě v příslušném sloupci, čísla řádek setřídíme a pak provedeme s oběma seznamy operaci IXOR, případně IXAND podle podmínky v dotazu. Tato optimalizační technika snižuje počet indexů, které musíme nad tabulkou vytvářet a tím šetří čas potřebný k jejich aktualizaci a diskový prostor. MySQL tuto techniku dlouho neumělo, teď si nejsem jist zda se to naučilo ve verzi 4.1 nebo 5.0.

Další změny v DB2 2.2 byly zlepšená podpora SQL standardů, přístup k datům uloženým v DB2 databázi na jiném systému a rozšíření omezování systémových zdrojů náročným SQL dotazům - DB2 Governor, který se používá dodnes, ačkoliv je postupně v DB2 9 vytlačován systémem workload manager, který je integrován přímo do databázového jádra - DB2 Governor je externí program sledující vytíženost databáze pomocí monitorovacího API.

Verze 2.3 z 25 října 1992 byla opět napěchována řadou novinek. Pravděpodobně nejvýznamnější změnou bylo uvedení packages (nepléct si to s packeges v Oraclu. Této funkcionalitě se říká v DB2 terminologii modules). Před uvedením packages byly přístupové plány pro statické SQL ukládány do systémového katalogu samostatně pro každý SQL příkaz uvedený v aplikačním programu, s příchodem packages se práce se statickým SQL výrazně zjednodušila. Packages pracují zhruba takto: Aplikační program napsaný v jazyku který podporuje statické SQL - nejčastěji to bude SQLC (koncovka .sqc) nebo SQLJ (koncovka .sqlj) se přeloží preprocesorem který rozumí embedded SQL syntaxi. Z tohoto preprocesoru vypadne standardní C nebo JAVA program a binární soubor s koncovkou bnd. Soubor bnd nahrajeme s příslušnými parametry příkazu BIND do databáze a při nahrání se vytvoří přístupový plán pro v něm obsažené SQL příkazy. Při vykonávání aplikačního programu již databáze nemusí kontrolovat přístupová práva, parsovat SQL a vytvářet přístupový plán protože všechny tyto akce byly vykonány při nahrání bnd souboru do databáze a je proto vykonávání SQL příkazů rychlejší podobně jako v případě prepared statementů, které se používají u dynamického SQL. V databázi vznikne vazba aplikační program - balíček přístupových plánů.

Poprvé se objevil standardní protokol DRDA standardizující komunikaci mezi aplikací a databází. Definici tohoto protokolu si můžete přečíst u Open Group. V současnosti používá tento protokol DB2 na všech platformách jako svůj primární komunikační protokol, který ustoupil proprietárnímu "DB2 private" komunikačnímu protokolu. DRDA podporuje také Informix, Apache Derby a Oracle Gateway for DRDA. S použitím DRDA mohli poprvé k DB2 snadno přistupovat aplikace na ne-IBM operačních systémech.

Další důležitou inovací bylo rozšíření SQL jazyka o klauzuli OPTIMIZE FOR n ROWS, kterou databázi naznačíme kolik řádek z výsledku SELECTu hodláme v aplikaci přečíst. Databáze tak dostane možnost vybrat přístupový plán který vrátí první řádky výsledků rychleji. Aplikace stále může přečíst libovolný počet řádků, klauzule ovlivňuje jen optimalizer. Protože IBM navrhovala i hardware, tak si mohla upravit procesor aby na něm lépe běžela databáze. Tyto optimalizace ostatně provádí IBM dodnes, a to nejen na úrovni svých procesorů, ale i na úrovni operačních systémů. V této verzi byla poprvé použita hardwarová podpora třídění v klauzulích ORDER, UNION, DISTINCT, GROUP, CREATE INDEX. Na scénu přišla i replikační technologie nazývaná SQL replikace založená na čtení změněných dat z transakčního logu, které se používá dodnes ale často bývá nahrazována z důvodů nižší latence novým systémem založeným na posílání zpráv o změnách. Protože DB2 nezapisuje do transakčního logu celé změněné řádky ale jen změněné sloupce přibyl přepínač DATA CAPTURE NONE/CHANGES u tabulek, který ovlivňuje typ protokolování. Jeho aktivací řekneme DB2 aby pro danou tabulku zapisovala do redo logu celé řádky. Další změny se týkali především zvýšení dosavadních limitů.

Verze 3 vyšla 17. prosince 1993. Důležitých novinek bylo několik. Asi nejdůležitější byla podpora pro hardwarovou kompresi dat, která ušetřila zhruba 30-50 procent diskového prostoru a zrychlila zpracování dat protože se nemuselo tolik číst z disku. Další velkou novinkou byla podpora dvoufázového potvrzovacího protokolu neboli two phase commit neboli distributed unit of work. Jedná se o možnost provádět ACID transakce napříč databázemi. DB2 nevyžadovala externí transaction monitor pro dvoufázové potvrzování, ale uměla spolupracovat s CICS nebo MQ Series. Při zpracování SQL dotazu bylo možné posílat disku současně více io operací a načítat data z více tabulek současně. Mezi podporované jazyky pro tvorbu aplikací přibylo C++ a IBM COBOL pro MVS a VM.

Maximální počet připojení k databázi byl zvýšen na 10 000, současně aktivních mohlo být 2 000. Dělení spojení na aktivní (právě provádějící nějaký příkaz) a neaktivní (čekající na další příkaz uživatele) je technika umožňující serveru více současně připojených uživatelů aniž by k tomu potřeboval hodně operační paměti. Pro příklad vužití této techniky v praxi nemusíme chodit daleko - web server Apache toto běžně dělá. Hezky je to vidět pokud používá prefork model - pokud má více připojení než má spuštěno procesů tak je nechá čekat až nějaký dokončí činnost. Z dalších novinek je ještě zajimavá možnost vytvářet indexy s volbou DEFER. Při použití této volby se index nevytvoří, jen se zapíše do systémového katalogu. K vlastnímu vytvoření indexu dojde až po spuštění externí utility REBUILD, která je na rozdíl od vestavěného třídícího subsystému optimalizována pro třídění velkých objemů dat.