5. ANDMEBAASDE MONITOORIMINE

 

 

 

5.1. Andmebaaside monitoorimise olemus ja eesmärk




Andmebaas on töökorras, kui tal on kõiki oma tööks vajalikke ressursse piisavalt, kui tarkvara on töövõimeline, kui andmekandjatel asuvad andmestruktuurid ja neisse salvestatud andmed on korrektsed ja kui andmebaasile juurdepääsu kanalid töötavad korrektselt. Andmebaasiga on seotud veel hulgaliselt asju nagu näiteks andmebaasiga seotud paketttöötluse protsessid ja andmebaasi käsitluse erinevate töökohtade tarkvara, teiste andmebaasidega suhtlemise tarkvara jms. Kuigi nende töö on väga tihedalt ja vältimatult seotud andmebaasidega kuulub nende monitoorimine siiski eraldi tegevuste valdkonda.



Töötav andmebaas

Andmebaasi monitoorimine on protsess, mille käigus jälgitakse andmebaasis toimuvaid füüsilisi protsesse. Sisuliselt tähendab see siis andmebaasi mootori töö jälgimist. Mida siis jälgitakse? Jälgitakse nelja tüüpi asju.



Füüsiliste protsesside jälgimine

Esiteks jälgitakse (nappide) ressursside (ära)kasutamist veendumaks, et süsteemi töövõime tagamiseks vajalik erinevate ressursside piisav reserv on süsteemi töö igal hetkel saadaval sellises mahus, mis välistaks iga ressursi ülekasutuse - alati peab alles jääma kas või õige pisika varu. Määratlus „õige pisike“ on siin muidugi natuke liiga segane määratlus. Tegelikkuses määratakse igale ressursile kasutamise piir ja üritatakse vältida selle ületamist või siis selle vältimatul ületamisel laiendatakse ressurssi selliselt, et määratud vaba ressursi piir oleks jälle saavutatud.



Ressursi kasutamise jälgimine ja ressursi olemasolu tagamine

Teise asjana jälgitakse tarkvara töövõimelisust. Selle monitooringu ülesandeks on leida tõrkeid süsteemi töös so. Selliseid hetki, kus andmebaasi mootor ei ole suuteline töötlema temale saadud korraldusi või siis kulub nende töötlemisele ülearu palju aega. Oluline on siin eristada ajutisi tõrkeid ja jäävaid tõrkeid. Kui esimeste puhul ei tule eh kohe midagi kiiresti ette võtta vaid püüda kõigepealt leida nende tekkimise põhjused ja seejärel kõrvaldada need, siis teiste puhul tuleb alustada viivitamatuid süsteemi töövõime taastamise toimingudi. Loomulikult peab ka sellega kaasnema vigade analüüs ja nende põhjuste välja selgitamine.



Süsteemi töövõimelisus

Oluline on ka veendumus, et andmekandkatele salvestatud andmebaasi struktuurid ja seal paiknevad andme on „füüsiliselt terved“. Andmestruktuuride riknemise peamisteks põhjusteks on riistvara vead ja tarkvara (andmebaasi mootori) vead. Riistvaraliste ja tarkavaraliste vigade tulemusena riknenud andmete struktuursed elemendid või andmed ise põhjustavad tavaliselt sellise olukorra, kus kõiki ressursse on piisavalt tarkvara töötab (nüüd juba) korrektselt, kuid andmete käsitlus on häiritud. Tavalislet on sellise „häirumise“ tunnuseks see, et baasist loetavad andmekomplektid ei ole need (tavaliselt osaliselt), mida sealt tegelikult välja küsiti ja andmed salvestuvad baasi valesti. Kuidas valesti – see on igal juhtumil erinev.



Andmebaasi struktuuri terviklikkuse kontroll

Kuigi kanalite toimimine kuulub rohkem riistvara monitoorimise juurde on ta andmebaasi toimimise seisukohalt nii oluline ressurss, mille riknemine muudab töövõimetuks kogu andmebaasi, siis tuleb seda monitoorida ühtses kompleksis teiste andmebaasi monitoorimise protsessidega.



Kanalite toimimine

Sageli ei anna ühe konkreetse ressursi toimimise monitooringu andmete eraldi analüüs ammendavat tulemust probleemide iseloomu kohta. Andmebaaside monitoorimisel ongi see enamasti just nii. Probleemide ilmnemisel ühe monitooritava ressursi toimimisel tuleb uurida, kas kõrvalekaldeid tavalisest on ka teiste ressursside monitooringu andmetes. Nende kõrvutamine võib anda oluliselt teisi tulemusi kui seda annab ühe, eraldi seisva monitoorimisprotsessi andmete analüüs. Näiteks kui kanali monitooring annab häiret, et kanali koormuse maht hakkab ammendusm siis tuleks kindlasti vaadata ka serveri protsessori koormuse monitoorimise logi ja andmebaasipoole saadetud korralduste logi. Kui need näitavad samuti „suuri numbreid“, siis on selge, et mingil põhjusel on selle hetkel tõepoolest kasutusaktiivsus suur ja asi „täiesti normaalne“. Samas kui serveri protsessori koormuste logi ja tehtud päringute logi näitavad süsteemi passiivsust, siis tuleb hakata otsima viga kanalis.



Kompleksne analüüs

