DB2 Version 5 for OS/390 - pokračování

Další zlepšení dostupnosti dat bylo vylepšení příkazu pro reorganizaci tablespaces REORG. Dříve bylo nutné než začala reorganizace dát celý tablespace do offline stavu. REORG tedy doznal dvou významných změn:

1. jednak byl stávající algoritmus trochu poupraven - místo aby se nová data zapisovaly přímo do cílového tablespace tak se použil pro sestavení tabulek a indexů dočasný tablespace. Dokud probíhalo sestavování tak zůstal původní obsah nedotčen a aplikace k němu mohli stále přistupovat, ale nemohli jej už měnit. Tablespace bylo potřeba exklusivně zamknout až v okamžiku kdy se začal přepisovat novými přeogranizovanými daty.

2. Druhá změna byla revolučnější. Místo aby se přeorganizovával celý tablespace najednou tak se přeorganizovávaly vždy jen 2 sousedící bloky. Tomuto se říkalo online reogranizace protože nebylo už potřeba zamykat celý tablespace a dalo se do něj během reogranizace i zapisovat v podstatě bez omezení protože zámky reorganizovaných bloků byly drženy po minimální dobu. Online reorganizace měla dvě nevýhody vyplývající z její metody práce:

   1. při přesunu řádek musela aktualizovat i indexy a aktualizace indexů se navíc musela protokolovat do redo logu. To dost zdržovalo

   2. nebylo možné současně dělat reorganizaci indexů. Ona se reogranizace indexů vpodstatě nedělala ani v případě offline reoganizace, tam se indexy sestavily celé znova, což zajistlilo jejich optimální rozložení. Navíc se při offline reogranizaci standardně vytváření indexů neprotokolovalo. Pokud by databáze zhavarovala tak by byl při restartu index označen za neplatný a vytvořil by se při přístupu k datům znova. Po online reogranizaci bylo proto vhodné spustit ještě REORG indexů s parametrem CLEANUP ONLY, což vymazalo smazané záznamy z indexů a pokud byla stránka v indexu téměř prázdná, tak ji to smazalo a data se přesunuly do vedlejší.

Online reorganizace byla proto znatelně pomalejší než offline, udávalo se že v nejhorších případech může být až desetkrát pomalejší. Bylo ji proto možné a žádoucí spouštět se sníženou prioritou aby negenerovala příliš IO operací a nebrzdila provoz databáze. Její pomalost všem nijak nesnižovala revolučnost, kterou přinesla do oblasti dostupnosti dat. Pokud byl čas v časovém okně vyhrazeném na denní údržbu a batch joby i na offline reogranizaci tak databázoví administátoři preferovali ji.

Utility LOAD a offline REORG navíc dostaly novou volbu pro vytváření kopie tablespace během běhu. Tyto dvě utility se totiž protokolují jen minimálně a při rollforward recovery se z protokolovaných informací nedá obnovit obsah tablespace. Proto dříve pokud doběhly byl tablespace ve stavu COPY PENDING kdy se před jeho použitím vyžadovalo spustění utility COPY která provede jeho kopii - plnou nebo inkrementální. V DB2 5 bylo COPY uděláno inteligentnější protože se s pomocí nového parametru CHANGELIMIT dovedlo rozhodnout zda bude lepší plná nebo přírůstková kopie. Kopie během REORG či LOAD se vnyní volitelně vytvářely takříkajíc zaběhu - obsahovaly všechny změněné bloky do kterých se během operace zapsalo. Pokud byl některý blok měněn v průběhu akce vícekrát tak se v kopii také vícekrát objevil. Tato vlastnost se používá dodnes. Když jsme u těch utilit tak byly také zoptimalizovány LOAD, REINDEX, COPY pro nižší spotřebu CPU a všeobecné zrychlení a RUNSTATS umělo samplovat data a nemuselo pokaždé procházet celou tabulku jen kvůli spočitání statistik pro optimalizer.

