Saatteeksi
Myönnetään, että aihe on vähintäänkin haastava, mutta samalla erittäin mielenkiintoinen. Tarkoituksena on tarkastella Exchangen ESE-tietokantaa kolmesta eri näkökulmasta: fyysinen topologia, transaktiomalli ja looginen topologia. Esimerkit käsittelevät Exchange 2003, 2010 ja 2013 versioita ja ne on mainittu kussakin yhteydessä. Tietokannan toimintaa on hyvä ymmärtää, jotta ongelmatilanteissa ymmärretään, mitä pitää tehdä. Kun tilanne on ns. päällä, ei tällaisen aiheeseen tutustumiseen ole yksinkertaisesti silloin enää mahdollisuuksia, koska jokainen minuutti ja tunti on tärkeä.
Johdanto
Exchangen tietokantana on ollut JET sen koko elinkaaren aikana. Exchange 2003:n jälkeen huhuttiin, että kanta siirrettäisiin myöhemmin SQL:n päälle. Näin ei kuitenkaan ole tapahtunut. Voi olla, että tulevaisuudessa näin on. Sen verran aikaa on kulunut ja järjestelmät ovat kehittyneet, että voisi kuvitella Microsoftin tekevän tutkimustyötä SQL:n päälle siirtymisen kanssa. Tilanne saattaa myös olla se, että talon sisäisesti ei päästä yhtenevään näkemykseen tietokantamoottorista. Onhan JET-kantoja muissakin kohteissa käytössä kuin Exchange esim. Active Directory. Ja onhan JET-kannoista olemassa myös eri versioita. Exchangen alustana oleva JET on kehittynyt vuosien saatossa ja se on optimoitu Exchangea silmällä pitäen. Eräs asia mikä mietityttää näissä kantaratkaisuissa on se, että JET-kantojen hallintyökalut näyttävät tämän päivän näkökulmasta melko alkeellisilta. Alkeellisuus johtuu osittain siitä, että esim. ESEUTIL-työkalu on tarkoitettu alemman tason tietokannan operointiin sivutasolla (Page), joka edustaa kannan fyysistä rakennetta. Käytännössä ylläpitäjät eivät ole kovin tuttuja työkalun kanssa tai sen sujuva hallinta edellyttää melkoisen syvää ymmärtämistä yleensäkin Exchangen tietokannan rakenteesta ja logiikasta. Onneksi harvemmin nykyään työkalua joutuu käyttämään, sen verran kehittynyt alusta on ja siinä on itseään korjaavia ominaisuuksia tullut mukaan kuten myös paranneltu tarkistussumman (Checksum) käyttö.
Mielenkiintoista on huomata aiheeseen liittyvän materiaalin suhteen, että syvemmälle menevät artikkelit ovat verrattain vanhoja ja liittyvät Exchange 2000/2003-versioihin. Syykin on tavallaan selvä. Siihen aikaan kannoissa oli oikeasti toiminnallisia ongelmia ja Microsoftin mukaan jopa 40% kannan korruptoitumisongelmista johtui ns. Bit Flipin ansiosta eli 1 ja 0 vaihtavat paikkaa. Itse tietokannan sivu oli kunnossa, mutta se oli fyysisesti väärässä paikassa. Esimerkiksi jos Exchange muokkaa sivua numero 70 (BIN 100110). Sivu itsessään ei ole vioittunut, mutta levyohjaimen tai käyttöjärjestelmän käyttämä sivunumero muuttuu sattumalta toiseksi yhden bitin muuttuessa (BIN 000110) viallisen muistin takia. Tällöin numerosta 70 tulee numero 6. Lopputulos on se, että tarkistussumma täsmää, mutta sivun looginen numero ei täsmää fyysisen kanssa. Oli selvää, että tuolloin ylläpitäjille ESEUTIL tuli väkisinkin tutuksi. Exchange 2003 SP1 myötä tarkistussummaa muutettiin siten, että siihen lisättiin toinen tarkistussumma. Ensimmäinen tarkistaa datan yhtenäisyyden ja sen onko sivu vioittunut ja toinen (ECC) tarkistaa ja korjaa satunnaiset korruptiot.
Näyttäisi siltä, että tietokannan vioittumisen murheet ovat taakse jäänyttä, mutta niiden olemassaolo on hyvä kuitenkin huomioida. Ja edelleenkin, jos kantaan tulee murheita, on ESEUTIL edelleen se ainoa työkalu, jolla tietokantaa operoidaan. Tästä syystä on hyvä lukea hieman vanhempaakin materiaalia läpi, jotta taustat tulevat selville ja myös korjaustavat. Jälkimmäisen suhteen mikään ei ole muuttunut.
Hyviä lähteitä vanhempiin Exchange-versioihin:
- Microsoft Exchange 2000 Server: Extensible Storage Engine and Store Concepts by Mohammad Afzal, May 6, 2003 (PowerPoint-esitys löytyi)
- Microsoft Exchange: Offline Defragmentation with ESEUTIL Utility by Bill Long, June 4, 2002 (Webcast, jota ei ole saatavilla)
- Microsoft Exchange: Understanding and Resolving Error -1018 by Michael Lee, February 4, 2003 (PowerPoint-esitys löytyi)
- Understanding and analyzing -1018, -1019, and -1022 Exchange database errors http://support.microsoft.com/kb/314917
- XADM: How to Determine Which Mailbox Owns a Particular Page in a Database http://support.microsoft.com/kb/262196
- Error -1018 (JET_errReadVerifyFailure) http://support.microsoft.com/kb/151789/EN-US
- XADM: Orphaned LV Errors When Running ESEUTIL Consistency Checker http://support.microsoft.com/kb/185271/EN-US
Täytyy huomioida, että materiaali on verrattain vanhaa ja liittyy nimenomaan vanhoihin Exchange-versioihin. Microsoftilla on oikeastaan kaksi pääartikkelia, jotka käsittelevät Exchangen tietokantaa ja niistä viimeisin on Exchange 2007:een liittyen.
- Extensible Storage Engine Architecture (Exchange 2003, päivitetty 16.1.2006) http://technet.microsoft.com/en-us/library/aa998171(v=exchg.65)
- Extensible Storage Engine Architecture (Exchange 2007, päivitetty 19.11.2008) http://technet.microsoft.com/en-us/library/bb310772(EXCHG.80).aspx
Mielenkiintoista kyllä Exchange 2010:n yhteydessä dokumenttia ei ole päivitetty. Nämä kaksi artikkelia ovat sisällöllisesti hyvin lähellä toisiaan, melkeinpä identtisiä. Exchange 2010:n yhteydessä on julkaistu Storageen liittyen useampikin artikkeli, jotka käsittelevät hieman eri tavalla. Ovat ikään kuin lisänä kahdelle ESE-artikkelille.
- Understanding the Exchange 2010 Store
http://technet.microsoft.com/en-us/library/bb331958 - New Exchange Core Store Functionality
http://technet.microsoft.com/en-us/library/bb125040
Storagen mitoittamiseen on useita artikkeleita ja työkaluja, mutta niistä ei sen enempää tässä yhteydessä.
Toki Exchangeen liittyviä kirjoja on julkaistu vuosien aikana useita ja eri kustantajien toimesta. Niissä ei ole mielestäni käsitelty laajemmin tai syvemmin tietokantaan liittyviä asioita kuin näissä ESE-artikkeleissa. Ongelmana kolmannen osapuolen kirjoituksissa on asian paikkansapitävyys. Itse olen törmännyt kirjoihin, joissa on melkoisen karkeita asiavirheitä. Microsoft on julkaissut kirjan ”Exchange Server 2010 – Best Practices”, jossa tietokannasta käsitellään samoja vanhoja asioita lyhyesti, mutta sen lisäksi Data Contiguity ja Gap Coalescing asioita.
TechEDissä on pidetty viime vuosien aikana kaksi Exchangen tietokantaan liittyvää esitystä, jotka täydentävät vanhempia artikkeleita:
- Exchange 2007: ESE Internals – Ross Smith IV (TechEd 2008) http://channel9.msdn.com/Events/TechEd/NorthAmerica/2008
- Storage in Microsoft Exchange 2010 Server – Matt Grossage (TechEd 2009) http://channel9.msdn.com/Events/TechEd/NorthAmerica/2009
Tässä allekirjoittaneen kirjoituksissa ei varsinaisesti mitään uutta ole perusasioihin, koska ei niistä ole julkisesti saatavilla sen enempää tietoa. Pyrin esimerkkien avulla ehkä valottamaan hieman tarkemmin, mistä tietyissä asioissa on kyse. Tietokannan loogisen rakenteen tarkasteluun olen löytänyt työkalun, joka antaa uutta tietoa. Täytyy muistuttaa, että Exchangen tietokanta on eräänlainen mustalaatikko, joka toimii, mutta sen sisälle rakenteisiin on vaikea päästä, eikä sitä ole julkisesti juurikaan dokumentoitu. Mitä syvemmälle asiassa menee, sitä enemmän alkaa itsellä nousta esiin kysymyksiä, jotka valitettavasti jäävät ilman vastausta tai sitten niitä voi yrittää ratkaista loogisesti päättelemällä. Toisaalta ymmärrän senkin, että Microsoft ei ole julkaissut tarkempaa kuvausta ESE:n toiminnasta. Siihen tarvittaisiin kohtuullisen paksu opus erittäin vaikeasti ymmärrettävää tekstiä ja se tuskin kiinnostaisi kovinkaan montaa henkilöä. Eikä sillä olisi oikeastaan mitään käyttöä. Muistan jostain lukeneeni/kuulleeni, että Exchange 2003:n aikoihin Storage ja ESE olivat niin keskeisiä asioita, että muut asiat jäivät vähän varjoon. Tällä hetkellä niiden merkitys on toki tärkeä, mutta se ei ole enää niin keskipisteessä, kuin ennen, koska I/O-vaatimukset ovat vähentyneet niin merkittävästi ja kannan vakaus on korkea.
Ei kommentteja:
Lähetä kommentti