See et kõik koormused on „korraga üleval“ ei anna muidugi põhjust rahunemiseks. Peaks uurima , mis on selle põhjuseks ja kas tegemist oli mingi ühekordse nähtusegan või võib selline asi korduna hakata regulaarselt. Võis ju tõesti olla nii, et mingi ühekordne sündmus (näiteks rahasüsteemi ümberkorraldus: EEK -> EUR) tekitas ajutise koormuse kasvu ja niipea teist sellist sündmust oodata pole. Samas lisanduvad infosüsteemidele pidevalt uued funktsionaalsused, mis nõuavad ka oma osa serverite ja kanalite jõudlusest. On muidugi kui selline funktsionaalsuse lisandumine ja jõudluse kasvu nõue pole ette teada ja see avastatakse monitooringu tulemusena – see kõik peab olema ette kalkuleeritud. Aga noh, elus juhtub mõndagi!



Ühekordsed ja regulaarsed sündmused.


5.2. Ressursside kasutamise monitooring




Ressursse mida andmebaasi juures monitoorima peab on seitse seejuures peab enamiku puhul nendest koguma andmeid selliselt, et oleks teada nii vaba ressursi hulk kui ka kasutatud ressursi hulk määratud ajahetkedel. Need määratud ajahetked on tavaliselt ajahetked, mingi ettemääratud intervalli järel. Seejuures ei ole see intervall sugugi kõikide ressurssde puhul sama vaid võib erineda üksteisest kordades -aktiivsemaid ressursse (näiteks protsessori koormus) monitooritakse väiksema sammuga samas passiivsemiad ressursse (näiteks vaba salvestuspinna maht) jällegi oluliselt pikema sammuga.


Ressursside monitoorimise tsüklilisus


5.2.1. Protsessori koormuse monitooring




Serveri kasutatav jõudlus peab olema vastavuses lahendatava ülesandega. Mida suurem on andmebaasi kasutamise intensiivsus seda suurema jõudlusega peab olema server. Serveri jõudluse ei ole muidugi kinni ainult tema protsessori võimekusest. Serveri jõudluse tõstmisel on tavaliselt oluliselt suurema tähtsusega piisavalt suur vaba operatiiv mälu hulk (sllest täpsemalt natuike all pool) ja piisavalt kiirelt andmesalvestusseadmed ning kiired kanalid serveri ja andmesalvestusseadmete vahel. Siiski on väga oluline ka piisava protsessori ressursi olemasolu. Mida tähendab piisav?



Serveri jõudlus vs muud ressursid

Andmebaasiserver ei tohi kunagi töötada koormuse piiril. Pigem vastupidi. Andmebaasi serveveri protsessori koormus ei tohiks „tavalises töörežiimis“ ületada 10%-list koormust. Miks? Seda selle pärast, et andmebaasi ressurss on infosüsteemides üks kriitilisemaid ressursse. Kui kõiki teisi ressursse infosüsteemis on võimalik suhteliselt väikese vaevaga kordistada (tööjaamad, aplikatsiooniserverid, kanalid jms.) siis andmebaasiserveri kordistamine on väga-väga kallis ja alati mitte soovitud tulemust andev üritus. Ainuke korrektselt kobarana (cluster) toimiv andmebaasiserver täna on Oracle RAC (Real Application Clusters) see on aga hoopis teisest hinnaklaasist „tükk“ kui seda on Oracle tavaline (mitte Enterprise) andmebaasisüsteem ja teised andmebaasisüsteemid.



Andmebaasiserveri „normaalne“ koormus peab olema pigem madal kui kõrge

Andmebaasiga tehtavad toimingud on perioodilise iseloomuga – rutiinid korduvad tundide, päevade, kuude, kvartalite ja aastate kaupa. Aja möödudes muidugi pidevalt suuremates mahtudes – süsteemidel juba on kord omadus kogu aeg laieneda. Selles tsüklilisuses on nii rahulikuma kui ka suurema aktiivsusega perioode. Toimingud jagunevad tavalisteks „rahulikeks“ töötegevusteks, kus salvestatakse baasi andmeid ja loetakse nende tegevuste toetuseks andmeid. See ei nõua serverilt tavaliselt suurt protsessori koormust. Samas kui läheb andmete analüüsiks ja keeruliste raportite koostamiseks võivad serveri koormused tõusta „olulistesse kõrgustesse“. Nad võivad viia protsessori jõudluse nii kõrgele, et see hakkab takistana normaalset igapäevase töö tegemist – see lihtsalt „ei mahu“ enam analüüsi ja raportite kõrvale. Seega peaks andmebaasitoimingute tegemiseks olema piisav jõudluse varu, selleks et teha ka veidi ressursimahukamaid tegevusi ilma et igapäevane töö oleks takistatud



„Igapäevane töö“ vs. analüütika ja raporteerimine

Tegelikkuses ei ole protsessori koormuse suurus siiski väga kriitiline näitaja – oluline on see, et jääks kogu aeg 90% piiresse. See on aga väga oluline, sest suuremate koormuste korral me tegelikult enam ei tea, kas protsessori jõudlust jagus või „hoiab server ennast tagasi“ st. server on osa tegevusi pannud järjekorda ja need ootavad vaba jõudluse tekkimist.



90% - soovituslik maksimaalne koormus

Protsessori koormuse monitoorimiseks tuleb luua protsess, mille protsessori koormuse registreerimise sagedus sõltud serveri kasutamise intensiivsusest ja olulisusest. Kui tegemist on avalikkusele suunatud väga populaarset teenust teenindava serveriga võib tunduda, et monitooringu andmete salvestamise sagedus võiks olla üsna suur. Tegelikkuses on selliste serverite koormus kellaajaliselt tõusev ja langev suhteliselt sujuvalt nii et suuremat sagedust kui 5 minutit pole mitte mingit mõtet rakendada. Samas võib hoopis suuremat monitooringu andmete salvestamist nõuda sisemiseks kasutuseks ettenähtud ebaühtlase kasutusega server, millel asuvate andmetega seotud tarkvara arendus käib hoogsalt ja sinna lisandub pidevalt uut funktsionaalsust. Tegelikkuses on siiski nii, et andmebaasiserveri monitooringu korraldaja ise peab otsustama, millise sagedusega logi salvestatakse – see peab olema piisav selleks, et näh ära olulised ekstreemumid koormuste tõusudes ja langustes. Mingit väga konkreetset sagedust siin ette anda küll ei ole võimalik.



