Rautakaupan myyjä on klassinen vitsailun kohde. Palvelun laadussa ja tehokkuudessa on ollut toivomisen varaa. Oletko koskaan käynyt rautakaupan varastossa? Siellä eivät asiat aina näytä olevan kovin viimeisen päälle järjestyksessä. Jos varasto on kunnossa, niin tuntuu kuin palvelukin pelaisi tehokkaammin. Erilaisiin varastoihin törmää arkielämässä päivittäin. Rautakaupat, kirjastot, apteekit ja kirpputorit sisältävät varastoja joiden organisointitapa, tehokkuus ja "käyttöliittymät" ovat erilaisia.
Eräs mielenkiintoinen ja erilainen varasto on tietovarasto, jonka tehokkaan ja laadukkaan toiminnan edellytyksiä pyrkii tämä kirjoitus osaltaan tuomaan esiin. Tietovarastoa hallitsee aina jokin tiedonhallintajärjestelmä ja näitä järjestelmiä on lukuisia laiteympäristöstä, varusohjelmistosta ja tietojen käyttötarkoituksesta riippuen.
Kun tässä kirjoituksessa jatkossa viitataan esimerkinomaisesti joihinkin käsitteisiin, ne liittyvät joko DL/I tai DB2 for MVS ympäristöön.
Käsitteeseen tietovarasto liitetään hyvin helposti myös varaston sisältö eli itse tiedot. Kun ajatellaan tietovaraston elinkaarta, se on hyvin harvoin sama kuin tiedon elinkaari. Tietovaraston rakenne suunnitellaan ja varasto pystytetään. Useimmiten tietovaraston sisältö saadaan pääosin konversion tuloksena jostain vanhasta tietovarastosta, jonka rakenne ei enää vastaa sisällöllisiä tai teknisiä vaatimuksia. Konversion jälkeen vanha tietovarasto käy tarpeettomaksi ja sen elinkaari päättyy, mutta sen aikanaan sisältämät tiedot ovat edelleen olemassa.
Tietovaraston elinkaari alkaa sen fyysisestä määrittelystä. Sen sisältö syntyy siis joko massana konversiosta tai vähitellen sovellusten erilaisten prosessien tuloksena. Koko elinkaarensa ajan tietovarastoa kohtaan kohdistuu kaksi vaatimusta, joihin sovellukset eivät vaikuta:
Eheys pitää ymmärtää tässä varsin fyysisenä ja teknisenä asiana eikä sillä ole mitään tekemistä tietojen loogisen oikeellisuuden kanssa. Siitä vastaavat sovellusohjelmat.
Tietovarasto ei ole ehyt, jos se sisältää esim. epätäydellisiä päivityksiä tai rivejä/segmenttejä joihin hakemisto/osoitin ei viittaa.
Tiedonhallintajärjestelmä takaa sen, että tietovarasto on ehyt tai vaurion tapahduttua pystytään palauttamaan ehyeksi, jos tietovaraston hoitaja hoitaa oman osuutensa: Tallettaa lokit sekä ottaa ja tallettaa varmuuskopiot, eikä syyllisty omavaltaisuuksiin.
Tehokkuus taas merkitsee sitä, että tietojen käsittely on niin nopeata kuin mahdollista eikä mitään resurssia tuhlata.
Kun tiedot on ladattu tietovarastoon tai se on uudelleenjärjestetty, ollaan lähtötilanteessa. DB2 taulutiloissa taulujen rivit ovat ryvästyshakemistojen määräämässä järjestyksessä ja vapaa tila on tasaisesti jakautuneena tietokannan hoitajan valitsemien arvojen mukaisesti. DL/I kannassa tietokantatietueen segmentit ovat mahdollisimman lähellä ankkuripistettä, ellei katkaisuraja ole pakottanut osaa näistä ylivuotoalueelle. Vapaa tila ei ole tasaisesti jakautuneena.
Molemmissa tapauksissa hakemistot ovat alimpia tasoja myöten järjestyksessä ja vapaa tila on tasaisesti jakautuneena.
Tässä tilanteessa ns. hyvyysluvut ovat parhaimmillaan. Kun tietoja muutetaan eli tapahtuu lisäyksiä, päivityksiä ja poistoja, saattaa jollekin sivulle/valvontajaksoon vapautua tilaa, mutta samalla tarvitaan myös vapaata tilaa toisaalla. Tiedonhallintajärjestelmä pyrkii sijoittamaan rivin/segmentin tai hakemistoviittauksen mahdollisimman edulliselle paikalle ryvästyshakemiston avaimen tai segmenttihierarkian perusteella. Hakemistoviittaus on pakko sijoittaa aina avaimen mukaiselle paikalle.
Kun lähdemme tarkastelemaan tilanteita, jotka johtavat hyvyyslukujen huononemiseen, keskitymme jatkossa vain DB2 for MVS ympäristöön.
Lähes poikkeuksetta syynä siihen, että tietovaraston muuttamisen jälkeen tilanne ei enää ole optimaalinen, on vapaan tilan loppuminen sivulta. Poikkeuksena tähän on päivitys, jossa rivin ryvästyshakemiston avain muuttuu. Riviä ei uudelleensijoiteta muuttuneen avaimen perusteella ja näin se ei välttämättä enää ole ryvästyshakemiston mukaan oikealla sivulla.
Kun vapaata tilaa ei löydy hakemiston sivulta lisäyksen tai päivityksen yhteydessä, joudutaan sivu puolittamaan ja uusi sivu sijoittuu tiedoston loppuun ellei löydy täysin tyhjiä sivuja tiedoston keskeltä.
Kun lisättävä rivi ei mahdu taulutilan sivulle, sille haetaan tietyn algoritmin mukaan paikka. Tarvittaessa laajennetaan tiedostoa.
Jos päivitystilanteessa rivin pituus kasvaa siten, että sivulta ei löydy tilaa pidentyneelle riville, se sijoitetaan jollekin toiselle sivulle siten, että hakemistojen kautta osoittaminen tapahtuu edelleen alkuperäisen kotisivun kautta. Aikaisemmin rivin piteneminen oli mahdollista vain jos se sisälsi vaihtuvanmittaisia sarakkeita tai tauluun oli lisätty sarake ALTER lauseella eikä taulutilaa oltu tämän jälkeen uudelleenjärjestetty. Nyt kun tiedon talletus pakatussa muodossa on tullut mahdolliseksi ja kannattavaksi, on tällaisten tilanteiden esiintyminen paljon todennäköisempää ja näiden epäsuorien viittausten esiintymistä pitää seurata.
Vaikka vapaan tilan riittämättömyys on lähes yksinomaan syynä siihen, että tietovaraston hyvyysluvut huononevat ja tietovarasto joudutaan uudelleenjärjestämään, ei vapaan tilan perusteeton lisääminen kuitenkaan ratkaise ongelmia, vaan saattaa huonontaa tehokkuutta toisaalla. Jos vapaata tilaa on perusteettoman paljon, huononee puskurialtaan tehokkuus. Kun yhdellä sivulla on vähemmän tietoa, joudutaan lukemaan enemmän sivuja altaaseen ja allasviipymä lyhenee. Samoin kasvavalla levytilan tarpeella on hintansa.
Käytännössä on varsin helppoa laskea teoreettinen vapaan tilan tarve, kun valitaan aikaväli, jolle se lasketaan ja on käytettävissä kasvuennusteet. Tositilanteessa ongelmaksi muodostuvat kasvuennusteiden virheellisyydet ja lisäysten epätasainen jakautuminen taulutilan tai hakemiston eri kohtiin. Erikokoiset asiakkaat, vakuutukset tai konttorit tuottavat erilaisen määrän tietoa, joka kasautuu tiettyihin pisteisiin. Erityisen ongelmallinen on taulu, jonka ryvästystekijä on pääosin laskeva tai nouseva, jolloin kasvu tapahtuu yhdessä pisteessä.
Erityistä huomiota vaatii myös tietovarasto, jonka tietosisältö syntyy tapahtumapohjaisesti siten, että aluksi tietovarasto on tyhjä. Tällaiseen tietovarastoon pitää määritellä hyvin korkea vapaan tilan taso ja alkuvaiheessa hyvin tiuhaan tapahtuvilla uudelleenjärjestyksillä pyritään ikäänkuin kaulimalla levittämään tiedot useammalle sivulle lukitusongelmien välttämiseksi. Kun tietomäärä lisääntyy, voidaan vapaan tilan tasoa vähitellen laskea ja uudelleenjärjestysväliä harventaa.
On varsin yleistä, että tietovarastoille suoritetaan perkauksia eli poistetaan inaktiivista tai vanhentunutta tietoa. Tällöin toimitaan yleensä niin, että tietovarasto perataan ja sen jälkeen uudelleenjärjestetään jolloin vapautuu levytilaa. Jos tässä yhteydessä tehdäänkin niin päin, että ensin uudelleenjärjestetään ja sitten vasta perataan, voidaan saada aikaan vapaan tilan epätasainen jakautuma siten, että sitä on paljon siellä, missä sitä tullaan paljon tarvitsemaankin. Tämä ei ole yleisohje, vaan erikoistemppu, joka saattaa olla käyttökelpoinen joissain erikoistilanteissa.
Tietovaraston todellisesta tilanteesta saadaan tietoa keräämällä siitä statistiikkatietoja. DB2 for MVS ympäristö tarjoaa tähän apuohjelmat RUNSTATS ja STOSPACE. Seurannan kannalta oleellinen on nimenomaan RUNSTATS:in tuottamat tiedot. Markkinoilla on tarjolla muitakin tuotteita tähän tarkoitukseen.
Oleellisin ero RUNSTATS:in ja ulkopuolisten tuotteiden välillä on se tosiasia, että RUNSTATS näyttää vain tilastointihetken tilanteen, kun taas muut tuotteet tallettavat havainnot, jolloin voidaan tuottaa raportteja, joista voidaan vetää johtopäätöksiä pidemmällä aikavälillä useampaan havaintoon perustuen. Tämä puute on varsin helppo korjata perustamalla oma tietovarasto, johon RUNSTATS:in tulos talletetaan aikaleimalla varustettuna. Tästä tietovarastosta on mahdollista tuottaa raportteja erilaisiin aikaväleihin perustuen.
Ulkopuoliset statistiikan keruu ohjelmistot tuottavat tiedon mm. siitä, kuinka paljon taulutilassa tai hakemistossa on täysiä sivuja. Tämän luvun seuraaminen on varsin tarkoituksenmukaista, jos se on saatavilla.
Tietovaraston uudelleenjärjestyksen yhteydessä joudutaan tarkistamaan taulutilojen ja hakemistojen levytilan tarve. Jos käytettävissä ei ole tuotetta, joka sen laskee, joutuu TKH rakentamaan oman laskentavälineen manuaalin kaavoihin perustuen. Kun tilantarve on laskettu ja talletettu statistiikan yhteyteen, voidaan tuottaa lauseet, joilla uusi tilantarve saadaan kirjattua tiedonhallintajärjestelmään.
Tämä kirjoitus on käsitellyt hyvin karkealla tasolla tietovaraston tehokkuuden ja tilan seurantamenetelmiä. Tarkoituksellisesti on sivuutettu pohdinta siitä, kuinka usein statistiikka pitäisi kerätä ja mitkä muutokset hyvyysluvuissa antavat aihetta toimenpiteisiin. Onhan selvää että statistiikan kerääminen ei ole ilmaista ja niiden toimenpiteiden, joihin ryhdytään, pitäisi maksaa itsensä takaisin toimintojen tehostumisena. Toisaalta toimenpiteet on suoritettu oikea-aikaisesti silloin, kun ne tehdään ennen kuin tehottomuutta on havaittavasti edes esiintynyt. Tämä tekee toimenpiteiden hyödyn mittaamisen entistä vaikeammaksi.
Matti Ståhl, OCTEL Oy,