Byla zvýšena efektivita provádění SQL pomocí prepared statementů. Přístupový plán dynamického SQL které se vykonává opakovaně může být nyní uložen a znova použit. U krátce běžících SQL příkazů lze tak dosáhnout velmi významného zrychlení až o stovky procent. Protože změněný parametr při volání prepared statementu nemusí vést ke stejnému prováděcímu plánu byla do utility BIND přidána volba REOPT pro ovlivnění zda se má u statického SQL přeoptimalizovat dotaz s ohledem na novou hodnotu parametru. Další vylepšení se týkalo zavedení optimalizátoru výrazů, který přepisoval dotazy tak aby šel použít index. Toto je dost unikátní vlastnost i dnes, jen málo která databáze to dneska umí. Optimalizovat šly kromě základních výrazů jako A*2 > 100 i pokročilejší věci jako ENDDATE > CURRENT DATE - 30 DAYS. Když už jsme u těch zlepšení SQL tak do příkazu SELECT přibyla možnost použít CASE výrazy, které se dříve nahrazovali emulací přes UNION.

Síťový protokol DRDA, kterým komunikuje DB2 klient a DB2 server byl aktualizován na verzi 2. Nejdůležitější vlastností verze 2 byla technika kterou dnes nazýváme pipelining. V jedné zprávě bylo možné odeslat SQL dotaz + žádost o výsledek předchozího. Efektivita protokolu se zvýšila i použitím optimalizace zvané block fetch kdy server posílal řádky v blocích a klient mohl na úrovni protokolu specifikovat kolik řádek má zájem maximálně přečíst. Mainframová DB2 se také konečně naučila komunikovat TCP/IP protokolem, což oceňovali zejména uživatelé Windows 3.X, kteří nemuseli podstupovat utrpení při konfiguraci APPC. Ve Windows 95 byla konfigurace APPC přece již o něco jednoduší. Vylepšena byla i podpora pro autorizační metody co nepoužívají heslo - kupříkladu kerberos nebo DCE tickety a bylo umožněno pomocí DRDA protokolu měnit uživatelům heslo, což byla poměrně neobvyklá funkce vzhledem k tomu že DB2 narozdíl od většiny dnešních db nemá vlastní autentifikační databázi a standardně si nechává uživatele autentifikovat od operačního systému nebo autentifikačního pluginu připojujícího se k externí autentifikační službě. V pětce přibyla navíc možnost volat pro autentifikaci externí program - této metodě se říká v terminologii použité IBM user exit.

DRDA byl v DB2 5 opravdu významně vylepšen a poprvé tak výkonově překonal a nahradil starší protokol DB2 private protokol, který byl původně protokol pogramu DDF Distributed Data Facility a byl zaveden v DB2 verzi 2. Ve verzi DB2 Verze 2 Release 3 byla přidána podpora 3-vrstvého protokolu DRDA a protokol DDF již nebyl rozvíjen. Člověk by proto zcela logicky očekával že tento protokol brzy zmizí. Nestalo se tak. V současné DB2 verzi 9 je tento protokol pořád podporován, ačkoliv je již teď označován oficiálně za zastaralý a DB2 hlásí warning. Zde hezky vidíte co znamená slovo konzervativní a ochrana investic když to vztáhneme na IBM mainframy.

Stored procedury získaly novou možnost vracet otevřené kurzory a vracet tak více údajů než bylo možné doposud předávat pres INOUT či OUT parametry. Tato vlastnost stored procedur není zdaleka samozřejmá, implementace v databázi není jednoduchá a databáze obvykle potřebují několik verzí než tuto vlastnost u stored procedur implementují. DB2 k tomu ještě přinesla hned dvě inovace: 1. umožňovala vracet více otevřených cursorů a tak bylo možné předávat několik sad řádek 2. umožňovala specifikovat komu mají být tyto cursory předány - jestli tomu kdo proceduru zavolal nebo uživatelskému programu volající DB2 přes API. Proceduru totiž nemusí volat přímo uživatelský program, ale může to být i jiná procedůra. Tato druhá vlastnost je velmi zajímavá.