Monitooringu andmete salvestamise sagedus.

Kui Serveril on mitmeid protsessoreid japrotsessoritel mitmeid tuumasid, siis tuleb monitoorida igat tuuma eraldi, kuna siit võib paista välja ka erinevate protsessorite ja erinevate tuumade ebaühtlane koormus. See omakorda võib aga tingida vajaduse serveri seadistamiseks. Koos logitavate andmetega tuleb salvestada ka logimise hetke ajatempel.



Monitooritavad andmed

Serveri jõudluse monitoorimise eesmärgiks on protsessori(te) koormuse jäämine 90% piiresse serveri töö igal hetkel. Seda on võimalik saavutada kolme erinevat moodi: konfigureerides serveri parameetreid, tehes serveri riistavara parendusi, optimeerida rakendusi, mis pöörduvad serveril olevate andmebaasidepoole või siis vahetada välja serveri riistvara. Monitoorimise andmed peavad andma meile hea aluse selleks, et otsustada, milline eel pool pakutud variantidest on kõige otstarbekam (kuluefektiivsem). Paraku serveri jõudluse logimisest ja nende andmete analüüsist üksi jääb väheks, et siin õigeid otsuseid vastu võtta. Selleks tuleb analüüsida ka teisi logisid.



Serveri jõudluse monitoorimise eesmärk


5.2.2. Kettaseadmete jõudluse monitoorimine




Kettaseadmete, kus andmebaase hoitakse, jõudluse monitoorimine on üsna sarnane serveri protsessori jõudluse monitoorimisega. On ju mõlemal puhul tegemist mingi ressursi jõudluse monitoorimisega. Kettaseadmete puhul on määratletud ära maksimaalne ajaühikus võimalik I/O (input/output) operatsioonide hulk. Monitoorimise tulemusena peame me hoidma seda, et „teha üritatavate“ I/O operatsioonide hulk ei saavutaks maksimaalset võimalikku taset. Siin kehtib täpselt sama soovitus kui protsessori koormuse puhulgi – üritada tuleb mitte ületada 90% võimaliku I/O operatsioonide arvust ajaühikus. Suurema koormuse korral on väga raske öelda, kas tõepoolest seadme koormust jagub või üritab süsteem ise asju puhverdades koormust kontrolli all hoida.



Sarnasus protsessori jõudluse monitoorimisega

90% nõue

I/O operatsioonide arvu ajaühiksu hoidmine võimalikus piirides on oluliselt tähtsam ülesanne, kui seda oli protsessori koormuse hoidmine lubatud piirides. Seda sellepärast, et ketaseadmed on kogu süsteemi kõige aeglasem osa – füüsiliselt pöörlevad kettad lihtsalt on „aeglased“. Kui tõrked toimuvad selles süsteemi astmes, siis viivitused on sellised, mis kordades ja isegi kümnetes kordades (kui mitte rohkemgi) aeglustavad süsteemi tööd.



Kettaseadmete töö monitoorimise olulisus

Kettaseadmete kohta tuleb monitoorimise käigus talletada minimaalselt I/O operatsioonide hulk ajaühikus. Seda saab teha muidugi siis, kui kettaseade annab välja sellist statistikat. Üldiselt on see monitooring väga konkreetset marki kettaseadme keskne ja monitooringu üles ehitamisel tuleb hoolega vaadata, milliseid parameetreid kettaseade enda kohta üldse „välja annab“.



Monitooritavad andmed

Kettaseadmete jõudluse monitoorimise eesmärgiks on I/O koormuse jäämine 90% piiresse kettaseadme I/O maksimaalsest võimest sellei töö igal hetkel. Seda on võimalik saavutada kahte erinevat moodi: konfigureerides kettaseadme parameetreid (kui on tegemist sellise massiiviga, mille parameetreid on võimalik häälestada) või siis optimeerida rakendusi, mis pöörduvad seadmel olevate andmebaasidepoole. Monitoorimise andmed peavad andma meile hea aluse selleks, et otsustada, kumb eel pool pakutud variantidest on kõige otstarbekam.



Kettaseadmete jõudluse monitoorimise eesmärk



5.2.3. Vabade salvestusmahtude monitoorimine




Vabade salvestusmahtude monitoorimine toimub kahes etapis – kettaseadmel oleva vaba mälumahu muutumise monitoorimine ja kettaseadmel andmebaaside jaoks eraldatud piirkondade vaba andmemahu muutumine. Lisaks selle tuleb viimast monitoorida struktuursete osade lõikes. Nende struktuursete osade loend sõltub konkreetsest andmebaasisüsteemis (kaubamärgist), kuid suure tõenäosusega on sellisteks eraldi monitooritavateks aladeks süsteemne piirkond, andmebaaside piirkond ja logide piirkond. Andmebaaside piirkond ja logide piirkond võivad olla tükeldatud veel väiksemateks alampiirkondadeks. Sellisel juhul tuleb vaba mälu muutumist monitoorida nende alampiirkondade lõikes.



Füüsiline ketta maht vs. andmebaasidele eraldatud ketta maht

