3. ANDMEBAASIADMINISTRAATORI TEGEVUSED JA TÖÖVAHENDID

3.1. Andmebaasiadministraatori töö olemus

Andmebaasiadministraator on oma ametikohutustest tingituna “sunnitud” tegema erinevaid tegevusi. On äärmiselt vale arvata, et andmebaasi administraatori tegevused on seotud ainult administreeritava andmebaasi vahetu häälestamise, kontrollimise (jälgimise), andmestruktuuride, trigerite ja protseduuride muutmise, kasutajate haldamise jms. Andmebaasiadministraatori tegevuste koosseisu kuulub lisaks sellistele tegevustele vee hulgaliselt tegevusi mis ei ole nii vahetult seotud konkreetse andmebaasi või andmebaaside haldamisega. Sellisteks tegevusteks on näiteks enese täiendamine, erinevate metoodiliste plaanide välja töötamine, töögraafikute koostamine, suhtlemine andmebaasisüsteeme tootvate firmadega, kasutajate probleemide väljaselgitamine jne.

Andmebaasiadministraatori töö mitmekülgsus

Olenemata nende tegevuste laiahaardelisusest ja suhteliselt erinevast iseloomust on pea kõigi nende läbi viimisel vaja metoodilist lähenemist ja mingite kindlate vahendite kasutamist. Sõltuvalt tegevuse iseloomust peab tegevuse teostamise vahend tihti olema spetsiaalne programm. Seda just sellistel juhtudel kus tegemist on tegevusega, mis nõuab vahetut suhtlemist andmebaasiga – andmebaasi jälgimine, andmestruktuuride muutmine, andmebaasi häälestamine, protseduuride kirjutamine, kasutajate ja kasutajagruppide haldamine jms. Paljudel juhtudel ei ole siiski nii – on mitmeid tegevusi, mida saab “häda korral” teha ka “paberi ja pliiatsiga”. Ise asi on see, kas seda on ka mõtet teha, kuna näiteks Excel ja Word (või mingid muud kontoritarkvarad) on “paberist ja pliiatsist” mitu korda etemad.

Töö tsüklilisus ja metoodilisus

Kontoritarkvara kasutamine

Olenevalt hallatava andmebaasi komplekssusest on andmebaasi haldamise tegevuste teostamisel mõttekas kasutada erineva “võimsusega” vahendid – keeruliste ja mahukate andmebaaside haldamisel peaksid ka haldamise vahendid olema nüansikamad ja komplekssemad  ning lihtsamate ja vähemmahukate andmebaaside haldamisel  jällegi lihtsamad.

Õigete vahendite valik

Ei ole mingit mõtet raisata raha kalliste haldamisvahendite ostmiseks, kui hallatava andmebaasi on  lihtne, väike, vähese kasutajate arvuga, väikese transaktsioonide arvuga ja ei esita mingeid erilisi nõudeid käideldavuse kõrge taseme (high-availability) seisukohalt. Samas kui mõni nendest kirjeldatud keerukuse tasemetest hakkab kas mahtude suuruse või struktuuride keerukuse poolest ületama mingit “taluvuse piiri”, siis tuleb mõelda konkreetse ressursi haldamiseks kas tarkvara ostmist või siis ka ise kirjutamist. Paljudel juhtudel piisab tõepoolest “kriisi” lahendamiseks näiteks mingi väikese Access-rakenduse kirjutamisest.

Vahendite valik sõltuvalt teostatavate tööde mahust

Käesolevas loengumaterjalis vaadeldaksegi andmebaasiadministraatori erinevaid töiseid tegevusi ja analüüsitakse andmebaasiadministraatori vajadusi erineva tarkvara kasutamiseks erinevate andmebaaside administreerimise tegevuste läbi viimisel ja nende tarkvaravahendite “võimsust” sõltuvalt  teostatava tegevuse mahukusest või keerukusest.

Loengu eesmärk

Ees pool mainitud “paberi ja pliiatsi” rakendamise näidet ei tasu siiski väga tõsiselt võtta – jah see on küll paljudel juhtudel võimalik, kuid siiski tuleks sellistel juhtudel rakendada mõnda “elektroonilist paberit ja pliiatsit”. See teeb võimalikuks nii mõnegi tegevuse mida tavalise “paberi ja pliiatsi puhul ei saa teha – kindluskoopiad, materjalide võrgus levitamine, materjalide täiendamine mitmest kohast jms.

Elektrooniliste vahendite eelistamine

Selleks et midagi kahe silma vahele ei jääks, vaatleme andmebaasiadministraatori poolt kasutatavaid vahendeid andmebaasiadministraatori oskuste ja tegevuste lõikes. Et midagi olulist andmebaasi administraatori oskuste ja  tegevuste hulgas mitte ära unustada, on toodud loendi aluseks võetud raamatus “Oracle Database Administration, The Essential Reference” (David C. Kreines, Brian Laskey). Seda loendit on täiustanud vastavalt omadele kogemustele ka loengukonspekti autor.

Oracle Database Administration, The Essential Reference” (David C. Kreines, Brian Laskey).

3.1. Andmebaasiadministraatori teadmised

Kõik algab teadmistest – selleks et teha oma ametiülesannetega määratud tegevusi peab andmebaasiadministraator oma ma teatavat “kriitilist massi” teadmisi, ilma milleta tal ei ole võimalik omada terviklikku pilti andmebaasidest ja nende administreerimisest. Seda enam aga konkreetse andmebaasisüsteemi konkreetse eksemplari administreerimisest.

Kõik algab teadmistest

