Zbavte se problémů s databází v síti

Když vývojářský tým dokončí databázově orientovanou aplikaci pro zajištění obchodních procesů firmy, může usp...


Když vývojářský tým dokončí databázově orientovanou aplikaci pro zajištění
obchodních procesů firmy, může uspořádat večírek. Avšak síťoví administrátoři
se večírku zúčastnit nemohou, neboť jejich údělem je zajistit bezproblémový
provoz databáze i aplikací ve firemní síti.
Příliš často se stává, že se tým síťových správců vůbec nedostane ke slovu, aby
mohl pomoci při výběru relační databáze, obvykle nedostává od programátorů
přímé odpovědi na své požadavky týkající se síťového přenosu a nedisponuje
odpovídajícími nástroji, s jejichž pomocí by managementu a vývojářům ukázal
dopad nasazení aplikace na síťové zdroje.
Nicméně i přesto je to právě ten tým, který je následně zodpovědný za
spolehlivost, konektivitu a celkovou přístupnost takové aplikace.
Nejpravděpodobnějším problémem, jehož řešení budete vystaveni, je nízký výkon
či rychlost. Chování relační databáze a její výkon závisejí na bezpočtu
faktorů, mezi něž patří serverové a síťové prostředí, parametry pro jeho
vyladění, design aplikace a uživatelské zátížení.
Navíc většina databázových produktů běží na širokém spektru operačních systémů
i typů počítačů. Tyto faktory, jakož i volba platformy, vytvářejí natolik
složitý systém vzájemně se ovlivňujících podmínek pro běh databáze i aplikace,
že práce s nimi vyžaduje široké odborné znalosti. Zvědavi na to, jak jednotlivé
faktory ovlivňují výkon databáze, jsme zkoumali, jak mohou 4 nejpopulárnější
relační databáze Oracle9i, Sybase Adaptive Server Enterprise (ASE) 12.5,
Microsoft SQL Server 2000 a IBM DB2 Universal Database 7.2 (nedávno již byla
zveřejněna verze 8.1) ovlivňovat problémy s provozem v síti. Z pohledu sítě
spadají problémy s výkonem databáze do čtyř obecných kategorií: Databázový
software okupuje CPU serveru, tráví nadměrnou dobu přístupem na disk nebo do
paměti, přetěžuje síťové adaptéry serveru nebo emituje výrazně vyšší síťové
přenosy, než se očekává.

Náležitá konfigurace
Správci sítě si musejí pohlídat, jak administrátor databáze (DBA) nakonfiguruje
databázový software, a to obzvláště při počátečním nasazení nové aplikace. DBA,
který následuje doporučení pro vyladění, která poskytuje každý dodavatel
databáze, může snadno vytvořit databázový server, který zaplaví veškeré síťové
zdroje nebo zahltí server.
Prostřednictvím nastavení či modifikace parametrů, které potlačují množství a
pozmění charakteristiky běhu serverových procesů, dávají všechny 4 uvedené
produkty správci téměř plnou kontrolu nad tím, jakou bude mít relační databáze
maximální spotřebu času CPU, paměti, pevného disku a dokonce i síťových
adaptérů.
Způsob, jakým např. databázový server Oraclu používá parametry nastavené
admninistrátorem, aby bylo vytvořeno a proběhlo více procesů pro příjem a
distribuci SQL požadavků, je dobrým příkladem toho, k čemu může dojít. Software
databázového serveru Oracle spouští jeden nebo více dispatcher modulů, aby mohl
přijímat SQL*Net požadavky od databázových klientů. SQL*Net je komponenta
Oraclu pro klientskou stranu, která přenáší SQL příkazy přes transportní vrstvu
protokolu.
Každý dispatcher modul typicky distribuuje SQL*Net přenosy pro zhruba 10
uživatelů. Jestliže Oracle spustí příliš málo dispatcherů, příchozí zprávy
čekají uvnitř zásobníku protokolu na své zpracování. Na druhou stranu, když je
úroveň provozu při databázových transakcích vysoká a Oracle spustí příliš mnoho
dispatcherů, mohou zahltit paměťové nebo CPU zdroje na serveru.
Programování pro SQL Server zahrnuje stejný objem správy procesů a spouštění
threadů jako u Oraclu. ASE a DB2 jsou poněkud více omezeny co do spotřeby
výpočetní kapacity CPU i paměti databázového serveru, avšak také tyto produkty
mohou vytvářet situace vedoucí k zahlcení CPU a paměti, pokud správce databázi
nesprávně nakonfiguruje.