Enamike arvestatavate andmebaaside puhul ei kasutata andmebaaside talletamiseks kogu saada olevat kettaseadmete pinda vaid sealt eraldatakse (reserveeritakse) andmebaaside jaoks ainult osa. Iga selline mälu eraldus tehakse tavaliselt nö. käsitsi. See tähendab seda, et administraator vaatab üle vabad füüsilise ketta mahud, praeguseks andmebaasidele eraldatud piirkondade vaba mälu ja otsustab, palju ta annab andmebaaside talletamiseks lisa mälu. Iga sellise mälu eraldusega väheneb füüsilise ketta vaba mälu maht. Kettaseadme vaba mälu mahu muutumise monitoorimine peab andma eelnevat informatsiooni füüsiliste kettamahtude ammendumise kohta selleks, et õigel ajal hankida uusi kettaseadmeid.



Mälu eraldused andmebaasidele

Andmebaaside talletamise piirkondadele lisamälu eraldamine on aga tingitud andmebaasidesse talletatava informatsiooni laekumise kiirusest ja korraga talletatavatest andmemahtudest. Seega füüsiliste kettamahtude ammendumise kiirus on tegelikkuses tingitu andmebaasidele eraldatud kettapiirkondade kasvuvajadustest. Siit nähtub, et neid kahte monitooritavat suurust saab vaadelda ainult üksteisega koos – andmemahtude suurenemise füüsilised piirid seab kettaseadme füüsiline maht samas kui tema ammendumise tingib andmebaasidele eraldatud piirkondade laiendamise vajaduse kiirus.



Andmebaasidele eraldatud vaba mälu muutuste monitooring

Kuma paljudel juhtudel on andmebaasides andmete talletamiseks eraldatud kettapind sisemiselt struktureeritud, siis võib see piirkond „saada täis“ hulk aega enne seda, kui kogu andmete talletamiseks eraldatud piirkond täis saab. Seda selle pärast, et andmete talletamiseks eraldatud piirkond „saab täis“ siis, kui mahud ammenduvad mistahes tema alampiirkonnal. Näiteks kui täis saab logide talletamise piirkond, siis on andmeid võimalik veel baasist pärida, kui talletada ja muuta sinna juba varasemast talletatud andmeid enam ei saa, kuna iga sellise tegevusega kaasneb logikirje kirjutamine, kuid seda enam teha ei saa. Sama toimub siis, kui täis on saanud andmete talletamise piirkond. Kui nüüd mõni piirkondades on jaotatud veel alampiirkondadeks, siis kehtib see jutt ka nende kohta. Kuigi siin võib saada natuke „armuaega“ - töötada saab nii kaua, kui talletamiseks ei kasutata neid piirkondi, mis on täitunud. See on aga väga determineerimata olukord ja tegelikkuses suhteliselt sarnane veneruleti mängimisega – eales ei või teada, kas järgmine padrunisalve pesa on tühi või padruniga.



Andmebaasidele eraldatud kettaosa struktuuri täitumise iseärasused

Väga oluline on ka operatiivmälu kasutuse monotooring. Võiks öelda, et see on isegi andmebaasiserveri korrektse töö tagamisel võtmetähtsusega tegevus. Miks? Kuna arvutite operatsioonisüsteemid on juba üsna tükk aega „ehitatud“ nii, et kui operatiivmälusse sinna mahtumapidavad asjad enam ära ei mahu, siis kirjutatakse hetkel mitte vajalikud andmed arvutikettaleselleks, et vabastada ruumi nendele asjadele, mida just vajatakse käimas olevate protsesside täitmiseks. See tähendab seda, et arvutisüsteem hakkab swap-ima. Sisuliselt tähendab see ajajaotussüsteemides seda, et kettalekirjutatakse need prgrammid ja andmed, mille täitmine on lühemaks või pikemaks „hetkeks“ peatatud. Pikemaks „hetkeks“ need protsessid, mis on passiivses olekus ja lühemaks „hetkeks“ need, mida parasjagu ei töödelda, sest nende täitmiseks eraldatud ajahetk on selleks korraks otsa saanud.



Operatiivmälu monitooring

Seega, kui andmebaasiserver hakkab swap-ima, on kõik muud selle serveri jõudluse optimeerimise ja parendamise tööd mõttetud, kuna suurem osa serveri ajast läheb andmevahetuses operatiivmälu ja ketaste vahel. Võib isegi öelda, et servveri töö sisuliselt lõppeb, kuna kasutajate teelimuste täitmiseks jääb aega vaäga vähe järele.



Serverite ei tohi „swap-ima lasta“

Operatiivmälu monitoorimine tulen üles ehitada loogikase, kus logitakse vaba mälu mahtu ja jälgitakse selle muutumist. Eesmärgiks on võime teha õigel ajal riistvara parendusi (mälu lisamine, serveri välja vahetamine) või siis üritada asja parandada süsteemide ümberkonfigureerimisega. Täpsemini formuleeritud eesmärgiks on vältida situatsiooni, kus server hakkab mälu swap-ima.



Vaba mälu mahu muutumine

See, aga et operatsioonisüsteemi tasemel on mäluga kõik korras, ei tähenda paljude suuremate andmebaasisüsteemide seisukohalt aga veel sugugi seda, kõik on korras ja andmebaasisüsteem korrektselt töövõimeline. Selliste andmebaasisüsteemide puhul on vaja monitoorida ka nende poolt kasutatava operatiivmälu sisemist struktuuri ja nende erinevate osade mälukasutust. Siin võib tekkida situatsioon, kus andmebaasi tegevus on pärsitud, kuna mingi mälu struktuurne osa on liiga väike samas kui mõnes teises piirkonnas on ressursi üleküllus. Selline monitooring ja ja monitooringu tulemuste analüüs on vaäga konkreetse andmebaasisüsteemi (kaubamärgi) keskne. Vahend, millega seda monitooringut tehakse peab olema loodud just konkreetse andmebaasisüsteemi monitoorimiseks ja analüüsi teostaja peab väga hästi tundma just selle andmebaasi omadusi ja vajadusi.



