Partitioning lze použít jako elegantní řešení široké škály problémů - distribuci tabulky na více disků (pokud z nějakých důvodů nechcete použít RAID pole), efektivní mazání archivních dat (bez DELETE), atd. Automaticky ho lze realizovat pomocí triggerů nebo pravidel. Podívejme se na puzzler související s partitioningem realizovaným pomocí RULE.
Pokud jste se v někdy trochu seriózněji zabývali laděním výkonu v některé z novějších verzí Oracle, možná jste se setkali s legendárním statspackem (viz. také Oracle Statspack Survival Guide), či s jeho následovníkem Automatic Workload Repository (AWR) jehož princip spočívá ve vytváření "snapshotů" důležitých interních statistik (počet dotazů, transakcí, čtení z disku, z cache, ...) a následné analýze rozdílů mezi provedenými snapshoty. Málo se ale ví že pro PostgreSQL existuje nástroj pgstatspack, který už svým názvem na Statspack odkazuje - je založen na stejném principu (analýza rozdílů mezi snapshoty), a i když je pochopitelně jednodušší může být stejně neocenitelným pomocníkem při ladění výkonu.
Přibližně před rokem jsem si pořídil netbook Eee PC 1000H od firmy Asus - hned od začátku jsem na něm provozoval své oblíbené Gentoo a KDE 3.5, i když to občas nebylo bez komplikací. Ale vzhledem k tomu že jsem "notorický vrtač" a "ignorant zpráv z portage" dostal se můj netbook do stavu kdy nebylo jiné cesty než kompletní reinstalace - a to rovnou na KDE 4.3.
Předem upozorňuji že se nejedná o instalační návod - konec konců k tomu máme výborný Gentoo Handbook. Spíše se jedná o užitečné a zajímavé informace specifické právě pro 1000H (a případné podobné netbooky), tj. například konfiguraci jádra, use flagy, místa kde jsem měl problémy apod.
Čas od času je potřeba během vývoje otestovat reakci aplikací na "úmrtí" databázového serveru. V PostgreSQL mailing listu se na toto téma odehrála poměrně zajímavá diskuse, ve které se objevilo několik zajímavých přístupů (od velmi elegantních až po brutální). Podívejme se tedy na jednotlivé způsoby zabíjení PostgreSQL ...
Říká se že "Cesta do pekel je dlážděna dobrými úmysly," a platí to i pro SQL dotazy. Mnoho problémů je způsobeno vývojáři kteří se snaží o optimalizaci a snížení zatížení databáze, mnohdy ale bohužel bez potřebných znalostí o vnitřním fungování.
Podívejme se na jiný zdroj problémů - strukturu tabulky. Opět, toto je velmi široké téma, uvedu pouze jeden častý modelový příklad, jehož další variace si jistě dovedete sestavit sami.
Minulý týden jsem sem vložil první SQL puzzler týkající se generování náhodných čísel resp. výběru náhodných řádků v PostgreSQL, s tím že se jedná o první a na nějakou dobu asi poslední puzzler. Co čert nechtěl, dnes jsem na podobnou vychytávku narazil v Oracle - takže s chutí do toho!
A nyní se konečně podívejme na problémy se samotnými SQL dotazy. S indexy mohou vznikat v zásadě dva standardní problémy - použití indexu v situaci kdy se použít nemá (false positive) a nepoužití v případě že se použít má (false negative). Pokud nevíte co to indexy jsou nebo tápete v tom jak fungují, přečtěte si o nich něco - například můj článek základní principy fungování a použití indexů v relačních databázích který se právě základům použití indexů v DB věnuje.
První (a prozatím i poslední) SQL puzzler, týkající se tak základních pojmů v relačních databázích jako je primární klíč. Poznámka - tento puzzler je poměrně úzce spjat s PostgreSQL databází (jednak využívá některé PL/pgSQL funkce pro generování dat, ale s PostgreSQL souvisí i jinak).
Možná se to nezdá, ale příčinou mnoha problémů s výkonem SQL dotazů jsou v prvé řadě chybami administrátora. Některé z těchto problémů velmi úzce souvisí s konkrétním databázovým systémem. Způsobů jak špatně nakonfigurovat systém nebo databázi je samozřejmě mnoho - podívejme se alespoň na dva poměrně časté problémy.