Kuna andmebaaside administreerimine (eriti suurte – Oracle, Sybase DB2 jms.) on muutunud üha spetsiifilisemaks, siis on siingi valdkonnas levimas spetsialiseerumine. Seepärast on enamik teadmisi konkreetse tootja andmebaasisüsteemi kesksed.

Erinevate tootjate andmebaaside administreerimine on täiesti erinev

Minimaalne “komplekt” andmebaasiadministraatori teadmisi on järgmine:

Minimaalsed teadmised

●

Andmete modelleerimise põhimõtete tundmine ja andmemudelite kirjelduste (ERD) lugemise oskus

ERD lugemise oskus

●

Andmebaasisüsteemide üldiste põhimõtete tundmine. Klient/teenindaja (Client/Server) arhitektuuri tundmine.

Üldised loogikad

●

Konkreetse andmebaasisüsteemi mälustruktuuride ja andmebaasisüsteemi poolt teostatavate  protsesside ning protsessi-loogikate tundmine

Mälustruktuuride ja protsessiloogika tundmine

●

Konkreetse andmebaasisüsteemi loogiliste ning füüsiliste struktuuride tundmine

Loogilised ja füüsilised struktuurid

●

Konkreetse andmebaasisüsteemi häälestusvõimaluste tundmine

Andmebaasi häälestamine

●

DDL (Data Description Language) – konkreetse andmebaasisüsteemi andmekirjelduskeele tundmine. Näiteks CREATE TABLE, CREATE INDEX , CREATE PROCEDURE jms. Korraldused SQL-andmebaasides.

Andmestruktuuride kirjeldamine

●

DML (Data Manipulation Language) – konkreetse andmebaasisüsteemi andmete manipuleerimiskeele tundmine (INSERST-, UPDATE- ja DELETE-lause)

Andmetega manipuleerimine

●

DQL (Data Query Language)– konkreetse andmebaasisüsteemi päringukeele tundmine (SELECT-lause)

Päringud

●

Konkreetse andmebaasisüsteemi protseduur-keele tundmine - trigerite, funktsioonide, pakettide, protseduuride jms. Loomiseks (Näiteks Sybase ja MS SQLServer – Transact-SQL, Oracle – PL/SQL)

Protseduur-keelte tundmine

●

Jaotatud andmebaaside käsitlemise üldiste loogikate ja meetodite tundmine. Replikatsioonide ja MQ-loogikate (Message Queueing) tundmine

Jaotatud andmebaasid ja nende vahelised sünkronisatsioonid

●

Konkreetse andmebaasisüsteemi jaotatud arhitektuuri (distributed architecture) tundmine *)

Kasutatavate jaotatud arhitektuuri vahendite tundmine

●

Andmete lukustusmetoodikate üldise loogika tundmine

Andmete lukustamise üldised metoodikad

●

Konkreetse andmebaasisüsteemi lukustusmehhanismide tundmine

Konkreetse toote lukustusmetoodika

●

Andmebaaside varunduspõhimõtete ja protsessiloogikate tundmine

Andmebaaside varundamine

●

Nende operatsioonisüsteemide tundmine, mille keskkonnas andmebaasisüsteem töötab. Mõistmine, kuidas konkreetne operatsioonisüsteem mõjutab tema keskkonnas töötava konkreetse andmebaasisüsteemi tarkvara toimimist.

Operatsioonisüsteemide tundmin

*) Igal andmebaasisüsteemil ei ole jaotatud arhitektuuri olemas. Alati võib kasutada ka mingi “kolmanda tootja” jaotatud arhitektuuri loomise toodet. Konkreetses rakenduses võib jaotatud arhitektuur ka üldse puududa.

3.2. Turvalisusega seotud tegevused ja nende realiseerimise vahendid

Turvalisusega seotud tegevused võib jagada neljaks suuremaks grupiks – üldine planeerimine, kasutajagrupide loomine ja nende õiguste kirjeldamine, kasutajate loomine ja nende personaalsete õiguste kirjeldamine, kasutajate poolt tehtavate toimingute seire.

Turvatoimingute erinevad liigid

Üldise planeerimise alla kuuluvad turvalisusega seotud mudelite ja metoodikate välja töötamine – kasutajarollide struktuuri planeerimine, privileegide (õiguste) süsteemi välja töötamine ja autentimise strateegia loomine. Loomulikult kuulub selle tegevusvaldkonna alla ka välja töötatud mudelite haldamine/muutmine.

Kasutajagrupid, kasutajad ja kasutajate tegevuste seire

Igasugust planeerimist tuleb alustada mudelite koostamisest – see tagab loodava süsteemi ülevaatlikkuse ja mis peamine – jätkusuutliku arengu tulevikus. Planeerimisel on vaja joonistada nii diagramme kui kirjutada selgitavaid tekste loodud diagrammide juurde. Seega on siin vajalik nii mõni diagrammide joonistamise süsteem (näiteks MS Visio) ja ka tekstitöötlussüsteem (näiteks Word või Open Office). Millede koostööna vormistatakse arhitektuuri dokumendid. Oluline on just kasutada diagrammide joonistamiseks mingit selleks spetsiaalselt ettenähtud süsteemi, kuna see muudab mudelite haldamise tulevikus oluliselt hõlpsamaks.

Protsesside modelleerimine kui selline