Mälu sisemise struktuuri monitooring



5.2.4. Monitoorimise vahendid




Monitoorimist võib läbi viia nii turul olemasolevate vahenditega kui ka ise enda poolt loodud või tellitud vahenditega. Mõlemal variandil on nii häid kui halbu külgi.



Osta või ise teha – selles on küsimus

Loomulikult on ostetava monitooringutarkvara suureks miinuseks tema suhteliselt kõrge hind. Samas pakuvad nad juba vamis ja testitud vahendeid ja lahendusi maailmas levinud monitoorimisliikidele vastavate monitooringute läbi viimiseks. Probleemiks võib osutuda ka see, et sama tarkvaraga saab teha monitooringut ainult määratud andmebaasisüsteemidele. On olemas nii spetsiaalselt ühe konkreetse andmebaasisüsteemi (kaubamärgi) monitoorimise tarkvarasid ka mitme erineva andmebaasisüsteemi monitoorimise tarkvarasid. Paraku ei ole olemas selliseid monitoorimistarkvarasid, mis lubaksid kombineerida tööd mistahes andmebaasisüsteemidega. Juhul, kui firmas kasutatavate erinevate admebaasisüsteemide jaoks ei leidu sellist monitoorimistarkvara, mis võimaldaks monitoorida neid kõiki, tuleb hankida mitu erinevat tarkvara ja nende kombineerimisel üritada leida minimaalne komplekt, mis kataks ära kõikide andmebaasisüsteemide monitoorimise. See tekitaba aga keerukust juurde monitoorimise komplekssele haldamisele.



Osta?

Ega monitoorimistarkvara ise tegemine pole ka probleemi vaba. Kindlasti on siin võimalik kokkuhoida maksumuselt. Samas tekkib oluline surve selle projektile monitoorimisalaste kogemusete ja teadmiste poole pealt – kas meie teadmised on ikka nii suured, et me suudame kõik vajalikud tegevused luua vajalikul tasemel. Samas, kui teadmistega probleemi ei ole õnnestub meil luua süsteem, mis on nii toimimise kui hallatavuse seisukohal ühtne tervik.



Teha ise?

Kuidas siis otsustada. Üheks võimaluseks otsustada on määta seda hanget rahas. Kui tegemist on suurte andmebaasidega, mille ülalhoiu maksumus on kõrge siis on suurema tõenäosusega vaja maandada kompetentsi puudulikkuse riske ja minna tarkvara ostmise teed. Lisaks sellele ei ole monitooringu tarkvara maksumus sellidel juhul infosüsteemi maksumusega võrreldes ebaproportsionaalselt suur. Kui andmebaasisüsteemi halduskulud on odavamad, siis kulude taseme hoidmiseks on mõtet luua monitoorimise vahendid ise. Lisaks sellele, arvestade ülalhoiu kulude taset, on siis kompetentsi puudulikkuse risk ka oluliselt väiksem.



Raha räägib

Igal andmebaasisüsteemil on endal olemas ka mingid vahendid monitooringu läbi viimiseks. Need ei ole tavaleiselt mingi „kena“ kasutajaliidesega vaid pigem andmebaasisüsteemi omadused mida saab „sisse ja välja lülitada“. Neid on hea kasutada komponentide oma monitooringu vahendite loomisel.



Andmebaasisüsteemi vahendid

Üks asi on monitooringu selle osa läbi viimine, mis talletab süsteemide jälgimise logid. Asja teine pool on nende logide töötlemine ja selle alusel administreerimis- ja haldusotsuste tegemine. Osa monitoorimise tulemusi on sellised, mida saab rakendades nn. on-line filtreid, mis jälgivad sisenevat logide voogu ja initsieerivad, mingite etteantud limiitide ületamisel (või ka neile alla jäämisel), selle samal limiidi ületamise hetkel häireid. Kui limiidid on kehtestatud, siis saab ja tulebki nende alusel automaatseks hoiatamiseks luua filtrite- häirete süsteem. Näiteks operatiivmälu ületäitumisel, ketta I/O limiidi ületamise jne. Samas peab aga „vähekegi tõsisem“ monitoorimise protsess sisaldama endas ka monitooringu logide analüüsi. Enamikus monitooringu tarvis loodud tarkvarades on need mingi tasemeni välja arendatud. Paraku jääb suurte süsteemide monitoorimisel sellest väheks. Sellise puudujäägi kõrvaldamiseks tuleb monitoorimisandmete töötlemiseks kasutada neid samu äri intelligentsi süsteeme, mida kasutatakse ka ärinadmete kaevandamisel ja analüüsil. Andmed ja nende tähendus on erinev, kuid töötluses alluvad nad samadele üldistele loogikataele mis äriandmedki.



Monitooringu tulemuste jälgimine ja analüüs



5.2.4.1 Monitoorimise tarkvara




Allpool toon lihtsalt näitlikustamiseks mõned enam kasutatavad andmebaaside monitoorimise tarkvarade nimetused.




Quest Software

Oracle, DB2 ja SQLServer; süsteemide pere erinevate probleemide lahendamiseks

http://www.quest.com/database-management/



