Zajištění optimálního výkonu databázových aplikací začíná správně napsanýcm SQL dotazem.
Je známo, že 75% problémů způsobujících snížení výkonu databáze, je právě v důsledku špatně napsaných dotazů SQL a aplikačního kódu jako takového. Ale psaní efektivních SQL dotazů může být ošidné. Zvláště pak pro programátory, kteří SQL začínají nebo neprošli zádným ze základních školení na SQL. A že těchto školení existuje celá řada, sám některé z nich školím. Není možné postihnout veškeré možné chyby, navíc nejsem programátor, ale i jako DBA, musíte umět napsat základní (někdy i složitější dotaz), abyste získali potřebné informace.
Zde uvádím, alespoň dva základní příklady:
Na začátku je potřeba začít přemýšlet relačně. V čem to spočívá? Hlavně v tom, že si uvědomíte, že ne všechna data co máte uložena v tabulkách v databázi potřebuje a že je zbytečné veškerá data načítat do aplikace a v ní poté pracovat. Snažte se z databáze načíst jen ta data, která opravdu potřebuje, protože každá další infomrace znamená vyšší zatížeženi CPU a IO. Takže, následující SQL je lepší než jen čtení všech dat bez WHERE a pak kontrolovat každý řádek v programu, zda plat je vyšší než 10000.
SELECT EMPNO, LASTNAME, SALARYFROM EMPWHERE SALARY > 10000;
SELECT *
Dalším krokem je vždy vybrat pouze ty sloupce se kterými budete pracovat. Nebuďte líní při zápisu SELECT sloupc1, sloupec2, atd. Běžně používaný zápis „SELECT *“ se může hodit pro rychlé vyhledání potřebné informace, ale nedoporučuji ho používat v produkčním prostředí. Těch důvodů je více, ať již spotřeba zdrojových prostředků, protože takový zápis čte veškeré sloupce z tabulky, tedy i ty které dálenikde nevyužíváte. Tento zapis také může způsobit pád vaši aplikace poté co přidáte do vybírané tabulky sloupec. Tedy pozor na tento zjednodušený zápis.
Nepotřebujete-li v aplikaci některé sloupce, nezahrnujte je do klauzule select.
WHERE
Další pravidlo: Používejte klauzuli WHERE k filtrování dat v SQL místo toho, abyste veškerá data načítali do aplikace. Databáze se stvořená k tomu, aby velmi rychle aplikovala vámi zadané filtry a poskytla vám pouze omezený počet řádků. Uvědomte si, že na každý řádek čteny ze souboru potřebuje databázové zdroje I/O a CPU, které jsou omezené a společné pro všechy procesy napříč databází. Čím méně řádků vašim SQL dotaze získáte, tím bude efektivnější, rychlejší.
Dalším důležitým pravidlem je zamezit čtení řádků, které již znáte. Možná to zní banálně, ale mnoho programátorů toto pravidlo porušuje, aniž by si to vůbec umědomili. Například. Co je špatného na následujícím SQL dotazů?
SELECT EMPNO, LASTNAME, SALARYFROM EMPWHERE EMPNO = ‚000010‘;
Našli jste to? Problém je v tom, že do SELECTu je zahrnut i sloupec EMPNO zdela zbytečně, protože již v klauzuli WHERE definujete podmínku, kde je počet řádků omezen pouze na zaměstnance s číslem 10. Někdy toto číslo potřebujete, ael ve většině případů vám stačí pouze příjmení a plat. Tento zápis způsobé dodatčné režijní náklady.
Z hlediska správy nemohu opomenout databázové statistiky, což jsou informace o objektech obsažených v databázi. Tyto informace jsou uloženy v tzv. datovém slovníku a je potřeba dané statistiky udržovat aktualizované. Aktuální statistiky umožnují CBO zvolit nejvýhodnější exekuční plán, tedy cestu, jak získat požadovaná data.
Typické statistická data uložená v systémovém katalogu patří: – Informace o tabulkách, včetně počtu řádků, kompresní detaily a celkový počet stran; – Informace o sloupcích včetně počtu diskrétních hodnot pro sloupce a rozsah hodnot uložených ve sloupci; – Aktuální stav indexu včetně jeho organizaci stavu (počet úrovní a listové stránky), počet diskrétních hodnot index key a zda je index klustrovaný; – Informace o tabulkového prostoru (tablespace) a index nodegroups nebo oddíly (partitions). Dodržujte pravidla Při vytváření indexů neplatí pravidlo čím více, tím lepe. Vytvářejte indexy jen nad sloupci, které jsou zahrnuty v klauzuli where. Téma indexu je na delší povídání a já se k němu pokusím vrátit v některém z dalších článků.
Postačí, když řeknu, že pokud budete postupovat podle všech výše uvedených pravidel nebude dělat „nováčkovské“ chyby. Tato pravidla nejsou obtížné sledovat a další, in-hloubkové ladění bude zapotřebí. Ale po výše uvedených pravidel zajistí, že nejste dělat „nováčka“ chyby, které mohou zabít výkon aplikací.