DB2 survival guide Bohuslav Dvorský, IBM 14.11.2012

Agenda Jak předejít problémům? Jak řešit problém? Co nikdy nedělat?

Jak předejít problémům? Backup & recovery Nastavení storage Autonomní operace Jak předejít případným problémům – většina přítomných se primárně DB2 nechce zabývat, není to primární náplní jejich práce a potřebují, aby DB2 fungovala. DB2 v poinstalační konfiguraci funguje v zásadě správně, nicméně pro zajištění plynulého chodu v dalších letech, nebo pojištění případu havárie je třeba vykonat několik kroků, které zabezpeční výše uvedené. Je tedy nutné uvažovat o proaktivním přístupu, ve chvíli kdy nastane problém, databáze nefunguje, je už pozdě. Scénář – DB2 běží, nevyskytují se žádné problémy – jedná se o bezproblémový stav, který by v poinstalační konfiguraci mohl vydržet roky Jenomže mohl to nám bohužel nestačí – v několika jednoduchých, ale zásadních krocích si ukážeme jak databázi optimálně nakonfigurovat

Backup & recovery Kruhové logování Parametry LOGARCHMETH1 a LOGARCHMETH2 nastaveny na OFF V DB2 rozlišujeme 2 typy logů – primární a sekundární. Primární logy jsou prealokované logy, do kterých se transakce zapisují nejdříve. Sekundární jsou dynamicky alokované logy, pro případ, že by došlo k zaplnění kapacity primárních logů. Kruhové logování jak již název napovídá používá pro logování tzv. kruh logů. Transakce jsou zapisovány do logů a ve chvíli kdy dojde k bezpečnému zápisu na tablespace(na diskový prostor) dochází k přemazání bezpečně zapsaných transakcí. V případě havárie/výpadku je po nastartování systému ihned spuštěna crash recovery, která za pomoci logů uvede databázi do konzistentního stavu. Pro zapnutí kruhového logování nastavíme parametry Logarchmeth1 a 2 na OFF Výhoda: logy jsou neustále přemazávány a nedochází k plnění diskového prostoru Nevýhoda: nelze se vrátit v čase do určitého bodu, lze provádět pouze offline backup Update db cfg using logarchmeth1 OFF

Backup & recovery Archivní logování Parametry LOGARCHMETH1 nebo LOGARTMETH2 nastaveny na ON Archivní logování jak již název napovídá archivuje všechny transakce do externího logu. Je zapnuto ve chvíli, kdy je jeden z parametrů logarchmeth(nebo oba) nastaven na on. Tímto parametrem rovněž specifikujeme cestu až na 2 různá úložiště. Striktně se doporučuje umístit archivní logy na jiné úložiště než databázová disková pole samotná, v případě selhání disku by nám totiž byly logy k ničemu. Archivní logování zaznamenává veškeré transkace probíhající na databázi. V případě lidské chyby, nebo z jiných důvodů, je možno vrátit se v čase do určeného bodu. Rovněž můžeme díky archivnímu logování provádět ONLINE backup databáze, právě díky zápisu všech logů v čase, kdy je full backup díky logům uveden do konzistentního stavu. Aktivní logy – transkace zatím nezapsané do tablespace Online archive – logy zapsané do tablespace a dále uchovávány Update db cfg using logarchmeth1 DISK:/u/dbuser/archived_logs

Backup & recovery Záloha databáze Online – pouze full db backup, nutno zapnout archivní logování Offline – inkrementální, delta, full backup, archivní i kruhové log. BACKUP DATABASE <název_databáze> [ TO <cesta> ] db2 BACKUP DB sample TO C:\BACKUPS ONLINE COMPRESS INCLUDE LOGS

Backup & recovery Obnovení databáze Obnovení po havárii nebo restartu Obnovení verze nebo obrazu Obnovení roll-forward RESTORE DATABASE <název_databáze> [from <cesta>] [taken at <čas.razítko>] RESTORE DB sample FROM <cesta> TAKEN AT 20101128105511

Nastavení storage Separace tablespace Separátní tablespace pro LOBy Separátní tablespace pro indexy + separátní bufferpooly Zejména pokud se v databázi uchovávají velké objekty – tzv. LOBy, striktně se doporučuje optimalizovat databázi za pomoci separace tablespace. Jde o vytvoření samostatného tablespace pokud možno na rychlém diskovém poli s pagesize 32k do kterého umístíme tabulku, které se ukládají LOBy. Stejně tak se doporučuje vytvořit k těmto tablespace nové bufferpooly rovněž s velikostí page 32k. Stejná pravidla platí I pro indexy. Rádi bychom co nejrychlejší indexaci, proto vytvoříme separátní tablespace pro indexy na nejrychlejším diskovém prostoru.