Quest Database management Products

SQL Power Tools

Süsteemide pere SQL AB-de monitoorimiseks ja administreerimiseks

http://www.sqlpower.com/



SQL Power Tools Inc.

Precise

Süsteem Oracle, DB2, SQL Server ja Sybase andmebaaside monitoorimiseks ja administreerimiseks

http://www.precise.com/solutions/db-database.asp



PreciseSoftware solutions

ion

Oracle andmebaaside monitoorimise tarkvara

http://www.dba-oracle.com/monitoring.htm



Burleson Consulting

Manage Engine Application Manager

Rakenduste ja andmebaaside (Oracle, MS SQL, Sybase, IBM DB2 and MySQL) monitoorimise tarkvara

http://www.manageengine.com/products/applications_manager/index.html?dbmonitor



ZOHO corp.

Siit on näha, et monitooritavate andmebaasisüsteemide „komplektid“ on üle erinevate tarkvarade on väga erinevad. Lisaks sellele võib mingi tarkvara komplekssus olla hulga laiem kui ainult andmebaasisüsteemide monitoorimine. Viimane tarkvara selles loendis ongi lisatud siia selleks, et näidata kuidas samasse tarkvarasse võivad olla liidetud ka andmebaaside ja rakenduste monitoorimine.



Varieeruv „komplektsus“


5.2.4.2 NÄIDE: ORACLE operatiivmälu kasutuse lihtne logi



NÄIDE

Andembaasisüsteemi ORACLE poolt kasutatavast operatiivmälust on olulismi osa, mida monitoorida SGA (System Global Area). Monitoorida tuleks SGA suurust ja selle kasutamse protsenti. Samuti on oluline jälgida erinevate süsteemsete ressursside kasutamis hetkel, nende maksimaalset väärtust töö käigus ja piiranguid, mis ressurssidele mingil ajahetkel kirjeldatud on. Alustame viimasest.



SGA – System Global Area

Oracle andmebaasis on süsteemne vaade (view) v$resource_limit, mis sisaldab hetke väärtustena mitmete süsteemsete ressursside vaadeldava hetke ressursi (mälu) kasutust ja viimasest süsteemi startimisest arvestatud maksimaalset ressursi kasutust. Selles vaates on igal hetkel iga vaadeldava ressursi kohta üks kirje. Selle vaate struktuur on järgmine:



Vaade v$resource_limit


RESOURCE_NAME

Ressursi nimi (dml_locks, enqueue_locks, enqueue_resources, LM_PROCESSES, LM_LOCKS (local_listener), max_shared_servers, parallel_max_servers, processes, ROLLBACK_SEGMENTS (max_rollback_segments), sessions, SORT_SEGMENT_LOCKS, TEMPORARY_LOCKS)





CURRENT_UTILIZATION

Ressursi kasuamise väärtus hetkel





MAX_UTILIZATION

Ressursi kasutamise maksimaalne väärtus alates süsteemi viimasest käivitamisest





INITIAL_ALLOCATION

Süsteemi parameetrites määratud väärtus süsteemi käivitamisel või UNLIMITED





LIMIT_VALUE

Kehtestatud maksimaalne väärtus või UNLIMITED




Nagu öeldud on siin vaates ainult hetkeväärtused. Selleks et saada ülevaade nende väärtuste pidevast muutumisest peame looma tabeli ja korjama sinna kokku need hetkeväärtused. Loome tabeli dba$resource_limit:



Loome tabeli dba$resource_limit:


 

CREATE TABLE dba$resource_limit

(timestamp DATE,

 resource_name VARCHAR2(30),

 current_utilization NUMBER,      

 max_utilization NUMBER,

 initial_allocation VARCHAR2(10),

 limit_value VARCHAR2(10));




CREATE TABLE

Nagu näha on siin esialgse vaate struktuurile lisatud ainult ajatempli veer. Sellesse kirjutatakse väärtuste registreerimise aeg. Nüüd kirjutame INSERT-lause sellesse tabelisse kirjete lisamiseks. Kirjeldame lause Oracle protseduurina. Seda selleks, et teda oleks võimalik käivitada kalenderplaani (scheduler) alusel:





 

CREATE PROCEDURE scott.MONITORING1

BEGIN
INSERT INTO dba$resource_limit

(timestamp, resource_name, current_utilization, max_utilization, initial_allocation, limit_value )

SELECT TRUNC(SYSDATE), resource_name, current_utilization, max_utilization, initial_allocation, limit_value

FROM v$resource_limit

END:



INSERT-lause protseduurina

Ja nüüd lisame loodud protseduuri kalenderplaani poolt „tuntud“ protseduuride hulka nime all PROG_COLLECT_RESSOURCE:



Protseduuri kirjeldamine kalenderplaanis


 

begin  
    dbms_scheduler.create_program  
      (program_name=> 'PROG_COLLECT_RESSOURCE',        -- protseduuri unikaalne nimi kalenderplaanis
       program_type=> 'STORED_PROCEDURE',                          -- protseduuri tüüp
       program_action=> 'scott.MONITORING1',                                -- käivitatav protseduur
       enabled=>true,                                                                             -- on aktiivne või mitte (true/false)
       comments=>'Kogub ressurside andmeid'                                -- vabatekstiline kommentaar
      ); 
end;

 




Nüüd on vaja luua kalenderplaani rida, mis ütleb mis ajast alates, kui sagedasti ja kui kaua (millise kuupäevani) protsessi täidetakse. Käivitame selle



Kalenderplaani rea loomine


 