Další změny se týkaly utilit a to ať již standardně dodávaných se serverem nebo placených extra. Novinka byla utilita Visual Explain, která existuje pod stejným názvem a prakticky nezměněná dodnes. Tato utilita graficky zobrazovala výsledek příkazu EXPLAIN, který zobrazoval prováděcí plán k SQL příkazu. Byla velmi užitečná utilita protože výsledek příkazu EXPLAIN se nezobrazoval v textové formě nýbrž se ukládal poměrně netypicky do tabulek a obsahoval velké množství podrobností, pravděpodobně více než jakákoliv jiná databáze. Ukládání do tabulek nebyl vůbec špatný nápad, protože bylo možné mít pro porovnání uložená vysvětlení z minulosti. Uživatel si ale pak buďto musel napsat program který uložené výsledky zobrazil nebo použít dodávaný program EXFMT který tyto výsledky zobrazil v textové podobě. Vzhledem k velkému množství podrobností nebyl jeho výpis moc, tedy spíš vůbec, přehledný. Visual Explain se tak velmi hodil. Nejenže plán hezky graficky prezentoval, ale vynechal i nepodstatné podrobnosti aby uživateli zbytečně nepletl hlavu.

Další zajímavou utilitou byl DB2 performance monitor. Byl to online monitorovací systém pro DB2 který monitoroval výkonost serveru. Tedy on uměl poměrně nezvykle monitorovat výkonost i na klientu, ale to se zas tak moc nepoužívalo. Uměl zobrazovat nejen současný stav co se na serveru děje, ale uměl i schraňovat data pro historickou analýzu z kterých pak dělal hezké reporty. Byl to velmi užitečný program a většina velkých instalací se bez něj neobešla, protože uměl najít velmi rychle uživatele, spojení nebo aplikaci brzdící databázi. Taky uměl monitorovat vyjímky - kupříkladu chybu při čtení nebo zápisu dat, sezbírat detailní informace, spustit uživatelem definovanou akci a kupříkladu vyjímku oznámit přes SNMP. Bylo to prostě něco, co si každá DB2 instalace řekněme nad 50 uživatelů velmi ráda zakoupila. V dobách před DB2 performance monitorem si každý administrátor musel napsat pár skriptů kterými zpracovával data poskytovaná DB2 monitorovacím subsystémem a ty data se pak obvykle nahrávaly do tabulkového procesoru k analýze a prezentaci.

Další utilita byla naše stará známá Net.Data, dříve nazývaná DB2 WWW Gateway o které jsem se již zmiňoval. Tento produkt ve spolupráci s Data Joinerem uměl přistupovat i k IMS, což byla nejpoužívanější databáze na mainframech. Net.Data se používala především na intranetech, protože se v ní daly rychle napsat formuláře pro vkládání dat - na sofistikovanější aplikace to nebylo vhodné a navíc se již pohybujeme v čase kdy existoval IBM Websphere Aplikační server, který Net.Data rychle odsunul do pozadí zájmu. Jestě by stálo za zmínku, že bylo kromě HTML podporováno i VRML, kterému se tehdy předpovídala skvělá budoucnost.

Posledním produktem byl DB2 Estimator. Uměl vyhodnocovat přístupové plány podobně jako příkaz EXPLAIN. Nepracoval ovšem ze současným stavem databáze, ale se stavem imaginárně změněným uživatelem. Poskytoval tak odpovědi na otázky typu: Co se stane s výkonem když přidám index, zkomprimuji data, udělám table partition nebo trochu změním SQL dotaz? Uměl kromě SQL příkazů odhadovat i doby běhu utilit jako byly LOAD, REORG, RUNSTATS. Nebyl ale moc oblíben a v dalších verzích byla jeho funkcionalita přetvořena do produktu DB2 Design Advisor, který je standardní součástí DB2.

IBM obvykle nekomentovala co budou další verze DB2 obsahovat. Tady ale udělala vyjímku a prozradila co bude DB2 6 obsahovat:

1. Large Objekty {LOB}

2. Uživatelem definované funkce {UDF}

3. uživatelem definované typy {UDT}

4. Triggery

5. DB2 Extendery

Tyto věci nebyly na poli DB2 novinka, protože je nemainframová DB2 uměla již ve verzi 4. Nejednalo se tedy o nějakou novou převratnou funkcionalitu, tu by asi IBM neoznámila, ale o portaci kódu na OS/390.