Monitorovací nástroje
Naštěstí nabízejí Oracle a SQL Server (při své instalaci na Windows NT Serveru
nebo Windows 2000 Serveru) komponenty pro monitorování výkonu k Performance a
System Monitoru pro Microsoft Management Console. Performance a System Monitor
pak mohou poskytovat dostatek detailů o chování databázového serveru.
Jestliže vaše nástroje pro monitoring výkonu indikují, že databázový software
konzumuje příliš mnoho času CPU, není třeba ihned nahrazovat server rychlejším
strojem nebo serverem s více procesory. Nejprve požádejte správce databáze, aby
změnil její konfigurační parametry, a redukoval tak maximální počet threadů pro
zpracování požadavků klientů nebo procesů, které může server spustit.
Následně prošetřete výkon klientů a výsledný nový vztah mezi využitím CPU
serveru, využitím síťových adaptérů a přístupy k disku a paměti. Jestliže se
výkon zlepší, nové parametry konfigurace způsobily redukci zatížení při správě
procesů databázového softwaru na úroveň, kterou funkce pro řízení procesů
zvládá snadněji.
Jestliže naopak nezaznamenáte žádná zlepšení, potom byste měli spolu se
správcem databáze pokračovat ve zkoumání nastavení, abyste zjistili, proč
databázový software příliš zatěžuje CPU.
Rovněž si můžete položit otázku, zda SQL výrazy, které aplikace vysílá, nejsou
komplexnější, než je nezbytně nutné. Všechny čtyři databázové produkty
disponují sofistikovanými SQL kompilátory, které interpretují a pracují podle
SQL příkazů, které obdrží. Avšak převedení složitých textových příkazů (jako je
SQL) do série operací pro vyhledání záznamů a jejich aktualizaci může znamenat
obtížný úkol i pro sebelépe napsaný počítačový program.
Podobně také analýza využití paměti serveru (paging nebo swapping) může pomoci
určit, zda databázový software efektivně využívá paměť, která je k dispozici.
Kvůli lepšímu výkonu udržují všechny čtyři databáze v paměti kopie diskových
dat, která klienti vyhledávají nebo ukládají. Databázový software se totiž může
vyhnout relativně pomalým fyzickým přístupům k datům na disku, jestliže při
zpracování následujícího požadavku na čtení (např. SQL příkazu Select) operační
paměti serveru.
Přidání fyzické paměti do serveru může poměrně dramaticky zvýšit výkon
databáze, ale dokonce i jednoduchý krok provedením úpravy velikosti
stránkovacího souboru (paging file) operačního systému může pomoci. Pro
pochopení, proč tomu tak je, si můžete představit databázový server s obzvláště
velkým souborem stránkování, jako kdybyste měli dvě kopie databáze na disku.
Diskový soubor databáze existuje ve formátu tabulky a záznamů, zatímco soubor
stránkování je reprezentací bajtových adres stejných dat. Jestliže klient
aktualizuje záznam, databázový server musí data zapsat na disk dvakrát, pokaždé
v příslušném formátu.
Jestliže zjistíte, že úzkým hrdlem databázového serveru je využití serverového
disku, nejdříve ve spolupráci se správcem databáze přemístěte databázové
soubory na různé disky, případně využijte i různé diskové řadiče.

Databáze v síti
Příliš zatížený síťový adaptér databázového serveru (na základě grafů
vytvořených vašim nástrojem pro monitoring výkonu) nebo využití síťové
infrastruktury na horší úrovni, než by se dalo očekávat (zjištěné na pomocí
analyzátoru protokolu), může poukazovat na problém v designu aplikace, na
významné úzké hrdlo v síti nebo i jiný typ problému.
Protokol pro přenos SQL k databázovému serveru je v SQL Serveru i ASE označován
jako Tabular Data Stream (TDS), zatímco Oracle využívá tzv. Transparent Network
Substrate (TNS). Většina nástrojů pro analýzu protokolu dekóduje TDS a TNS
pakety, avšak podpora pro transportní protokol SQL používaný v DB2 je poměrně
výjimečnou záležitostí. Nicméně s tím, jak procházíte sbírku zachycených
paketů, zjistíte, že textově založené SQL příkazy pro všechny uvedené
databázové produkty jsou poněkud odlišné (charakteristické). Pakety obsahující
SQL příkazy se tedy liší od zbytku síťové komunikace.
Jestliže klientská strana aplikace vyvolává velký počet záznamů a (na úrovni
klienta) aplikuje filtrování či selekční kritéria pro tyto záznamy, může být
důsledkem velké zatížení sítě. "Silný" klient, který např. sestává z programů
ve Visual Basicu běžících na klientských počítačích, může způsobit významné
zvýšení síťového provozu, jestliže vykonatelné soubory programu putují sítí ke
klientům nebo když tyto programy vydávají SQL požadavky, jejichž výsledkem je
vyvolání většího množství záznamů z obsahu databáze. Příliš pomalé WAN
připojení je pak pro takovou aplikaci hlavním úzkým hrdlem.

Umění i věda
Pouhé zvýšení šířky pásma však nemusí problém příliš vysokého zatížení sítě
vyřešit. Vyladění samotné databázové aplikace spolu s vylepšením programu, díky
němuž dojde k hospodárnějšímu využití síťové kapacity, je často tím nejlepším
směrem, kterým se lze vydat. Spolu se správcem databáze můžete změnit
konfigurační parametry databázového softwaru, avšak tyto změny se pravděpodobně
neprojeví redukcí zatížení sítě tak, jako změny v samotné aplikaci.
Rozumné využití možností monitorování výkonu serveru a nástrojů pro analýzu
protokolu za účelem diagnózy výkonových problémů databáze je stejně tak uměním,
jako vědou. Avšak použitím důmyslných technik a při úzké spolupráci se správcem
databáze i týmem pro vývoj aplikací můžete pomoci proměnit pomalou databázovou
aplikaci v užitečný systém pro vaši firmu, který bude efektivně využívat
možností vašich serverů a síťové infrastruktury.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.