Õiguste süsteem on tavaliselt infosüsteemi keskne – igal infosüsteemil on tavaliselt oma privileegide komplekt, mille kaudu saab profileerida kasutajagruppide ja kasutajate õigusi. Tavaliselt ei ole andmebaasiadministraatoritel siin midagi suuremat planeerida – kogu planeerimise töö on tehtud ära infosüsteemide loomise käigus. Samas on pahatihti kogu õiguste süsteemi kirjeldus hajutatud üle infosüsteemi kirjelduse – iga konkreetset õiguse määramise võimalust on kirjeldatud konkreetse funktsionaalsuse juures. Selleks, et mugavalt luua erinevate kasutajagruppide ja kasutajate õiguste kirjeldusi on mõtekas luua kasutajaõiguste teatmikud, kust on lihtne leida ühe või teise õiguse määramise võimalusi ja piiranguid. Lihtsamatel juhtudel (väiksemad infosüsteemid) võib selliseid dokumente luua näiteks hierarhiliste HTML- lehekülgedena, kus siis on võimalik navigeerida üldiselt üksikule või siis teha täistekst otsingut. Keerulisematel juhtudel tuleb loomulikult kasutada keerulisemaid vahendeid. Turul on siin erinevaid litsentseeritud ja vabavaralisi produkte. Kui kasutusel on mõni SSO (single sign-on) süsteem võin selliseks registreerimiseks kasutada ka selle süsteemi vahendeid.

Õiguste loendid infosüsteemide kaupa

Selliste õiguste kataloogide tähendus on väga suur. Siin saab iga õiguse juurde märkida konkreetses firmas kehtivad õiguste välja andmise piirangud kuni sinna maani, et et antud õigust ei anta välja mitte kunagi mitte kellelegi või siis on see õigus alati kõigil. Kuna õiguste süsteemid ja andmetele juurdepääsu piiramine muutavad nii „tänu“ häkkerite rünnakule kui tööstusspionaažile üha olulisemaks, siis andmetele juurdepääsu tagamise ühene mõistmine kõigi administraatorite poolt on ülimalt oluline

Õiguste süsteemi ühese mõistmise olulisus

Üldise planeerimise käigus tuleb luua kasutajagruppide (rollide) süsteem. Kunagi ei tohi luua kasutaja gruppe „lihtsalt“ töö käigus. See viib lõpuks selleni, et õiguste „tähendus“ hajub kasutajagruppide vahele ära ja samade õigustega töötajaid on võimalik luua kasutades erinevaid rolle. Kasutajagruppide struktuur tuleb hoida kindlalt kontrolli alla ja iga uue kasutajagrupi loomisel paigutada see kõige pealt üldisesse mudelisse ning kontrollida, et ei tekkiks kattuvusi õiguste süsteemis. Kasutajagruppide mudel tuleks üles joonistada ka graafiliselt. Siis on see ülevaatlik, lihtsamini mõistetav ja seega ka oma eesmärki paremini täitev – võimaldab paremini hallata kasutajagruppide struktuuri ja vältida n.ö „ülekatteid“ s.o. samatähenduslikke või siis liiga sarnaste kasutajagruppide tekkimist. Omal kohal on siis nii diagrammide joonistamise süsteem kui ka tekstitöötlussüsteem.

Kasutajagruppide (rollide) planeerimine

Kasutajagruppe on võimalik kavandada nii ühe infosüsteemi keskselt kui ka laiemalt – mitmete infosüsteemide üleselt. Sellisel juhul on meil vaja n+1 mudelit. Me vajame mudelit iga infosüsteemi kohta eraldi, mis kirjeldatakse selle konkreetse infosüsteemi õiguste komplektidena. Samas vajame me ühte lisamudelit, mis erinevate infosüsteemide mudelid oma vahel ära seoks. Erinevate infosüsteemide rolli-mudelit siduvaks kihiks on tavaliselt ärirollide puu, mis tuleneb otseselt ettevõtte struktuurilisest ja funktsionaalsest ülesehitusest. Erinevate infosüsteemide kasutajagruppide sidumine kõrgemal tasemel tehakse erinevates infosüsteemides kirjeldatud kasutajagruppide sidumisel samade ärirollidega.

Infosüsteemi keskne ja infosüsteemide ülene kasutajagruppide planeerimine

Oluline on omada ka ülevaadet äri-rollidest ja nende omavahelistest seostest. Ka see struktuur tuleb visuaalselt üles joonistada ja kommenteerida. Ilma täpselt ja üheselt ärirolle mõistmata ei ole võimalik moodustad erinevate infosüsteemide kasutajagruppide mudelitest ärikeskseid rolle.

Ärirollid vs. kasutajagrupid

Omaette keeruline teema on kasutajatele personaalsete kasutajaõiguste andmine. Tegelikkuses on ideaalne olukord see, kus kasutajatele personaalseid õigus ei anta vaid nad saavad kõik oma õigused nendest kasutajagruppidest kuhu nad mingil konkreetsel hetkel kuuluvad. Seda selle pärast, et kui me hakkame kasutajatele õigus jagama personaalselt muutub õiguste süsteem sedavõrd hajusaks, et meil tegelikkuses kaob kontroll kogu õiguste süsteemi üle ära. Me lihtsalt ei suuda enam jälgida kelle millised õigused on. Eriti keeruliseks läheb asi sellel hetkel, kui töötaja vahetab ametikohta nii, et tema õiguse muutuvad suures osas. Siis on ju ainuke võimaluis võtta temalt „käsitsi“ tema „vanad eriõigused“ ja anda talle „uued eriõigused“.

Probleemid kasutajatele eriõiguste andmisel

Sellel asjal on kaks suurt miinust. Esiteks on see töö väga palju aega nõudev ja teiseks on selline käitumine väga suurte vigade allikas. Vead õiguste süsteemis maksavad aga ennast karmilt kätte.

