Bankovní institut vysoká škola Praha - is ambis

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.


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: [email protected]

mailto_yellow: [email protected]

#########################################################################

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


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



#########################################################################

name: tredbp01_rs

type: _REP_


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



#########################################################################

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.


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.


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ů.


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.


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.


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


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


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.


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.


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".


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".


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".


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".


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.


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".


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".


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".


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".


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.


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)

http://www.edbarlow.com/document/procs/readme.htm#link10


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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


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


bb_db_check.lib:get_db_list


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




bb_db_check.lib:check_latency env.lib:get_server_result


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



bb_server_check.lib:createsp_segsize

bb_server_check.lib:get_userdatabases_online


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:reporterror

env.lib:reporterror

env.lib:reporterror

bb_server_check.lib:get_check_engines env.lib:get_server_result


env.lib:reporterror


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


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:reporterror


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: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_db_list_all


env.lib:reporterror

env.lib:JulDate

env.lib:exec_sql


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


bb_inv_check.lib:run_sp_auditdb


env.lib:reporterror

bb_inv_check.lib:run_sp_auditsecurity


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:exec_sql

bb_inv_check.lib:create_sp_auditsecurity




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_server_check.lib:create_sp_sysmon2


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:reporterror




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: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_check_events

bb_inv_check.lib:crt_evnts




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í

Bankovní institut vysoká škola Praha - is ambis

Documents

Transcript of Bankovní institut vysoká škola Praha - is ambis