Epäjärjestys hermostuttaa, etenkin jos se on mitattavissa. Relaatiokantataulujen ja niiden hakemistojen järjestysasteen saa nykyään helposti selville. Miten järjestysasteeseen pitäisi suhtautua? Onko se käyttöorganisaation päänsärky vai olisiko sovelluskehittäjienkin sitä pohdiskeltava?
Tietokantataulujen epäjärjestysastetta kuvaa väärälle sivulle joutuneiden rivien määrä. Oikean sivun määrittelee ryvästävä hakemisto (clustering index). Jos asiakastaulun ryvästävän hakemiston avain on ASNIMI, ovat taulurivit ihannetilanteessa tarkalleen nimen mukaisessa järjestyksessä.
Eräät järjestelmät - esimerkiksi DB2 for MVS - vievät uudet rivit oikealle sivulle, jos siellä on riittävästi tilaa. Toisinsijoittuneiden osuus voi pysyä nollana kauankin, jos siroteltua tyhjää tilaa on alunperin jätetty riittävästi ja lisäykset hajautuvat satunnaisesti taulun kaikille sivuille.
Joissakin järjestelmissä lisäykset viedään mille tahansa sivulle, usein loppuun - näin toimii esimerkiksi DB2 for OS/2. Toisinsijoittuneiden määrä alkaa tällöin yleensä nousta heti ensimmäisten lisäysten myötä ja tilanne korjautuu vasta uudelleenjärjestelyssä, jolloin rivit siirretään oikeille sivuilleen.
Hakemistorivit on ketjutettava täsmälleen oikeaan järjestykseen, jotta tietty avainarvo löytyisi nopeasti. Hakemiston luonnin ja uudelleenjärjestelyn jälkeen hakemistorivien ketju kulkee yleensä fyysisesti vierekkäisten sivujen läpi.
Lisäykset viedään oikealle sivulle, jos tyhjää tilaa on - muutoin sivu halkaistaan kahdeksi puolitäydeksi sivuksi, joista toinen joutuu tiedoston loppuun tai jonnekin missä tilaa on. Hakemiston epäjärjestystä kuvaa väärään paikkaan joutuneiden sivujen määrä tai loogisesti peräkkäisten sivujen välinen keskietäisyys.
Sekä taulujen että hakemistojen epäjärjestyksen mittaluvut ovat staattisia, käsittelytavasta riippumattomia. Niillä ei ole yksinkertaista yhteyttä käsittelyn hidastumiseen.
Ehkä emme tiedä mitään tietojen käyttötavasta, näemme vain taulujen ja hakemistojen järjestysasteen. Tällöin on loogista tuottaa raportit, joissa taulut ja hakemistot on lajiteltu epäjärjestysasteen mukaan. Mahdollisen huoltokatkon aikana järjestetään raporttien mukaan huonoimpia tiedostoja niin paljon kuin ehditään. Jatkuvasti listan kärjessä oleviin tiedostoihin lisätään ehkä siroteltua tyhjää tilaa uudelleenjärjestelyvälin pidentämiseksi.
Tätä lähestymistapaa voidaan sofistikoida painottamalla kauas oikeasta sivulle joutuneiden rivien määrää, koska vain ne hidastavat peräkkäiskäsittelyä ryvästyshakemiston kautta. Perusongelmaksi kuitenkin jää oletus kaikkien tiedostojen yhtäläisestä järjestystarpeesta.
Mikä on siedettävä epäjärjestysaste? STST-kerholaisten sormituntuman mukaan 5 prosenttia toisinsijoittuneita ei yleensä aiheuta tuntuvaa käsittelyn hidastumista. On kuitenkin nähty tauluja, joissa uudet rivit ovat pääosin väärillä sivuilla mutta epäjärjestysaste on alle 5 %, koska kaikki riittävän vanhat rivit ovat oikeilla sivuilla. Jos käsittely keskittyy äskettäin saapuneisiin riveihin, taulun epäjärjestysasteen hälytysrajaa pitäisi nostaa taulun kasvaessa ja vanhojen taulurivien osuuden kasvaessa.
Taso 1 välttänee ympäristöihin, joissa huoltoajoille on runsaasti aikaa - esimerkiksi muutama tunti joka yö - ja tietokanta niin pieni, että suuri osa tauluista ja hakemistoista voidaan uudelleenjärjestää tiheästi - esimerkiksi viikottain.
Taulun epäjärjestys ei haittaa, jos taulua luetaan äärimmäisen harvoin. Tällaisia tauluja voivat olla esimerkiksi historiataulut, joihin vanhat rivit talletetaan kaiken varalta.
Jos käyttäjät tyytyvät keskimäärin hyviin vasteaikoihin eli hyväksyvät harvinaisten tapahtumatyyppien hitauden, voidaan epäjärjestyksen seuranta rajoittaa niihin tauluihin, joilla levylukujen määrä ylittää sovitun rajan.
On helppoa mitata levylukujen määrä per tiedosto per vuorokausi. Harvoin ajettavat tärkeät eräajot tekevät kuitenkin tämän lähestymistavan hieman vaaralliseksi.
Taulun uudelleenjärjestelyn kannattavuuden määrää siitä saatava käsittelyn nopeutuminen. Olisi hyvä tietää, miten moni hajaluku muuttuu uudelleenjärjestelyn jälkeen peräkkäisluvuksi; tällöin synkroninen levyaika putoaa yleensä N x 20 millisekunnista nollaan, jos peräkkäisluku on asynkronista ennakkolukua. Tässä ei tiedostokohtainen mittaus riitä; olisi tutkittava ohjelmakohtaisia I/O-määriä ja selvitettävä, missä määrin niiden kasvu johtuu tietojen epäjärjestyksestä. Tämä on periaatteessa mahdollista mutta käytännössä liian työlästä, ainakin jos tauluja ja ohjelmia on tuhansia.
STST-kerhossa pidettiin realistisena taulujen jakamista kahteen ryhmään järjestysherkkyyden mukaan:
A) Taulut, joiden käsittely ei hidastu epäjärjestysasteen noustessa.
Näitä ovat kaikki yksisivuiset taulut sekä sellaiset monisivuiset taulut, joihin ei koskaan kohdistu peräkkäiskäsittelyä: ei läpilukua eikä usean rivin lukua ryvästyshakemiston kautta. Tähän ryhmään voidaan sijoittaa myös pysyvästi keskusmuistissa makaavat taulut; epäjärjestyksen tuoma CPU-ajan kasvu on todennäköisesti kuitenkin vähäinen ongelma.
B) Muut taulut
Näiden käsittely voi nopeutua uudelleenjärjestelyn jälkeen
Ryhmittely sujuu varmaan parhaiten sovelluksittain: sovelluksen tunteva suunnittelija rastii ne monisivuiset taulut, joihin kohdistuu peräkkäiskäsittelyä. A-ryhmään jäävät rastittomat poistetaan niistä järjestysasteraporteista, joiden perusteella uudelleenjärjestelypäätökset tehdään.
Päivittäisen naularaportin (yksittäiset ylipitkät tapahtumat lajiteltuna ohjelman nimen mukaan) voidaan tarkastaa, onko jokin B-taulu luokiteltu epähuomiossa A-ryhmään: johtolangan siitä antaa tietynlaisten naulojen katoaminen uudelleenjärjestelyn jälkeen.
Jos tietokantajärjestelmä osaa sijoittaa lisäykset ryvästyshakemiston määräämälle oikealle sivulle, kannattaa luonnin ja uudelleenjärjestelyn yhteydessä jättää T % tyhjää per sivu. Miten T valitaan?
Todella kiireiset käyttävät T:lle vakioarvoa - esimerkiksi 20. Jos tietokannan levytilakustannukset ovat vähäiset, voidaan tähän tyytyä. Taulujen luokittelulla päästään kuitenkin parempaan käsittelynopeus/levytila-suhteeseen:
B1) Kyselytaulut (lisäyksiä vain uudelleenluonnin yhteydessä, ei päivityksiä)
T = 0
B2) Lisäysten kotisivu viimeinen sivu (ryvästävän hakemiston avain kasvava, esimerkiksi pvm ja klo)
T = 0, jos rivit kiinteänmittaisia
T = 10, jos rivi voi kasvaa
B3) Lisäysten kotisivu satunnainen (esimerkki: ryvästävän hakemiston avain on asiakkaan nimi)
T = 20, uudelleenjärjestelyväli = 0.1 x rivien nykymäärä / rivimäärän päiväkasvu (sivukohtaisesta sirotellusta tyhjästä käytössä keskimäärin puolet ennen uudelleenjärjestelyä; täyttyneiden sivujen määrä pieni, jos lisäykset sijoittuvat todella satunnaisesti).
B4) Lisäysten kotisivuista yksi ylitse muiden (esimerkki: tilaustaulun ryvästävän hakemiston avain on asiakkaan numero, tilauksista 10 % yhdelle asiakkaalle)
T yksilöllinen, uudelleenjärjestelyväli = T x kuuman alueen rivimäärä / kuumien rivien määrän päiväkasvu (kuumat rivit saavat sijoittua kuumalle alueelle, esimerkiksi 32 sivulle kotisivun lähellä). B4-tyyppi vaatii yksilöllistä seurantaa; toisinsijoittuneiden kokonaisosuus antaa liian valoisan kuvan uudelleenjär-jestelytarpeesta
Näissä T:n valinnan perusohjeissa on oletettu, että sivulle mahtuu ainakin viisi riviä. Pitkät rivit vaativat yksilöllistä kohtelua.
STST-kerho suhtautui skeptisesti taulujen päiväkasvun ennustamiseen. Toimivampana lähestymistapana pidettiin vierihoitoa: uusien taulujen rivimäärän kasvua seurataan muutama kuukausi. Sovelluksen tuntijoilta kaivataan kuitenkin luokittelua B1/B2/B3/B4, koska esimerkiksi lisäysten kasautumista ei ole nykymittareilla helppo havaita.
Suurkoneympäristöissä tietokantatiedostot pidetään nykyään varsin hyvässä järjestyksessä. Uudelleenjärjestelypäätös perustuu yleensä järjestysasteraporttiin - joko suoraan tai heuristisin kehitelmin. Sovellustuntemusta kannattaisi ilmeisesti hyödyntää nykyistä enemmän:. tasolta 1 tai 2 kannattaisi kohottautua tasolle 3. Jo A/B-ryhmittelyllä levylukuja voitaisiin vähentää.
Pienissä ja keskisuurissa ympäristöissä ryvästykseen ei juuri ole kiinnitetty huomiota, vaikka näissä lisäykset joutuvat useimmiten väärille sivuille ryvästyshakemistotuen puuttuessa. Uudelleenjärjestelyväli on monella taululla aivan liian pitkä ja taulurivien talletusjärjestykseksi valitaan usein kaavamaisesti perusavain. Tällaisessa ympäristössä harkittu ryvästys voisi parantaa monen tapahtuman vasteaikaa ja lyhentää monen eräajon kestoa.
Tasolle 3 ei määritelmän mukaan päästä ilman sovelluskehittäjien myötävaikutusta. Useissa isoissa taloissa on koulutettu sovellusaluekohtaisia tietokannan vastuuhenkilöitä, tietokanta-asioiden puolispesialisteja, joiden päätyö on sovelluskehitys. Näille luontuisi taulujen luokittelu ja uusien taulujen vierihoito.
Jos kirjastot toimisivat nykyisen tietokantakulttuurin mukaisesti, isoimmissa kirjastoissa laskettaisiin joka maanantaiaamu montako prosenttia kunkin hyllykön kirjoista on väärässä paikassa. Henkilökunta jäisi maanantai-iltana ylitöihin uudelleenjärjesämään ne hyllyköt, joiden järjestysaste alittaa sovitun hälytysraan - riippumatta siitä, miten asiakkaat hyllyä käyttävät, selkämyksiä silmäilemällä vai kortiston kautta. Muissa kirjastoissa palautetut kirjat pantaisiin sinne missä tilaa on, mutta hyllyn numero merkittäisiin aina hakemistokorttiin. Kirjat ryvästettäisiin vain remonttien yhteydessä. Numeron perusteella mikä tahansa kirja löytyisi nopeasti, mutta Kafkan koko tuotannon etsintä olisi tarpeettoman työlästä.
Tapio Lahdenmäki, IBM