Nastavení storage Table space management db2 create bufferpool testbufpool pagesize 32k db2 "create tablespace tblspc pagesize 32k managed by automatic storage using ('/data/db2inst1/NODE0000/dbname/T0000002/')" bufferpool testbufpool Table space management System Managed Storage Database Managed Storage Managed by Automatic Storage Table space managemet – systém fyzického ukládání dat může být řízen 3 způsby. SMS je možností, kdy ukládání dat na diskové pole řídí operační systém. Poskytuje maximální kontrolu na využitím diskového prostoru, alokací a umístění souborů, nicméně za cenu nemalého úsilí a času. Využíváno většinou zkušenými DBA. DMS je možností, kdy se o ukládání stará databáze. Dynamicky alokuje diskový prostor a fragmentuje data. Díky DMS se nemusíme o nic starat, nicméně ztratíme kotrolu, kterou bychom mohli mít díky SMS. Automatic storage je nejvhodnějším kompromisem mezi výše uvedenými a je námi pro použití s Lotus doporučován. Databáze se automaticky rozhoduje, jaký typ table space managementu použije pro ukládání, kterých dat.

Autonomní operace STMM = Self tuning memory manager Automatic database backup (AUTO_DB_BACKUP) = ON Automatic table maintenance (AUTO_TBL_MAINT) = ON Automatic runstats (AUTO_RUNSTATS)= ON Automatic reorganization (AUTO_REORG) = ON UPDATE DB CONFIG USING AUTO_MAINT ON AUTO_TBL_MAINT ON AUTO_RUNSTATS ON AUTO_REORG ON Autonomni operace jsou nedilnou soucasti DB2. Jsou to operace, ktere v zasade usnadnuji administratorovi praci a automatizuji chod databaze. V zasade se jedna o 3 nejdulezitejsi a sice automatickou zalohu databaze, automaticke sbirani statistiky a automatickou reorganizaci (defragmentaci) databaze. Automaticke statistiky sbiraji statisticke informace o probihajicich transakcich a na jejich zaklade je sestavovan optimalni exekucni plan, staraji se tedy o optimalizaci a co mozna nejrychlejsi chod databaze. Automaticka reorganizace provadi “defragmentaci” dat v tabulkach. Diky probihajicim transakcim se muze stat ze vznikaji zbytecne volne prostory na disku, nebo jsou souvisejici data “daleko od sebe”. STMM = Self tuning memory manager db2 update dbm cfg using instance_memory automatic

HOWTO - Jak to nastavit Doporučené nastavení zálohování Zapnutí archivního logování Update db cfg using logarchmeth1 DISK:/u/dbuser/archived_logs Update db cfg using logarchmeth2 DISK:<jiná cesta> Zazálohojeme databázi Compress: pro komresi zálohy až o 90% include logs: přiloží dostupné logy – pro jednodušší restore do určitého bodu Online: bez nutnosti odpojit uživatele db2 BACKUP DB <jméno databáze> TO <cesta> ONLINE COMPRESS INCLUDE LOGS Správné nastavení autonomních operací UPDATE DB CONFIG USING AUTO_MAINT ON AUTO_TBL_MAINT ON AUTO_RUNSTATS ON AUTO_REORG ON

Jak řešit problém? 1. Nastal problém 2. Identifikace problému Nastal problém, instance nejde nastartovat, databáze vyhazuje errory…nefunuguje to. Vyvstává nám zásadní otázka, jak problém identifikovat a jak ho vyřešit? 3. Řešení problému

Jak řešit problém? Vysoká důležitost PIC IBM forum APARy IDUG V případě že došlo k havárii na důležitém systému, produkčním systému je rozhodně nutné kontaktovat IBM support. Důležité je přiřadit problému odpovídající severitu 1 nebo 2. a poté čekat reakci supportu. U nejmenované energetické společnosti při severitě 1 trvala odezva IBM support 20 min a následně se problém řešit nepřetržitě 24/7. Support se dá rovněž využít i pro méně závažné případy, nebo I pro pouhé získání informací. V tomto případě však musíme očekávat, že odezva supportu může být I několik dní. PIC IBM forum APARy IDUG Nižší důležitost, výstrahy, varování, informace