dbms_scheduler.create_schedule
    (schedule_name => 'INTERVAL_EVERY_1_MIN',                    -- kalenderplaani rea unikaalne nimi
     start_date=> sysdate,                                                                    -- esimese käivitamise aeg (praegune hetk)
     repeat_interval=> 'FREQ=MINUTELY; INTERVAL=1;',            -- taaskäivitamise intervall (1 minut)
     comments=>'Runtime: after every 1 minute');                            -- vabatekstiline kommentaar
end; 

 




Nüüd on protseduur kalenderplaanis kirjeldatud (PROG_COLLECT_RESSOURCE) ja ka kalenderplaani rida kirjeldatud (NTERVAL_EVERY_1_MIN). Nüüd jääb need kaks asja omavahel siduda – öelda, et kirjeldatud protseduuri tuleb hakata käivitama vastavalt reeglile, mis on kirjeldatud kalenderplaani reas so. kirjeldada tuleb töö:



Protseduuri sidumine kalenderplaani reaga

 


 
begin
dbms_scheduler.create_job
(
job_name      => 'ARC_MOVE',-- kirjeldatava töö unikaalne nimi
program_name  => 'PROG_COLLECT_RESSOURCE',-- käivitatava protseduuri nimi
schedule_name => 'INTERVAL_EVERY_1_MIN',-- kalenderplaani rea nimi, millega protseduur seotakse
comments      => 'Log resources',-- vabatekstiline kommentaar
enabled       => TRUE-- on aktiivne või mitte (true/false)
);
end;
 




Nüüd on meil loodud mehhanism, mis töötab meist sõltumatult ja kirjutab iga minuti järel andmed süsteemsest vaatest v$resource_limit meie poolt loodud tabelisse dba$resource_limit.



Sõltumatult käivitatav protseduur

Sama kalenderplaani reaga saab siduda mitmeid erinevaid töid. Sellest räägime lähemalt all pool.



Sama kalenderplaani rida – mitu protseduuri

Teeme nüüd logi SGA erinevate piirkondade vaba mälu muutumisest. SGA piirkondad vaba mälu mahu hetke väärtused on võimalik lugeda vaatest v$sgastat. Selle vaate struktuur on järgmine



v$sgastat struktuur


POOL

SGA struktuurse pooli (kogumi) nimi





NAME

Ressursi nimi poolis (vaba mälu korral 'free memory')





BYTES

Ressursi suurus baitides




Käitume täpsel nii nagu eelmiselgi juhtumil – loome andmete kogumiseks tabeli, mille struktuur on sama, mis vaatel v$sgastat lisade sinna vaid ajatempli. Loome tabeli dba@sgastat:



Loome tabeli v$sgastat


 

CREATE TABLE dba$sgastat

(timestamp DATE,

 pool VARCHAR2(30),

 name VARCHAR2(30),

 bytes NUMBER);




CREATE TABLE

Nagu näha on siin esialgse vaate struktuurile lisatud ainult ajatempli veer. Sellesse kirjutatakse väärtuste registreerimise aeg. Nüüd kirjutame INSERT-lause sellesse tabelisse kirjete lisamiseks. Kirjeldame lause Oracle protseduurina. Seda selleks, et teda oleks võimalik käivitada kalenderplaani (scheduler) alusel:





 

CREATE PROCEDURE scott.MONITORING2

BEGIN
 INSERT INTO dba$sgastat (timestamp, pool, name, bytes )

SELECT TRUNC(SYSDATE), pool, name, bytes

FROM v$sgastat;

WHERE NAME='free memory'

END;



INSERT-lause protseduurina

Ja nüüd lisame loodud protseduuri kalenderplaani poolt „tuntud“ protseduuride hulka nime all PROG_COLLECT_SGA:



Protseduuri kirjeldamine kalenderplaanis


 

begin  
    dbms_scheduler.create_program  
      (program_name=> 'PROG_COLLECT_SGA',                         -- protseduuri unikaalne nimi kalenderplaanis
       program_type=> 'STORED_PROCEDURE',                          -- protseduuri tüüp
       program_action=> 'scott.MONITORING2',                                -- käivitatav protseduur
       enabled=>true,                                                                             -- on aktiivne või mitte (true/false)
       comments=>'Kogub SGA andmeid'                                         -- vabatekstiline kommentaar
      ); 
end;

 




Käivitame loodud protseduuri analoogiliselt eelmise protseduuriga iga minuti tagant. Kuna selline kalenderplaani rida on meil juba loodud (NTERVAL_EVERY_1_MIN), siis nüüd jääb vaid loodud protseduur (PROG_COLLECT_SGA) siduda selle kalenderplaani reaga – öelda, et kirjeldatud protseduuri tuleb hakata käivitama vastavalt reeglile, mis on kirjeldatud kalenderplaani reas so. kirjeldada tuleb töö:



Protseduuri sidumine kalenderplaani reaga

 


 
begin
dbms_scheduler.create_job
(
job_name      => 'ARC_MOVE',-- kirjeldatava töö unikaalne nimi
program_name  => 'PROG_COLLECT_SGA',-- käivitatava protseduuri nimi
schedule_name => 'INTERVAL_EVERY_1_MIN',-- kalenderplaani rea nimi, millega protseduur seotakse
comments      => 'Log SGA',-- vabatekstiline kommentaar
enabled       => TRUE-- on aktiivne või mitte (true/false)
);
end;
 




Nüüd on meil loodud mehhanism, mis töötab meist sõltumatult ja kirjutab iga minuti järel andmed süsteemsest vaatest v$sgastat meie poolt loodud tabelisse dba$sgastat.



Sõltumatult käivitatav protseduur


