|
1. ANDMEBAASIDE ADMINISTREERIMISE OLEMUS. PÕHIMÕISTED |
|
|
|
|
1.1. Koht tarkvara elutsüklis |
|
|
|
|
Mitte just kogu loodav tarkvara ei jõua oma elutsüklis kasutamise faasi. Siiski, vaatamata kõigele, suur hulk tarkvarast rakendatakse ja võetakse regulaarsesse kasutusse. See, kui tarkvara kasutusse jõuab, lõpetab ühe projekti – tarkvara loomise projekti ja alustab teise projekt – infosüsteemi haldamise projekti. See projekt on küll vähem määramatusi sisaldav kui eelnev projekt ja selle läbiviimise meetodid ka palju täpsemalt determineeritavad, kuid vaatamata sellele tuleb infosüsteemide haldamise projektidesse suhtuda väga tõsiselt – ootamatusi ja ebareeglipärasusi jätkub siingi piisavalt. Tarkvara arendamine võib olla läbi viidud väga hoolikalt ja saadud tulemus olla ka täiesti kasutatav, kuid kui infosüsteemide haldamist korraldada valesti, võib kogu eelnev töö osutuda täiesti kasutuks – infosüsteemi kasutamine kas osutub täiesti võimatuks või väga vaevaliseks ja ebaefektiivseks. |
|
|
Infosüsteemi haldus kui projekt
|
|
Mis on siis infosüsteemi haldus? Infosüsteemi haldus on pidevalt läbi viidavate metoodiliselt teostatud tegevuste kompleks, mis tagab infosüsteemi töövõime ja toimimise. Seejuures infosüsteemi all mõeldakse siin riistvaraliste ja tarkvaraliste vahendite kompleksi mingi kindla sisu ja eesmärgiga infotöö teostamiseks. |
|
|
Infosüsteemi haldus kui perioodiliselt läbi viidatavate metoodiliste tegevuste kompleks |
|
Andmebaasid on infosüsteemide lahutamatu koostisosa. Andmebaaside haldamine on infosüsteemide haldamise protsessi koostisosa. Nende haldamistegevuste läbiviijateks on andmebaasiadministraatorid |
|
|
Andmebaaside administreerimine – infosüsteemide administreerimise lahutamatu koostisosa |
|
1.2. Andmebaaside haldamise olemus |
|
|
|
|
Andmebaaside haldamisel võib rääkida kahe suurema valdkonna ülesannete lahendamisest. Esimene nendest on andmebaaside töövõime tagamine ja teine andmebaaside toimimise tagamine. |
|
|
Töövõime vs. toimimine |
|
Töövõime tagamine tähendab seda, et plaanipäraste meetmete rakendamisega tagatakse andmebaasi tööks vajaliku riistvara ja tarkvara korrektne (lubatud piirides tõrgetega) töö ning riistvara arendamine ja tarkvara korrigeerimine vastavalt infosüsteemi funktsionaalsetele vajadustele ja esitatud nõuetele. Tegemist on siis puhtalt füüsilise korrektsusega – tagatakse andmebaasisüsteemide ja andmebaaside tõestatud valmidus selleks et neid oleks võimalik kasutada. See kas neid keegi üldse kasutab ei ole siin kohal oluline. Oluline on ainult see, et kogu süsteem funktsioneeriks laitmatult. |
|
|
Töövõime – tarkvara ja riistvara korrektne toimimine |
|
Toimimise tagamine peab kindlustama andmebaasi tõrgeteta, eesmärgipärase kasutamise. Selles meetmete komplektis on need tegevused, mis tagavad andmebaasisüsteemides säilitatavate andmete juurdepääsu ja vajalike tegevuste õigeaegse käivitamise. See, kas süsteem, mille toimimist tagatakse on üldse töövõimeline pole siin kohal oluline. Oluline on ainult see, et oleks tagatud need toimingud, mis tagavad andmebaaside toimimise. |
|
|
Toimimine - eesmärgipärase kasutamise tagamine |
|
Tegelikult ei ole need kas meetmete kompleksi siiski nii eraldatud nagu eelnevalt näidata püüti – süsteem ei saa toimida, kui tema töövõime pole tagatud, toimimine aga annab suure osa infot süsteemi töövõime kohta. |
|
|
Töövõime ja toimimine |
|
1.3. Tegevused andmebaaside haldamisel |
|
|
|
|
Erinevat tüüpi tegevusi, mida tehakse andmebaaside haldamisel, on palju ja vaevalt, et neid kõiki õnnestukski kellegi üles lugeda – elu on nii mitmekülgne, et selle kõiki tahke kirjeldada ei ole võimalik ja see oleks ka täiesti mõttetu. Siiski on võimalik andmebaaside haldamisel tehtavatest tegevustest eraldada see osa, ilma milleta andmebaaside haldamisel läbi ei saa. Järgnevalt ongi kirjeldatud neid tegevusi grupeerituna taotletava eesmärgi lõikes. |
|
|
|
|
1.3.1. Jälgimine |
|
|
|
||
|
Erinevat tüüpi tegevusi, mida tehakse andmebaaside haldamisel, on palju ja vaevalt, et neid kõiki õnnestukski kellegi üles lugeda – elu on nii mitmekülgne, et selle kõiki tahke kirjeldada ei ole võimalik ja see oleks ka täiesti mõttetu. Siiski on võimalik andmebaaside haldamisel tehtavatest tegevustest eraldada see osa, ilma milleta andmebaaside haldamisel läbi ei saa. Järgnevalt ongi kirjeldatud neid tegevusi grupeerituna taotletava eesmärgi lõikes. |
|
|
Jälgimine kui halduse alusmüür |
||
|
Andmebaasisüsteemi jälgimine peab kindlustama teabe andmebaasisüsteemi töövõime seisundi kohta – millised andmebaasisüsteemi ressursid töötavad ilma probleemideta, millised ressursid võivad lähemas või kaugemas perspektiivis probleeme tekitada (ammenduda, tõrkuda või rikneda) ja millised ressursid on riknenud. Samuti tuleb võimalikult täpselt registreerida andmebaasisüsteemi töö kõik juhuslikud ja süstemaatilised (regulaarsed) tõrked. Kogu saadav informatsioon tuleb süstematiseerida ja selle alusel teostada analüüs, mille eesmärgiks on tulevikutegevuste määramine. Loomullikult on ka sellist jälgimisest saadavat informatsiooni, mille sügavam analüüsimine ei oma mingit mõtet, sest juba jälgimise andmetest on aru saada, et mingi ressurss on lakanud töötamast või on tema tõrkeid liiga palju. |
|
|
|
||
|
Kogu jälgimise protsess on ehitatud üles peamiselt kahele meetodile: töövõime teatamisele või töövõime pärimisele. Esimesel meetodi korral teatab ressurss ise jälgivale protsessile teatava ettemääratud regulaarsusega oma töövõime parameetrid. Kui teade jääb ettenähtud ajal tulemata, siis klassifitseeritakse asi tõrkeks, kui aga teadete saabumine lakkab üldse (saabumata jääb määratud arv järjestikuseid teateid), siis klassifitseeritakse asi rikkeks. Teise meetodi korral küsitakse ressursilt ettemääratud regulaarsusega tema töövõime parameetreid. Kui ressurss ei vasta klassifitseeritakse asi tõrkeks, kui ressurss lõpetab vastamise üldse (vastamata jääb ettemääratud arv järjestikuseid teateid), siis klassifitseeritakse asi rikkeks. |
|
|
Teatamine ja pärimine
Tõrge ja rike |
||
|
On võimalik ka ressursi töövõimetus ilma tõrke või rikketa. Sellistel juhtudel on tegemist mingi ressursi töös normaalse, kuid toimimise mudelis ebanormaalse juhtumiga. Näiteks seisak on see, kui andmebaasisüsteemi serveris saavad täis kõik ketasmälud – ressurss ise on küll korras, kuid tema töövõimet piirab tema ühe olulise alamressursi ammendumisega. Seisakud on ressursi seisundid, mis ressursi enda seisukohalt vaadatuna normaalsed (lubatavad), ressursi töövõime seisukohalt aga ebanormaalsed. Jälgimise üks ülesandeid ongi ennetada ka selliseid seisakuid ja täiendada aegsasti uuendamist vajavaid ressursse. Kui jälgimine ja jälgimistulemustele reageerimine on korrektselt korraldatud, siis seisakuid ei tohiks tekkida. Loomulikult on võimalik, et mingit täiendatavat ressurssi ei õnnestu teatavate süsteemi väliste tegurite kokkulangemise tõttu lihtsalt hankida. |
|
|
Töövõimetus ilma tõrke või rikketa
Seisak |
||
|
Kogu jälgimisest saadava informatsiooni analüüs toimub kolmel erineval tasemel. Esmane analüüs teostatakse automaatselt, vastavalt ettekirjeldatud reeglitele. Nende reeglitega kirjeldatakse situatsioonid, mis tähendavad olulisi tõrkeid ja rikkeid. Need on situatsioonid, millest antakse koheselt teada süsteemi jälgijatele (dispetšeritele) ja nendele teadetele tuleb koheselt reageerida meetmega tõrgete, seisakute või rikete kõrvaldamiseks. Selliste teadete eiramine võib põhjustada kas rikke või seisaku lähemas tulevikus. Sellised teated võivad muidugi olla põhjustatud tekkinud rikkest. Ka sellisel juhul on kohene reageerimine muidugi vältimatu. Näiteks on selline teade mingi võrguseadme rikkest või mingi andmebaasi mootori töötamast lakkamise kohta. |
|
|
Esmane analüüs – toimunud sündmustest teavitamine |
||
|
Ka teise taseme analüüs teostatakse automaatselt vastavalt kirjeldatud reeglitele. Sellesse gruppi kuuluvad hoiatused võimalikest tulevikus toimuvatest seisakutest. Näiteks sellest, et rahaautomaadis hakkab raha lõppema või mingi serveri ketta maht ammenduma. Need hoiatused analüüsitakse välja tavaliselt mingi defineeritud kriitilise piiri ületamise avastamise tulemusena. |
|
|
Teise taseme analüüs – tuleviku sündmuste „ennustamine“ |
||
|
Kolmanda taseme analüüs toimub juba n.ö. käsitsi. Ainult ettevalmistustööd tehakse analüüsisüsteemi poolt – grupeeritakse andmed vastavalt määratud grupeerimisreeglitele ja esitatakse koonditena. Edasine töö jääb juba spetsialistide teha. Nii näiteks jälgitakse töös olevate seadmete tõrkeid ja nende samas kohas kuhjumisel planeeritakse sinna remont vms. Siin on võimalik rakendada täiesti tavalisi andmekaevandusvahendeid, millega otsitakse seoseid ja mustreid äriandmetes. |
|
|
Kolmanda taseme analüüs – seoste ja mustrite otsimine |
||
|
Kõik andmebaasisüsteemide töövõime jälgimisest saadud andmed logitakse olenemata sellest kui ohtlikud või mitteohtlikud “tunduvad” need andmed automaatsele analüüsisüsteemile - ka tagant järele peab olema võimalik uurida andmebaasisüsteemide jälgimisest tekkinud mistahes infot. See võib osutuda vajalikuks siis, kui mingi välja analüüsitud ohusituatsiooni uurimiseks on vaja tuvastada teiste, antud probleemiga otseselt mitte seotud, kuid võimalikult mõjutatavate ressursside toimimise teateid intsidendi toimumise ajal. |
|
|
Jälgimise andmete logimine |
||
|
Jälgimise andmete süstematiseerimise ja analüüsi tulemusena ettevõetavad tegevused võib laias laastus jagada järgmiselt |
|
|
|
||
|
a) |
|
seadme (riistvara) töövõime tuvastamine (võrguseadmed, printerid, kaugterminalid, automaadid, (andmebaasi)serverid, varundusrobotid jms.) |
|
|
|
|
b) |
|
programmi töövõime tuvastamine (andmebaasisüsteem, ressursi haldaja, andmevahetussüsteem, WEB-server, FTP-server, automaadi teenindusprogramm, jms.) |
|
|
|
|
Andmebaasisüsteemide jälgimine toimub tegelikult ka kaudsete vahenditega – töötajad, kes infosüsteemiga iga päev töötavad märkavad kindlasti, kui infosüsteemi käitumises midagi muutub. Lisaks sellele võivad ilmneda vead ja ebatäpsused infosüsteemi funktsioneerimises, mida ei olegi kuidagi võimalik analüüsida, mida aga oma töises tegevuses märkavad süsteemi kasutajad. Ka selliste juhtumite registreerimise ja neile reageerimise metoodika ja toimimise mehhanism peab olema liidetud infosüsteemi jälgimise automaatsete andmise kogumisega. |
|
|
|
||
|
Pole vahet, kuidas saadakse informatsiooni andmebaasisüsteemide töövõimest, oluline on see talletada, süstematiseerida ja analüüsida. Analüüsi alusel tuleb võtta aga vastu otsused edasiseks toimimiseks. |
|
|
|
||
|
Oluline on mõista, et andmebaasiserverite ja andmebaasisüsteemide jälgimine ei ole midagi eraldi seisvat võrrelduna muu infosüsteemi jälgimisega, kuna infosüsteemi osad on üksteisega väga tihedalt seotud ja üks pisike viga, häire vms. ühes kohas võib tekitada palju suuremaid vigu mitmes teises kohas. |
|
|
|
||
|
1.3.2. Loomine |
|
|
|
|
Igasuguste ressursside haldamine (kaasaarvatud andmebaaside adminnistreerimine) algab selle ressursi loomisest.. |
|
|
Töövõime vs. toimimine |
|
Töövõime tagamine tähendab seda, et plaanipäraste meetmete rakendamisega tagatakse andmebaasi tööks vajaliku riistvara ja tarkvara korrektne (lubatud piirides tõrgetega) töö ning riistvara arendamine ja tarkvara korrigeerimine vastavalt infosüsteemi funktsionaalsetele vajadustele ja esitatud nõuetele. Tegemist on siis puhtalt füüsilise korrektsusega – tagatakse andmebaasisüsteemide ja andmebaaside tõestatud valmidus selleks et neid oleks võimalik kasutada. See kas neid keegi üldse kasutab ei ole siin kohal oluline. Oluline on ainult see, et kogu süsteem funktsioneeriks laitmatult. |
|
|
Töövõime – tarkvara ja riistvara korrektne toimimine |
|
Toimimise tagamine peab kindlustama andmebaasi tõrgeteta, eesmärgipärase kasutamise. Selles meetmete komplektis on need tegevused, mis tagavad andmebaasisüsteemides säilitatavate andmete juurdepääsu ja vajalike tegevuste õigeaegse käivitamise. See, kas süsteem, mille toimimist tagatakse on üldse töövõimeline pole siin kohal oluline. Oluline on ainult see, et oleks tagatud need toimingud, mis tagavad andmebaaside toimimise. |
|
|
Toimimine - eesmärgipärase kasutamise tagamine |
|
Tegelikult ei ole need kas meetmete kompleksi siiski nii eraldatud nagu eelnevalt näidata püüti – süsteem ei saa toimida, kui tema töövõime pole tagatud, toimimine aga annab suure osa infot süsteemi töövõime kohta. |
|
|
Töövõime ja toimimine |
|
1.3.3. Ennetamine ja taastamine |
|
|
|
||
|
Jälgimisest kogutud andmete analüüsi alusel tehtavad tegevused võib nende tegevuste toimumise aja ja toimunud või võimalikult toimuva rikke, tõrke või seisaku aja suhtes jagada kahte rühma:. |
|
|
Ennetamine v.s. taastamine |
||
|
a) |
|
ennetavad tegevused – need on tegevused, kus võimalik rike seisak või tõrge õnnestub jälgimise tulemusena selgitada välja enne selle tegelikku toimumist ja seega ka kõrvaldada selle tekkimise põhjus enne sündmuse toimumist. |
|
|
Ennetamine |
|
b) |
|
taastamistegevused – on tegevused, mis tehakse rikke, seisaku või tõrke tõttu tekkinud situatsiooni korrastamiseks (rikkele eelneva situatsiooni taastamiseks kõrvaldades ühtlasi rikke tekkimise põhjuse, kui selline veel eksisteerib) pärast seda, kui sündmus on juba toimunud. |
|
|
Taastamine |
|
Jälgimise eesmärk on suurendada ennetavate tegevuste osakaalu ja vähendada taastamistegevuste osakaalu. Ennetavad tegevused on alati odavamad kui taastamistegevused. Kui ka mõlemad tegevused nõuavad ehk sama palju ressursi kulu on esimesel juhul alati kokku hoitud selle kahju arvelt, mida põhjustab töövõimetu või osaliselt töövõimeline ressurss |
|
|
Ennetamise
maksimeerimine |
||
|
1.3.4. Korrigeerimine, täiustamine, ennistamine ja asendamine |
|
|
|
|
Analüüsi tulemusel planeeritavad kas ennetamis- või taastamistegevused tegevused võib jagada nelja erinevasse gruppi: korrigeerimine, täiustamine, ennistamine ja asendamine. . |
|
|
Tegevuste liigid |
|
Korrigeerimistööd võetakse ette juhul, kui mingi ressurss töötab valesti, kuid seda mitte selle pärast, et ta on valesti koostatud või on ta täielikult või osaliselt riknenud vaid seetõttu, et tema mingid häälestusparameetrid on määratud valesti. Sellisel juhul piisab ressursi töövõime taastamiseks valede parameetrite korrigeerimisest.. |
|
|
Korrigeerimine |
|
Täiustamine võetakse ette juhul, kui süsteemi töövõime on häiritud see tõttu, et mingi ressurss on komplekteeritud puudulikult selle funktsiooni täitmiseks, milleks ta on ette nähtud. Sellisel juhul tuleb võtta ette täiustustustööd, mille käigus ressursi komplektsus muudetakse vastavaks vajadustele. Selline ressurss ei pruugi olla valesti koostatud kohe esialgselt vaid ta võib olla selliseks muutunud arengu käigus arengule „jalgu jäädes“. |
|
|
Täiustamine |
|
Ennistamine võetakse ette juhul, kui mingi ressurss on kaotanud oma töövõime ja selle põhjuseks on ressursi komplektsuse ja seetõttu ka töövõime kahjustumine. Sellisel juhul taastatakse ressurss kahjustuste eelses seisus ja kõrvaldatakse kahjustumise põhjus, kui see peaks veel eksisteerima. |
|
|
Ennistamine |
|
Asendamine võetakse ette siis, kui avastatakse ressurss, või alamressurss, mis oma olemuselt on sobimatu ja kas pärsib või halvab süsteemi töövõime täielikult. Selline ressurss ei pruugi jällegi olla valesti koostatud kohe esialgselt vaid ta võib olla selliseks muutunud arengu käigus „ajale jalgu jäädes“. Asendamise põhjuseks võib muidugi halvemal juhul olla ka ressursi riknemine. |
|
|
Asendamine |
|
1.3.5. Varundamine, kindluskoopiad ja muutuste logid |
|
|
|
|
Kindluskoopia on tarkvaravahendite seisu koopia, mille kohta on teada koopia täpne tegemise aeg ja kopeeritud tarkavarkogumi sisukord. Kindluskoopia võimaldab taastada riistavarale paigaldatud tarkvara seisu kindluskoopia tegemisele vahetult eelneva seisuga. |
|
|
Koopia teada oleva sisukorra ja tegemise ajaga |
|
Kindluskoopia tehakse alati eelnevalt määratletud tarkvara kogumist (programmid ja/või andmed) ja seejuures regulaarselt, kindla metoodika järgi. Kindluskoopiaid tehakse alati seeriana. Kui kopeeritav tarkvarakogum muutub harva, siis piisab kindluskoopia tegemisest iga kord pärast muutust. Kui tarkvara kogum muutub pidevalt, siis on kindluskoopiatest seda rohkem kasu, mida tihedamini neid tehakse. Siiski on harva selliseid kindluskoopiaid, mida tehakse sagedamini, kui kord ööpäevas. |
|
|
Regulaarselt tehtav |
|
Tavaliselt kasutatakse kahte erinevat tüüpi kindluskoopiaid – täiskoopia (full-backup) ja muudatuste koopia (incremental backup). Täiskoopia puhul varundatakse iga kord kogu määratletud tarkvara kogum. Uuenduste kindluskoopia puhul aga varundatakse muudatused viimase täiskoopia suhtes. Kogu kindluskoopiate süsteem võib olla üles ehitatud täis-koopiatele. Sellisel juhul tehakse iga kord koopia kogu varundatavast tarkvarakogumist. Ainult muudatuste koopiatele varundussüsteemi üles ehitada ei saa. Muudatuste koopiaid saab teha ainult mingi täiskoopia suhtes. Uuenduste kindluskoopiasse kantakse ainult muutused, mis on toimunud pärast eelmise kindluskoopia tegemist. Sellisel juhul tuleb tarkvara hävimise puhul taastada seis viimasest täis-koopiast ja seejärel uuendada seda kõikide sellele järgnevate uuenduste koopiatega. Et vältida taastamise ebamugavust ei tohiks täiskoopiaid teha liiga harva – näiteks mitte harvemini kui kord nädalas. |
|
|
Täiskoopia vs muudatuste koopia |
|
Nagu öeldud, ainult muudatuste koopiatele varundamist üles ehitada ei saa. Paraku on tänapäeval andmete maht aga tihti juba liiga suur ja kasutada oleva ajaga pole enam võimalik täiskoopiat teha. Sellisel juhul tehakse viimasest täiskoopiast ja talle järgnevatest muudatuste koopiatest uus täiskoopia n.ö. Off-line's. See tähendab on olemas tarkvarad, mis võimaldavad võtta täiskoopia ja “liita” temaga järgnevad uuenduste koopiad saades nii uue täiskoopia. |
|
|
Kombineeritud koopia |
|
Kindluskoopiate tegemine on kohustuslik. Tavaliselt saadakse sellest aru siis, kui esimest korda selgub, et seda oleks väga vaja. |
|
|
Varundamine on kohustuslik! |
|
1.3.6. Litsentsihaldus |
|
|
|
|
Vaimse omandi õiguse kaitse on iga infotehnoloogi seisukohalt väga tähtis asi – teiste tehtud tööd ja õigust selle töö pealt raha saada tuleb austada. Seda kas või juba sellepärast, et iga infotehnoloogi endagi töö on kas või mingilgi määral seotud vaimse omandiga. Enda omandit kaitseb iga üks kiivalt (olgu see siis kas materiaalne või vaimne), miks mitte mõista siis ka teist püüdlusi enda omandi kaitsel. |
|
|
Vaimne omand ja selle kaitse |
|
Enamik kasutatavat tarkvara on litsentseeritav see tähendab, et selle kasutamise eest tuleb selle omanikule maksta litsentsi tasu. Andmebaaside litsentsi tasu on üldjuhul seotud andmebaasimootorit kasutavate töötajate arvuga, tarkvara installatsioonide arvuga ja serveri protsessorite arvuga. Nende kahe arvu vahel on vahe sees – esimene ütleb, mitu kasutajat võib antud litsentsi alusel andmebaasimootorit kasutada, teine ütleb, mitmele serverile võib antud andmebaasimootori installeerida ja kolmas seda, mitmel protsessoril tohib seda tarkvara “jooksutada”. Näiteks kui firma on ostnud ühe protsessori andmebaasimootori ühe installatsiooni litsentsi 15 kasutaja jaoks, siis ei ole tal õigust seda sama andmebaasimootorit teise kohta installeerida, kuigi selles esimese kohas töötab süsteemiga ainult 7 inimest ja teises kohas hakkas tööle veel 6 inimest – kasutajate litsentside arv ei ole küll saavutatud, küll aga installatsioonide arv. |
|
|
Litsentsi
tasu |
|
On võimalik ka litsentseerimispoliitika, kus litsentsid kinnitatakse konkreetsete kasutajatega ja vaatamata selle, et need konkreetsed kasutajad mingil ajahetkel andmebaasi ei kasuta, ei saa teised kasutajad selle baasi poole pöördumisi teha, kuna nemad ei kuulu sellesse ringi, kelle litsentsid on kinnitaud. Selliseid litsentse nimetatakse nimelisteks litsentsideks. Kui nimelist litsentsi tahab hakata kasutama mingi teine kasutaja, siis peab andmebaasi administraator võtma ühel seniselt litsentsi omanikult õigused ja andma need teisele. Loomulikult on alati võimalik ka litsentse juurde osta. |
|
|
Nimelised litsentsid |
|
Nii kummaline kui see ka tunduda võib olla oluliseks ka serveri protsessori maksimaalne taktsagedus, millele andmebaasimootor on litsentseeritud. |
|
|
Litsents protsessori taktsagedusele |
|
Kuna litsentsita tarkvara kasutamine võib kaasa tuua suured trahvid on äärmiselt oluline pidada arvestust erinevate tarkvarade lõikes litsentside arvu ja nende tarkvarade kasutajate arvu üle. Litsentside arvu üle arvet pidada on lihtne – on ju teada, kui uusi litsentse ostetakse ja uute litsentside ostmisel tuleb lihtsalt teha märkused litsentside registrisse, mis võib olla nii elektrooniline kui ka paberil. |
|
|
Arvestuse pidamine olemasolevate ja kasutuses olevate litsentside üle |
|
Süsteemi iga olulise parameetri muutumisel (kasutajate arv, protsessorite arv, taktsageduse muutus) tuleb üle vaadata, kas muudatus ei ole kuidagi läinud vastuollu litsentsitingimustega. |
|
|
Litsentside kasutuse üle vaatamine |
|
Litsentse tuleb osta suuremate komplektidena ja perspektiiviga ette poole – see tuleb odavam. Enamikel tarkvaramüüjatel on sooduslepingud (Näit: MOLP) suuremate koguste litsentside ostmiseks. Neid on väga erinevate koguste ja väga erinevate soodustuste tasemega. Selleks, et osta firma jaoks vajalikud litsentsid võimalikult soodsalt, tuleb enne litsentside ostmist teha litsentside vajaduse plaan ja sobitada see pakutavate sooduslepingutega. |
|
|
Litsentside ostude optimeerimine |
|
Loomulikult on olemas ka vabavara, mida võib kasutada tasuta ja kohtades, kus seda saab teha, tulebki seda kasutada – see muudab infosüsteemi maksumuse oskuslikult kasutamisel odavamaks. Siiski hoitakse siin tavaliselt kokku vaid tarkvara litsentside maksumus. Alles jäävad kõik hooldus ja koolituskulud. |
|
|
Vabavara |
|
1.3.7. Pakett-töötlus andmebaasides |
|
|
|
|
Igal infosüsteemil on teatav hulk tegevusi, mis ei ole seotud konkreetselt ühegi töötaja tegevustega vaid süsteemi globaalsete tegevustega. Näiteks toimub pangas igal öösel päeva lõpetamine, kuu viimasel ööl kuu lõpetamine aj aasta viimasel ööl aasta lõpetamine. Selliste operatsioonide olemasolu infosüsteemides on täiesti tavaline. Seejuures ei ole need kõik sugugi ainult öösel tehtavad palju on ka selliseid tegevusi, mida tuleb teha kindlal kellaajal – olenemata sellest, kas on öö või päev, tööpäev või puhkepäev. Osa nendest tegevustest on vaja käivitada täpselt mingil kellaajal osa pärast mingi teise (või teiste) toimingute toimumist, osa aga lihtsalt mõnest elu sündmusest tingituna. |
|
|
Protsesside
käivitamine konkreetsel kellaajal |
|
Kõigil tegevustel, mida klassifitseeritakse kui “pakett-töötluse” tegevusi on üks ühine omadus. Nad käivitatakse mingite algandmetega, nad töötavad ilma et neile saaks vahele segada ja nad lõpetavad oma töö kas edukalt või edutult. Seda aga, millise tulemusena protsess jõuab ei saa kuidagi interaktiivselt mõjutada. |
|
|
Protsesside mõjutamatus |
|
Infosüsteemi seisukohalt vaadatuna on sellised tegevused väga olulised ja mõne sellise ära unustamine võib tuua kaasa tõsiseid tagajärgi. Seepärast tuleb kõikide selliste tegevuste kohta pidada registrit ja igal sellisel tegevusel peab olema ka vastutaja, kes peab tagama selle protsessi toimumise. |
|
|
Pakkett-töötluse eest vastutajad |
|
Kõikide selliste protsesside toimumine või mittetoimumine tuleb logida. Logida tuleb ka toimumise tulemuse – kas oli edukas toimumine või ebaedukas toimumine ja kui oli ebaedukas, siis milline oli lõpetamise veakood. Vigadega lõpetanud tegevustest tuleb kohestelt teatada dispetšerile ja/või protsessi eest vastutajale, kes peavad tagama tegevuse toimumise. |
|
|
Pakkett-töötluse logimine ja veakäsitlus |
|
1.3.8. Tegevuste registreerimine ja kontroll |
|
|
|
|
Mida suurem on infosüsteem, seda suurem on võimalus, et mõni volitatud kasutaja teeb seal mingisuguseid lubamatuid tegevusi. Seda ei saa kuidagi vältida. Võimalik on aga registreerida kõik andmebaasides toimuvad tegevused koos tegevuse tegija tunnuse ja tegevuse parameetritega ja analüüsida neid andmeid. Võrreldes töötaja poolt tehtud tegevusi ja konkreetsete tegevuste tegemise statistikat töötajate ametialaste ülesannetega võib avastada nii mõndagi sellist, mis ei sobi hästi kokku konkreetse töötaja tööalase tegevusega (liiga laiaulatuslikud päringud, konkreetsete raportite liiga sage vaatamine, raportite piiramine liiga tihti samade, kuid ametikoha seisukohalt ebaoluliste filtritega jne). |
|
|
Tegevuste registreerimine ja analüüs |
|
Selliseid analüüse ei saa teha muidugi käsitsi. Selleks on olemas spetsiaalne (ja väga kallis) tarkvara, mis tavaliselt pakuvad välja ka analüüsi metoodikad. |
|
|
Analüüsivahendite kasutamine |
|
Tegevuste registreerimine kannab ka teist kuid eelpool kirjeldatule suhteliselt lähedast eesmärki. Süsteemi volitatud kasutajad võivad teha ka omakasupüüdlike tehinguid. Neid ei ole tavaliselt võimalik avastada mingi analüüsi käigus (kui need tegevused pole just liiga sagedased). Sellised tegevused võivad selguda aga suhtluses partnerite ja klientidega ning erineva aruandluse koostamisel. Sellise lubamatu toimingu avastamisel on registreeritud andmetest hea vaadata, kes sellega hakkama sai. |
|
|
Tagant järele kontroll ja tuvastamine |
|
Siin tuleb märgata vahet lihtsa andmete muudatuste logi ja süsteemi tegevuste registreerimise vahel. Andmete muudatuste logi registreerib ainult andmete muutused süsteemis. Süsteemi tegevuste registreerimisel registreeritakse mistahes süsteemis tehtud tegevus koos selle tegevuse parameetritega, olenemata sellest, kas tegevus muutis andmete kooseisu või ainult luges baasist andmeid. |
|
|
Muudatuste logi vs. tegevuste logi |
|
1.3.9. Andmebaasiadministraatori (DBA) tegevuste registreerimine |
|
|
|
|
Andmebaasiadministraator peab protokollima kõik oma tegevused, mida ta on teinud andmebaasisüsteemide ja andmebaaside haldamisel. Iga tegevus (üks kõik kui tühine see asi tundub) peab olem protokollitud kuupäeva ja kellaajaliselt. Hea oleks kui seda kõike logiks infosüsteem ise automaatselt – sellisel juhul ei unune midagi olulist ära. Paraku ei ole see alati võimalik. Sellisel juhul peab seda kõike tegema „käsitsi“. |
|
|
DBA tegevuste registreerimine |
|
Sellisel viisil moodustuvad “päevikud” peavad olema süstematiseeritud serverite ja andmebaaside kaupa – lihtsalt peab olema vaadatava see, mida ühe või teise andmebaasiserveri või andmebaasiga on tehtud. |
|
|
Administraatori „päevikud“ |
|
ERITI OLULISED ON PROTOKOLLIDA NEED TEGEVUSED, MIS MUUDAVAD KAS ANDMEBAASISERVERI, ANDMEBAASISÜSTEEMI või ANDMEBAASI KONFIGURATSIOONI VÕI PARAMEETREID. |
|
|
Konfiguratsiooni ja parameetrite muudatuste logimine |
|
See võimaldab vigade tekkimisel lihtsamalt selgitada välja need muudatused, mis vigade tekkimiseni viisid ja need vead kiiresti kõrvaldada või muudatused kuni vea selgitamiseni tagasi võtta. . |
|
|
Vigade kõrvaldamine või muudatuste tagasi võtmine |
|
KASULIKUD LINGID |
|
|
|
|
http://www.ibm.com/support/documentation/us/en/?cm_re=masthead-_-supdl-_-documentation |
|
|
IBM TIVOLI juhendid |
|
|
|
HP
OpenView juhendid |