7.SUURTE ANDMEBAASIDE ADMINISTREERIMISE ISEÄRASUSED

7.1. Suured andmebaasid – midagi erilist?

Korrektselt toimiva infosüsteemi tähtsaimaks aluseks on “õigesti” projekteeritud ja rakendatud andmebaas, kuid see, mis peab olema “õigesti” projekteeritud ja rakendatud, on oma mõõtmetelt tunduvalt laiem kui seda on andmebaas klassikalises tähenduses. Reaalselt eksisteeriv andmebaas omab oma terviklikku ja tegelikku tähendust ainult vaadelduna koos tema kasutuskeskkonna ja kasutajatega.

Tavaliselt kui räägitakse andmetebaasidest, siis mõeldakse selle all enamasti instrumentide komplekti, mis sisaldab:

Andmebaasi all mõistetakse enamasti

●

struktureeritud andmeid – skeemid (schemas), tabelid (tables), vaated (views) jms.

Andmed

●

tabelite vahelisi seoseid – relatsioonid (relations) ja seose terviklikkus (referential integrity)

Seosed

●

andmeotsingu kiirendeid – indeksid (indexes)

Indeksid

●

piiranguid – andmetüübid (data types), formaadid (formats), tingimused (constraints) jms.

Piirangud

●

andmebaasiprotseduure (procedures)

Protseuurid

●

andmete käsitluskeelt – SQL-keel (Structured Query Language) või kirje kaupa pöördus (RLA- Row Level Access)

Käsitluskeel

Kui andmebaasi vaadata tõepoolest ainult sellise instrumentide kogumina, siis võib „suure“ andmebaasina käsitleda ainult suure andmemahuga andmebaase. Andmebaasisüsteeme tootvate firmade käibesse ongi tekkinud mõiste VLDB (Very Large Database), millega tähistatakse väga suuri andmekogumeid, mis on organiseeritud andmebaasidena. Üldiselt kapseldatakse kogu probleemistik suurte andmebaaside puhul peamiselt nelja teemasse:

Väga suur andmebaas - VLDB

●

andmete pärimise kiirus – suurtes andmebaasides kulub andmete pärimise peale oluliselt rohkem aega, kuna vajalike andmete otsimine suurema hulga andmete seast võtab lihtsalt rohkem aega. Lisaks sellele kipuvad suuremates andmebaasides ka päringute tulemused (selection) olema pikemad. Kõik see nõuab kiireid kettaseadmeid ja oluliselt parema metoodikaga programme.

Andmete pärimise kiirus

●

andmete varundamise metoodikad, mis tagaksid piisavalt lühikese ajaga varunduskoopiate tegemise; probleemi tekitab see, et mida rohkem on andmeid, seda kauem võtab aega nende varundamine. Paraku on aga varundamiseks kasutada võimalik aeg piiratud. Kasutatakse meetodeid, kus terviklik varundus koopia tehakse ainult üks kord – kõige alguses. Edaspidi tehakse varunduskoopiaid nendest andmebaasi osadest, mis eelmisest varunduskoopiast alates on muutunud. Uus terviklik varunduskoopia tehakse eelmisest terviklikust koopiast lisades sellele muudatuste varunduskoopia jne.

Andmete varundamise metoodikad

●

andmete taastamine võimalikult lühikese ajaga – see on üks keerukamaid probleeme. Kui varundada saab andmeid ositi (nagu ülal pool kirjeldatud), siis taastada saab andmebaasi alati ainult tervikuna – viimasest loodud terviklikust varunduskoopiast. Siin on kasutiusel erinevad meetodid andmebaaside kiirlaadimiseks.

Andmete taastamise metoodikad

●

Andmete jaotamin erinevate seadmete vahel tagamaks andmete võimalikult kiiret riistvaralist käsitlust. See teema haakub otseselt kõigi eelmiste teemadega, kuid on siiski täiesti eraldi seisev probleem – riistvara aeglus on oluliseks piiravaks teguriks kõigi eelnevate probleemide lahendamisel. Lisaks andmete jagamisele erinevate seadmete vahel ja seeläbi paralleeltöötluse võimaluse tekkimisele otsitakse pidevalt uusi ja kiiremaid tehnilisi lahendusi. Nii näiteks on Oracle uues andmebaasiserveris kasutusel kuni 2TB suurune välk-mälu cash mis asetseb „ketaste ja kasutajate vahel“, ning muudab töö andmetega kümneid kordi kiiremaks.

Andmete jaotamine

Tegelikkuses on „andmebaaside suurusega“ seotud probleemide juured hoopis laiemad, kui seda on lihtsalt andmete suur maht. Sama suureks probleemiks, kui andmete suur maht, võib andmebaaside puhul osutuda mistahes teine omadus, mille maht on võrreldes tavalisega ülepaisutatud. Nii näiteks võib mahult suhteliselt keskmise või isegi tagasihoidliku suurusega andmebaasi haldamise teha tavalisest oluliselt keerukamaks tavatult suur kasutajate hulk või andmete äärmiselt kõrge konfidentsiaalsuse tase.

Andmebaaside suuruse mitu tahku

Selleks, et andmebaasi suuruse probleemi vaadata laiemalt, peame me veidi laiemalt vaatama ka andmebaase endid. Tegelikkuses ei vaadeldagi andmebaase enam ammu sugugi nii kitsalt, kui me tegime seda käesoleva jaotise alguses. Tegelikkuses võib igale toimivale andmebaasile (aga selliseid me ju vaatleme) lisada üsna mitu instrumenti, ilma milleta reaalses töös andmebaasidega hakkama ei saa – eriti, kui meie andmebaas on suur (ükskõik, mille poolest siis ta suur on):

Andmebaas laimealt vaadatuna

●

monitooringu vahendid – selleks, et näha ressursside kasutamise muutumist ja pudelikaelu ressursside kasutamisel

Monitooringu vahendid

●

andmebaaside administreerimise vahendid – kasutajate haldamine, mälustruktuuride haldamine, süsteemi parameetrite häälestamine.

Administreerimise vahendid

●

õiguste tagamise vahendid, mille abil garanteeritakse, et kasutajatele jagatud õigused ka realiseeruvad.

Õiguste tagamine

●

liidesed teiste süsteemidega – ODBC, OLE DB, JDBC, native link, , XML, SOAP, jne.

Liidesed teiste süsteemidega

●

rakendused andmebaaside kasutamiseks

Rakendused

Kui nüüd hakata üle nende instrumentide vaatama, mille poolest üks andmebaas „suur“ saab olla, siis märkame kohe, et andmebaasi võib suureks teha hoopis midagi muud, kui seda on andmete maht. Järgnevalt püüamegi vaadelda erinevaid „mõõtmeid“ mille poolest üks andmebaas võib olla „suur“.

3.1. Andmebaasi suuruse erinevad tahud

3.2. Turvalisusega seotud tegevused ja nende realiseerimise vahendid

3.3. Andmestruktuuride administreerimine

3.4. Andmete varundamine ja andmebaaside taastamine

3.5. Tarkvara ülalhoid ja tarkvara toimimise tagamine

3.6. Ressursside haldamine

3.7. Jälgimine ja veakäsitlus

3.8. Enesetäiendamine