Töömahukus ja vigade rohkus

Seega on kõige parem õiguste skeem selline, kus kõikides infosüsteemides on kirjeldatud kasutajagrupid ja need on seotud ärirollidega. Ärirollid võib omakorda siduda ametikohtadega. Kui nüüd töötaja vahetab ametikohta, siis koos ametikohaga saab ta oma ärirolli ja sellest tulenevad ka läbi kasutajagruppide tema õigused.

Amet -> äriroll -> kasutajagrupp -> õigused

Paraku on aga elu lõpmata mitmekesine ja pinguta kuidas tahad ikka ei läheb vaja kellelgi anda eriõigusi. Seega tuleb kirjeldada mõiste eriõigus. Kasutaja eriõigus on selline õigus, mida kasutaja ei vaja pidevalt vaid ainult mingil piiritletud ajaetapil. Siit tuleneb ka eriõiguste andmise kord – eriõigus antakse alati tähtajaliselt ja selle tähtaja maksimaalne lubatud kehtivusaeg peab olema piiratud ettevõtte siseste turvaeeskirjadega. Sellise õiguse vajadusel tellitakse see iga kord uuesti ja lubatud aja täitumisel kaob see automaatselt. Sellisel käitumisel ei saa jääda „ripakile“ õigusi, mille üle meil puudub teadmine ja seega ka kontroll.

Kasutajate eriõigused

Kasutajagruppide ja nende õiguste kirjeldamise vahendid on tavaliselt olemas infosüsteemides enestes. Siin peab administraator jälgima ainult seda, et kõik süsteemides kirjeldatud õigused ja nende muutused säilitaksid kusagil oma muutuste ajaloo – ka tagant järele peab olema võimalik määrata, kellel millised õigused olid. Kui infosüsteemil enesel puudub õiguste ajaloo säilitamise mehhanism tuleb see luua mingite väliste vahenditega. Näiteks on üheks võimaluseks luua tööandmebaasi kõrvale teine andmebaas, kuhu trigerite abil kirjutatakse iga õiguste muutumise korral uued õigused. Kui nüüd tööbaasis on ainult õiguste jooksev seis, siis selles teises baasis säilitatakse kogu õiguste muutumise ajalugu. Infosüsteemi töö seisukohakt pole mitte mingil juhul vaja hoida õiguste muutumise ajalugu, küll on seda vaja aga turvaanalüüsi ja tagant järele „pattude“ tuvastamise vajadusteks.

Õiguste muutumise ajalugu, analüüs ja „pattude“ tuvastamine

Andmebaaside poole tehtavate pöördumiste seire ja auditeerimine enam nii lihtsalt ei lähe – kui seda teha ikka tõsisest vajadusest, siis tuleb siin rakendada ka tõsisemaid vahendeid. Andmete muutmisi (ISERT, UPDATE DELETE) on logida suhteliselt lihtne – andmebaasi tuleb lihtsalt kirjutada trigerid, mis käivituvad andmete muutmise tegevuste peale ja kirjutavad andmete muutuse lisaks sellele tabelile, kus andmeid muudeti ka muutuste logisse. Lisades sinna muidugi ka muutuse tegija ja muutuse kuupäeva ning kellaaja. Asi läheb veidi keerulisemaks siis, kui muutuse tegijaks ei ole mitte konkreetne isik vaid mingi protsess. Sellisel juhul tuleb andmete muutuse juurde lisada protsessi nimi aga võib olla vahel ka see, kelle töö tulemusena see protsess käivitus. Selliselt saame me piisava baasi, et teha vajadusel tehtud muudatuste auditit.

Andmete muutuste seire

Paraku ei piisa alati ainult muudatuste jälgimisest, sest pea sama oluline on jälgida andmebaasi poole tehtud päringuid – andmete mittevolitatud kasutamine päringutes on konfidentsiaalsete andmete puhul (aga äriandmed on seda enamuses) sama ohtlik kui nende mitte volitatud muutmine. Seega tuleb paljudel juhtudel salvestada logidesse ka need päringud, mis andmebaasi saadeti. Seejuures tuleb jällegi fikseerida ka kasutaja ja päringu tegemise aeg analoogiliselt sellega, mis tehti andmete muutuste logimisel. Siin on aga asi juba oluliselt keerulisem. Pahatihti ei anna üksikute SELECT-lausete salvestamine terviklikku pilti sellest, mi tegelikult toimus. Seepärast on olulistes infosüsteemides päringute salvestamine grupina organiseeritud juba infosüsteemi enda vahenditega.

Päringute jälgimine.

Võib vaid arvata, millises mahus sellise seire tulemusena logisid salvestatakse. Nende läbi vaatamine ei ole üldse väga lihtne ja mingite triviaalsete vahenditega seda enam teha ei saa. Siin peab rakendama samu meetodeid ja süsteeme, mida kasutatakse äriandmete kaevandamisel ja analüüsil (Näiteks süsteemi SSPS või SAS).

Logide analüüs

Kõikide turvalisusega seotud tegevuste dokumenteerimise üldiseks printsiibiks on see, et kõik tehtud muudatused tuleb dokumenteerida selliselt, et oleks üheselt mõistetav muudatuse aeg, muudatuse tegija ja muudatuse sisu.

KOKKUVÕTE

3.3. Andmestruktuuride administreerimine