5.2.4.3 NÄIDE: ORACLE kettaruumi monitoorimine



NÄIDE

Vaatame, kuidas lihtsate päringutega andmebaasi süsteemsetesse tabelitesse on võimalik saada teavet kettaruumi ammendumise või mitteammendumise kohta.




Andmebaasi kettaruum jaguneb tavaliselt kaheks suuremaks osaks. Süsteemses piirkonnas, kus andmebaasisüsteem hoiab enda tööks vajalikke andmeid ja mille struktuuri ja ka suure osa seal hoitavate andmete eest hoolitseb süsteem ise. Kasutaja saab ainult kirjeldada seal piirkonnas asuvate parameetrite väärtusi. Andmebaaside piirkonda saab kasutaja luua andmebaas. See piirkond võib olla jagatud partitsioonideks. Kõik andmebaasi partitsioonid on registreeritud süsteemses piirkonnas. Oracle nimetab andmabaasipiirkondi table space-deks.



Süsteemne piirkon vs. Andmebaasi piirkonnad

Table-space

Andmebaasi piirkonnad on tavaliselt „käsitsi“ eraldatud piirkonnad st. keegi andmebaasi administraatoritest on need kirjeldanud. Siiski on võimalik enamike andmebaaside puhul teha neid mälueraldusi ka automaatselt (Oracle puhul AUTOEXTEND). Sellisel juhul eraldab andmebaasi mootor andmebaasidele mingi vaikimisi suuruseka mälumahu kettal ja väldib selle ületäitumist sellega, et enne kriitilise piiri saabumist eraldab lisa mälu. Seda on mõistlik kasutada aga ainult väiksemate andmebaaside puhul, kuna suuremate paaside puhul hakkab see pärssima töö kiirust. Asi pole mitte pidevas laiendamises enese vaid selle, et selline „kontrollimatu laiendamine“ muudab andmebaasi sisemiselt tugevasti fragmenteerituks ja see aeglustab andmebaasimootori tööd.



AUTOEXTEND

Nagu operatiivmälu kohta saime informatsiooni andmebaasis asuvatest süsteemsetest vaadetest, nii saab sedasi informatsioonika kettamälu kasutamisest. Oma näites kasutame süsteemseid vaateid DBA_SEGMENTS ja DBA_FREE_SPACE.



Vaated DBA_SEGMENTS ja DBA_FREE_SPACE

Tabel DBA_SEGMENTS kirjeldab mälumahud, mis segmendis on reserveeritud kasutajate objektide jaoks. Tabelis DBA_SEGMENTS on palju veergusid, kuid kirjeldame siinkohal ära ainult meie jaoks olulised (kasutatavad) veerud:



Tabeli DBA_SEGMENTS struktuur


OWNER

Segmendi omaniku kasutajanimi





SEGMENT_NAME

Segmendi nimi või tühi





TABLE_SPACE_NAME

Selle table space nimi, mis sisaldab segmendi





BYTES

Segmendi suurus baitides





NEXT_EXTENT

Järgmise ekstendi suurus, mis lisatakse segmendile





MAX_EXTENT

Maksimaalne ekstentide arv, mis segmendis on lubatud




Tabeli DBA_SEGMENTS täielik kirjeldus asub aadressil: http://www.sc.ehu.es/siwebso/KZCC/Oracle_10g_Documentacion/server.101/b10755/statviews_2319.htm



Tabeli DBA_SEGMENTS täielik kirjeldus

Tabel DBA_FREE_SPACE kirjeldab kõik vabad ekstendid kõikides table space-des. Tabelis DBA_FREE_SPACE on palju veergusid, kuid kirjeldame siinkohal ära ainult meie jaoks olulised (kasutatavad) veerud:



Tabeli DBA_FREE_SPACE struktuur


TABLESPACE_NAME

Selle table space nimi, milles ekstent asub





BYTES

Ekstendi suurus baitides




Tabeli DBA_FREE_SPACE täielik kirjeldus asub aadressil: http://www.sc.ehu.es/siwebso/KZCC/Oracle_10g_Documentacion/server.101/b10755/statviews_2105.htm#sthref1751



Tabeli DBA_FREE_SPACE täielik kirjeldus

Koostame päringu selle kohta, millistel segmentidel on oht järgmise ekstendi loomisel ületada pideva vaba mälu piir. Kasutame selleks süsteemseid tabeleid dba_segments ja dba_free_space.



Vabamälu piiri ületamise päring


 

SELECT s.owner, s.tablespace_name, s.segment_name, s.bytes, s.next_extent, MAX(f.bytes) largest

FROM dba_segments s,dba_free_space f

WHERE s.tablespace_name = f.tablespace_name(+)

GROUP BY owner, s.tablespace_name, segment_name, s.bytes, next_extent

HAVING next_extent*2>largest;

 




Nüüd pärime andmebaasist välja, millised segmendid on jõudnud lähedale oma MAX_EXTENT väärtusele so. teeme ressursi ammendumise päringu.



Ressursi ammendumise päring


 

SELECT owner, tablespace_name, segment_name, bytes, extents, max_extents

FROM dba_segments

WHERE extents*2 > max_extents;




Samuti nagu tegime muutuste logimise protseduurid vaadete v$resource_limit ja v$sgastat jaoks saame seda teha ka viimati vaadeldud kahe vaate jaoks.



Logide moodustamine



5.3 ÜLESANNE



ÜLESANNE

Looge tabelite protseduuride ja kalenderplaani kirjeldused selleks, et logida vaadete DBA_RESOURCE ja DBA_FREE_SPACE andmeid sagedusega üks kord ööpäevas – öösel kell 3:00.