Post on 29-Mar-2023
Bankovní institut vysoká škola Praha
Katedra matematiky, statistiky a informačních technologií
Monitorování databázových serverů Sybase
Diplomová práce
Autor: Jakub Ježek
Informační technologie a management
Vedoucí práce: Ing. Vladimír Beneš
Jakub Ježek Duben 2011
Prohlášení:
Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou
použitou literaturu.
Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její
tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně
BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze
elektronických vysokoškolských prací.
V Čelákovicích, 25. 3. 2011 Jakub Ježek
Za pomoc s touto prací, odborné vedení, trpělivost a hodnotné rady bych chtěl velmi
poděkovat Ing. Vladimíru Benešovi. Dále bych rád poděkoval všem kolegům za hodnotné
podměty a požadavky na monitoring.
Anotace:
Práce popisuje možnost implementace monitorování databázových serverů z portfolia
společnosti Sybase jako je Sybase Adaptive Server Enterprise, Sybase replication
server a Sybase IQ a to tak, jak je implementováno v Commerzbank.
Annotation:
This thesis describes one of possibile implementation of Sybase database servers like
Sybase Adaptive Server Enterprise, Sybase replication server a Sybase IQ as it has
been implemented in Commerzbank.
Obsah:
Úvod 7
1 Portfolio enterprise DB serverů Sybase 8
1.1 Adaptive server Enterprise 8
1.1.1 Architektura ASE serveru 8
1.1.2 Rozšiřující moduly 9
1.2 REP 9
1.2.1 Heterogenní replikace 10
1.2.2 Architektura replikací (WS vs. MSA) 10
1.3 IQ 11
2 Nejčastější problémy v praxi DB administrátora 12
2.1 Alokovaný prostor datového segmentu je zaplněn 12
2.2 Prostor pro transakční žurnál je zaplněn 12
2.3 Problémy se zámky 12
2.3.1 Deadlock 13
2.3.2 Dlouho běžící procesy 13
3 Monitorované veličiny 14
3.1 běžná kontrola stavu DB serveru 14
3.1.1 Kontrola volného místa v databázi 14
3.1.2 Kontrola blokovaných procesů a stavu zámků 15
3.1.3 Kontrola dlouho běžících procesů 16
3.1.4 Kontrola nového obsahu error logu 16
3.1.5 Kontrola konzistence systémových tabulek 16
3.1.6 Kontrola latence 16
3.2 kontrola replikace 17
3.2.1 Kontrola replikačních procesů v databázových serverech 17
3.2.2 Kontrola volného místa ve stable queue 17
3.2.3 Kontrola nového obsahu errorlogu 17
3.3 Každodenní kontrola stavu DB serveru 18
3.3.1 Kontrola záloh databází 18
3.3.2 Získání informací o databázích 18
3.4 Týdenní kontrola stavu 19
3.4.1 Kontrola konzistence databází 19
3.4.2 Kontrola uživatelských práv 19
3.4.3 Automatická údržba systémových databází 19
4 Implementace monitoringu Sybase serverů nad open source projektem Big Brother 20
4.1 Proč BB 20
4.2 Architektura BB v CoBa 21
4.3 Struktura jednotlivých kontrol 25
4.3.1 Sybinfo 26
4.3.2 Env.lib 32
4.3.3 ASE 35
4.3.4 ASED 44
4.3.5 ASEP 49
4.3.6 ASEW 52
4.3.8 IQ 55
4.3.9 IQD 60
Kontrola pokračuje testem na funkčnost spouštěče plánovaných úloh (cron daemon).
Zjišťuje se, zda je v OS běžící démon. 61
4.3.10 ASER 62
4.4 Eskalace problémů 63
4.4.1 Reportování chyby 64
4.4.2 SMS 65
4.4.3 ASM 66
Závěr 68
Seznam použité literatury 69
Přílohy: 71
7
Úvod
Správně fungující databázové servery jsou alfou a omegou úspěšného byznysu. V Bance
toto platí dvojnásob. Ještě mnohonásobněji toto tvrzení platí zejména pro oblast
investičního bankovnictví a obchodování na burzách. Rozdíl jedné vteřiny může být
rozdílem mezi obrovským ziskem a mezi obrovskou ztrátou. Důležité proto je, aby
Commerzbank byla vždy minimálně o tuto vteřinu před svými konkurenty. Tohoto však
nelze bez optimálně fungujících databázových strojů dosáhnout.
Cílem práce je tedy vytvořit sadu skriptů odpovědných za komplexní monitorování stavu
Sybase databázových serverů v Commerzbank. Dále pak tyto skripty naimplementovat
jako další moduly na stávající produkt Big Brother, který slouží k monitorování prostředí
operačního serveru Unix.
8
1 Portfolio enterprise DB serverů Sybase
Sybase software jako jeden z předních výrobců databázového software se vydal – na rozdíl
od např. Oracle – cestou několika specializovaných SŘBD nástrojů. Pro Online transaction
processing (OLTP) je jím Adaptive server Enterprise (zkráceně ASE). Pro systémy
datových skladů a systémy pro podporu rozhodování (DSS) je využíván pak Sybase IQ
server (zkráceně IQ) s technologií vertikálního ukládání dat v indexech.
Významným produktem společnosti Sybase je Sybase Replication server (zkráceně
repserver) pracující v několika režimech. Nejjednodušší režim je tzv. Warm-Standby kdy
repserver na primární straně čte transakce a replikuje je na Standby server.
Dalšími produkty společnosti jsou různé small business edice.
1.1 Adaptive server Enterprise
Adaptive server enterprise je hlavním databázovým serverem z produktového portfolia
Sybase Software určený především na OLTP 1a částečně na DSS
2aplikace. Díky novému a
velmi kvalitním Query optimizeru je výkon v OLTP aplikacích nesrovnatelný s jakýmkoliv
jiným enterprise databázovým serverem.
1.1.1 Architektura ASE serveru
ASE databázový server je SŘBD který ovládá několik systémových databází ve kterých je
uložen například katalog, konfigurace apod. a dále několik uživatelských databází.
Z pohledu hostujícího operačního systému se databázový server ASE tváří jakou soubor
několika procesů (2+počet engines).
Obrázek 1: Schéma ASE.
Zdroj:[I.]; str. 37
1 Online transaction processing. SŘBD je optimalizován pro co nejrychlejší vyřízení transakce.
2 Decission support system. SBD je optimalizován pro aplikace podporující rozhodovací procesy.
9
1.1.2 Rozšiřující moduly
Funkcionalita databázového serveru ASE může být rozšířena pomocí samostatně
licencovaných modulů (licensed options). Pro verzi 15.5 jsou k dispozici následující
moduly:
ASE_JAVA – podpora Javy přímo v databázovém serveru
ASE_HA – High availability. Podporuje rychlou migraci databází mezi
jednotlivými instancemi databázového serveru.
ASE_EFTS – Modul pro fulltextové vyhledávání.
ASE_DIRS – Modul pro podporu autentizace pomocí LDAP.
ASE_ENCRYPTION – Podpora šifrovaného ukládání dat do sloupců tabulek.
ASE_PARTITIONS – Podpora uživatelem definovaných partitions.
1.2 REP
Sybase replikační server je sada programů určených k synchronizaci databází. Během této
synchronizace je replikační server schopen provádět např. konverze datových typů.
Replikace může být v režimu Warm-standby a nebo v režimu Multi-Site availability
(zkráceně MSA). V režimu WS probíhá replikace jak DML 3tak i DD
4L příkazů. MSA
replikace ignoruje DDL příkazy a replikuje pouze DML. Architektura replikačního serveru
Replikační server se skládá ze tří částí. První je Replikační agent (RepAgent, RA), který
čte data z transakčního logu zdrojové databáze a předává je replikačnímu serveru – druhé
části replikačního systému do tzv. Inbound queue5. Replikační server z přečtených
transakcí sestaví SQL příkazy. Dále může provádět konverze datových typů, změny
v datech, část dat zahodit apod. Po skončení tohoto procesu jsou SQL příkazy předávány
pomocí tzv. Outbound queue6 DSI
7 procesu ke spuštění v replikované databázi.
3 DML: Data manipulation language. Soubor příkazů pro manipulaci s daty. Insert;Update; Delete.
4 DDL: Data definition language. Jazyk pro definici objektů. (create, drop, alter) + (table, view, procedure,
triger apod.)
5 Inbound queue: Fronta transakcí přečtených replikačním agentem mířící do replikačního serveru.
6 Outbound queue: Fronta dat mířících z replikačního serveru do cílových SŘBD, či dalšího repserveru.
7 DSI: Data Server Interface. Proces replikačního serveru, který se stará o komunikaci s cílovým
databázovým serverem.
10
1.2.1 Heterogenní replikace
Na rozdíl od jiných SŘBD Sybase replikační server podporuje heterogenní replikace -
replikace mezi produkty třetích stran - pomocí utility Enterprise Connect Data Access
(ECDA). Pokud není primárním databázovým serverem Sybase ASE, je replikační agent
samostatným procesem na úrovni OS. V současnosti jsou podporovány tyto SŘBD:
IBM DB2 Universal Database [Enterprise Edition 8.2.2, 9.1, 9.5]
Oracle Server [9i (9.2.0), 10g (10.1, 10.2), 11g (11.1, 11.2)]
Microsoft SQL Server [2000, 2005, 2008]
Sybase ASE
Sybase IQ data warehouse (pouze jako cílový server).
Obrázek 2: Příklad heterogenní replikace.
Zdroj: [X].
1.2.2 Architektura replikací (WS vs. MSA)
Při warm standby replikaci jsou data přicházející z replikačního agenta uložena do tzv.
Inbound Queue, odkud je vyzvedne replikační server, sestaví z nich SQL text a bez dalšího
zpracování jej předá exekučnímu procesu ke spuštění na Standby straně. Data jsou tedy
replikována jedna ku jedné a to včetně DDL příkazů.
Při MSA replikaci mohou po přečtení dat z Inbound Queue a sestavení SQL příkazu
proběhnout modifikace v datech. Po těchto modifikacích jsou SQL příkazy předány DSI
procesu ke spuštění v replikovaných serverech. Příkladem Heterogenní MSA replikace je
uveden na obrázku 2.
11
1.3 IQ
Sybase IQ server je vlajkovou lodí Sybase software pro datové sklady8. Společně s ASE a
REP patří do rodiny enterprise produktů. Na rozdíl od ASE, nemá IQ server starších verzí
(< 15.0) možnost obsluhovat více uživatelských DB v jedné instanci SŘBD. Od verze 15 je
však tato funkcionalita k dispozici.
8 Datový sklad (data warehouse): Skladiště dat společnosti uložených v elektronické podobě. Jejich hlavní
význam spočívá v podpoře rozhodování. Data warehouse systémy podporují tvorby zpráv, analýzu
uložených dat apod.
12
2 Nejčastější problémy v praxi DB administrátora
Cílem práce databázového administrátora je, aby byl databázový server optimálně
využíván. Toho nelze dosáhnout prostým řešením nastalých problémů. Je třeba, aby
administrátor byl do své práce „vtažen“ a aktivně se zajímal o možná rizika a o co nejlepší
optimalizaci práce databázového serveru. Je tedy třeba problémy nejenom řešit, ale, a to je
nejdůležitější, je třeba jim předcházet. Ve většině případů je databáze alfou a omegou
života společnosti. Během mé praxe jsem se setkal s celou řadou problémů s databázemi.
2.1 Alokovaný prostor datového segmentu je zaplněn
Tato chyba je nejčastěji se vyskytujícím problémem. Vyplývá už z povahy databáze.
Všichni si ukládají do databáze data, ale málokdo si uvědomuje, že databáze nemá
neomezenou kapacitu. Jistě, není problém kapacitu snadno navýšit o desítky až stovky
gigabytů, ale tato skutečnost není nejvhodnějším řešením už jen proto, že:
1. S jídlem roste chuť. Každý si bude do databáze ukládat více a více dat a její
rozšířená kapacita přestane vyhovovat.
2. Nad databází je potřeba provádět pravidelnou údržbu, která s tím, jak databáze
roste, se neúměrně prodlužuje. Toto se dá dočasně vyřešit novým, výkonnějším
hardwarem, ale opět nejde o trvalé řešení.
Jediným trvalým řešením je pravidelná archivace historických záznamů a vymazání
nepotřebných dat z databáze.
2.2 Prostor pro transakční žurnál je zaplněn
Dojde k zastavení transakcí v DB z důvodu nedostatku volného místa pro transakci v
transakčním žurnálu. Tato situace je poměrně častá a tak má v sobě databázový server
připravenou proceduru, která se pokusí tuto situaci vyřešit vykopírováním transakčního
žurnálu do souboru v operačním systému.
2.3 Problémy se zámky
Z důvodu nutnosti zachování nezávislosti transakcí má v sobě SŘBD implementován
systém zámků pomocí kterého zaručuje nezávislost jednotlivých transakcí. Těchto
paměťových struktur je omezení množství.
13
2.3.1 Deadlock
Deadlock je závažná situace kdy na sebe různé procesy navzájem čekají. Z důvodu
požadavku na nezávislost transakcí není možno tyto provést. Existují různé mechanismy a
implementace řešení této situace, ale vždy je to na úkor průchodnosti transakcí
databázovým serverem.
2.3.2 Dlouho běžící procesy
Dlouho běžící procesy či transakce v databázi mohou negativním způsobem ovlivnit
průchodnost. Důvodem je držení zámků na jednotlivých objektech (tabulkách, indexech)
zamezující práci se stejnými daty různým procesům, transakcím či uživatelům. Tento
požadavek vychází z ACID.
Existuje několik možností řešení a většina závisí na optimalizaci zpracování požadavku.
Optimalizací se rozumí (seřazeno se vzrůstající pravděpodobností úspěchu):
1. Úprava SQL příkazu tak, aby pracoval efektivněji. Popravdě v moderních verzích
databázových serverů je absolutně bez úspěchu.
2. Konfigurace databázového serveru, zejména keší, ale i jiných parametrů ke zvýšení
průchodnosti určitých typů transakcí.
3. Aktualizace statistik charakterizujících rozložení dat v jednotlivých sloupcích
jednotlivých tabulek.
4. Úprava databázového schématu, zejména vytvoření nového indexu.
5. Změna isolačního stupně databázového serveru.
6. Použití tzv. relaxed ACID
14
3 Monitorované veličiny
Z výše uvedeného vyplývá, že je třeba dohlížet nad celou řadou veličin. Pokud máme
jenom několik serverů, není toto problémem. Představte si však, že v týmu deseti lidí
spravujete více než 500 instancí databázových strojů. Většina z nich, pak hostuje několik
různých uživatelských databází. V tomto měřítku již není možné pracovat bez jakéhokoliv
nástroje, který rychle a přesně zanalyzuje stav systému a pomůže odhalit budoucí
problémy.
3.1 běžná kontrola stavu DB serveru
Běžná kontrola stavu databázového serveru by měla poskytnout rychlý přehled o stavu
systému. Je třeba pečlivě zvážit, co všechno je třeba kontrolovat takto často, neboť bychom
mohli způsobit zbytečnou zátěž systému. Z praxe se jako nejlepší kombinace pravidelně
monitorovaných veličin hodí následující.
3.1.1 Kontrola volného místa v databázi
Je třeba zkontrolovat, zda je v databázi dostatek volného místa. Výstup by měl být ve
formě přehledné tabulky, ve které se lze rychle orientovat. Výhodou tabulky oproti grafu je
zobrazení přesných hodnot. Dále je vhodné vynášet aktuální měřená data do grafu a tak
rychle a přehledně získat informace o trendu využívání místa alokovaného v databázi.
Obrázek 3: Příklad grafu využití místa alokovaného v databázi.
Zdroj: Monitoring v Commerzbank.
15
Dále je potřeba zkontrolovat obsazení transakčního žurnálu, neboť při jeho zaplnění dojde
k zastavení všech uživatelských procesů v dané databázi. Využívání transakčního žurnálu
je rovněž vhodné kromě uvedení přesné hodnoty zaplnění a rezervovaného místa i zakreslit
do grafu.
Obrázek 4: Příklad grafu zobrazující využití transakčního žurnálu.
Zdroj: Monitoring v Commerzank.
3.1.2 Kontrola blokovaných procesů a stavu zámků
Kvůli zajištění ACID 9je nutné v SŘBD implementovat systém zámků oddělující
jednotlivé uživatele. V ASE jsou implementovány všechny čtyři úrovně izolace dle ANSI.
Dle typu uživatelské transakce rozlišujeme několik typů zámků. Pro standardní uživatelské
transakce rozlišujeme mezi exkluzivními a sdílenými zámky. Sdílené zámky se používají
v případě select DML příkazu a jsou navzájem kompatibilní (více uživatelů může vidět
stejná data v ten samý okamžik). V případě insert/update/delete DML se používá
exkluzivní zámek, který není s ničím kompatibilní (Isolation z ACID). Pokud tedy jeden
z uživatelů drží v rámci transakce nad objektem exkluzivní zámek, všichni ostatní
uživatelé musí čekat, dokud tato transakce není potvrzena, nebo zrušena. Zámky jsou
paměťové struktury a je jich omezený počet. Pokud jsou všechny zámky použity, další
transakce musí čekat, dokud se nějaké zámky neuvolní. To opět snižuje průchodnost
transakcí v databázovém serveru. Toto je hlavní důvod proč monitorovat využité zámky.
9 ACID: Atomicity – Consistency – Isolation – Durability. Hlavní požadavky na SŘBD. Atomicity je
požadavek na transakční zpracování. Změny v datech musí v transakci proběhnout buď všechny anebo
žádné. Consistency je požadavek na konzistentnost dat. Databáze musí být v každém okamžiku
konzistentní (splňovat všechny Constraints). Isolation je požadavek na izolovanost jednotlivých uživatelů.
Není možné vrátit data, která jiný uživatel změnil a ještě je nepotvrdil. Durability je požadavek na trvalost
dat uložených v databázi. SŘBD musí po potvrzení transakce zaručit, že data jsou trvale uložena.
16
Opět je velmi vhodné zobrazit jak aktuální hodnotu použitých zámku, tak jí i vynést do
grafu a sledovat trendy.
3.1.3 Kontrola dlouho běžících procesů
Dlouho běžící procesy jsou potencionální riziko, neboť je velká pravděpodobnost, že
budou držet zámky a zhoršovat průchodnost transakcí databázovým serverem. Další riziko
spočívá v hrozbě tzv. Deadlocku. To je situace, kdy jedna transakce čeká na uvolnění
zámků druhou transakcí a tato zároveň čeká na uvolnění zámků držených první transakcí.
Jediným východiskem z této situace v ASE je zrušení jedné z transakcí.
3.1.4 Kontrola nového obsahu error logu
Chybový log je asi nejdůležitějším místem pro kontrolu. Databázový server do něj zapisuje
všechny informace. Jedná se o chyby, ale i varování, která se nevyplácí ignorovat. Tento
soubor je však příliš velký, než aby se prohledával celý. Tudíž je potřeba navrhnout
kontrolu tak, aby začala prohledávat chybový log od místa, kde předchozí běh skončil.
3.1.5 Kontrola konzistence systémových tabulek
Tato kontrola není jen kontrolou alokace systémových tabulek, ale i logickou kontrolou
hodnot v těchto tabulkách. Jednou se v praxi stalo, že nesprávným výpočtem hodnoty do
systémové tabulky se část místa na disku alokovaného jedné uživatelské databázi
překrývala s druhou uživatelskou databází. Naštěstí při pokusu alokovat místo na disku
SŘBD objevil, že datové struktury jsou již alokované, takže nedošlo ke ztrátě dat, avšak
tato situace byla pro uživatele tak nepříjemná, že vnikl požadavek na kontrolu hodnot
v systémových tabulkách.
3.1.6 Kontrola latence
V replikovaném prostředí je třeba kontrolovat hodnotu tzv. „Latence“, neboli zpoždění
mezi primárním a replikovaným serverem. Hodnota latence se téměř nedá ovlivnit, a tudíž
není třeba ji přesně vypisovat. Mnohem vhodnější je hodnoty vynášet do grafu a sledovat
trendy. Na základě těchto trendů je pak možnost například upravit plánované aktivity do
doby, kdy servery nejsou tak využívány.
17
Obrázek 5: Graf zobrazující hodnoty "latence" pro dvě uživatelské databáze.
Zdroj: Monitoring v Commerzbank.
3.2 kontrola replikace
Tato kontrola se zaměřuje na potencionální problémy s replikací databází. Replikace
funguje na principu přehrávání transakcí zaznamenaných v transakčním žurnálu zdrojové
databáze v databázi, či databázích cílových. Podrobnější informace o replikacích naleznete
v kapitole 1.2.
3.2.1 Kontrola replikačních procesů v databázových serverech
Pro funkční replikace je třeba tří komponent. Replikačního agenta ve zdrojové databázi,
replikačního serveru a DSI exekutoru v každé cílové databázi. Tato kontrola ověřuje, zda
je ve zdrojovém serveru funkční replikační agent a zda je v cílových serverech funkční DSI
exekutor.
3.2.2 Kontrola volného místa ve stable queue
Transakce přijaté replikačním serverem od replikačního agenta je nutno uložit pro následné
zpracování v replikačním serveru. Tímto zpracováním je myšlena například konverze
datových typů, modifikace dat před jejich odkopírováním do cílového serveru apod. Pokud
dojde k zaplnění tohoto bufferu, replikační agent nemůže dále odesílat transakce vykonané
na primární databázi a může dojít až k zaplnění transakčního žurnálu.
3.2.3 Kontrola nového obsahu errorlogu
Samozřejmě jsou všechny chyby, výjimky a zprávy důležité pro administrátory
zaznamenány do chybového výstupu. Tento je tedy zkontrolován a informace o případných
chybách jsou ihned vyreportovány.
18
3.3 Každodenní kontrola stavu DB serveru
Některé veličiny nemá smysl kontrolovat každých pět minut. To buď proto, že jejich dopad
je minimální (změny v konfiguraci, či systémových tabulkách) anebo proto, že se jejich
stav během dne nemění. Typickým příkladem je kontrola záloh databáze.
3.3.1 Kontrola záloh databází
Dle německých právních předpisů a dalších interních předpisů je nutné provádět
pravidelné zálohy databází a to minimálně jedenkrát denně. Spuštění zálohování je běžně
součástí End of day skriptů. BB jen ověřuje, zda záloha proběhla a kdy naposledy.
3.3.2 Získání informací o databázích
Dále byl požadavek na vypsání přehledu o konfiguracích databází. Aby byl výpis
použitelný pro případnou rekonstrukci databáze, jsou shromažďovány následující sestavy:
Database segment map
Sestava Database segment map vychází ze systémových tabulek sysdatabases,
sysusages a sysdevices. Pro každou databázi popisuje následující hodnoty:
o dbid (identifikační číslo databáze)
o segmap (odpovídá master.dbo.sysusages.segmap sloupci)
o segs (popisuje rozložení systémových segmentů na fragmentech)
o device fragment (jméno zařízení na kterém je fragment alokován)
o start (číslo logické stránky, na kterou začíná tento fragment)
o size (velikost fragmentu).
Database information
Sestava poskytující informace o dbid, celkové velikosti alokované každé databázi,
konfiguraci jednotlivých databází a datum a čas vytvoření databáze.
Database allocation map
Tato sestava popisuje pro každé databázové zařízení informaci o jménu zařízení a
databází, které mají na tomto zařízení svůj fragment, začátku fragmentu v rámci
zařízení, o velikosti fragmentu
Device number, default and space usage
Sestava informuje o zařízeních, jejich identifikátorech vdevno, o informaci o
zrcadlení zařízení v rámci databázového serveru, a nakonec informaci o celkové
velikosti, volném a alokovaném místě.
19
Device location
Jednoduchá sestava informující o jménu zařízení v databázovém serveru a o jeho
fyzickém umístění v rámci operačního systému.
Na závěr je vypsána kompletní konfigurace databázového serveru.
3.4 Týdenní kontrola stavu
Každou neděli je naplánováno spouštění DBCC (database consistency checker) za účelem
odhalení alokačních chyb. Toto byl jeden z důvodů pro vytvoření týdenní kontroly. Tato
kontrola je spouštěna každé pondělní ráno.
3.4.1 Kontrola konzistence databází
Plánované spouštění Database consistency checkeru patří nejenom k best practices, ale je
vlastně nutností. Sybase má několik režimů DBCC které se liší typem a předmětem
kontroly. Výstup je vždy psán do specifického souboru a během týdenní kontroly
prohledáván na možné chyby.
3.4.2 Kontrola uživatelských práv
Tento test hledá objekty, které mají nestandartní nastavení práv. Tedy například update-
insert-delete povoleno skupině public apod. Dále kontrola upozorní na uživatelské účty,
které jsou definované, ale již nemají odpovídající účet v žádné databázi apod.
3.4.3 Automatická údržba systémových databází
Během této kontroly dojde ještě ke zkrácení transakčního žurnálu v systémových
databázích.
20
4 Implementace monitoringu Sybase serverů nad open source
projektem Big Brother
Na základě předchozích požadavků a interview s kolegy jsem se rozhodl pro napsání
několika skriptů monitorujících potřebné veličiny.
Monitoring Big Brother začínal jakou open-source software, vyvíjený jeho komunitou.
Následně celý projekt i s jeho komunitou přešel pod společnost Quest Software, která
projekt BB rozdělila na dvě větve. První z nich je určena pro komerční využití a je
licencovaná. K této větvi Quest software nabízí podporu a několik základních modulů.
Druhá větev je oficiálně nepodporovaná. Před zhruba třemi roky Quest software změnil
licenční podmínky pro tuto větev a tato je nadále využitelná pouze pro nekomerční využití.
Systém Big Brother rozlišuje 6 barevných kódů. První tři, zelená, žlutá a červená slouží
k popisu stavu monitorované veličiny. Zelená pak znamená, že je vše v pořádku, žlutá
značí upozornění na potencionální problém a červená, alarm, znamená, že se v systému
objevila kritická chyba. Další barvy, fialová, modrá a průhledná pak označují stav
samotného monitoringu. Nejčastější barvou je fialová, která označuje potencionální
problém s komunikací mezi klientem a serverem. Fialovou je nahrazena jakákoliv z barev
zelená, žlutá červená a to v případě, že monitorovaný systém 30 minut neodeslal žádné
hlášení o stavu. Fialovou barvu pak lze překrýt barvou modrou, která označuje stav údržby.
Poslední „barva“ – průhledná značí, že určená veličina se nemonitoruje.
Obrázek 6: Přehled barevných kódů v monitoringu Big Brother.
Zdroj: Monitoring v Commerzbank
4.1 Proč BB
Jelikož všechny databázové servery pracují pod OS Unix, a vzhledem ke zkušenostem se
psaním skriptů pro shell jsem se rozhodl pro skripty v Kornshellu, který je výchozím
shellem v Commerzbank. Vzhledem k tomu, že v Commerzbank již byl implementován
monitoring Big Brother pro monitorování prostředí operačního systému Unix. Monitoring
Big Brother je modulární systém a tak rozhodnutí padlo na dopsání modulů do tohoto
software.
21
4.2 Architektura BB v CoBa
Big Brother monitoring se skládá ze dvou částí. První z nich – klientská, se skládá ze
spustitelných souborů zodpovědných za:
přenos dat na centrální server,
časovače spouštění skriptů,
ze skriptů zodpovědných za monitoring.
Druhou částí - serverovou - je opět sada spustitelných souborů zodpovědných za:
přijetí dat z klienta,
časovače spuštění centrálních skriptů,
skriptu zodpovědného za generování HTML stránek,
konzole s přehledem aktuálních problémů,
eskalování problémů vniklých mimo standardní pracovní dobu do centrálního
Operačního týmu.
Jak je tedy vidět BB je poměrně jednoduchý nástroj. Doporučený příklad implementace je
znázorněn na obrázku 7.
22
Obrázek 7: Struktura monitoringu BB.
Zdroj: [XIII].
Implementace v Commerzbank je poněkud odlišná. Předně kvůli zjednodušení Je
Notification server a Display server spojen do jedné virtuální Unixové zóny. Dále je
vytvořen vlastní server, neboť business požadavek na eskalování problémů mimo pracovní
dobu zahrnuje i ukládání reportů do databáze a následné odeslání do centrálního
monitoringu – Tivoli. Big brother monitoring v Commerzbank je tedy implementován
podle obrázku 8. Ještě je třeba zmínit, že pro zjednodušení práce s BB monitoringem jsou
v Commerzbank v provozu tři instance, označované jako bbprod, bbprel a bbtest. Jak již
názvy napovídají, jsou to instance pro jednotlivá prostředí. Instance bbprod je zodpovědná
za produkční prostředí, bbprel za testovací prostředí a bbtest je zodpovědný za vývojové
servery.
Klientská část BB funguje následovně. Časovač spouštění skriptů na klientu zavolá skript
k provedení připravených testů. Výsledkem tohoto skriptu je report v textovém formátu,
který může obsahovat HTML značky. Tento text je pak přenesen programem bb přes síť na
server označený jako BB Monitor. Pokud monitorovací skript na klientu objeví chybu,
23
odešle chybové hlášení ještě jednou do BB Monitoru s takovým příznakem, že BB Monitor
ji zapíše do extra souboru, který obsahuje jen chybová hlášení.
Serverová část systému BB je o poznání složitější. Na serveru označeném jako BB monitor
je spuštěn program bbd – big brother daemon, který naslouchá na předem definovaném
portu. V Commerzbank je pro BB vyhrazen port 1984. V momentě kdy bbd detekuje
příjem reportu z monitorovaného klienta, provede bbd operaci fork přičemž nová instance
opět poslouchá na daném portu a stará instance je zodpovědná za uložení reportu do
souboru v adresáři /var/bb/{prod|prel|test}/bbvar/logs. Nezávisle na přijatých reportech
časovač spouštění skriptů spouští dva typy skriptů. První z nich je již dodáván s instalací
systému BB. Tento je zodpovědný za generování html stránek z jednotlivých reportů
z adresáře $BBVAR. Tyto reporty pak ukládá do adresáře
/var/bb/{prod|prel|test}/bb/www. Tento adresář by zároveň měl být DocumentRoot serveru
apache.
Obrázek 8: Schéma implementace BB v Commerzbank
Tivoli View24/7 Operating
DBA PC
Laptop DBA
BB Monitor
ASM Server
Monitorované databázové servery
SMS
DBA
Report
Report
SQL
E-mail to SMS gateway
Tivoli ClientHTTP
HTTP
Zdroj: Vlastní úprava
24
Druhý z hlavních skriptů spouštěných serverem je pak skript zodpovědný za čtení souboru
se souhrnem všech chyb ze všech monitorovaných serverů. Tento skript všechny nově
příchozí chyby reportuje podle konfiguračního souboru. Tímto je možno například:
ignorovat eskalování chyb z určitého serveru,
ignorovat eskalování chyby ze všech serverů, případně skupiny serverů
ignorovat určité chyby v určitém časovém úseku,
odeslat určité chybové hlášení e-mailem, případně pomocí SMS přímo týmu
zodpovědnému za příslušnou aplikaci.
Tento skript se rozhoduje podle aktuálního času a podle aktuálního dne a řeší eskalování
dvojím způsobem, podle následujícího klíče:
1. chyba nastala v pracovní dny mezi 8:30 a 19:30:
V tomto časovém úseku je vždy někdo z příslušného DBA týmu připraven k řešení
nastalých problémů. Chyba je pouze odeslána e-mailem.
2. chyba nastala během dne pracovního klidu, nebo mezi 19:30 a 8:30:
Nikdo z DBA týmu není přítomen „on-site“ a tudíž je třeba hlášení o chybě eskalovat. Toto
se prování jednak odesláním e-mailu na tým DBA a odesláním SMS na mobilní telefony
členů týmu držící pohotovost. Dále je tento skript zodpovědný za vložení informace o
chybě do databázového serveru. Toto se provádí pomocí uložené procedury sp_createalert
s parametry (číslo chyby, název serveru, text chybové hlášky) v ASM databázovém
serveru.
25
4.3 Struktura jednotlivých kontrol
Pro udržení modulárnosti projektu jsem se rozhodl pro rozdělení kontrol do několika
modulů. Jako základ jsem použil skriptů určených pro monitorování Sybase ASE
databázového serveru poskytovaných komunitou systému Big Brother na serveru
dadcat.net. Monitoring pro Sybase servery byl požadován pro produkty Sybase ASE,
Sybase REP a Sybase IQ. Z tohoto vychází i základní členění na tři řady modulů. Protože
moduly používají některé funkce obdobně, rozhodl jsem se pro jednu knihovnu (env.lib)
poskytující tyto společné funkce všem modulům. Další požadavek byl na rozdělení modulů
pro Sybase ASE a Sybase IQ na moduly monitorující běžnou činnost a na moduly
speciální, spouštěné jednou denně, či jednou týdně. Všechny moduly čtou společný
konfigurační soubor (sybinfo), který popisuje prostředí. Toto umožňuje nasadit
monitorování na různých verzích databázových serverů a zachovat funkční monitoring i na
rozdílných prostředích. V současné době BB monitoring pracuje na operačních systémech
Unix ve verzích 6, 8 a 10 a na OS Linux s kernelem řady 2.6. Přestože jsou všechny
databázové servery v Commerzbank provozovány na OS Unix, s integrací systémů
akvírované Dresdner bank vznikl požadavek i na linuxovou verzi systému BB.
Obrázek 9: Přehled komponent.
Zdroj: Interní dokumentace Commerzbank.
26
4.3.1 Sybinfo
Protože soubor sybinfo může obsahovat důležité informace, jako jsou
uživatelské jméno a heslo uživatele databázového serveru použitého při
získávání dat z databázového serveru je velmi doporučeno omezit oprávnění ke
čtení tohoto souboru. Uživatel, který je použit pro připojení do databázového
serveru totiž musí mít udělena zvýšená oprávnění. Následující SQL skript je
použit k vytvoření uživatelského účtu pro BB.
declare @passwd varbinary(128)
/* Password for bbmonitor is same as for sa login*/
select @passwd=password from syslogins where name="sa"
/* No we are going to create the bbmonitor login... */
exec sp_addlogin bbmonitor, 'Secure-11', master, null, 'Big Brother
monitoring [TECH]',0, 0, 0
exec sp_modifylogin bbmonitor, 'authenticate with', 'ASE'
/* Let’s modify the bbmonitor login to suid -666 and update the passwd */
exec sp_configure 'updates', 1
update syslogins set suid=-666 where name="bbmonitor"
print 'Successfully updated suid for bbmonitor to -666.'
update syslogins set password=@passwd where name="bbmonitor"
exec sp_configure 'updates', 0
/* Now we have to grant roles necessary to monitor... */
grant role sa_role to bbmonitor
grant role mon_role to bbmonitor
grant role sybase_ts_role to bbmonitor
exec sp_tempdb bind, 'LG', bbmonitor, 'DB', tempdb_sa
Na každém monitorovaném serveru je konfigurační soubor – sybinfo. V tomto souboru má
každý databázový server hostovaný na serveru svoji sekci. Sekce pro jednotlivé servery
jsou odděleny dlouhým řádkem plným symbolů „#“.
Většina parametrů je nepovinná a uvádí se jenom v případě, že výchozí hodnoty
nevyhovují. V následujícím příkladu souboru sybinfo je vidět, že na serveru jsou
hostovány, dva databázové servery ASE a jeden replikační server. Z názvu druhého
serveru lze hádat, že replikační schéma je Warm - standby. Názvy nepovinných parametrů
jsou vyznačeny kurzívou.
27
name: tredbp01
type: _ASE_
srvparams: 80 80 1 5 95 95 101
excldbs: model
databaselimits: 90 96 50 75
errignore: 31004 31009 31105 31102
databases: TRE_PROD dbccdb master sybsecurity sybsyntax sybsystemdb
sybsystemprocs
dump: TRE_PROD master sybsystemprocs
prim_dbs: TRE_PROD
1000: 5:0-24:0000
31112: 0:4:0000
sybase_dir: /usr/local/sybase
oc_bin_dir: /usr/local/sybase/OCS-15_0/bin
oc_library_dir: /usr/local/sybase/OCS-15_0/lib
os_install_dir: /usr/local/sybase/ASE-15_0/install
os_library_dir: /usr/local/sybase/ASE-15_0/lib
os_bin_dir: /usr/local/sybase/ASE-15_0/bin
latency: 1 1 10 10
sysmon: "00:02:00"
sysmoncheck: disable
perf_cache: 10 95 95 -1 -1 -1 20 90 90 -1 -1 -1
perf_task_w: 80 60 60 60 60 60 60 60 60 60 60 60 60 60 60
perf_task_a: 90 80 80 80 80 80 80 80 80 80 80 80 80 80 80
dbcc: /var/sybase/scripts/logs/dbcc_log
mailto_red: status@commerzbank.com
mailto_yellow: status@commerzbank.com
#########################################################################
name: tredbp01_ws
type: _ASE_
srvparams: 80 80 1 5 95 95 101
excldbs: model
databaselimits: 90 95 50 75
errignore: 31004 31009 31105
31112: 0:4:0000
rep_dbs: TRE_PROD
databases: TRE_PROD tredbp01_rs_RSSD dbccdb master sybsecurity sybsyntax
sybsystemdb sybsystemprocs
dump: TRE_PROD tredbp01_rs_RSSD master sybsystemprocs
1000: 5:0-24:0000
sybase_dir: /usr/local/sybase
28
oc_bin_dir: /usr/local/sybase/OCS-15_0/bin
oc_library_dir: /usr/local/sybase/OCS-15_0/lib
os_install_dir: /usr/local/sybase/ASE-15_0/install
os_library_dir: /usr/local/sybase/ASE-15_0/lib
os_bin_dir: /usr/local/sybase/ASE-15_0/bin
latency: 1 1 10 10
sysmon: "00:02:00"
sysmoncheck: disable
perf_cache: 10 95 95 -1 -1 -1 20 90 90 -1 -1 -1
perf_task_w: 80 60 60 60 60 60 60 60 60 60 60 60 60 60 60
perf_task_a: 90 80 80 80 80 80 80 80 80 80 80 80 80 80 80
dbcc: /var/sybase/scripts/logs/dbcc_log_ws
mailto_red: status@commerzbank.com
mailto_yellow: status@commerzbank.com
#########################################################################
name: tredbp01_rs
type: _REP_
sybase_dir: /usr/local/sybase
oc_bin_dir: /usr/local/sybase/bin
oc_library_dir: /usr/local/sybase/lib
os_install_dir: /usr/local/sybase/REP-15_1/install
os_library_dir: /usr/local/sybase/lib
os_bin_dir: /usr/local/sybase/bin
mailto_red: status@commerzbank.com
mailto_yellow: status@commerzbank.com
#########################################################################
Význam většiny parametrů je zřejmý z jejich názvu, ale některé z nich si dovolím
vysvětlit:
srvparams – základní parametry monitorované každých 5 minut v pořadí:
o počet procent využitých konexí z celkově konfigurovaných,
o procento využitých zámků,
o počet minut, kdy probíhá měření popisující základní výkonnostní parametry
serveru,
o počet minut, po jejichž překročení bude blokovaný proces vyreportován,
o procentní využití CPU; při překročení dojde k vypsání chyby,
o procento vytížení CPU I/O operacemi
o procento nevyužívání CPU = CPU je ve stavu idle.
excldbs – databáze vyřazené z monitorování
29
databaselimits – hranice pro využití místa alokovaného pro databázi v pořadí (čísla
udávána v %):
o Varování pro datový segment,
o Chybové hlášení pro datový segment,
o Varování pro segment transakčního logu,
o Chybové hlášení pro segment transakčního logu.
errignore – jaké chyby se mají ignorovat.
dumps – u jakých databází se kontroluje, zda úspěšně proběhla záloha (kontrola
probíhá jednou denně, ráno).
prim_dbs & rep_dbs – jména primárních a replikovaných databází.
latency – zpoždění replikace v minutách první hodnota pro varování a druhá pro
ohlášení chyby, v případě obousměrné replikace se pak uvádí ještě jednou pro
opačný směr.
*_dir – cesty k důležitým adresářům.
perf_cache – základní ukazatele práce s keší. Sybase ASE server nepřistupuje
k datům přímo ale vždy a pouze prostřednictvím keší. Jejich špatná konfigurace
může mít fatální dopad na výkonnost databázového serveru. Problematika keší je
v ASE databázovém serveru natolik komplikovaná, že případné zájemce odkazuji
částečně na Sybooks online, sekci Adaptive server enterprise 15 a podsekci
Performance and Tuning. Bohužel keším není věnována samostatná část. Další
informace o keších jsou však (ne)dostupné buď z interní dokumentace případně ze
školení Sybase s názvem „Performance and tuning: Configuring ASE“, číslo kurzu
EDB 356. Jednotlivá čísla pak mají následující význam:
o spinlock contention warning – v případě, že dochází k přepínání procesů na
engines databázového serveru z důvodu velkého počtu čekání na tzv.
spinlock zámky dramaticky se snižuje průchodnost serveru. Výchozí
hodnota pro úroveň varování je 10%; Pro úroveň chyby pak 20%. Spinlock
zámky jsou dočasné jednoduché zámky omezující různým procesům práci
s jedním zdrojem. Typicky se problém vyskytuje se zámkem na poslední
stránce transakčního žurnálu.
o cache utilization warning – vypíše varování, případně chybu, pokud je míra
využití keší menší než zadané hodnoty. Výchozí hodnoty jsou pak 95% pro
varování a 90% pro chybu.
30
o cache hits warning – další úroveň monitorování keší. Tento ukazatel svědčí
buď o nedostatečné velikosti keše, případně o její nevhodné konfiguraci.
Vypíše varování, případně chybu, pokud nebyly požadované stránky
nalezeny v keši. V důsledku dochází k přepnutí procesu z engine do tzv.
sleeping queue. Výchozí hodnoty jsou opět 95% pro varování a 90% pro
chybové hlášení.
o Large IO warning – opět poukazuje na efektivitu v konfiguraci keší. Pro
large IO je využívána keš o velikosti 8 datových stránek. Toto číslo souvisí
s interními strukturami ASE databázového serveru. Pokud opět není
dostatečně nakonfigurován příslušný buffer pool, dochází k přepínání
procesů do sleeping queue a k neefektivnostem v práci databázového
serveru. Výchozí hodnoty jsou opět 95% pro varování a 90% pro chybové
hlášení.
o 2-page buffer pool warning – využití stránek základního buffer poolu.
Pokud je v buffer poolu příliš málo použitých stránek, může být server
překonfigurován a zmenšením tohoto buffer poolu je možno buď přidat
jinému buffer poolu, či zmenšit keš a uvolněnou paměť použít jinde.
o 8-page buffer pool warning – obdoba předchozího, ale pro osmistránkový
buffer pool (large IO).
Dále se význam hodnot opakuje, ale pro panic úroveň chyb.
perf_task_w, perf_task_a – Monitoruje důvody přepnutí procesu ze stavu
execution. Jak název napovídá, určují hodnoty pro varování (s koncovkou w) a pro
chybové hlášení (s koncovkou a). Výchozí hodnoty pro varování jsou 30%, pro
chybové hlášení pak 50%. Hodnoty mají následující význam:
o Task context switches due to Voluntary Yealds – normální přepnutí ze dvou
důvodů. Buď proces dokončil svoji práci, nebo mu vypršel přidělený čas.
Logika pro vyhodnocování chyb je v tomto případě obrácená. Varování je
vypsáno, pokud je přepnutí v těchto případech méně než 70 %; chyba je
vypsána při méně než 50% přepnutí.
o Task context switches due to Cache Search Misses – přepnutí z důvodu
nenalezení odpovídající datové stránky v žádné z keší. Datová stránka musí
být přečtena z disku, a protože jsou diskové operace pomalé, proces je
odsunut do sleep queue a jeho místo zaujímá další proces. Vysoké procento
poukazuje na nedostatečnou velikost datové keše.
31
o Task context switches due to System Disk writes – proces je uspán z důvodu
potřeby fyzicky zapsat datovou stránku na disk. Toto je způsobeno při tzv.
Page splittingu, což je rozdělění datové stránky na dvě z důvodu
nedostatečné kapacity na datové stránce na kterou má být záznam zapsán.
Vztahuje se jen na tabulky se zamykacím schématem APL10
a klastrovaným
indexem.
o Task context switches due to I/O Pacing – přepnutí procesu z důvodu
velkého požadavku na I/O operace. Tyto operace jsou řízeny samostatně
pomocí tzv. I/O subsystému a není třeba, aby proces čekající na I/O
zbytečně okupoval engine.
o Task context switches due to Logical Lock Contention – přepnutí procesu
z důvodu požadavku na objekt držený jiným procesem. Objektem může být
datová či indexní stránka, poslední stránka transakčního žurnálu apod.
o Task context switches due to Address Lock Contention – přepnutí z důvodu
uzamčené adresy na indexní stránce. Týká se jedině APL zamykacího
schématu.
o Task context switches due to Latch Contention – přepnutí z důvodu již
uzamčené vnitřní datové struktury databázového serveru (alokační stránky).
Postihuje systémy s APL zamykacím schématem a obřími (desítky až
stovky gigabytů) tabulkami.
o Task context switches due to Log Semaphore Contention – proces byl
přepnut z důvodu obsazené poslední stránky transakčního žurnálu jiným
procesem. Poukazuje na špatný transakční profil aplikace.
o Task context switches due to PLC Lock Contention – přepnutí kvůli
problému s keší transakčního žurnálu. Přiřazený buffer pool (čtyřstránkový)
je pravděpodobně příliš malý.
o Task context switches due to Group Commit Sleeps – proces přepnut, dokud
se keš transakčního žurnálu nezapíše na disk. Nastává v případě, že se
uživatelská keš transakčního žurnálu nestihne přesunout na stránky
transakčního žurnálu.
10 APL – All Page Locking je typ zamykacího schématu, při němž dochází k zamčení všech souvisejících
datových i indexních stránek.
32
o Task context switches due to Last Log Page Writes – přepnutí procesu
během pokusu o zapsání dat na poslední stránku transakčního žurnálu.
o Task context switches due to Modify Conflicts – přepnutí procesu kvůli
konfliktům při pokusu o přístup k systémovým tabulkám zpracovávaným
jiným procesem. V některých případech je totiž vyžadován exkluzivní
zámek i při čtení.
o Task context switches due to I/O Device Contention – přepnutí procesu
z důvodu požadavku na fyzické čtení ze zařízení, pro které již existuje
požadavek na I/O operace od jiného procesu.
o Task context switches due to Network Packet Received – toto přepnutí
může vzniknout za dvou okolností. První z nich je čekání na přijetí dalšího
paketu s požadavkem. Druhá je čekání no další požadavek poté, co
předchozí již byl kompletně odeslán. Pokud naměřené hodnoty převyšují
obvyklé hodnotu, pak je vhodné prověřit síťové rozhraní.
o Task context switches due to Network Packet Sent – přepnutí procesu je
způsobeno čekáním na odeslání result setu přes síť. Pokud je toto číslo
obzvlášť vysoké a result sety obsahují velké množství dat, je nanejvýš
vhodné zvětšit velikost paketů pomocí konfigurační volby „default network
packet size“.
4.3.2 Env.lib
Knihovna základních a univerzálních funkcí, které jsou vyžadovány všemi kontrolami.
Tato je zodpovědná za nastavení standardního prostředí, naplnění systémových
proměnných, za zprostředkování obsahu správné sekce v konfiguračním souboru sybinfo
apod. Každá kontrola nejprve zavolá knihovnu env.lib, která nastaví proměnné a
nadefinuje nejdůležitější funkce a připraví je tím na vlastní zavolání v rámci běhu
pravidelné kontroly. Funkce definované knihovnou env.lib jsou následující:
timeout ()
Tato funkce nastartuje tzv. Watchdog proces a jejím úkolem je ukončit případnou
dlouho běžící kontrolu. V minulosti docházelo k problémům s NFS které vedly
k tomu, že jakékoliv volání systémové procedury nebo utility skončilo čekáním. A
protože se kontroly spouští automaticky každých 5 minut docházelo k hromadění
procesů v systému.
cleanup()
33
Protože mnoho automatických utilit pro údržbu databází píše výstupy do
souborového systému /tmp bylo požadováno, aby se všechny starší soubory
automaticky mazaly.
cleanup2()
Tato funkce je spouštěna na konci každé kontroly. Jejím úkolem je zrekapitulovat
všechny odhalené chyby ve tvaru:
kód_chyby jméno_serveru chybová_hláška link_na_www
a tyto pak odeslat na centrální server. Dále pak budou využity k eskalaci problémů
(viz kapitola 4.4).
initialize()
Funkce initialize ověří nastavení základní proměnné $BBHOME a z adresáře
$BBHOME/etc spustí skripty zodpovědné za nastavení prostředí a proměnných
závislých na prostředí, typu a verzi operačního systému. Dále zkontroluje, zda je
čitelný soubor sybinfo (viz kapitola 4.3.1). Pokud není, tak není další zpracování
možné, kontrola se ukončí a funkce odešle varování e-mailem. Poté nastaví pozadí
stránek s reporty, které se mění dle závažnosti na výchozí, zelenou. Nakonec
následuje inicializace pracovních souborů v adresáři $BBTMP a nastavení
konstant.
initialize2()
Tato funkce inicializuje soubory v adresáři $BBTMP určené pro zapisování
samostatných informací o nalezených chybách.
reporterror()
Funkce odpovědná za korektní vypsání chyby, případně za ignorování chyby,
anebo záměnu chyby za jinou chybu. Automaticky volá funkci set_color a pokouší
se měnit barevné pozadí stránky s reporty podle závažnosti chyb.
set_color(COLOR)
Je fuknce odpovědná za zobrazení správné barvy pozadí reportu. Jediným
parametrem je barva, na kterou se má nastavit pozadí. Funkce zajistí to, aby byly
barvy dle závažnosti měněny jen v pořadí zelená žlutá červená.
get_server_list()
Návratem této funkce je seznam databázových serverů běžících na daném stroji.
Tyto informace jsou přečteny ze souboru sybinfo. Tím je umožněno na jednom
stroji provozovat jak monitorované, tak nemonitorované databázové stroje.
34
Všechny následující funkce této knihovny mají svůj původ v projektu bb-ase vyvíjeného
komunitou kolem serveru deadcat.net. Byly však pro naše potřeby více či méně upraveny.
get_server_attribute(ATRIBUTE_NAME)
Funkce prohledává soubor sybinfo a hledá v sekci určené danému databázovému
server (čte proměnou $SERVER) daný atribut. V případě, že atribut neexistuje,
vrátí prázdnou hodnotu.
exec_sql()
Funkce zajistí spuštění příkazů v jazyce SQL v databázovém serveru. Funkce čte ze
standardního vstupu. Je třeba, aby na prvním řádku přečetla heslo do databázového
serveru. Funkce vyžaduje mít nastavené proměnné $SERVER a $ASE_USER.
get_server_result()
Je podobná funkci exec_sql, ale její použití je mírně odlišné. Je totiž chytřejší a
automaticky se stará o omezení výstupu z databázového serveru. Princip funkčnosti
je ten, že do výstupu této funkce projdou jen a pouze ty řádky, které jsou uvozeny
řetězcem obsaženým v konstantě $ROWSIGN. Na toto je třeba myslet při psaní
SQL a všechny řádky, které chceme zobrazit ve výstupu označit touto konstantou.
check_if_word_in_list(WORD, LIST)
Podpůrná funkce kontrolující, zda slovo je součástí seznamu slov. Pokud je slovo
na seznamu, vrací návratovou hodnotu 0, pokud není, vrací návratovou hodnotu 1.
check_db_exist(DB_NAME)
Návratová hodnota je 1, pokud databáze v databázovém serveru neexistuje; nula,
pokud databáze existuje. K připojení do databázového serveru využívá funkce
get_server_result. Vlastní SQL text je následující:
if not exists (select name from master.dbo.sysdatabases
where name = "$DB_NAME")
select "$ROWSIGN", 1
else
select "$ROWSIGN", 0
go
get_rep_db_list()
Funkce určí, pokud je databáze součástí replikačního systému a to buď jako
primární (zdrojová) anebo jako cílová.
set_sybase_env()
35
Funkce nastavující prostředí pro další práci. Její zodpovědností je nastavit
především systémové proměnné:
o $SYBASE,
o $SYBASE_ASE,
o $SYBASE_OCS,
o $LD_LIBRARY_PATH,
bez kterých není další zpracování možné. Dále se pokusí zjistit ze souboru sybinfo
login, jakým se má přihlásit do databázového serveru. Pokud sybinfo žádný neobsahuje,
použije základní login sa. V souvislosti s novým požadavkem auditu však budeme muset
toto přepracovat, neboť není přípustné, aby monitoring používal výchozí login, který má
být podle doporučení společnosti Sybase z bezpečnostních důvodů uzamčen. Dále nastaví
pro potřeby pozdějších funkcí proměnné:
o $PASSWD
o $SERVERTYP
o $SERVER
get_db_list_all()
Vrátí jména všech databází v rámci databázového serveru, ať už jsou v jakémkoliv
stavu (online, offline, suspect, …).
JulDate( YEAR, MONTH, DAY )
Ze zadaných hodnot vypočítá číslo Juliánského dne.
get_dec_month()
Funkce převádí třípísmennou zkratku označení měsíce na pořadové číslo měsíce.
4.3.3 ASE
Pravidelný test databázového serveru Sybase Adaptive Server Enterprise. Je spouštěný
každých 5 minut pomocí časovaného spouštěče bbrun. Cílem tohoto testu je rychle
zkontrolovat stav a v případě problémů anebo blížících se problémů na tyto upozornit a
zanalyzovat stav. Tento test vyžaduje knihovny env.lib, bb_server_check.lib,
bb_db_check.lib a bb_errorlog_check.lib poskytující funkce s definovanými testy. Test se
spouští sériově pro všechny databázové servery hostované na konkrétním stroji. Nejprve se
nastaví prostředí společné pro všechny servery (zejména proměnná $PATH) a nadefinují
se všechny funkce. Dále se nastaví prostředí specifické pro každou instanci databázového
serveru.
Kontroly definované v rámci testu bb-ase.ksh jsou popsány následujícím schématem.
36
Obrázek 10: Schéma funkcionality bb-ase.ksh.
Zdroj: Monitoring v Commerzbank.
V příloze naleznete schéma volaní jednotlivých funkcí, v testu ASE. Nejprve test začíná
ověřením, zda databázový server běží, zda je možné se k němu připojit a zjistí verzi
databázového serveru. Ověření, že instance běží, se provádí prohledáváním procesů na
úrovni operačního systému. Kontrola možnosti připojení se pak provádí spuštěním
programu isql – nativního řádkového klienta, který se pokusí připojit k serveru. Kontrola
verze je vlastně čtení systémové proměnné @@version konkrétní instance databázového
serveru a očištění této hodnoty od dalších informací vracených v rámci této proměnné.
Pokud jakýkoliv z testů neproběhl, nemá smysl pokračovat dále, systém ohlásí chybu a test
se ukončí.
Pokud je vše v pořádku, tedy v systému je odpovídající proces, do serveru se lze připojit a
číslo verze dává smysl, test pokračuje kontrolou backup serveru. Nejde v podstatě o nic
jiného než zavolání procedury sp_who na backup serveru pomocí RPC a následné ověření
vrácených dat. Pro backup server je při instalaci instance databázového serveru vytvořen
alias s názvem SYB_BACKUP. Celé volání je tedy ve formátu:
exec SYB_BACKUP…sp_who;
Po kontrole funkčnosti backup serveru následuje kontrola nového obsahu errorlogu
aktuálně kontrolované instance. Nekontroluje se celý soubor, ale kontrolu je pouze od
místa, kde skončil předchozí běh. Počet řádků errorlogu je při každém běhu zaznamenán
do souboru v adresáři $BBTMP. Všechny nové řádky v errorlogu jsou vypsány do
monitorovacího výstupu. Dále jsou všechny řádky prohledány a v případě, že obsahují
jakýkoliv z definovaných řetězců, jsou dále analyzovány. Řetězce označující řádky
popisující chyby jsou následující:
37
Error
Warning
Stack
Failure
Segmentation
Msg
Timeslice
Ueshutdown
Sddone
configuration option
U řádků obsahujících tyto řetězce pak dochází k podrobnějšímu zkoumání. Hlídá se
například, kdy přesně chyba vznikla a případně souvislosti mezi chybami. Tím, že
monitoring řeší toto zcela automaticky, ušetří práci databázovým administrátorům a
zároveň je nutí případnou chybu eskalovat přesně dle vnitropodnikových pravidel.
Obrázek 11: Příklad upozornění na chybu 694 a výpis nových řádků v errorlogu.
Zdroj: Monitoring v Commerzbank, úprava autor.
Běh testu pokračuje kontrolou dlouho běžících procesů. Vyhledávají se takové procesy,
které v systému běží déle než čas definovaný v konfiguračním souboru sybinfo (parametr
srvparams). Pro tyto účely se prohledává tabulka master..syslogshold, ve které
jsou uvedeny nejstarší transakce v každé databázi. Tyto informace jsou pak doplněny o
údaje z tabulek master..systransactions, master..syslogins, a
master..sysprocesses. Ve výstupu je však třeba ignorovat záznam určený pro
replikačního agenta.
Kontrola běhu, připojení a verze.
Kontrola funkčnosti backupserveru.
Informace o fyzickém stroji a odkaz na inventory.
Jméno kontrolované instance DBS.
38
Obrázek 12: Příklad hlášení dlouho běžícího procesu.
Zdroj: Monitoring v Commerzbank.
Po zkontrolování dlouho běžících procesů je na řadě kontrola výkonnosti. Během této
kontroly se postupně vyhodnocují tyto veličiny:
počet blokovaných procesů,
počet přihlášených uživatelů,
konfigurovaný maximální počet současných uživatelských sezení,
aktuální počet použitých zámků,
počet uživatelských procesů ve stavu „AWAITING COMMAND“,
počet exkluzivních zámků nad celou tabulkou,
využití CPU uživatelskými procesy,
využití CPU pro I/O,
CPU idle.
V případě, že dojde během kontroly k nalezení blokovaných procesů, určí se čas, po který
jsou blokovány. V případě, že je takto vyhodnocený čas delší, než konfigurovaný
v souboru sybinfo (čtvrtá hodnota v řádku srvparams:), Big Brother spustí analýzu stavu.
Během této analýzy vypíše blokující procesy (tedy ty které momentálně drží zámek, na
který je podán jiný avšak nekompatibilní požadavek). Ke každému blokujícímu procesu je
vypsán i SQL příkaz. Dále vypíše seznam blokovaných procesů. Tedy těch, které požadují
zámky nekompatibilní se zámky již umístěnými. Příklad výpisu blokovaných procesů je na
následujícím obrázku.
Obrázek 13: Ukázka hlášení blokovaných procesů.
Zdroj: Monitoring v Commerzbank.
39
Po kontrole výkonnosti následuje kontrola volného místa alokovaného pro datový segment,
pro segment transakčního logu a pro případné uživatelsky definované segmenty v každé
databázi v rámci instance. Tyto kontroly mají na starosti funkce:
check_database
Úkolem této funkce je předávání informací mezi všemi funkcemi a synchronizace
jejich činností. Dále se stará o celkovou prezentaci dat uživateli.
get_database_sizes
Tato funkce se připojí do instance databázového serveru a ze systémových tabulek
master databáze a pomocí systémových funkcí databázového serveru vrátí pro
každou databázi dva řádky. První řádek je obsazené a volné místo na datových
segmentech System a Default. Druhý řádek pak poskytuje mimo jiné informace o
použitém a volném místě pro segment transakčního žurnálu (logsegment).
check_segments
Obdoba předchozí funkce jenom s tím rozdílem, že počítá informace o volném a
použitém místě pro uživatelsky definované segmenty. K tomuto využívá proceduru
sp_segsize, kterou si v případě potřeby vyrobí.
tempdb_datasegment_usage
tempdb_logsegment_usage
Tyto funkce spolupracují podle následujícího schématu.
Obrázek 14: Schéma spolupráce funkcí zajišťující monitorování kapacity.
check_database
-DB_Name-Seg_id-Seg_name-Size_MB-Free_MB-Percent_Free
get_database_sizes
check_size
-DB_Name-Seg_id-Seg_name-Size_MB-Free_MB-Percent_Free
check_segments
tempdb_datasegment_usage
tempdb_logsegment_usage
Zdroj: Kresba autora.
40
Obrázek 15: Výstup funkcí monitorujících využití alokovaného místa.
Zdroj: Monitoring v Commerzbank.
Následuje kontrola nazývaná check_db. Její běh je řízen stejnojmennou funkcí a jeho
úkoly jsou následující:
zkontrolovat, že server obsahuje všechny databáze, které má obsahovat;
Pro kontrolu se vychází ze seznamu databází v konfiguračním souboru sybinfo.
Prohledává se, zda pro každou položku z řádku databases existuje odpovídající
záznam v tabulce sysdatabases.
41
zkontrolovat, že všechny databáze jsou použitelné;
Kontrola probíhá tak, že se pro každou databázi konfigurovanou v souboru sybinfo
(opět řádek databases) zkouší zjistit počet záznamů v tabulce sysobjects, která
obsahuje právě jednu datovou větu pro každý databázový objekt.
zkontrolovat, zda databáze nějakým způsobem nefiguruje v replikaci.
Pokud je databáze replikovaná, monitoring očekává, že najde tabulku latency se
dvěma sloupci (src, dest) oba jsou datového formátu datetime. Dále se očekává, že
v systému existuje externí skript, který na primární straně každou minutu provede
vložení záznamu (insert into latency(src) values getdate();)
do této tabulky. Replikační systém se pak postará o přenesení transakce do
sekundárního systému. Monitoring pak vypočítá rozdíly mezi maximální hodnotou
z tabulky latency na primární a sekundární straně. Tento rozdíl je pak označen za
zpoždění replikace.
Pro spuštění kontroly zpoždění replikace je nutná konfigurace v souboru sybinfo. V sekci
primárního databázového serveru je nutné, aby jména replikovaných databází byla uvedena
v řádku uvedeném primdbs. Na sekundární straně je pak nutné, aby jména replikovaných
databází byla uvedena v řádku repdbs.
Z těchto kontrol je samozřejmě možné databázi vyřadit tím, že její jméno uvedeme do
konfiguračního souboru sybinfo do řádky excldbs (excluded databases).
Obrázek 16: Graf zobrazující průběh zpoždění replikace.
Zdroj: Monitoring v Commerzbank.
Test následuje hledáním procesů údržby, které během provozu mohou negativně ovlivnit
výkonnost serveru. Prohledává se tabulka sysprocesses na následující procesy údržby:
update statistics
Pro správné rozhodování query optimizeru je nutné, aby tento měl přehled o datech
uložených v jednotlivých databázích. Proto je třeba pravidelně tyto statistiky
42
aktualizovat. V mnoha případech však aktualizace statistik znamená, že se prochází
celá tabulka a hodnoty v jednotlivých sloupcích se pak zaznamenávají do statistiky.
‚Díky’ konceptu I/O operací však tímto dochází k vytlačování datových stránek
z keší a tímto k nárůstu fyzických I/O. Někdy je však nutné aktualizovat statistiky
pro vybrané tabulky i mimo předem stanovené časy. Je to například z toho důvodu,
že v tabulce došlo k velké změně dat a statistiky vlastně popisují jiná data.
Výsledek je pak ten, že se query optimizer nevhodně rozhoduje o postupu
zpracování a neúměrně se prodlužuje čas od zadání požadavku až do vrácení
odpovědi. Zpravidla je pak po předchozí domluvě spuštěna aktualizace statistik na
konkrétní tabulky. Jelikož jsou datové stránky této tabulky zpravidla v datové keši.
Nemá aktualizace těchto statistik významný dopad na výkonnost. Samozřejmě
nemá význam reportovat takovýto proces. Proto je v textu kontroly běžících
aktualizací statistik ignorován takový proces, který má jen velmi omezený počet
fyzických I/O operací.
DBCC (database consistency check)
Kontroly konzistence jsou také náročné na fyzické I/O operace a tudíž není
žádoucí, aby tyto operace údržby probíhaly za provozu.
reorg
Čas od času je třeba data na datových stránkách přeskládat. K tomuto účelu se
používá příkaz reorg. Stejně jako všechny předchozí je i tento velice náročný na
fyzické I/O operace a tím má velký dopad na celkovou výkonnost serveru.
později byla ještě přidána kontrola na procesy ve stavu logsuspend.
logsuspend
Proces ve stavu logsuspend je takový, který potřebuje zapsat data do transakčního
logu, avšak v transakčním logu již není žádné místo. To může být způsobeno tím,
že proces sám zaplnil veškerou kapacitu alokovanou pro transakční log anebo tím,
že téměř celou tuto kapacitu zaplnil jiný proces, který ještě nebyl uživatelem
ukončen buď potvrzením (commit) anebo zrušením (rollback). Tím, že tyto procesy
drží i zámky na objektech tímto znemožní průchodnost serverem i pro příkazy
select, které žádný prostor v transakčním logu nepotřebují.
Poté již následují poměrně jednoduché testy a to především:
test oprávnění na konfiguračním souboru sybinfo
43
Konfigurační soubor sybinfo totiž může obsahovat heslo pro uživatele se
zvýšenými oprávněními. Tento uživatel je použit systémem BB k získání údajů
z databázového serveru.
test počtu konfigurovaných a online exekučních engines
kontrola dočasné databáze (tempdb) přiřazené uživateli sa (system administrator)
Od Sybase ASE verze 12.5.3 existuje možnost mít více uživatelských dočasných
databází. Tyto lze spojovat s různými uživatelskými účty, takže zaplnění jedné
z dočasných databází neovlivní uživatele s jinou uživatelskou databází. Dle
interních standardů musí být výchozí dočasnou databází pro uživatele sa databáze
tempdb.
kontrola logické konzistence dat ve vybraných systémových tabulkách
Dle doporučení Sybase jsme implementovali kontrolu logické konzistence dat nad
tabulkami master..sysdevices, master..sysusages a
master..sysdatabases. Který má pomoci odhalit chyby, pokud došlo
k manuálnímu zásahu do těchto tabulek.
set nocount on
select "_DATAROW_" as "rowsign", u1.*, "32701" as "errno",
convert(varchar(70),"Sysusages: overlaping rows found!") as "msg"
into #inconsistencies from sysusages u1, sysusages u2
where u1.dbid = u2.dbid
and u1.lstart > u2.lstart
and u1.lstart < (u2.lstart + u2.size)
and not exists (select 1 from sysusages u3
where u3.dbid = u1.dbid
and u1.lstart = u3.lstart + u3.size)
insert into #inconsistencies select "_DATAROW_", *, "32702", "Sysusages:
found rows not belonging to any database!"
from sysusages u
where not exists (select 1 from sysdatabases d
where d.dbid = u.dbid)
insert into #inconsistencies select "_DATAROW_", *, "32703", "Sysusages:
gaps in a database's logical page numbering found!"
from sysusages u1
where lstart != 0
and not exists (select 1 from sysusages u2
where u2.dbid = u1.dbid
and u1.lstart = u2.lstart + u2.size)
select rowsign, dbid, case
when segmap=4 then "log"
when segmap=3 then "data"
else "datalog" end,
lstart, size, vstart, unreservedpgs, str_replace(crdate, ' ', '\ '),
vdevno, errno, msg from #inconsistencies
drop table #inconsistencies
44
Po kontrole konzistence těchto systémových tabulek následuje odeslání hotového reportu
na centrální servery, kde se, v případě jakékoliv chyby, dále zpracovává. Jinak je pouze
uložen a na základě http požadavku od klienta prostřednictvím http protokolu zobrazen.
4.3.4 ASED
Ne všechny monitorované veličiny je třeba kontrolovat každých pět minut. Nemá smysl,
neustále zjišťovat, zda se v noci provedla záloha, jak se změnily naplánované úlohy, či
například informovat o změnách konfigurace. Toto byl důvod pro vytvoření kontroly, která
bude spouštěna každý den ráno. Kontrola se jmenuje se ASED – ASE Daily. Jelikož je
objem informací zpracovávaný touto kontrolou mnohem větší, bylo nutné, aby se všechny
kontroly nespustily najednou. Proto je definováno, že se skript spustí ve víceméně
náhodném čase, každé ráno, nejdříve v 6:00, nejpozději však v 8:00.
Kontrola začíná otestováním, zda server běží a zda se k němu lze připojit. Pokud ne, test
končí s chybou, že se nepodařilo připojit k serveru. Pokud je vše v pořádku o celý běh
kontroly se stará funkce check_inventory z knihovny bb_inv_check.lib.
Jako první je spuštěn test na ověření funkčnosti auditování. Test si nejprve přečte
z konfiguračního souboru sybinfo, zda by v databázovém serveru měl auditing běžet. Dále
se z konfiguračního souboru databázového serveru ověří, zda je auditování povoleno.
Nakonec tohoto testu se ověří, zda je v databázovém serveru skutečně aktivní auditovací
proces.
Následuje test na ověření licence databázového serveru. Licenční politiku Sybase lze
označit za poněkud specifickou. Chování databázového serveru ASE, v případě licenčního
problému pak lze označit za ještě specifičtější. Díky tomu je vyžadováno pečlivé sledování
licencí, jejich exspirovaní apod. Informace o licencích je získávána z tabulky monLicense.
To znamená, že pro úspěšný běh tohoto testu je třeba mít v databázovém serveru
konfigurované monitorovací tabulky. Nicméně dle vnitropodnikových standardů jsou
monitorovací tabulky na všech serverech zapnuty a konfigurovány. V případě problému
s licencí je testem (mimo standartních způsobů eskalování problémů) automaticky odeslán
e-mail upozorňující na situaci.
Po kontrole licencí je na řadě kontrola změn dat v systémových tabulkách. V databázi
master se kontrolují tabulky:
syscharsets
sysconfigures
sysdatabases
45
sysdevices
syslanguages
syslisteners
sysloginroles
syslogins
sysservers
syssrvroles
sysusages
systhresholds
syscurconfigs
sysremotelogins
dále test pokračuje systémovými tabulkami ve všech databázích uvedených
v konfiguračním souboru sybinfo na řádku databases. Jedná se o tabulky:
sysaltrernates
sysusers
syssegments
sysattributes
Všechny změny v těchto tabulkách jsou označeny jako varování a odeslány do výstupu
kontroly.
Obrázek 17: Daily check se zobrazením rozdílů v systémových tabulkách.
Zdroj: Monitoring v Commerzbank.
46
Následující test v rámci této kontroly je ověření funkčnosti CRONu. Cron se používá ke
spouštění plánované údržby a pokud by nepracoval správně, hrozí, že nebudou k dispozici
například zálohy apod.
Dále kontrola vypíše způsob, jakým se databázový server startuje. Tedy zda se používá
startovací skript v /etc/init.d (Solaris 8) či zda se používá Solaris Facility management
(Solaris 10).
Po analýze spouštění databázového serveru následuje funkce shromažďující informace o
prostředí operačního systému, na kterém běží databázový server. Ve výpisu se zobrazuje
jméno stroje, jméno a verze operačního systému, uživatelský účet v operačním systému,
pod kterým běží databázový server, systémové proměnné důležité pro běh databázového
serveru a cesty k důležitým souborům jako je errorlog databázového serveru, cesta
k master databázi apod.
Obrázek 18: Daily check zobrazující informace o prostředí operačního systému.
Zdroj: Monitoring v Commerzbank.
Dále kontrola vytiskne informaci o DTM licenci. DTM licence umožňuje Sybase ASE
serveru pracovat v režimu two-phase commit a komunikovat s transakčním manažerem.
Tímto lze synchronizovat transakce mezi různými databázovými servery.
Následuje běh funkce get_server_map. Jejím úkolem je vygenerovat sestavy popisující
databáze tak, aby se daly v případě nemožnosti obnovit server ze záloh vybudovat znovu.
Také se dají použít v případě, že dojde ke ztrátě master databáze a nebude k dispozici její
záloha, či záloha bude nepoužitelná. Generuje se šest následujících sestav:
database segment map
Pro každý fragment všech databází se vypíší následující údaje: jméno a id databáze,
jaké segmenty jsou na daném fragmentu, na jaké pozici na diskovém zařízení
začíná daný fragment a velikost fragmentu.
47
Obrázek 19: Ukázka reportu "Database segment map".
Zdroj: Monitoring v Commerzbank.
database information
Tato sestava vypisuje informace o všech databázích v databázovém serveru. Jedná
se o tyto informace: celková velikost databáze, identifikační číslo databáze, jak je
databáze nakonfigurována a kdy byla vytvořena.
Obrázek 20: Ukázka sestavy "Database information".
Zdroj: Monitoring v Commerzbank.
device allocation map
Sestava vychází z tabulky sysusages a je vlastně mírně upravenou zálohou této
tabulky.
48
Obrázek 21: Sestava "Device allocation map".
Zdroj: Monitoring v Commerzbank.
device number, default & space usage.
Poslední sestavou je vlastně dvojitá sestava. První část je věnována databázovým
zařízením a popisuje informace o všech zařízeních.
Obrázek 22: Sestava "Device number, default & allocation map".
Zdroj: Monitoring v Commerzbank.
Druhá část je pak extrémně obsáhlá a popisuje konfiguraci databázového serveru.
Následuje test kontrolující, zda byly ke všem databázím uvedeným v konfiguračním
souboru sybinfo v řádce dump: provedeny zálohy. Informace o zálohách se čtou z logu
backupserveru náležícího s příslušné instanci databázového serveru. V případě, že záloha
chybí déle než dva dny je vypsána chyba. Jiná chyba je vypsána, pokud záloha nebyla ještě
nikdy vytvořena.
Obrázek 23: Ukázka hlášení chybějících záloh databáze.
Zdroj: Monitoring v Commerzbank.
Po kontrole záloh následuje zkrácení transakčního logu v databázi master a nakonec
následuje test zaměřený na replikaci. Během tohoto testu se kontroluje, zda neexistuje
tabulka, která má vytvořenou replikační definici, ale nemá zapnutý příznak pro
replikování. Tento test by vytvořen z důvodu častého opomínání nutnosti nastavit tento
příznak, což vede k problémům s replikacemi.
49
4.3.5 ASEP
ASEP je akronymem pro ASE performance check. Tedy kontroly výkonnosti ASE
databázového serveru. Enterprise edice databázového server Sybase ASE disponuje
nástrojem sysmon určeným právě k monitorování výkonnosti a průchodnosti databázového
serveru. Nevýhodou nástroje sysmon je jeho dopad na výkonnost systému, která může být
až 10%. To je důvod, proč se ASEP kontrola spouští pouze každých 30 minut. Doba
sbírání informací je stanovena na dvě minuty, ale může být konfigurovaná v souboru
sybinfo v řádku „sysmon:“.
Všechny klíčové funkce jsou uloženy v knihovně bb_server_check.lib. Dále je použito
několik funkcí se sdílené knihovny env.lib. Hlavní funkcí řídící celou kontrolu je funkce
run_sp_sysmon2 z knihovny bb_server_check.lib. Schéma volání jednotlivých funkcí je
opět uvedeno v příloze.
Kontrola začíná pokusem o vytvoření procedury sp_sysmon2. Tato procedura vychází
z procedury sp_sysmon dodávanou společností Sybase spolu s databázovým serverem
ASE. Výstup této procedury je však upraven, aby lépe vyhovoval potřebám dalšího
zpracování výsledků.
Dále je třeba zjistit, zda je v databázovém serveru zapnuto používání monitorovacích
tabulek. Toto je nutné, neboť některé čítače jsou sdílené a jsou po ukončení procedury
sysmon automaticky nulovány. Toto je nutné jen ve verzích Sybase ASE nižších než 15.0.
Pokud je tedy server konfigurován k použití MDA (monitorovacích) tabulek je třeba
spustit sp_sysmon s parametrem ‘noclear’.
Poté následuje vlastní spuštění procedury sysmon na dobu stanovenou v konfiguraci.
Během této doby se nic neděje a běžící proces sysmonu v databázovém serveru sbírá data
k vyhodnocení. Výstup z procedury sysmon je uložen do textového souboru a později
připojen na konec reportu z běhu kontroly.
Po ukončení běhu procedury sp_sysmon následuje spuštění procedury sp_sysmon2.
Výstupy z procedury sp_sysmon2 jsou následně zpracovány funkcí check_sysmon_line.
Funkce check_sysmon_line tedy sériově čte řádky předané procedurou sp_sysmon2 a
zpracovává je.
50
Nejprve je třeba určit typ řádku. Podle něj pak pokračuje v dalším zpracování. Typ řádku
je uveden na druhé pozici v řádku (první je identifikátor datového řádku). Identifikátor
může nabývat následujících hodnot:
TaskContextSwitches,
Popisuje důvody přepnutí procesu v databázovém serveru ze stavu running do stavu
sleeping. Další informace na řádce pak jsou procentuální počty procesů. Důvody
přepnutí již byly popsány v kapitole 4.3.1. Příkladem takového řádku může být
následující:
_DATAROW_ TaskContextSwitches 0.8 0.1 1.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 3.8 2.9
Obrázek 24: Graf "Task context switches".
Zdroj: Monitoring v Commerzbank.
TransactionProfile,
Popisuje transakční profil. Tedy procentuální zastoupení operací insert, update,
update pro DOL tabulky a delete. Příkladem řádku transaction profile je následující:
_DATAROW_ TransactionProfile 99.6 0.1 0.0 0.4
Obrázek 25: Graf "Transaction profile".
Zdroj: Monitoring v Commerzbank.
51
Cache,
Řádek cache reprezentuje hodnoty:
o Jméno cache
o Spinlock contention
o Utilization
o Cache hits
o Lage I/O Performed
o 2 - page pool usage
o 8 - page pool usage
a to jak pro „default data cache“ tak i pro uživatelem definované keše.
Obrázek 26: Graf "Transaction profile".
Zdroj: Monitoring v Commerzbank.
Disk.
Řádek disk, generovaný pro každý disk alokovaný databázovému serveru, obsahuje
pouze dvě hodnoty: První je jméno disku a druhou je pak procentní vytížení disku
I/O operacemi.
Obrázek 27: Graf "Disk I/O".
Zdroj: Monitoring v Commerzbank.
Poté dojde k přípravě grafů popisujících stav systému a nakonec výztupu kontroly je
připojen celý text procedury sp_sysmon.
52
Obrázek 28: Ukázka výstupu z utility Sysmon.
Zdroj: Monitoring v Commerzbank.
4.3.6 ASEW
Na základě požadavků interního auditu jsme byli donuceni vytvořit kontroly určené
k auditování bezpečnosti systému. Jelikož výsledky testů vytvořených dle požadavku
auditorů jsou velmi obsáhlé a jejich zpracování zdlouhavé, došli jsme po diskuzi k modelu
spouštění těchto testů každé pondělní ráno.
Další důvod pro týdenní testy byl, že během neděle a noci na pondělí běží DBCC kontroly.
Výsledky těchto kontrol tak mohou být shrnuty a v pondělí ráno nahlášeny databázovým
administrátorům.
Běh této týdenní kontroly je řízen funkcí check_weekly z knihovny bb_inv_check.lib
Nejprve dojde k vyhledání chyb ve výstupu DBCC (database consistency check).
Z hodnoty řádku „dbcc:“ konfiguračního souboru sybinfo je zjištěno, kde se nalézá soubor
s výstupem dbcc. Dále se zkontroluje, kdy byl soubor vytvořen. Pokud je starší než 5 dnů,
53
je vypsána chyba. Poté test prochází výstup z dbcc řádek po řádku a vyhledává v něm
chyby. Tyto jsou vždy uvozeny klíčovým slovem „Msg“ následovaným číslem chyby.
Dále je pro každou databázi spuštěna uložená procedura sp_auditdb. Následuje spuštění
procedury sp_auditsecurity. Tato se spouští pouze jednou pro celý server. Obě tyto
procedury jsou převzaty od Sybase guru Eda Barlowa. Jejich specifikace převzata z Webu
Eda Barlowa [XIV]:
sp__auditsecurity
DESCRIPTION
Reports Users With Passwords like the Username
Reports Users With Null Passwords
Reports Users With Short (<=4 character) Passwords
Reports Users With Master/Model/Tempdb Database As Default (except sa)
Reports allow updates is set
Reports Users with stupid passwords like "sybase"....
USAGE
sp__auditsecurity [@print_only_errors,] [@srvname, @hostname ] if @print_only_errors
is not null then prints only errors. Otherwise it will print statements about successes
Programs that collect errors can pass the parameters parameters (@srvname &
@hostname) to the procedure. If these are passed, the procedure will print a slightly
different return set that includes error numbers and other information.
ACCESS
This procedure is only runable by sa because it reveals users with weak passwords.
SAMPLE OUTPUT
1> sp__auditsecurity
Security Violations
------------------------------------------------------
(No Users With Null Passwords)
User monitor Has master Database As Default
User mon6 Has master Database As Default
User a Has master Database As Default
Allow Updates is Set
(Allow Updates is Not Set)
(No Trusted Remote Logins)
54
sp__auditdb
DESCRIPTION
Checks Common Database Problems
Lists users in group public if groups are used.
Warn about lack of groups if no groups exist besides public.
List users aliased to another non dbo user.
List aliases without logins (login previously dropped).
List users without logins (login previously dropped).
List objects owned by non-dbo (maybe poor code control?).
Find objects with access to syslogins in them. This
procedure excludes normal objects like sp__addlogin. Use
of this procedure will identify potential Trojan horses.
Find any objects with public access.
If not master db, list any objects starting with "sp_" that
are also in master (Trojan horses).
Database has not had transaction log dump in 24 hours.
Checks Object / Comment mismatch (hand deleted, or rename)
Create object permissions granted to users
USAGE
sp__auditdb [@srvname, @hostname ] External programs that collect errors can pass the
parameters parameters (@srvname & @hostname) to the procedure. If these are passed, the
procedure will print a slightly different return set that includes error numbers and other
information.
ACCESS
This procedure can be only runable by sa because it may reveal information that can help
an intruder..
SAMPLE OUTPUT
1> sp__auditdb
Error
---------------------------------------------
Object get_comn_syslogins has access to syslogins
Object get_comn_sysusers has access to syslogins
Object get_comn_sysusers has access to syslogins
User sa is a member of group public
Group Public access to object pb_catcol type=P
Group Public access to object pb_catedt type=P
Group Public access to object pbcatfmt type=U
Group Public access to object pbcattbl type=U
55
Případné zájemce o kód procedur tedy odkazuji na webové stránky jejich autora; viz[XIV].
Pokud tyto procedury nejsou v DB serveru ještě vytvořeny, tak je BB automaticky vytvoří
a poté ihned spustí.
Nakonec je celý výsledek testu odeslán na centrální server, kde je z něj vytvořena
plnohodnotná webová stránka.
4.3.7 IQ
Kontrola pojmenovaná IQ je základní kontrolou stavu IQ databázového serveru. Je to
obdoba ASE kontroly a provádí se automaticky každých pět minut. Jejím cílem je získat
základní přehled o stavu databázového serveru a tím pomoci předcházet možným
komplikacím a výpadkům služeb. Bohužel je Sybase IQ (dříve Sybase Adaptive Server IQ)
stále ještě „novinkou“ a nemá sjednocené a už vůbec ne uživatelsky přívětivé rozhraní.
Běh celé kontroly je řízen funkcí iq_check z knihovny bb_iq_check.lib. Jako první se
ověřuje, tak jako v případě ASE, zda server běží, a zda je možné se k němu připojit.
K tomuto jsou využívány funkce z knihovny env.lib, které jsou sdílené společně
s kontrolou pro ASE server.
Následuje spuštění procedury sp_iqstatus, která přehledně zobrazí nejdůležitější aktuální
veličiny. Data z výstupu procedury jsou jednak uchována pro další použití v dočasném
souboru /tmp/iqstatus.txt a zároveň parsována. Z výstupu jsou vyhledány následující
veličiny:
Main IQ Blocks Used
Vypovídá o zaplnění místa alokované hlavní databázi.
Temporary IQ Blocks Used
Vypovídá o zaplnění místa alokované dočasné databázi (odkládací prostor).
Main IQ Buffers
Vypovídá o využití bufferů pro I/O operace pro hlavní databázi.
Temporary IQ Buffers
Vypovídá o využití bufferů pro I/O operace pro dočasnou databázi.
Výstup těchto veličin je pak graficky znázorněn. Tím se zároveň uchová historie trendů.
56
Obrázek 29: IQ Space & buffers usage.
Zdroj: Monitoring v Commerzbank.
Other versions
Celkové zaplnění dočasné databáze dalšími verzemi (viz. Další text).
Dále je pak z prostředí operačního systému zjištěna informace o využití CPU procesem IQ
serveru. Následně je opět z IQ serveru zjištěna informace o celkovém počtu navázaných
spojení. Výstup z těchto veličin je pak společně s Other versions graficky znázorněn
v dalším grafu.
Obrázek 30: IQ Version & CPU usage.
Zdroj: Monitoring v Commerzbank.
Poté je spuštěn test na zaplnění jednotlivých dbspaces. Tento test má význam jenom pro
Sybase IQ ve verzi 15.0 a vyšší. Proto nejprve dojde ke zjištění verze, a pokud je
nevyhovující, test se ukončí. Následuje čtení některých sloupců z procedury sp_iqdbspace
a jejich interpretace do uživatelsky přívětivého formátu. Zároveň jsou informace
zapracovány do grafu.
Obrázek 31: DB Space usage.
Zdroj: Monitoring v Commerzbank.
57
Následuje test odhalující dlouho běžící a spící procesy (v Sybase IQ se procesy označují
jako ConnectionHandlery). Monitorování dlouho spících procesů nedává smysl a bylo
implementováno na základě požadavků týmu podporujícího aplikace využívající naše IQ
servery. Test probíhá ve dvou fázích, mezi kterými je desetivteřinová přestávka, aby došlo
ke změně některé čítačů. Před i po této přestávce dojde k uložení informací o procesech do
dočasných tabulek pomocí:
select datediff(mi, txn.TxnCreateTime, getdate()) as TxnRunTime,
con.ConnHandle as ConnHandle,
con.UserID as UserID,
con.ReqType as ReqType,
txn.TxnID as TxnID,
con.iqtosa_count as iqtosa_count,
con.satoiq_count as satoiq_count
into #bb_longrunning1
from sp_iqconnection() con,
sp_iqtransaction() txn,
sp_iqcontext() ctx
where con.TxnID = txn.TxnID and
con.ConnHandle = ctx.ConnHandle and
txn.state = 'ACTIVE' and
con.LowestIQCursorState <> 'END_OF_DATA' and
( ctx.CmdLine not like 'backup database%' and ctx.CmdLine <> 'NO
COMMAND')
and ctx.ConnOrCursor="CONNECTION"
select datediff(mi, con.LastReqTime, getdate()) as ConnRunTime,
con.ConnHandle as ConnHandle,
con.UserID as UserID,
con.ReqType as ReqType,
con.iqtosa_count as iqtosa_count,
con.satoiq_count as satoiq_count
into #bb_longsleeping1
from sp_iqconnection() noc
58
Následně jsou tyto porovnány a jsou vypsány výsledky jako pro long running:
select '$ROWSIGN' as "",
bbl2.TxnRunTime,
bbl2.ConnHandle,
substring(bbl2.UserID,1,10) as "UserID",
substring(bbl2.ReqType,1,10) as "TxnTYPE",
"RUNNING"
from #bb_longrunning1 bbl1,
#bb_longrunning2 bbl2
where bbl1.ConnHandle = bbl2.ConnHandle and
bbl1.TxnID = bbl2.TxnID and
(
bbl1.iqtosa_count != bbl2.iqtosa_count
or
bbl1.satoiq_count != bbl2.satoiq_count
)
and bbl2.TxnRunTime >= $YELLOW_PROCRUN
Tak i pro long sleeping procesy:
select '$ROWSIGN' as "",
bbs2.ConnRunTime,
bbs2.ConnHandle,
substring(bbs2.UserID,1,10) as "UserID",
substring(bbs2.ReqType,1,10) as "TxnTYPE",
"SLEEPING"
from #bb_longsleeping1 bbs1,
#bb_longsleeping2 bbs2
where
bbs1.iqtosa_count = bbs2.iqtosa_count
and
bbs1.satoiq_count = bbs2.satoiq_count
and
bbs2.ConnRunTime >= $YELLOW_PROCSLEEP
Jediný rozdíl mezi long running a long sleeping procesy je tedy v porovnání čítačů
iqtosa_count a satoiq_count. Pokud se tyto liší, je proces aktivní.
Následuje vypsání informací o využití verzí pro jednotlivé procesy. Na rozdíl od ASE
Sybase IQ nepoužívá zámků pro zaručení nezávislosti (ve smyslu ACID), ale pro procesy
vytváří tzv. Verze. Tato verze je pak pevně svázána s každým procesem a teprve po
potvrzení (commit) je tato uvolněna proces začíná pracovat s aktuální verzí databáze.
Pokud se uživatel připojí, spustí transakci A, ale nepotvrdí ji, další transakce mohou
systém modifikovat, ale stav databáze musí pro transakci A zůstat zachován. To znamená,
že ačkoliv se data v databázi mění, před změnou je původní stav uchován ve verzi spojené
s transakcí A. Pokud však uživatel odejde domů, aniž by svoji transakci potvrdil, může
dojít k zaplnění temporary dbspace a k zastavení práce serveru. Zjištění celkové velikosti
verze je poměrně jednoduché:
select top 3 '$ROWSIGN' as "", IQConnID, MaxKBRelease
from sp_iqversionuse()
where MaxKBRelease > 1000000 order by MaxKBRelease desc
go
59
Obrázek 32: Výpis velikostí verzí pro různé procesy.
Zdroj: Monitoring v Commerzbank.
Dále je vypsán počet Connection Handlerů pro jednotlivé uživatele. Tím je možno
detekovat chyby v aplikaci. Některé aplikace totiž zapomínají uzavírat své spojení s IQ
serverem a stejně jako v ASE je při využití všech konfigurovaných Connectioin handlerů
nemožné se k databázovému serveru připojit. Kód je opět velice jednoduchý:
select convert(varchar(30),Userid), count=count(*)
from sp_iqconnection()
group by Userid order by count desc
go
Obrázek 33: Informace o počtech připojení navázaných uživateli.
Zdroj: Monitoring v Commerzbank.
Následuje ověření databázových událostí (events). Sybase IQ umožňuje uživatelům
definovat reakce na události. Sybase IQ pak provede uživatelem definovanou reakci na
nějakou událost. V naší impelementaci využívám pouze událost DatabaseStartReport
definovanou následujícím způsobem:
create event DatabaseStartReport
type DatabaseStart
handler
begin
declare @msg varchar(100);
select @msg= @@servername+": Database "+db_name()+" started at
"+convert(varchar, getdate())+".";
insert into IQ_events_iface values('DatabaseStart', 32540, @msg);
commit
end
go
60
Nejdříve je však třeba vytvořit tabulku IQ_events_iface, pokud již neexistuje.
declare @rwcnt int
select @rwcnt= count(*) from sysobjects where name="IQ_events_iface"
if @rwcnt = 0
create table IQ_events_iface ( type varchar(20), errcde int, msg
varchar(100))
commit
go
Výběr dat z tabulky IQ_events_iface je uskutečněn prostřednictvím funkce
get_check_new_events. Data jsou následně zpracována funkcí check_new_events.
Nakonec je tabulka IQ_events_iface zkrácena.
Pokud je na serveru více instancí Sybase IQ serveru, pokračuje se následující instancí
přesně podle souboru sybinfo.
Pro kontrolu IQ je třeba sybinfo rozšířit o následující konfigurační řádky.
Longsleepers – počet minut pro varování a alarm pro dlouho neaktivní procesy.
Max_backup_age – počet dnů platnosti zálohy databáze (využíváno v IQD).
DBCC – cesta k souboru obsahujícímu výstup z DBCC (využíváno v IQD).
4.3.8 IQD
Denní kontrola pro IQ server je obdobou ased kontroly. Začíná zobrazením informací o
prostředí operačního systému, hostující Sybase IQ databázový server. Zobrazují se
informace o jménu hostujícího stroje a o verzi operačního systému. Dále je zobrazena
informace o systémových souborech IQ serveru a jejich umístění. Nakonec se zobrazí
informace o způsobu startování a o parametrech, s jakými byl server nastartován.
Obrázek 34: Výpis Unix information.
Zdroj: Monitoring v Commerzbank.
61
Následuje test záloh hlavní databáze. Dle interních standardů je jediným přípustným
způsobem zálohování full backup. Inkrementální zálohy nejsou považovány za bezpečné.
Pro zjištění, kdy proběhl poslední full backup je použit následující kód:
begin tran
go
begin
declare local temporary table iq_status_temp (
Name varchar(40) null,
Value varchar(128) null
) in SYSTEM on commit preserve rows;
execute immediate with quotes
'iq utilities main into iq_status_temp status';
select case when char_length(value) = 0
then datediff(dd, "2009-01-01 00:00:01", getdate())
else datediff(dd, Value, getdate())
end
from iq_status_temp where Name like "%Full Backup Time%"
end
go
rollback
go
Kontrola pokračuje testem na funkčnost spouštěče plánovaných úloh (cron daemon).
Zjišťuje se, zda je v OS běžící démon.
Následuje kontrola výstupu z DBCC. Tento je pravidelně spouštěn právě pomocí Cron
démona a výstup je zapisován do souboru. Ze souboru se nejprve zjistí celkový výsledek
DBCC. Pokud odpovídá „DBCC Status: No Errors Detected.“ Je vše v pořádku a test je
ukončen. Pokud však DBCC obsahuje chyby, jsou tyto následně vyhledány a vypsány.
Nakonec je vypsán seznam uživatelů s uzamčeným uživatelským účtem pomocí kódu:
declare @version int
select
@version=convert(int,substring(@@version,charindex('/',@@version)+1,2))
if ( @version >= 15 )
begin
select user_id, convert(varchar(20),user_name),
convert(varchar(40),reason_locked) from sa_get_user_status() where
reason_locked like "locked%"
end
else
begin
select convert(varchar(20), Locked_Users) from sp_iqlistlockedusers()
end
go
Obrázek 35: Informace o uzamčených uživatelských účtech.
Zdroj: Monitoring v Commerzbank.
62
Pokud je v serveru další instance IQ databázového serveru pokračuje se touto instancí.
Jinak kontrola končí a výsledek je odeslán na centrální server ke zpracování.
4.3.9 ASER
Aser je kontrola zaměřená na zjištění stavu replikačního serveru. Celý běh je řízen funkcí
rep_check z knihovny bb_rep_check.lib. Celý běh funkce se opakuje tolikrát, kolik je
definováno serverů v souboru sybinfo.
Kontrola začíná testem ověřujícím možnost připojení k replikačnímu serveru. Test se tedy
pokusí připojit k serveru a zjistí, zda je některý z procesů zodpovědných za replikaci ve
stavu „down“. V případě smysluplné odpovědi kontrola pokračuje a vypíše seznam
procesů ve stavu „down“. Pokud test nedostane žádnou odpověď, kontrola končí s chybou
„Could not get valid response from Repserver…“.
Kontrola pokračuje načtením informací o replikačním serveru z jeho procesu v operačním
systému. Z příkazu procesu je zjištěno jméno a umístění konfiguračního souboru
replikačního serveru. Z něj jsou pak nadále načteny hodnoty následujících proměnných:
$REPSERVER – jméno replikačního serveru
$SERVER – jméno databázového serveru obsahující RSSD databázi příslušného
replikačního serveru.
$DBNAME – jméno RSSD databáze.
$ASE_USER – jméno uživatele pro připojení k RSSD databázi.
$PASSWORD – heslo uživatele pro připojení k RSSD databázi.
V případě serverů v Commerzbank je situace jednoduchá, neboť konfigurační soubor
obsahuje heslo pro připojení k RSSD databázi v čitelné podobě. Na systémech Dresdner
Bank se bohužel používá kryptované heslo. Pokud tedy jde o replikační server Dresdner
Bank je nutné pro připojení k serveru obsluhujícím RSSD databázi použít uživatelský účet
z konfiguračního souboru sybinfo ze sekce příslušného serveru.
63
Následuje test na zaplnění stable queue (viz. 3.2.2). Informace o stable queue jsou zjištěny
z RSSD databáze z tabulky rs_diskpartitions následujícím kódem:
declare @version int
select @version = v.version from rs_version v, rs_sites s where
s.id=v.siteid and s.name="$REPSERVER"
if ( @version >= 1500 )
begin
exec('
select "$ROWSIGN", sum(a.used_segs)/(sum(a.num_segs)/100) as
pct_used
from
(
select count(*) as "used_segs", num_segs
from rs_segments, rs_diskpartitions
where used_flag=1 and rs_segments.partition_id =*
rs_diskpartitions.id
group by partition_id,logical_name
) a
')
end
else
begin
exec('
select "$ROWSIGN", convert(int,100*sum(convert(float,
sum(allocated_segs)))/
sum(convert(float,sum(num_segs)))) from rs_diskpartitions
')
end
go
Takto získané hodnoty jsou také zaznamenány do grafu.
Obrázek 36: Využití stable queue.
Zdroj: Monitoring v Commerzbank.
4.4 Eskalace problémů
V této kapitole bych se rád věnoval situaci, která nastane v případě, že systém detekuje
chybu. Databázoví administrátoři v Commerzbank mají nepřetržitou službu a jsou tak
schopni pružně reagovat na nastalou situaci. Pracovní den je členěn na dva
dvanáctihodinové cykly. Denní cyklus začíná v 8:00 a končí ve 20:00. Tento cyklus je
pokryt dvěma týmy po dvou členech. Každý tým je pak odpovědný za monitorování stavu
serverů pomocí BB konzole a za reakci na vzniklé problémy. Každý z týmů je tvořen
64
dvěma databázovými administrátory. Jejich kódová jména jsou E1 a E2 pro ranní směnu a
L1 a L2 pro odpolední směnu. Všichni pracovníci v těchto rolích jsou tzv. „on-site“. S
koncem odpolední směny předávají povinnosti reakce (však již ne monitorování) jednomu
z členů „On-call“ týmu (primary on-call DBA). Další dva členové on-call týmu jsou
k dispozici jako záloha a pro případ nutnosti reagovat na více chyb najednou. S Akvizicí
Dresdnerbank DBA tým získal dva členy v Singapuru, kteří přebírají povinnosti
primárního on-call člena zhruba ve 3:30 našeho času. Během víkendu a dnů pracovního
klidu je stanoven on-call tým, který má obvyklé povinnosti.
Tím došlo k vymezení dvou způsobů práce s monitoringem. První je během pracovního
dne mezi 8:00 a 20:00. Během této doby eskalování probíhá jednak do konzole BB a
jednak odesláním e-mailu DBA týmu.
Druhé období (se zvýšenou potřebou eskalování) začíná v pátek ve 20:00 a končí pondělím
8:00; dále pak každou noc pracovního dne od 20:00 do 8:00 následujícího dne. Během
tohoto období jsou všechny chyby eskalovány jako obvykle. Navíc je však odeslána SMS
na mobilní čísla všech On-Call databázových administrátorů. Dále je prostřednictvím ASM
služby chyba předána do Tivoli monitoringu, se kterým pracuje 1st level support.
4.4.1 Reportování chyby
Pokud jakýkoliv test chce ohlásit chybu, volá funkci reporterror() z knihovny env.lib. Tato
funkce se jednak postará o nastavení správného barevného kódu a jednak si informaci o
chybě zapíše do dočasného souboru v adresáři $BBTMP. Při odesílání dat na centrální
server dojde zároveň k odeslání seznamu detekovaných chyb. Na centrálním serveru pak
běží program, který informace z tohoto souboru (ase.err) zpracovává.
Obrázek 37: Výpis ze souboru ase.err.
Zdroj: Monitoring v Commerzbank.
Formát chybového hlášení je kód chyby:jméno serveru:jméno instance:Text chyby a URL
na webovou stránku. Program zpracovávající jednotlivé chyby pak tyto řádky parsuje a na
základě aktuálního času a dne se rozhodne, zda bude chybu eskalovat i prostřednictvím
SMS a do Tivoli. Eskalování do Tivoli probíhá pomocí nástroje ASM.
65
4.4.2 BB Konzole
Každá z instancí BB je rozšířena o konzoli. Tato konzole zobrazuje všechny události, které
byly vyreportovány monitorovacími skripty na všech monitorovaných strojích. Událost je
vždy zaznamenána, pokud dojde ke změně barevného stupně chyby a to jakýmkoliv
směrem.
Po přijetí jakéhokoliv chybového hlášení je toto zobrazeno v konzoli ve stavu current.
V případě, že problém zmizí je jeho stav automaticky upraven na open. Databázový
administrátor má ještě možnost změnit stav z current na ack. Tento stav znamená, že se
právě pracuje na odstranění chyby. Při této změně stavu je vyžadován od uživatele popis
situace, který si ostatní uživatelé mohou následně zobrazit pomocí žluté ikony. Posledním
definovaným stavem je stav closed, na který se však musí všechny záznamy přepnout
ručně. Tím je zabráněno případnému přehlédnutí chyby.
Obrázek 38: Konzole BB monitoringu.
Zdroj: Monitoring v Commerzbank.
66
4.4.3 SMS
V případě, že chyba byla vyreportována v období „pracovního klidu“ je nutné odeslat
informaci o chybách prostřednictvím SMS členům on-call týmu. Střídání on-call týmů je
pravidelně každý pátek. Povinností všech členů v týmu je zapnout si přijímání SMS ve
webovém nástroji BB SMS Routing tool.
Obrázek 39: BB SMS Routing.
Zdroj: Monitoring v Commerzbank.
Dále je možné vynutit si rozšířené eskalování i během pracovních dnů. Toto je vhodné
například pro státní svátky apod.
4.4.4 ASM
ASM je zkratka pro Advanced Sybase Monitoring. Toto je nástroj odpovědný za
eskalování všech problémů prostřednictvím Tivoli do 1st level support týmu (operating).
Tento nástroj se skládá z databázového serveru, sady ASM skriptů a klienta systému
Tivoli. V případě zpracování chyby ze souboru ase.err a rozhodnutí o nutnosti rozšířeného
eskalování je v databázovém serveru sybmonp1 v databázi asm_server spuštěna uložená
procedura sp_createalert s parametry jméno databázového serveru, jméno stroje, text
chyby. Tato procedura následně uloží tyto informace do tabulek defSERVER,
67
defDATABASE a monEXCEPTION ze kterých je pak vybírá skript a přepisuje do souboru
TIVOLI.log, který je monitorován Tivoli klientem a všechny nové chyby jsou předávány
na 1st level support. Celé schéma je znázorněno na obrázku 7. Modul ASM a vůbec celý
systém rozšířeného eskalování je implementován pouze pro produkční prostředí.
68
Závěr
Cílem práce bylo teoreticky popsat možnosti monitorování databázových serverů a
následně toto implementovat zvýšit jednak dostupnost služeb poskytovaných týmem
Sybase support v rámci Commerzbank a dále zlepšit komfort práce databázových
administrátorů. Tím došlo k výraznému omezení stresu a jím způsobených chyb v jejich
práci. Dále se podařilo do práce databázových administrátorů zapojit i týmy podpory
aplikací, kteří již zmateně nevolají: „Něco je špatně“…
69
Seznam použité literatury
I. Sybase, Inc. System and Database Administration: Adaptive Server Enterprise :
Volume 1. Version 1.0. Dublin, CA, USA : Vl.n., 2002. 606 s.
II. Sybase, Inc. System and Database Administration: Adaptive Server Enterprise :
Volume 2. Version 1.0. Dublin, CA, USA : Vl.n., 2002. 532 s.
III. VERSCHOOR, Rob. The Complete Sybase ASE Quick Reference Guide : ASE
versions 12.5, 15.0.3 & Cluster Edition 5th
edition. Den Haag, The Netherlands :
Sypron B.V., 2009. 151 s. ISBN 90-806117-1-9.
IV. VERSCHOOR, Rob. TheComplete Sybase Replication Server Quick Reference
Guide : Versions 12.0, 12.1, 12.5 & 12.6. First edition. Den Haag, The
Netherlands : Sypron B.V., 2004. 120 s. ISBN 90-806117-3-5.
V. VERSCHOOR, Rob. Tips, Tricks & Recipes for Sybase ASE. 2nd edition (updated
for ASE 15.0). Den Haag, The Netherlands : Sypron B.V., 2006. 500 s. ISBN 90-
806117-2-7.
VI. MICHAEL, Randal K. Matering UNIX Shell Scripting. second edition.
Indianapolis, IN, USA : Wiley Publishing, Inc., 2008. 1002 s. ISBN 978-0-470-
18301-4.
VII. Sybase, Inc. Sybase Adaptive Server Enterprise : System Tables Diagram. Dublin,
CA, USA : [s.n.], 2007. 1. MLG part number DC70204-01-1500-02.
VIII. Sybase, Inc. Sybase Adaptive Replication Server : System Tables Diagram. Dublin,
CA, USA : [s.n.], 2000. 1. MLG part number DC70003-01-1206-02.
IX. Sybase, Inc. Sybase Adaptive Server Enterprise : Monitoring Tables Diagram.
Dublin, CA, USA : [s.n.], 2008. 1. MLG part number DC70002-01-1502-01.
X. WIEBENER, JR., Robert H. Synchronizing Data Among Heterogeneous
Databases. Technical white paper [online]. 2010, no. 1, [cit. 2011-01-08].
Dostupný z WWW: <http://www.sybase.com/files/White_Papers/RepServer-Sync-
Heterogeneous-DB-WP.pdf>.
XI. SyBooks online [online]. c2000-2011 [cit. 2011-01-08]. Dostupné z WWW:
<http://infocenter.sybase.com/help/index.jsp>.
XII. Deadcat.net.au : The Big Brother FTP Archive [online]. c1998 - 2011 [cit. 2011-
01-08]. Dostupné z WWW: <http://www.deadcat.net/>.
70
XIII. Network Monitoring Software - Big Brother [online]. 2010 [cit. 2011-01-16].
System and Network Monitoring Software, Products, Big Brother. Dostupné z
WWW: <http://bb4.com/network-architecture-summary.asp>.
XIV. BARLOW, Ed. Ed Barlows Sybase shareware [online]. c1994-2000 [cit. 2011-04-
17]. Stored procedure Library. Dostupné z WWW:
<http://www.edbarlow.com/document/procs/readme.htm>.
71
Přílohy:
Adresářová struktura BB s důležitými soubory.
/var/bb/prod/ (obdobně i pro prel a test)
bb/ (hlavní adresář BB = $BBHOME)
etc/ (adresář s konfiguračními soubory)
bb-hosts (definuje monitorované klienty a jejich umístění)
bb-bbexttab
bb-exttab (definuje jaké moduly jsou na klientu spouštěny)
ext/ (adresář obsahující monitorující moduly)
bb-ase.ksh
bb-ased.ksh
bb-asew.ksh
bb-asep.ksh
bb-aser.ksh
bb-iq.ksh
bb-iqd.ksh
bin/
bb (přenáší report na server)
bbd (network listenner)
bbrun (časovač spouštění monitorovacích skriptů)
web/
mkbb.sh (z reportů generuje www stránky)
www/ (adresář s html stránkami s reporty = apache.DocumentRoot)
bbvar/ (přijaté reporty od klientů)
logs/ (aktuální)
histlogs/ (historické = při změně barvy)
hist/ (historie chyb)
console/ (adresář pro konzoli)
events/ (obsahuje všechny aktuální chybové hlášky)
users/
teams/
hosts/
tmp/
72
bb_server_check.lib:server_check
bb_server_check.lib:get_parameters
env.lib:get_server_attribute
bb_server_cehck.lib:get_parameters_string env.lib:get_server_result
bb_server_check.lib:check_ase_version bb_server_check.lib:get_check_ase_version env.lib:get_server_result
env.lib:reporterror
env.lib:get_server_result
env.lib:set_color
bb_server_check.lib:check_serverrunning
bb_server_check.lib:check_connectable
bb_server_check.lib:check_backupserver
bb_errorlog_check.lib:check_errorlog
bb_server_check.lib:check_longrunner
bb_server_check.lib:check_performance
env.lib:reporterror
bb_server_check.lib:get_check_connectable env.lib:get_server_result
bb_server_check.lib:get_check_backupserver env.lib:get_server_result
bb_errorlog_check.lib:get_errorlog_log
env.lib:get_server_attribute
bb_errorlog_check.lib:check_errorline bb_errorlog_check.lib:send_errorlog_exception env.lib:reporterror
bb_server_check.lib:get_check_longrunner
env.lib:exec_sql
env.lib:get_server_result
bb_server_check.lib:get_check_performance env.lib:get_server_result
env.lib:exec_sql
env.lib:reporterror env.lib:set_color
bb_server_check.lib:check_blocks bb_server_check.lib:get_check_blocks
bb_server_check.lib:get_check_blocked
env.lib:exec_sql
env.lib:exec_sql
env.lib:reporterror
bb-ase.ksh – schéma volání funkcí
73
bb_server_check.lib:check_database
bb_db_check.lib:check_db
env.lib:reporterror
bb_server_check.lib:check_segments
bb_server_check.lib:get_database_sizes
bb_server_check.lib:check_size
bb_server_check.lib:tempdb_datasegment_usage
bb_server_check.lib:tempdb_logsegment_usage
env.lib:exec_sql
env.lib:exec_sql
env.lib:exec_sql
env.lib:exec_sql
env.lib:get_server_attribute
bb_db_check.lib:get_db_list
env.lib:get_server_attribute
env.lib:check_if_word_in_list
env.lib:reporterror
bb_db_check.lib:check_db_exist
bb_db_check.lib:check_latency
bb_db_check.lib:check_db_latency_exists
bb_db_check.lib:check_usable
env.lib:get_server_result
env.lib:get_server_result
env.lib:get_server_result
bb_db_check.lib:check_latency env.lib:get_server_result
env.lib:get_server_attribute
env.lib:reporterror
bb_db_check.lib:get_check_usable env.lib:get_server_result
bb_db_check.lib:get_check_offline
bb_db_check.lib:get_db_process
env.lib:reporterror
env.lib:get_server_result
env.lib:get_server_result
bb_server_check.lib:createsp_segsize
bb_server_check.lib:get_userdatabases_online
env.lib:get_server_result
env.lib:exec_sql
bb-ase.ksh – schéma volání funkcí (pokračování)
74
bb_server_check.lib:check_processes
bb_server_check.lib:check_sybinfos
bb_server_check.lib:check_engines
bb_server_check.lib:check_tempdb
bb_server_check.lib:check_allocation
bb_server_check.lib:get_check_update_stats
bb_server_check.lib:get_check_dbcc
bb_server_check.lib:get_check_reorg
bb_server_check.lib:get_check_logsuspend
env.lib:get_server_result
env.lib:get_server_result
env.lib:get_server_result
env.lib:get_server_result
env.lib:reporterror
env.lib:reporterror
env.lib:reporterror
bb_server_check.lib:get_check_engines env.lib:get_server_result
env.lib:get_server_result
env.lib:reporterror
env.lib:get_server_result
env.lib:reporterror
bb-ase.ksh – schéma volání funkcí (pokračování)
75
bb_inv_check.lib:check_inventory
bb_inv_check.lib:check_auditing
bb_inv_check.lib:check_license_expired
env.lib:get_server_attribute
bb_inv_check.lib:do_mastertables
bb_inv_check.lib:do_database
bb_inv_check.lib:check_cron_running
bb_inv_check.lib:check_starting
bb_inv_check.lib:get_all_unix_info
bb_inv_check.lib:check_DTM
bb_inv_check.lib:get_server_map
env.lib:get_server_result
env.lib:get_server_attribute
env.lib:reporterror
env.lib:get_server_result
env.lib:reporterror
bb_inv_check.lib:get_diffs env.lib:reporterror
env.lib:exec_sql
bb_inv_check.lib:get_diffs env.lib:reporterror
env.lib:exec_sql
env.lib:reporterror
env.lib:get_server_attribute
env.lib:reporterror
env.lib:exec_sql
bb-ase-daily.ksh – schéma volání funkcí
76
bb_inv_check.lib:check_backups
bb_inv_check.lib:trunc_master_log
bb_inv_check.lib:replication_check
env.lib:get_server_attribute
env.lib:get_db_list_all
env.lib:check_if_word_in_list
env.lib:reporterror
env.lib:JulDate
env.lib:exec_sql
env.lib:get_server_attribute
bb_inv_check.lib:get_replicated_tables env.lib:get_server_attribute
env.lib:reporterror
bb-ase-daily.ksh – schéma volání funkcí (pokračování)
77
bb_inv_check.lib:check_weekly
bb_inv_check.lib:check_dbcc
env.lib:get_server_attribute
bb_inv_check.lib:run_sp_auditdb
env.lib:check_if_word_in_list
env.lib:reporterror
bb_inv_check.lib:run_sp_auditsecurity
env.lib:get_server_attribute
env.lib:reporterror
env.lib:get_dec_month
env.lib:JulDate
bb_inv_check.lib:create_sp_auditdb
bb_inv_check.lib:get_server_result
bb_inv_check.lib:get_server_result
bb_inv_check.lib:exec_sql
bb_inv_check.lib:create_sp_auditsecurity
bb_inv_check.lib:get_server_result
bb_inv_check.lib:get_server_result
bb_inv_check.lib:exec_sql
bb-ase-weekly.ksh – schéma volání funkcí
78
bb_server_check.lib:run_sp_sysmon2 env.lib:get_server_attribute
env.lib:reporterror
bb_inv_check.lib:get_server_result
bb_inv_check.lib:exec_sql
env.lib:get_server_attribute
bb_server_check.lib:create_sp_sysmon2
bb_inv_check.lib:exec_sql
bb_server_check.lib:check_sysmon_line
{sp_sysmon}
bb-perf.ksh – schéma volání funkcí
79
bb_iq_check.lib:iq_check
bb_iq_check.lib:check_iqrunning
bb_iq_check.lib:check_iqstatus
bb_server_check.lib:get_check_connectable env.lib:get_server_result
env.lib:reporterror
bb_iq_check.lib:check_dbspaces
bb_iq_check.lib:get_check_iqstatus
env.lib:get_server_attribute
env.lib:reporterror
bb_inv_check.lib:exec_sql
env.lib:get_server_attribute
bb_inv_check.lib:get_server_result
env.lib:reporterror
bb_iq_check.lib:check_iq_longrunner bb_iq_check.lib:get_check_iq_longrunner bb_inv_check.lib:get_server_result
env.lib:get_server_attribute
env.lib:reporterror
bb_iq_check.lib:report_version_usage bb_inv_check.lib:get_server_result
bb_iq_check.lib:check_connection_count bb_inv_check.lib:get_server_result
bb_iq_check.lib:check_new_events
bb_iq_check.lib:get_sql_statement bb_inv_check.lib:exec_sql
bb_iq_check.lib:create_events_iface
bb_inv_check.lib:get_server_result
bb_inv_check.lib:get_check_events
bb_inv_check.lib:crt_evnts
bb_inv_check.lib:get_server_result
bb_inv_check.lib:get_server_result
bb_inv_check.lib:get_server_result
bb_iq_check.lib:report_usage_by_SPID bb_inv_check.lib:get_server_result
bb_server_check.lib:check_connectable
bb-iq.ksh – schéma volání funkcí