Ühe kõige vastutusrikkama osa andmebaasiadministraatori tööst moodustab andmebaasise struktuuride ja sellega kaasnevate kirjelduste (indeksid, trigerid, protseduurid, paketid, replikatsioonivahendite häälestamine jms.) loomine ja muutmine. Laias laastus võib need tegevused jagada kuude gruppi:

Muudatused, millest sõltub kõik ülejäänu

Andmebaasi loomine andmemudeli alusel. Tänapäeval on andmebaasi loomise aluseks suure tõenäosusega mõne ERD-redaktoriga (ERWin, Power Designer, ERD Studio vms.) loodud andmemudel. Osa ERD redaktoreid (näiteks ERWin) võimaldavad võtta ühendust loodud tühja andmebaasiga ja genereerida andmebaasi struktuuri otse mudelist andmebaasi. Enamike puhul tuleb siiski mudeli alusel genereerida vastava andmebaasi mootori jaoks SQL-keele korralduste (DDL – Data description language) jada (skript) ja seejärel täita see korralduste jada mõne SQL-terminal tüüpi programmiga (Näiteks Oracle puhul on selliseks programmiks SQLPlus.exe ja SQLBase puhul SQLTalk.exe.

Andmebaaside loomine

●

Andmebaasi struktuuri muutmine (andmemudeli alusel). Kui esialgselt on andmebaas loodud ERD-redaktoriga, siis tehakse ka kõik muudatused selles mudelis. Ka nüüd on olemas osadel ERD-redaktoritel võimalus viia muudatused otse mudelist andmebaasi. Seda EI TOHI aga mingil juhul kasutada. Seda selle pärast, et muudatuste tegemise mehanism nendes süsteemides on UNIVERSAALNE ja selleks, et mingit muudatust mingis konkreetses andmebaasis läbi viia võidakse teha oluline hulk kirjelduste peale ja maha installeerimisi. Kui nüüd aga keegi on viinud andmebaasi kirjeldusi, mida mudelis ei ole, siis võib mõni mudeli järgi tehtav muudatus hävitada baasist ära sellise asja, mida mudelis pole. Näiteks vaate (view) kustutamisel selleks, et see luua uuesti ja uue struktuuriga võib mõnedes andmebaasisüsteemides ära hävitada ka kõik selle vaatega seotud protseduurid. Kui neid aga mudelis ei ole siis neid ka pärast vaate uuesti loomist ei taastata.

Andmestruktuuride muutmine

Samuti on selline protseduur ohtlik selle pärast, et kui see protsess millegi pärast katkema paks, siis jääbki andmebaas „poolikuks“ ja selle taastamiseks on suure tõenäosusega võimalik seda taastada ainult varunduskoopiast. See on aga töötavate baaside puhul väga halb variant, kuna andmebaasi töös tuleb teha pikem katkestus.

Protsessi katkemise oht

Õige on genereerida mudelist andmebaasi muudatuste skript, katsetada seda kõigepealt test-andmebaasi peal ja kui see õnnestub, siis käivitada sama skript töö-baasi peal. Vahendid selle tegevuste gruppi teostamiseks on samad, mis andmebaaside loomiselgi.

Muudatuste haldamine muudatuste skriptide abil

●

Andmebaasi seose terviklikkuse reeglite (Referential Integrity) haldamine. Sisuliselt tähendab see primaar- ja välis-võtmete (Primary Key – Foreign Key) paaride ja nendega seotud protseduuride haldamist, mis moodustavad seosed andmebaasi tabelite vahel. Seoste kirjeldused ise muutuvad harva – nad lihtsalt kas tekkivad uute tabelite ja tabelite vaheliste seoste lisamisel baasi või siis kaovad sealt, kui baasi mudelist eemaldada seoseid või tabeleid (viimane peaks küll väga harv juhus olema). Muutuda võivad aga seoste kirjeldustega seotud protseduurid, mis kirjeldavad seda, millised piirangud või kaasnevad tegevused täpsustavad seose toimumist. Selleks kasutatakse tavaliselt konkreetse andmebaasiga kaasa olevat vahendit.

Seose terviklikkuse haldamine

●

Ärireeglite rakendamine andmebaasi salvestatud protseduuride abil. Andmebaasis talletatud protseduuride muutmine ja sinna uute protseduuride lisamine tehakse tavaliselt konkreetse andmebaasi vahendite komplekti kuuluva SQL-trminal tüüpi programmi abil.

Ärireeglite rakendamine

●

Andmebaaside struktuurimuudatuste registreerimine. Registreerida tuleb viimane kui muudatus, mida andmebaasi struktuuris, protseduurides, vms. Tehakse. Kui muudatusi teha skriptide kaupa, siis piisab, kui need muudatuste skriptid salvestada tähenduslike nimedega kronoloogilises järjestuses selleks ettenähtud kaustade (directory) struktuurile. Lisaks sellele tuleb pidada päevikut käivitatud skriptide, käivitamise aja, käivitaja andmete ja saavutatud tulemuse kirjeldusega (minimaalselt: õnnestus/ ei õnnestunud ja mis päras seda tehti – näiteks; võeti muudatus tagasi). Seda päevikut võib pidada näiteks kas või MS Excelis. Parem variant on siiski see, kui kogu muudatuste tegemine siduda mingi kolmanda osapoole käest ostetud töökäskude süsteemiga, kus keegi koostab muudatuse ülesande, keegi kinnitab selle, keegi teostab töö ja märgib selle teostatuks. See annab parema ülevaate tehtud muudatustest.

Andmebaasi muudatuste registreerimine

3.4. Andmete varundamine ja andmebaaside taastamine

Nii nagu iga teinegi terviklik protsess algab ka varundusprotsessi läbi viimine protsessi planeerimisest. Koostada tuleb järgmised protseduurid ja reeglistikud. Need võib vormistada tavaliste teksti-dokumentidena.

Kehtestavatd korrad ja protseduurid

●

Varunduskoopiate tellimise kord (kes esitab tellimuse, kellele/kuhu esitatakse tellimus, varunduskoopia tellimusel esitatava kirjelduse struktuur: mis hetkest alates, kui tihti, ´mis hetkeni, kust kohast, kuhu kohta, kui kaua säilitatakse jms.)

Varunduskoopiate tellimise kord

●

Varunduskoopia tegemise kirjeldamise kord (tellimuse vastu võtmine, varundustegevuse protsesside loomine, tellija teavitamine, jms.)

Varundusprotsessi loomise kord

●

Varunduskoopia tegemise lõpetamise kord (kes esitab tellimuse kellel/kuhu tellimus esitatakse, mida kirjeldatakse tellimuses

Varunduskoopia tegemise lõpetamise kord

●

Varunduskoopiate säilitamise kord (kus, milliseid koopiaid ja kui kaua hoitakse)

Varunduskoopiate säilitamine

●

Iga konkreetse andmebaasi taastamise taasteplaanide loomine. Andmete varundamine on ainult asja üks pool. Sellel hetkel, kui andmebaas rikneb võib osutuda ainsaks võimaluseks selle situatsiooni lahendamisel, andmete taastamine varunduskoopiast. See kuidas mingi andmebaas riknemise korral taastatakse peab olema eelnevalt läbi mõeldud ja kirja pandud taasteplaanina – kes võtab varunduskoopia ja kust, milliseid tegevusi tehakse enne taastamist, kes taastab baasi, milliseid tegevusi tehakse pärast taastamist.

Taasteplaani tuleks pärast selle valmimist katsetada, et veenduda selle paikapidavuses ja et tõelises veasituatsioonis võiks sellele toetuda 100%-lise kindlusega.

Taasteplaanid

Koos iga korraga kaasneb ka vastutajate loend – kes mille eest vastutab.

Vastutus

Andmete varundamine ise viiakse tavaliselt läbi mitte andmebaasi enda vahenditega vaid kas selleks ostetud või ise loodud spetsiaalse vahendiga. Suurte infosüsteemide puhul on kindlasti vajalik mingi spetsiaalselt varundustegevuse toetuseks loodud infosüsteemi kasutamine. Andmebaaside enda vahendid võimaldavad enamasti küll varunduskoopiate loomise, kuid nad ei toeta selle protsessi perioodilisust. Seega kõige „minimaalsem“ andmebaasides olevate andmete varundamise vahend on andmebaasi poolt pakutud andmebaasi „välja laadimise“ funktsionaalsus, mis on seotud läbi protseduuri skripti mingi kalenderplaaniga, mille alusel käivitatakse protsesse.

Varundamine

Andmete varundamine on ainult asja üks pool. Sellel hetkel, kui andmebaas rikneb, ja muud võimalust peale varunduskoopiast taastamist enam pole, võetakse selle andmebaasi taasteplaan ja viikase läbi toimingud vastavalt sellele taasteplaanile. Pärast taastamise lõppemist tehakse vajadusel muudatusi taasteplaanis. Seda loomulikult juhul, kui taastamise käigus selgus, et seni kehtinud taasteplaani järgi ei õnnestunud taastamist läbi viia või oli seal ebatäpsusi. Selline toimimine tagab taasteplaanide täpsustumise.

Taasteplaanid

3.5. Tarkvara ülalhoid ja tarkvara toimimise tagamine

Tarkvara ülalhoiuga seotud tegevused võib jagada viide gruppi:

●

Andmebaasisüsteemi ja sellega seotud tarkvara installeerimine ja selle tarkvara uuendamine (patching, upgrade). Siin on kasutatavateks vahenditeks installatsioonipaketid, uuenduste paketid (upgrade) ja paranduste paketid (patch). Oluline on registreerida kõik tarkvara muudatused. Selleks võib kasutada nii elektroonilist žurnaali (minimaalselt kas või Exceli tabelit) või siis ülalpool mainitud töökäskude süsteemi, kus installeerimistööd antakse välja ja märgitakse täidetuks nagu mis tahes iga muu töö.

Siin on oluline teada seda, et uuendusi ja (eriti) parandusi ei panda peale kohe siis kui need välja tulevad. Uuendusi paigaldatakse tavaliselt etteantud plaani ja ette määratud intervalli järel. Parandusi paigaldatakse ainult siis, kui need parandavad ära mõne olulise üldise vea või siis kui nad parandavad midagi infosüsteemi toimimise seisukohalt olulist. Iga muudatuse peale panemine on oht infosüsteemi toimimisele ja seepärast tehakse seda ainult tungival vajadusel ja vastavalt kalenderplaanile.

Andmebaaside installeerimine, uuendamine ja paranduste paigaldamine

●

Versioonihaldus - kõik installeeritud komponendid ja nende uuendamine (upgrade) või parendamine (patch) peavad olema registreeritud vastavas žurnaalis (Word, Excel, spetsiaalne versioonihaldustarkvara). On oluline, et kui sama programm on installeeritud paljudesse kohtadesse, et siis saaks versiooni vahetusel versioon vahetatud kõigis nendes kohtades võimalikult lühikese aja jooksul. Igal ajahetkel peab olema täpselt teada, kus parasjagu milline versioon installeeritud on.

Versioonihaldus

●

Andmebaasisüsteemi konfigureerimine (parameetrite väärtustamine) Selleks kasutatakse tavaliselt konkreetse andmebaasi poolt pakutud vahendid või kolmanda osapoole poolt toodetud spetsiaalvahend (näiteks SQL Navigator). Oluline on see, et kõik andmebaasi konfigureerimise muudatused tuleb registreerida selliselt, et nende sisu, tegemise aeg ja teostaja on tagant järele tuvastatavad.

Konfigureerimine

●

Andmeühenduse (võrgu) probleemide välja selgitamine ja nende lahendamise koordineerimine. Nende probleemide lahendamine kuulub rohkem võrguadministraatorite tegevusvaldkonda, kuid andmebaasi serveri juures selliste probleemide ilmnemisel peab andmebaasiserveri administraator aktiivselt osalema probleemide välja selgitamisel, sest need võivad olla ka tingitud andmebaasiserveri puudulikust funktsioneerimisest.

Võrguhäirete kõrvaldamine

●

Andmebaasi startimise ja peatamise parameetrite häälestamine ja vastavate salvestatud protseduuride loomine. Seda tehakse tavaliselt serverile installeeritud operatsioonisüsteemi vahenditega (näiteks Windows puhul Services ja Scheduler häälestamisega ja käivitusprotseduuride (.BAT või .CMD) kirjutamisega).

Andmebaaside startimine ja peatamine

3.6. Ressursside haldamine

Ressursside haldamine sisaldab endast tegevusi mitmest erinevast valdkonnast, millede kõigi eesmärk on serveri töö optimeerimine/parendamine ja serveri tõrgeteta töö tagamine. Need tegevused on kõik väga konkreetse andmebaasimootori (kaubamärgi) kesksed ja enamikus kasutatakse nende teostamiseks konkreetse andmebaasi mootori vahendeid.

Ressursside haldamine

●

Indeksite loomine ja haldamine. Optimaalsest indeksite kirjeldustest andmebaasis sõltub andmebaasi töö kiirus ja serveri ressursi kasutamine väga oluliselt – iga asjatult loodud indeks teeb andmebaasi töö (andmete lisamise) aeglasemaks ja puudu olev indeks teeb samuti andmebaasi töö aeglasemaks (andmete pärimine). Seepärast tuleb jälgida, milliseid indekseid andmebaasis ei kasutata üldse ja hävitada need ning leida need kohad, kus uue indeksi lisamine teeb päringu kiiremaks (kohad, kus päringu teostamisel ei kasutata indeksit üldse või kasutatakse mingit sobimatut indeksit) ning luua vajalikud indeksid. See ei ole ühekordne protsess, kuna rakendused muutuvad kogu aeg ja seega muutub asuure tõenäosusega ka indeksite vajadus.

Indeksite haldus

●

Füüsiliste mälustruktuuride eraldamine – tähendab sisuliselt andmebaasidele kettamälu eraldamist ja serveri operatiivmälu proportsiooni juhtimist. Esimeselk juhul eraldatakse andmebaasiserverile kasutamiseks kettamälu andmebaaside jaoks, logifailide jaoks ja andmebaasisüsteemi juhtinformatsiooni ja süsteemse informatsiooni jaoks. Teisel juhul aga lisatakse serverile mälu ja parameetriseeritakse selle sisemise struktuuri jaotus erinevateks otstarveteks kasutatavate mälu mahtudena.

Füüsilised mälustruktuurid

●

Loogiliste mälustruktuuride haldamine on alati rangelt konkreetse andmebaasisüsteemi (kaubamärgi) keskne.- igal andmebaasisüsteemil on omad ainult temale omased mälustruktuurid ja ka vahendid nende haldamiseks on ehitatud selle andmebaasisüsteemi sisse. Suuremate ja tuntumate andmebaasisüsteemide (Oracle, Sybase, MS SqlServer jms.) jaoks leidub ka kolmandate osapoolte poolt toodetud andmebaaside haldureid, mis võimaldavad hallata pea kõiki (või siis vähemalt olulisemaid) andmebaasisüsteemi parameetreid. Enamikul juhtudest kasutatakse sellise „peenhäälestuse“ jaoks siiski andmebaasisüsteemide endi poolt pakutavaid vahendeid. Seda kas või juba selle pärast, et selliseid tegevusi pole vaja teha eriti tihti ja ka selliseid inimesi, kellel on teadmisis ja oskusi nende tegevuste tegemiseks, on väga vähe.

Loogilised mälustruktuurid

●

Andmemahtude planeerimine. Andmemahtude planeerimiseks on olemas suurepärased vahendid ERD-redaktorites. Kuna seal on kirjeldatud kogu andmebaasi struktuur, siis „teab mudel“ suurepäraselt, kui palju kulub andmemahtu ühe kirje salvestamiseks koos kõigi indeksite ja muude struktuuridega, mis ühe kirje salvestamisega kaasneb. Kui nüüd mudelile anda ette tabelite mahtude hetkeseisud ja kasvutendentsid kuus ning aastas, siis on ERD-redaktor suuteline välja arvutama andmebaasi suuruse mingiks konkreetseks etteantud ajahetkeks. Neid arvutustulemusi saab kasutada kettaseadmete ostude planeerimisel.

Andmemahtude planeerimine ERD-redaktori abil

Päris täpselt saab andmemahte ka planeerida andmebaasi kasvudünaamika jälgimise informatsiooni abil. Kui Talletada andmebaasipoolt kasutatav kettapinna mahu muutumine pikema aja jooksul, siis selle arvjada dünaamika alusel on võimalik suhteliselt täpselt ennustada, milliseid kettamahte nõuab oma tööks andmebaas tulevikus. Aastane dünaamika on kuude lõikes erinevates aastates suhteliselt stabiilne (seda muidugi nii kaua kui ei muudeta oluliselt kasutatavat funktsionaalsust ja püsitakse umbes samal äriaktiivsuse tasemel). Kui nüüd kõrvutada eelmiste aastate andmeid, siis on üpris suure täpsusega selgitada välja andmebaasi poolt nõutavad kettamahud. Seda meetodit saab kasutada muidugi ainult siis, kui meil on talletatud mitme (paari-kolme) aasta kettamahu kasvu dünaamika. Andmebaasi poolt kasutatavat kettamahtu saab registreerida andmebaasis eneses kasutades seleks andmebaasisüsteemi enda poolt pakutud vahendeid.

Andmemahtude planeerimine salvestatud statistika abil

3.7. Jälgimine ja veakäsitlus

Andmebaaside toimimise jälgimine ja jälgimisest saadava informatsiooni abil veasituatsioonide ennetamine ning tekkinud tõrgete kiire ja efektiivne kõrvaldamine on üks andmebaaside töö tagamise kriitilisi faktoreid.

●

Andmete lukustuskonfliktide jälgimine/avastamine, diagnoosimine ja lahendamine. Selle jaoks kasutatakse tavaliselt andmebaasisüsteemi enda tarkvara ja ka kolmandate osapoolte poolt toodetud andmebaasida haldamise tarkvara. Siiski on selle koha peal, kui lukustuskonflikte peaks tekkima palju, luua enda vahend nende tekkimise jälgimiseks ja automaatseks kõrvaldamiseks. Igas SQL-andmebaasis on andmebaasi tabeli kujul olemas kogu informatsioon antud hetkel baasis olevate lukustuste kohta. Samas on näha selles tabelis ka lukustuskonfliktid (Death Lock). Selle tabeli andmetele tuginedes on võimalik kirjutada andmebaasiprotseduur, mis jälgib koguaeg selle tabelis sisu ja lukustusprobleemide tekkimisel valib välja kasutaja, kelle kelle töö katkestamine lahendab probleemi kõige parmini ja logib näiteks „jõuga“ selle kasutaja baasist välja või katkestab tema hetke tegevuse.

Lukustuste jälgimine ja probleemide kõrvaldamine

●

Andmebaasi monitoorimine s.o. Järjepideva informatsiooni kogumine andmebaasi olukorra kohta. Seda nüüd enam väga lihtsate vahenditega teha ei saa. Siin tuleb selleks kasutada selleks spetsiaalselt ettenähtud süsteeme (näiteks HP OpenView, IBM Tivoli vms.) Monitoorimise eesmärgiks on saada andmebaasi kohta piisavalt järjepidevat ja askjakohast informatsiooni, sellesk, et analüüsida andmebaasimootor toimimist ja teha asjakohaseid otsuseid selle muutmise parendamiseks või probleemide ennetammiseks.

Monitoorimine

Andmebaasi monitoorimise oluline osa on andmebaasi jõudlust iseloomustava informatsiooni kogumine, selle hilisem analüüs ja analüüsi põhjal andmebaasi konfiguratsiooni muudatuste otsuste tegemine. Samuti võimmaldab see aegsasti avastada andmebaasi jõudluse probleeme.

Jõudluse monitoorimine

●

Andmebaasisüsteemi valmistaja ja müüa poolt pakutavate toetusteenuse kasutamine. Selle teenuse kasutamise tase tuleb määrata rakenduse olulisust arvestades. Tavalislet madalama taseme tuge läbi HTML-dokumentide pakub tarnija tänapäeval lisateenusena tasuta. Sama pädeb ka erinevate antud produktiga seotud uudisgruppide ja jututubate kohta. Probleemide tekkimisel tuleb neid aktiivselt kasutada. Eriti oluliseks ja tulemust andvaks osutub tihti just „enda taolistega“ vestlemine uudisgruppides ja jututubades – te näete, et te pole esimene, Kellel selline probleem tekkis. Olulisemate aplikatsioonide puhul tuleb mõelda teeninduslepingu sõlmimise peale, milles koosseisus tuleb siis valida kas telefonikonsultatsioonide võimalus või siis ka kohale tulemise (on-site) teenus.

Toetusteenuse kasutamine

●

Vigade ja nende kõrvaldamise registri pidamine sellisel tasemel, et oleks võimalik tagant järele tuvastada vea tekkimise aeg, avastaja, probleemi lahendus, probleemi lahendaja ja lahenduse teostamise kuupäev. Oluline on pidada seda registrit selliselt, et uue vea ilmnemisel oleks sellest registrist võimalik otsida, kas selline viga on ilmnenud ka varem ja kui on, siis kuhu see viga mõjus ja mida tehti siis selle vea kõrvaldamiseks.

Vigade register

3.8. Enesetäiendamine

Andmebaasiadministraatori enesetäiendamine peab haarama vähemalt kolme järgmist temaatikat:

Enesetäiendamine:

●

Andmebaasisüsteemide uute metoodikate ja üldiste tehniliste lahendustega enese kursis hoidmine

Uued metoodikad

●

Andmebaasisüsteemide kasutamise uute metoodikate ja tarkvaraliste vahendite arenguga enese kursis hoidmine

Vahendite areng

●

Konkreetse andmebaasisüsteemi uute arenduste tundma õppimine

Kasutatava andmebaasisüsteemi areng