Identifikace problému db2 ? command Zjišťování více informací o chybových kódech Pro získání více informací o obdrženém chybovém kódu odešlete kód s prefixem otazníku ve vkládacím okně Příkazového editoru a klikněte na tlačítko Execute. Znak otazníku (?) vyvolá příkaz nápovědy DB2. Níže je několik příkladů, jak vyvolat nápovědu, pokud například obdržíte SQL chybovou hlášku “-104”. Všechny příklady uvedené níže jsou ekvivalentní. db2 ? SQL0104N db2 ? SQL104N db2 ? SQL-0104 db2 ? SQL-104 db2 ? SQL-104N A.2 SQLCODE a SQLSTATE SQLCODE je kód obdržený po každém spuštění SQL příkazu. Význam jednotlivých hodnot je shrnut níže:  SQLCODE = 0; příkaz byl úspěšný  SQLCODE > 0; příkaz byl úspěšný, vrátil ale upozornění  SQLCODE < 0; příkaz nebyl úspěšný a vrátil chybu SQLSTATE je pětiznakový řetězec, který se přizpůsobuje ISO/ANSI SQL92 standardům. První dva znaky jsou známé jako kód třídy:  Kód třídy 00 znamená, že příkaz byl úspěšný.  Kód třídy 01 znamená upozornění. Kód třídy 02 znamená nenalezenou podmínku.  Ostatní kódy tříd se považují za chyby.

Identifikace problému Administrační notifikační log Poskytováni diagnostických informací o chybách v bodě selhání V systémech Linux/UNIX je to textový soubor pojmenovaný instance.nfy Ve Windows se všechny adm. notifikace zobrazují v Event Logu Administrační notifikační log poskytuje diagnostickou informaci o chybách v době selhání. Na platformách Linux a UNIX je administračním notifikačním logem textový soubor nazvaný <jméno_instance>.nfy (např. “db2inst.nfy”). Ve Windows se všechny zprávy administrační notifikace zapisují do logu událostí systému Windows. Konfigurační parametr DBM notifylevel umožňuje administrátorům specifikovat úroveň informací, která se má zaznamenávat:  0 – Nezachytávat žádné notifikační zprávy (nedoporučuje se)  1 – Fatální nebo neopravitelné chyby  2 – Vyžaduje okamžitou akci  3 – Důležitá informace, není vyžadována okamžitá akce (defaultní hodnota)  4 – Informativní zprávy

Identifikace problému db2diag.log Detailnější informace než notifikační log Používáno supportem nebo zkušenými DBA Support může vyžadovat jeho zaslání WindowsVista and later • ProgramData\IBM\DB2\ WindowsXP/2003(default) •C:\Documents and Settings\All Users\ Application Data\IBM\DB2\DB2COPY1\<instance name> Linux/UNIX(default) •INSTHOME/sqllib/db2dump (INSTHOME is the home directory of the instance owner) Log db2diag.log poskytuje detailnější informace než Administrační notifikační log DB2. Je běžně používán jen technickou podporou IBM DB2 nebo zkušenými DBA. Informace v db2diag.log obsahují:  DB2 kódovou lokaci, která reportuje chybu.  Aplikační identifikátory, které vám umožní uspořádat záznamy příslušející aplikaci v db2diag.logs serverů a klientů.  Diagnostickou zprávu (začínající na "DIA"), vysvětlující důvod chyby.  Všechna dostupná podpůrná data, jako SQLCA datové struktury a ukazatele na lokaci se soubory výpisů a léček. Ve Windows (kromě Vista) je db2diag.log umístěný defaultně v adresáři: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\<instance name> Ve Windows Vista je db2diag.log umístěn defaultně v adresáři: C:\ProgramData\IBM\DB2\DB2COPY1\<instance name> V Linuxu/UNIXu je db2diag.log umístěn defaultně v adresáři: /home/<instance_owner>/sqllib/db2dump

Řešení problémů IBM Support Přihlášení do Passport Advantage Zadání PMR/Service requestu Volat na helpdesk

Řešení problémů Public Information Center = PIC pro verze 9.5, 9.7, 10.1

Řešení problémů IBM DB2 Forum IDUG Forum http://www.ibm.com/developerworks/forums/db2_forums.jspa IDUG Forum http://www.idug.com/

Řešení problémů APAR = Authorized Program Analysis Report = problém(bug) nahlášený a uznaný IBM supportem - většinou vyřešen fix packem

Co nikdy nedělat? Nic nemazat Rozhodně nemazat logy nebo zálohy, pokud si nejsme 100% jistí, že nebude ohrožená případná obnova databáze Nemazat žádné systémové soubory/objekty databáze Zadat v PMR vyšší severitu než opravdu je Support se bude primárně starat o service requesty s nejvyšší severitou. Uvádění nepřesné (popřípadě záměrně vyšší) severity by mohlo vést k negativnímu přístupu supportu v případě budoucích problémů Nepodceňovat význam zálohy a logování Archivní logování se může ukázat nadměrně užitečným v případě lidské chyby, stejně tak provádění pravidelné zálohy nám ušetří případnou práci s rollworwardem transakcí v případě havárie

Děkuji za pozornost bohuslav_dvorsky@cz.ibm.com