FYYSINEN RAKENNE
Mikä on ESE?
Microsoft Exchange käyttää alustanaan ns. JET-tietokantaa. JET-tietokannasta käytetään myös nimitystä ESE (Extensible Storage Engine), joka viittaa Store-palveluun ja sen ESE.dll-komponenttiin. JET-tietokantaa käytetään muissakin Windows-pohjaisissa järjestelmissä ja palveluissa kuten esim. Active Directory, DNS, WINS ja DHCP. Exchangen tietokannasta käytetään nimitystä ESE98, jolla viitataan Exchange 2000 ja sitä uudempiin versioihin. Exchange 2010 myötä tietokannan rakenteeseen, Schemaan, on tullut merkittäviä muutoksia, jotka poikkeavat aikaisemmista versioista. Nimitys ESE98 on silti säilynyt samana.
ESE-tietokantaa kuvataan, että se on “multi-user ISAM (Indexed Sequential Access Method) database with full Data Manipulation Language (DML) and Data Definition Language (DDL) capabilities”. ISAM tarkoittaa Indexeihin perustuvaa nopeaa tiedonhakua ja Indexin avulla paikallistetaan tietue tietokannasta. ISAM on alun perin IBM:n kehittämä menetelmä Mainframe-tietokoneita varten. DLM tarkoittaa syntaksia, jolla tietokantaan voidaan lisätä, poistaa tai päivittää tietoa. DDL on syntaksi, jolla voidaan määritellä tietokannan rakenteita kuten esim. tietokantatauluja.
ESE:n fyysinen toteutus perustuu ns. B+Tree (Balanced)-puumalliin. Siinä tiedot järjestetään Blockeiksi tiedostojärjestelmän mukaisesti. Tehokkuus perustuu siihen, että tiedot tallennetaan syvyyssuunnassa mahdollisimman matalaan hierarkiaan, jotta tiedon palauttamiseen tarvitaan mahdollisimman vähän levyn I/O-operaatioita.
Tietokannan loogista rakennetta kuvaavat tietokantataulut, tietueet ja sarakkeet. Tietokanta sisältää postilaatikoita, jotka sisältävät kansioita, jotka taas sisältävät viestejä. Rakenne on hierarkkinen.
Tietokannan toiminta perustuu transaktioihin eli tietokantaan kohdistuvista sivujen muutoksista, jotka kirjoitetaan ensin transaktiolokiin ja sen jälkeen tietokantaan. Koko tietokanta voidaan palauttaa tarvittaessa lokeista.
B+Tree
ESE:n taustalla on puurakenne, joka mahdollistaa mahdollisimman tehokkaan tiedon tallentamisen ja erityisesti sen hakemisen. Tieto tallennetaan ja konvertoidaan tietokantaan käyttäen MAPI Propertyja. Tietokantaa kutsutaan myös nimellä MAPI Based Property Database File. MAPI Property on yksinkertaisesti MAPI-objektin jokin attribuutti. Objektina voi olla esim. viesti (Message) ja sen aihe (Subject) on attribuutti.
Puumallin muodostuu kolmesta tasosta, jotka ovat Root, Parent ja Child. Root määrittelee koko puun rakenteen, jonka alle muut tasot muodostuvat. Puumalli mahdollistaa myös eritasoisen hierarkian, jolloin samalla tasolla voi olla sekä Child että Parent. Exchangen sisällä on siis monenlaisia puurakenteita ja jokaisen kohdalla järjestelmä yrittää löytää mahdollisimman tehokkaan tavan toimia.
Puumallin tehokkuus perustuu siihen, että se on mahdollisimman matala. Tällöin kantaan kohdistuva I/O on mahdollisimman vähäinen. Tähän liittyy kaksi keskeistä käsitettä: korkeus (Height) ja polun pituus (Path Length). Korkeus on yhtä kuin kaikkien tasojen summa, josta vähennetään Root. Polun pituus taas määrittelee kaikki ne reitit, joilla itse dataan voidaan päästä. Kuvan mukaan on kahdeksan eri tapaa päästä käsiksi alimmalla tasolla olevaan dataan riippuen siitä, missä kohtaa puuta ollaan tietoa noudettaessa. Puun korkeus on kaksi.
Tämä rakenne myös määrittelee, montako I/O:ta tarvitaan tiedon poimimiseen.
Exchangen toteutuksessa puun korkeus on yleensä maksimissaan kolme tai joskus myös neljä. Alla olevassa kuvassa on esimerkki tällaisesta puurakenteesta. Olennaista tässä rakenteessa on, että ylempi taso tietää viittaukset alla olevaan dataan (horisontaalinen haku) ja taas toisaalta jokaisessa sivussa on tieto, mikä sivu on tätä ennen ja jälkeen (vertikaalinen haku). Tällä tavalla jokaisella I/O:lla pyritään saamaan hyvä hyötysuhde. Haku palauttaa samalla tasolla olevat sivutiedot samalla I/O:lla. Korkean Fan-outin ansiosta 50 GB tietokantataulusta pystytään poimimaan mikä tahansa tietue maksimissaan neljällä I/O:lla (kolmen viittausta ja yksi datasivua). Tätä pientä Parent-Child-rakennetta kutsutaan myös nimellä Shallow Tree. ESE tallentaa jokaisen puun tunnisteen (Key), jonka avulla se löytää koko puun kaikki tasot.
Puun Root-sivu on kuvassa ylimpänä oranssilla värillä. Sen sisällä on solmuja (Node) tai viittauksia (Reference) alla olevaan Parent-tasoon. Tätä kutsutaan myös nimellä Internal Pages. Näiden Internal Pages-sivujen sisällä on edelleen viittaus alla olevaan Child-tasoon (Leaf). Alimmalla tasolla on itse data, jota ollaan hakemassa.
Ylimmällä tasolla on tietokanta ja tietokannan sisällä on useita puita (B+ Tree). Puut muodostuvat sivuista, jotka sijaitsevat kolmella eri tasolla (Root, Internal, Leaf). Ylhäällä oleva sivu pitää sisällään viittauksia alempiin sivuihin, jotka taas viittaavat alla oleviin sivuihin ja jotka edelleen viittaavat tietueisiin (Record), siis itse dataan. Tietue on joko viittaus tai sitten itse data.
Viittauksia (Reference) muihin sivuihin voi olla noin 200 kpl jokaista 4 KB kohden (yhden viittauksen koko noin 20 tavua), jolloin 32 KB:n sivussa niitä voi olla 1600 kpl. Näin ollen yhden kolmen tason puun teoreettinen koko on 32 KB (Root) + 1600 * 32 KB (Internal) + 1600 * 1600 * 32 KB = 32 + 51200 + 81920000 = 81971232 = 80050 MB = 80,05 GB.
Tietokantataulu koostuu useasta puusta. Puita voi olla ainakin seuraavanlaisia:
- Data Tree
- Secondary Index Tree
- Long-Value Tree
- Space Tree
Jokainen tietokantataulu muodostuu yhdestä Data-puusta pitäen sisällään itse tiedon. Tietoon liittyvät eri näkymät tallentuvat ns. Secondary Index-puhuun. Esim. jos postilaatikon Inbox-kansion sisältö halutaan järjestää eri tiedon perusteella: aika, lähettäjä, tärkeys, liitetiedosto yms. Toisinaan kaikki tallennettava tieto ei mahdu taulun sarakkeeseen (Column) tai kenttään (Field). Tällöin tieto tallennetaan erilliseen Long-Value-puuhun.
Tietokantataulujen määritykset ja niiden liittymiset tiettyihin puihin tallennetaan erilliseen puuhun ns. System Catalogiin. System Catalogista pidetään identtistä kopiota järjestelmän toiminnan varmistamiseksi. Taulut ovat tietokannassa nimiltään: MSysObjects ja MsysObjectsShadow. MSysObjects on eräänlainen metataulu, taulujen taulu. Tästä siis Blogin nimikin on lähtöisin. Tarkastellaan näitä tauluja tarkemmin loogisen rakenteen puolella.
Sivun rakenne
Tietokannan pienin yksikkö on sivu ja sen koko on vaihdellut aikojen myötä: Exchange 2003 (4 KB), Exchange 2007 (8 KB) ja Exchange 2010 ja 2013 (32 KB). Exchange 2013:n koko tietokanta muodostuu siis puurakenteen sisällä olevista 32 KB paloista. Exchange 2007:ssa teoreettinen kannan koko on 2^31 eli noin 16 TB. Samalla analogialla Exchange 2010/2013-versioissa kannan teoreettinen koko on 64 TB (sivun koko 8 KB 32 KB). Tällaisten kantojen ylläpito, varmistaminen, palauttaminen ja sisäisten ylläpitotoimintojen suorittaminen on toistaiseksi mahdotonta.
Sivu sisältää kolme eri osiota: Header, Data ja Pointers. Header eli otsikko sisältää tärkeitä tietoja itse sivusta, kuten koska sitä muokattu viimeksi ja mikä sivu on tätä ennen tai tämän jälkeen. Tähän tietoon pääsee käsiksi ESEUTIL-työkalulla. Sivussa on tallennettuna tietueita, jotka eivät ole missään järjestyksessä, mutta sivussa oleva Pointer-tieto kertoo tietueiden järjestyksen.
Looginen sivu
Jokaisessa tietokannassa on alussa kaksi sivua, johon tallennetaan kannan Header-tiedot. Näitä kutsutaan myös nimellä Header Pages. Kummatkin sivut ovat identtisiä keskenään vikasietoisuuden takia. Fyysinen ja looginen numerointi poikkeaa juurikin tästä syystä toisistaan. Kaksi ensimmäistä sivua ovat loogisesti numeroita ”-1” ja ”0”.
Sivun paikantaminen vaatii hieman laskemista. Looginen sivu ”-1” alkaa kohdasta (Offset) 0 ja looginen sivu ”0” alkaa kohdasta 32768. Ensimmäinen varsinainen datasivu alkaa kohdasta 65536. Exchange 2007:ssa ensimmäinen datasivu alkaa kohdasta 16384 ja Exchange 2003:ssa vastaavasti kohdasta 8192.
Numero (Logical Page Number)
Logical page number = (byte offset ÷ 32768) – 1
Esim. sivun sijainti on 4104192, jolloin sen looginen numero on (4104192 ÷ 32768) – 1 = 124. Sivun numeron selvittäminen tulee kyseeseen, jos kanta on esim. korruptoitunut. Virheilmoitus voisi olla seuraavanlainen:
The database page read from the file "D:\exchsrvr\mdbdata\priv1.edb" at offset 98304 (0x0000000000018000) for 4096 (0x00001000) bytes failed verification due to a page checksum mismatch.
Sijainti (byte offset)
Sivun sijainti (byte offset) = (Logical page number + 1) x 32768
Jos halutaan tietää loogisen sivun tarkka sijainti, lasketaan se yllä olevan kaavan mukaisesti. Esim. sivun 44 sijainti fyysisessä tietokannassa on (44 + 1) x 32768 = 1474560. Sivu alkaa siis tuosta kohdasta.
Sivun muodostamat puut
Tiedot tietokannassa olevista sivuista ja puista saa listaamalla komennolla ESEUTIL /MS /V. Alla esimerkki.
******************************** SPACE DUMP *************************************
Name Type Owned(MB) %OfDb %OfTable Avail(MB) Avail%Tbl
=================================================================================
E:\Databases\DB1\Db\Db1 Db 136.000 100.00% 59.094
---------------------------------------------------------------------------------
Enumerated 562 Tables ( 82 Internal Trees, 12 Long Value Trees, 45 Secondary Indices )
Pages 4352 ( 1388 Used (31.9%), 2964 Available (68.1%) )
Note: This database is over 20% empty, an offline defragmentation can be used to shrink the file.
Komento listaa tietokantatauluissa olevan tyhjän tilan ja samalla yhteenvedon tauluista ja puista. Tässä tapauksessa tietokannan koko on 136 MB, jossa on pari postilaatikkoa, joissa hieman dataa. Tauluja on 562 kappaletta, joiden fyysisen rakenteen taustalla on 82 kpl Internal Tree, 12 kpl Long Value Tree ja 45 kpl Secondary indeksejä. Sivuja on kaiken kaikkiaan 4352 kpl. Sivujen Header-tiedot saa listattua komennolla ESEUTIL /M /V /P#numero tietokannan_nimi.edb. Koko tietokannan Dump-tiedosto on ladattavissa alla olevasta linkistä:
Exchange 2003
D:\DataVarasto\Technologies\Microsoft\Exchange ESE\Exchange2003>eseutil /m /v /p198 siirto3.edb
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: siirto3.edb
Page: 198
expected checksum = 0x263659c9a6c5aef9
new checksum format
expected ECC checksum = 0x263659c9
expected XOR checksum = 0xa6c5aef9
checksum <0x004B0000, 8>: 2753486944804908793 (0x263659c9a6c5aef9)
dbtimeDirtied <0x004B0008, 8>: 2931191 (0x00000000002cb9f7)
pgnoPrev <0x004B0010, 4>: 197 (0x000000c5)
pgnoNext <0x004B0014, 4>: 200 (0x000000c8)
objidFDP <0x004B0018, 4>: 341 (0x00000155)
cbFree <0x004B001C, 2>: 22 (0x0016)
cbUncommittedFree <0x004B001E, 2>: 0 (0x0000)
ibMicFree <0x004B0020, 2>: 4026 (0x0fba)
itagMicFree <0x004B0022, 2>: 2 (0x0002)
fFlags <0x004B0024, 4>: 10370 (0x00002882)
Leaf page
Primary page
Long Value page
New record format
New checksum format
TAG 0 cb:0x0008 ib:0x0000 offset:0x0028-0x002f flags:0x0000
TAG 1 cb:0x0fb2 ib:0x0008 offset:0x0030-0x0fe1 flags:0x0005 (vc)
Operation completed successfully in 0.15 seconds.
Exchange 2013
E:\Exchange\Bin>eseutil /m /v /p100 E:\Databases\DB1\Db\Db1.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: E:\Databases\DB1\Db\Db1.edb
Page: 100
HEADER checksum = 0x062406240922FFF4:0x0000000000000064:0x0000000000000064:0x18FD18FD07CF004E
checksum <0x0000000001F60000, 8>: 442485415231029236 (0x62406240922FFF4)
dbtimeDirtied <0x0000000001F60008, 8>: 504023 (0x7B0D7)
pgnoPrev <0x0000000001F60010, 4>: 94 (0x5E)
pgnoNext <0x0000000001F60014, 4>: 101 (0x65)
objidFDP <0x0000000001F60018, 4>: 13 (0xD)
cbFree <0x0000000001F6001C, 2>: 32684 (0x7FAC)
cbUncommittedFree <0x0000000001F6001E, 2>: 0 (0x0)
ibMicFree <0x0000000001F60020, 2>: 0 (0x0)
itagMicFree <0x0000000001F60022, 2>: 1 (0x1)
fFlags <0x0000000001F60024, 4>: 10250 (0x280A)
rgChecksum[0] <0x0000000001F60028, 8>: 100 (0x64)
rgChecksum[1] <0x0000000001F60030, 8>: 100 (0x64)
rgChecksum[2] <0x0000000001F60038, 8>: 1800622901054865486 (0x18FD18FD07CF004E)
pgno <0x0000000001F60040, 4>: 100 (0x64)
Leaf page
Empty page
Primary page
New record format
New checksum format
PageFlushType = 2
TAG 0 cb:0x0000 ib:0x0000 offset:0x0050-0x0050 flags:0x0000 ( )
Nodes: 0
min, ave, max, total
Logical Key Sizes: -1, 0.0, 0, 0
Node Data Sizes: -1, 0.0, 0, 0
Operation completed successfully in 0.47 seconds.
Sivujen Header-tietoja vertaamalla selviää, että tarkistussumma on muuttunut. Exchange 2003:ssa se muodostuu kahdesta 32-bittisestä osasta (yhteensä siis 64-bittiä), joista ensimmäinen osa tarkistaa sivun eheyden (XOR) ja toinen (ECC) satunnaiset korruptiot sivussa (SP1:n jälkeen). Exchange 2013:ssa on peräti 4 kpl 64-bitin tarkistussummaa. Kaksi keskimmäistä näyttää liittyvän sivun numeron tarkistamiseen (?) ja ensimmäinen ja viimeinen ovat varsinaisia sivun eheyden tarkistavia sekä satunnaisten muutosten estäviä tarkistussummia. Huomaa, että tyhjä sivu palauttaa aina virheellisen tarkistussumman.
Sivun otsikkotietojen koko on kasvanut. Exchange 2003:ssa yhteenlaskettu koko on 40 tavua ja Exchange 2013:ssa 68 tavua. Otsikot ovat lähinnä samoja, mutta 2013:ssa on muutama lisäys, tarkistussummien lisäksi on sivunumero.
Miltä sivu näyttää?
Exchange 2000 mukana tulee ESEFILE-apuohjelma, jolla voi tarkistaa sivun eheyden. Sillä voi listata myös fyysisen sivun sisällön. Ohjelma toimii vielä Exchange 2003:n kanssa, mutta ei uudempien. Tai se ei listaa mitään järkevää.
00000000 6b fc f1 66 56 58 a9 27 f8 52 1b 00 00 00 00 00 k..fVX.'.R......
00000010 13 00 00 00 16 00 00 00 02 00 00 00 5b 03 00 00 ............[...
00000020 b1 0b 33 00 0a 28 00 00 7f 80 00 00 2c 7f 80 02 ..3..(......,...
00000030 7f 80 00 01 02 0d 00 00 00 07 80 1f 00 2c 00 00 .............,..
00000040 00 02 00 02 01 00 00 02 00 00 00 01 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 80 02 00 4b 32 0c 00 01 00 ..........K2....
00000060 03 07 80 1f 00 2c 00 00 00 02 00 03 01 00 00 02 .....,..........
00000070 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 80 ................
00000080 02 00 4b 33 0c 00 01 00 04 07 80 1f 00 2c 00 00 ..K3.........,..
00000090 00 02 00 04 01 00 00 04 00 00 00 04 00 00 00 00 ................
000000A0 00 00 00 00 00 00 00 80 05 00 4c 31 30 39 30 0c ..........L1090.
000000B0 00 01 00 05 07 80 1f 00 2c 00 00 00 02 00 05 01 ........,.......
000000C0 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00 00 ................
000000D0 00 00 80 04 00 42 31 38 32 0c 00 01 00 01 07 80 .....B182.......
000000E0 1f 00 2c 00 00 00 02 00 01 01 00 00 02 00 00 00 ..,.............
000000F0 01 00 00 00 00 00 00 00 00 00 00 00 80 02 00 4b ...............K
00000FE0 6c 00 9a e9 52 00 06 ea 74 00 58 ea 4e 00 cc ea l...R...t.X.N...
<snip>
00000FF0 32 00 1a eb 32 00 4c eb 33 00 7e eb 0d 00 00 00 2...2.L.3.~.....
Rivejä on 256 kpl, joista jokaisessa rivissä on 16 tavua. Viimeinen rivi alkaa tavusta numero 4080 (0xFF0) ja sen 0-tavu on “32”. Rivin viimeinen tavu “00” on siis sivun 4096. tavu. Vaikka ohjelmalla ei voi listata uudempien Exchange-versioiden sivuja, voidaan samalla periaatteella määritellä, että Exchange 2013:ssa on 2048 riviä, joista viimeinen rivi alkaa arvolla 0x7FF0 ja sen viimeinen tavu on 0x7FFF.
Sivun otsikkotiedot
Sivun otsikkotiedot kertovat tärkeitä ominaisuuksia sivusta. Tiedot sijaitsevat sivun alussa ja niiden merkitys on seuraava:
dbtimeDirtied
Aikaleima, joka on jokaisella tietokannalla omansa. Tämä ei viittaa varsinaiseen kelloon, vaan on ikään kuin tapahtumajärjestysnumero. Jokaisella transaktiolla on oma yksilöllinen aikansa. Kahta samanaikaista transaktiota ei siis ole.
pgnoPrev ja pgnoNext
Tiedot kuvaavat, mikä sivu on tätä ennen (vasen) ja mikä on taas tämän jälkeen (oikea).
objidFDP
Tieto kertoo, mihin puuhun sivu kuuluu, yllä olevissa esimerkeissä numeroon 341 ja 13. FDP tulee sanoista Father of the Data Page. Käytännössä tämä on puun Root-sivu ja sen tunniste. FDP-sivua käytetään korjauksen yhteydessä. ObjidFDB identifioi myös taulun numeron, eli se on linkki, joka yhdistää fyysisen ja loogisen rakenteen toisiinsa. Yksi taulu voi muodostua useasta B+Tree-puusta, jolloin ensimmäisen puun objidFDP on toimii linkkinä. MSysObjects-taulussa on tieto siitä, mitä muita puita tauluun kuuluu sekä niiden puiden objidFDP (Id). Tämä käy selvemmäksi esimerkin avulla myöhemmin.
cbFree
Otsikko kertoo, paljon sivussa on vielä vapaata tilaa tavuina.
cbUncommittedFree
Arvo kertoo sivussa käytettävissä olevan tavumäärän, joita ei ole vielä tallennettu tietokantaan. Tavut ovat vapaita, mutta varattuja mahdolliseen Rollback-operaatioon. Rollback-termi liittyy transaktioon ja sitä käsitellään siinä yhteydessä tarkemmin.
ibMicFree
Microsoftin artikkeli antaa hieman puutteellisen kuvan Headerista: ”This value indicates the page offset for the next available byte at the top of the page”. Tämä arvo kertoo TAG:ien tavujen määrän yhteensä. Alla olevassa esimerkissä TAG0 + TAG1 + TAG2 = 0x10 + 0xA + 0xA = 16 + 10 + 10 = 36. TAG-rivillä Offsetin väli muodostaa arvon “cb:” Rivillä “ib:” edustaa kumulatiivista TAG:ien summan arvoa, 0, 16 ja 26. Hakasulkumerkinnät on lisätty teksiin selventämään sisältöä.
iTagMicFree
Arvo kertoo TAG:ien määrän kappaleina. TAG näyttäisi kertovan sivussa olevan datan osan (Node) ja sen sijainnin. Lopuksi on ilmoitetaan noodien määrä, joka on TAGien määrä – 1. Toisessa esimerkissä TAGeissä on viittauksia Leaf-tasolla oleviin sivuihin.
ibMicFree <0x0000000001D60020, 2>: 36 (0x24)
itagMicFree <0x0000000001D60022, 2>: 3 (0x3)
pgno <0x0000000001D60040, 4>: 2 (0x2)
Leaf page
Root page
Space tree page (spbuf: none)
Primary page
New record format
New checksum format
PageFlushType = 2
TAG 0 cb:0x0010 [=16] ib:0x0000 offset:0x0050-0x0060 [=cb] flags:0x0000 ( )
TAG 1 cb:0x000a [=10] ib:0x0010 offset:0x0060-0x006a [=cb] flags:0x0000 ( )
TAG 2 cb:0x000a [=10] ib:0x001a offset:0x006a-0x0074 [=cb] flags:0x0000 ( )
Nodes: 2
Toinen esimerkki.
ibMicFree <0x0000000001F20020, 2>: 96 (0x60)
itagMicFree <0x0000000001F20022, 2>: 7 (0x7)
pgno <0x0000000001F20040, 4>: 4 (0x4)
Parent of leaf
Internal page
Root page
FDP page
Multiple Extent Space (ParentFDP: 1, pgnoOE: 5)
Primary page
New record format
New checksum format
PageFlushType = 1
TAG 0 cb:0x0010 ib:0x0000 offset:0x0050-0x0060 flags:0x0000 ( )
TAG 1 cb:0x0013 ib:0x0016 offset:0x0066-0x0079 flags:0x0000 ( ) pgno: 13 (0xd)
TAG 2 cb:0x000e ib:0x0029 offset:0x0079-0x0087 flags:0x0000 ( ) pgno: 14 (0xe)
TAG 3 cb:0x000b ib:0x0037 offset:0x0087-0x0092 flags:0x0000 ( ) pgno: 21 (0x15)
TAG 4 cb:0x0013 ib:0x0042 offset:0x0092-0x00a5 flags:0x0000 ( ) pgno: 22 (0x16)
TAG 5 cb:0x000b ib:0x0055 offset:0x00a5-0x00b0 flags:0x0000 ( ) pgno: 23 (0x17)
TAG 6 cb:0x0006 ib:0x0010 offset:0x0060-0x0066 flags:0x0000 ( ) pgno: 19 (0x13)
Nodes: 6
Alla olevasta kuvasta näkyy Header-tiedot ja niiden sijainti sivun alussa. Lue tavut oikealta vasemmalle.
fFlags
Tieto kertoo, minkälaisesti sivusta on kyse. Exchange 2013:ssa sivuja on ainakin 32 kpl erilaisia. Ne määrittelevät muun muassa, onko sivu Root, Internal vai Leaf. Alla olevasta taulukosta selviää eri sivutyypit.
fFlags-taulukko
B+Tree esimerkki
Exchangen tietokantatauluista voi tehdä listauksen komennolla ESEUTIL /MM. Alla on esimerkki muutamasta taulusta. ObjidFDP on B+Tree:n tunniste ja PgnoFDP on kyseisen puun ensimmäinen sivu. Taulun perässä oleva tunniste ”_108” viittaa tiettyyn käyttäjään ja sen postilaatikon rakenteeseen.
******************************* META-DATA DUMP *******************************
Name Type ObjidFDP PgnoFDP
==============================================================================
E:\Da Db 1 1
Attachment_108 Tbl 179 777
<Long Values> LV 180 794
AttachmentPK Pri 179 777
Folder_108 Tbl 158 700
FolderByParent Idx 159 706
FolderChangeNumber Idx 160 709
FolderPK Pri 158 700
Mailbox Tbl 30 186
MailboxGuidIndex Idx 31 187
MailboxTablePK Pri 30 186
Message_108 Tbl 170 720
<Long Values> LV 173 771
ConversationIdUnique Idx 171 739
MessagePK Pri 170 720
MessageUnique Idx 172 755
MSysObjects Tbl 2 4
Id Pri 2 4
Name Idx 4 7
RootObjects Idx 5 10
******************************************************************************
Yllä olevat tiedot on siirretty alla olevaan kuvaan. Kuvassa on useita puita, jotka yhdessä muodostavat taulukoita. Kuvasta ilmenee myös puiden yhteydet toisiin puihin. Valkoiset sivut ovat Root-sivuja, joiden pgnoPrev- ja pgnoNext-arvot ovat ”0”, eli niitä ennen tai niiden jälkeen ei ole sivuja. Jos tieto on tallennettu useampaan sivuun, on sen viimeisen sivun pgnoNext-arvo aina ”0”. Tällöin kursori palautuu juureen. Oranssi sivu on FDP-sivu, eli sen puun ”isä”, ensimmäinen sivu. Kaikki sen puun sivut kuuluvat yhteen ja niiden objidFDP-arvo on siis sama. Jos Root-tasolla on useita sivuja, kuten esim. objidFDB 1:ssä, on sen puun ensimmäisessä sivussa viittaus seuraavaan sivuun ”Multiple Extent Space (ParentFDP: 0, pgnoOE: 2)”. Tämä tarkoittaa siis sitä, että myöskin FDP-sivuilla pgnoPrev- ja pgnoNext-arvot ovat ”0”. Vihreät sivut ovat Leaf-sivuja, joissa itse tieto sijaitsee. Ne muodostavat yleensä peräkkäisen sarjan, jos mahdollista. Yksi erikoisuus on MSysObjects-puun sivu numero 20. Sivussa on pgnoPrev ”14” ja pgnoNext ”21”, eli sen mukaan se kuuluisi näiden väliin. Mutta sivun 14 pgnoNext on ”21” ja sivun 21 pgnoPrev on ”14”! Flags-taulukosta näkyy myös se samoin kuin yllä olevasta esimerkistä, että Root-sivu voi pitää sisällään myös tietoa (Leaf, Primary). Huomaa myös objidFDP 180, jossa on useita sivualueita. Viimeinen sivualue on yli 450 kpl (2485-2940).
Puut muodostavat tauluja
MSysObjects-taulu määrittelee, miten nämä sivut ja puut liittyvät toisiinsa, eli muodostavat loogisia kokonaisuuksia, tauluja. Taulukosta ilmenee tämä asia hyvin. Taululla on arvo ObjidTable, joka on sama kuin puun objidFDP (taulukossa kenttä ”Id”). Tauluun Folder_108, jonka ObjidTable-arvo on ”158”, kuuluvat puut 158,159 ja 160 (Id eli objidFDP). Taulukosta selviää myös muitakin asioita, kuten kunkin puun FDP-sivu ja minkä tyyppisestä taulusta on kyse. MSysObjects-taulukossa on myös muitakin tietoja, mutta tässä on esitelty olennaisimmat.
Seuraavaksi
Seuraavassa osassa käsitellään Exchangen tietokannan näkökulmasta keskeisintä toimintoa, transaktiota.
Ei kommentteja:
Lähetä kommentti