Adatbázis rodeó

Ez egy érdekes alkalom. Tulajdonképpen le kellene írnom egy esetet… de a jelenséget Zoli már leírta, a megoldási lehetőségeket pedig bőségesen kitárgyaltuk a kommentek között.

Akkor mit akarok én itt?

Hát, például összefoglalni. Meg fut éppen egy projektem – és ez a szívás is része volt. Szóval, hajrá.

Karácsony előtt járunk. Az erdő szélén farkasok üvöltenek, a plázákban meg a tolakodó emberek – azaz igazi karácsonyi hangulat van. December 19-én, pénteken az utolsó címlistát is benyeleztem, elégedetten toltam hátra billentyűzetet. Idén is megtettünk mindent, amit ember tehetett. Meg egy kicsivel többet is. Hazamentem. Pihenni. (Mwhaha.)

December 20. Aranyvasárnap szombatja. Az ajándékozási ösztön már a levegőt is kiszorította a plázákból. Mivel mi idén nem vettünk senkinek semmit, angyali békességben készültünk a karácsonyra. Főzőcskéztünk, tettünk-vettünk.

Aztán csörgött a telefon. Kollégám keresett. Hogy mozgatná a postafiókokat, de kardjába dőlt a szerver. Betelt a logpartíció.
– Te, be kellett volna kapcsolni a circular loggingot – korholtam meg enyhén – hiszen mondtam is.
– Bekapcsoltam.
– Igen? Hm… Most is be van kapcsolva?
– Persze.
– És a logok ennek ellenére is kidagadtak a fazékból?
– Ki bizony.
– Hm… ez érdekes. Miaf?
– Ja.
– Oké, elöször rakjunk rendet, nyomozni ráérünk utána is. Csapjatok pár gigát a partícióhoz, mountoljátok fel az adatbázist, kapcsoljátok ki-be a cirkuláris logolást. Ennek meg kell ennie a logokat.

Így is történt.

Kolléga hívott kicsit később.

– Rendben, működik.
– Örülök. Találtál valami nyomot?
– Igen. Az ügyfélnél tesztelnek egy webes ügyfélszolgálati programot. Beismerték, hogy véletlenül ráküldtek 180000 levelet a rendszerre.
– Hogy az a @&xß$…! Hát ezek teljesen meghülyültek? Migráció közben? Úgy, hogy nem is szóltak?
– Azt mondták, véletlen volt.
– Ennél még a fiam is fantáziadúsabb kifogásokat tud! Na, mindegy. A lényeg, hogy túléltük. Akkor most minden oké?
– Ja.
– Akkor hajrá. Migráljatok tovább.

Vissza a karácsonyi hangulatba. Finom ebéd, Nej remekelt. Szieszta.

A telefon csörgése ébresztett.

– Te, megint betelt a log partíció.
– Mfmvmf?
– Megállt az Exchange cluster. Betelt az egyik log partíció.
– Asztakurva.
– Mit csináljunk?
– Amit délelőtt is. Meg hívd fel a tesztelőket és helyezz kilátásba egy élvekibelezést, ha nem mennek legalább két méter távolságba a billentyűzettől. Mondjuk, egy évig.
– Oké.

Innentől nem is volt baj, egészen január 5-ig. Az új év első munkahelyi hívása útközben ért. (De még mindig jobb volt, mint tavaly.)

– Megint betelt a log partíció.
– Micsoda? Mi az, hogy log? Meg partíció?
– Exchange szerver. Tranzakciós log. Kaput. Finito. Konyec.
– Ja, már rémlik. Tudjátok, mit kell csinálni. Hamarosan bent leszek. Ja, és le kell ordítani a hajat a tesztelőkről. Egyáltalán, tesztelnek most?
– A service fut.
– Leállítani!
– Oké.

Cifrázta a helyzetet, hogy mind december 20-án, mind január 5-én mentés teszt is volt. Nem is akármilyen téttel. Nem is akármilyen mentésé.
CCR rendszerről van szó és én VSS alapú mentést álmodtam a passzív node-ra. Mert így egyfelől meg lehet növelni az adatbázisméretet (el se hiszed, milyen kevés betű van az angol ABC-ben), másfelől így az a rövid éjszaka is elég lesz mindenre. Egy valamivel nem számoltam: ez a mentési mód teljesen új volt az ügyfél rendszerében, hiányoztak a tapasztalatok, hiányoztak a kliens szoftverek. Rengeteget kellett volna tesztelnünk. Csakhogy akárhányszor elindítottunk egy mentést, annyiszor vadult be a legelső adatbázis. És ekkor már két hete ment a rendszer, kezdtek üzemszerűen is feltelni a log partíciók.
Csak nem a mentés lenne az, ami behülyíti a rendszert?

Ebben az állapotban olvastam újra Zoli írását. Nem-e lehet-e? Tudom, ezzel már hárman ülnek a gyanúsítottak padján… de mind a három eléggé esélyes.

Az első kettővel túl sokat nem tudtam kezdeni. Maradt a harmadik.

Eleve itt van a Snefi által linkelt KB cikk. Elolvastam. Hajjaj, de hányszor olvastam el. És folyamatosan úgy éreztem, ez a recept arra, hogyan lehet birkavesével földrengést előídézni. Mi köze lehet egy operációs rendszer hibájának ahhoz, hogy bizonyos nyelvi beállítások esetén elhasal rajta az Exchange 2007 adatbázis-motorja?
És mi az a másik, rejtélyes patch, melyet Snefi említett?
Oké, hívjuk a PSS-t.

Rövid idő alatt ki lettem kupálva. (Bigup for Madaras Gábor.) Tehát tényleg van egy operációs rendszer szintjén előbukkanó hiba. Ez egy olyan hiba, mely – bizonyos nyelvi beállításoknál – az Exchange ESE motorját végtelen ciklusba zavarja. Meg lehet figyelni, amikor bevadul a log, igazából nincs is levelezési tevékenység. (Check the Message Tracking Log.) A patch javítja a hibát… de nem javítja az adatbázist. Ez ugyanis olyan, mint egy vírus: ha egy adatbázis bekapja, akkor vége. Hiába gyógyul meg a szerver, az adatbázis élete végéig köhögni fog.
Két megoldás létezik rá:

  • Gyógyszert adunk az adatbázisnak.
  • Megöljük az adatbázist.

Én, személy szerint, az utóbbi megoldást favorizálom. Valahogy… olyan véglegesebb.

De nézzük először az első megoldást. A gyógyszert úgy hívják, hogy interim fix. Azért interim, mert menetközben lett rajtakapva. Tudni kell, hogy a csomag, amelyből majd a rollup pack lesz, az idők során folyamatosan gyűlik. Amíg nem lesz belőle végleges Rollup Pack, addig interimnek hívják.
Azaz az a javítás, mely kikúrálná az adatbázisunkat, jelenleg még csak interim formában létezik. Ráadásul RU7 formában, azaz saccra csak nagyon sok hónap múlva lesz véglegessé. Miközben az interim patch nem egy barátságos jószág, de nem ám. Például nem lehet Rollup Pack-ot telepíteni rá. Ha feltennéd, akkor – mivel ez egy RU7 interim, eleve le is mondhatsz a RU6-ról. Hadd ne részletezzem, mennyi balhé lehet ebből, akár csak a legegyszerűbb PSS eszkaláció esetén is.

Szóval inkább akasszuk fel.

Ehhez bizony neki kell gyürkőzni. A felakasztás ugyanis egész konkrétan offline defregmentálást jelent. Miért is? Mitől gyógyíthat egy tömörítés? Attól, ahogyan tömörít. Az offline defrag ugyanis nyit egy új, temporary adatbázist, ebbe elkezdi átmásolni a még értelmezhető leveleket. Amelyeket nem tud értelmezni, azokat kihagyja. Kihagyásra kerül minden szemét, minden sérült ezmegaz. Csak azok az itemek kerülnek át, amelyek teljesen jók. (Ez a folyamat időnként meglepően pici új adatbázist eredményez. Ezért kell feltétlenül menteni is előtte.) A legvégén pedig törli az adatbázist, a temporary-t pedig átnevezi. Ezzel a módszerrel a fertőzés tuti kiesik, hiszen azt a másoló folyamat sem képes átvinni.
Miért nem vadul be offline defrag közben az adatbázis? Azért, mert ekkor az adatbázsi le van mountolva. Az Information Store service nyüsszögve kussol a sarokban.

Frissítsük csak fel, hogyan is van ez?

Az Exchange adatbázis-kezelésének legmélyén van egy ESE motor. Ez egy nagyon primitív motor, kifejezetten egyszerű utasításokat képes megérteni. Ez fölött van egy database layer – tulajdonképpen címfordítási céllal – majd jön a DSA, mely képes minden hozzáfordulóval megtalálni a közös hangot… és képes a kéréseket lefordítani az ESE hótprimitív nyelvére.

Nagyítás

Tudom, ez nem Exchange. Ez Active Directory. De ne felejtsd el, hogy az utóbbi az előbbiből nőtt ki.

Tehát, a lényeg az, hogy az ESE szempontjából az Information Store is csak egy ügyfél a sok közül. És amikor lemountolod az adatbázist, akkor az IS elveszíti fölötte a hatalmát.
Jöhetnek a többiek, az offline adatbázis-matyizók. Mint például az eseutl. Ez ugyanúgy a DSA-t keresi meg, konkrét kérdésekkel, mint az IS. De mégsem IS.

Tehát ha offline tömörítesz, akkor menetközben védve leszel ettől a misztikus hibától. Ráadásul a végső adatbázis is tiszta lesz. Nem kell vacakolnod az interim fix okozta megkötésekkel.

Ql.

Akkor mi a probléma?

Az idő. Az ügyfelünk magyar viszonylatban a felső-közép kategóriába tartozik, összességében 500 GB adatbázissal. A Microsoft szerint az offline defrag 5-10 GB/óra sebességgel tép. Ez testvérek között is 50-100 óra leállást jelent az ügyfélnél. Ha esetleg nem lennél jó fejszámolásban, akkor ez 2-4 nap. Levelezés nélkül.

El tudod képzelni?

Muszáj lesz. Ez az egyedüli értelmes kiút. Telepíteni kell a patch-et, majd offline defrag-gal gyógyítani az összes adatbázist. Az interim fix… több megkötést hoz, mint amennyi előnyt a leállás nélküli javítás jelentene.

Tesztelve.

11 Comments

  1. Mar tobbedszerre olvasom el ezt a cikket, es valami megmoccant bennem.
    Regebben irtal az un. dial-tone helyreallitasrol. Nem lehet itt esetleg valami hasonloval kiserletezni? Ugy ertem, a beteg adatbazis helyere betolni egy tokures ujat, a beteget atpakolni egy masik mbox store-ba (ugye felcsattintani nem kell), es amig megy az offline defrag, addig is van nemi levelezes. Majd a vegen osszefesulni a dolgokat.
    Persze tudom jol, hogy az offline defrag foleg azert olyan hosszu, mert eroforrasigenyes, viszont 2-4 napig no level… :S

  2. Szerintem ott fog megbukni a mutatvány, hogy nem lehet egyszerre ugyanazon a helyen két ugyanolyan nevű edb fájl. 🙂

    Másfelől gondold el, hogy van 16 Storage Group-od. Ennyinél lenne kedved szétszedni meg összefésülgetni?
    Egyébként nem volt olyan tragikus, éjszakai leállásokkal egy hét alatt megettük. És nagyon úgy tűnik, hogy tényleg csak a First Storage group sérül. Ugyanúgy, ahogy Zoliéknál, nálunk is csak az csinálta a balhét. (Ettől persze célszerű mindet defragolni, inkább az, mint a plusz kockázat.)

  3. Ja, és az 5-10 GB/óra érték felett is elrepült az idő. Nálunk 30-40 GB/órával tekert a vas.

  4. Jo, en persze az optimista gondolkodasommal abbol indultam ki, hogy az osszes letezo store bekapta, es a logmeretnovekedest meg mar nem tudja az alatett logdiszk tamogatni; plusz nem veszhet el egy level sem.
    Nyilvan ez a letezo legrosszabb scenario, a legtobb esetben meg lehet oldani ejszakai/hetvegi mokolasokkal, esetleg a kisebb store-ban levo userek szabadsagolasaval.
    Ezzel egyutt meg kell oldani ilyen helyeken is a problemat.

    Amugy meg a osszefesulgetes a kisebbik resze a dolognak, mivel nem eves tavlatokrol beszelunk az hamar megvan. Persze minden egyes store-val eljatszani mindenkepp szivatos – de hat ha mar szivni kell, adjuk meg a modjat, nem igaz? 🙂

    Szerencsetek volt. Valoszinu az inaktiv ido nagyon jot tett a dolognak.

  5. Amugy azt en se ugy gondoltam, hogy egy idoben ket ugyanolyan nevu edb fajl letezik, mondtam is, hogy a beteg adatbazis fajljait el kell mozgatni elobb.

  6. Akkor viszont nem tudod lefuttatni az eseutil-t az adatbázisra. Legalábbis nekem úgy rémlik.

  7. Akkor kell, ha RSG-be mozgatod. Errol szolt a dial-tone cikk. Enszerintem RSG-ben kell hogy engedje mar az eseutil-t.

  8. Hú. de perverz vagy. 🙂 Nekem meg se fordult a fejemben, hogy RSG-ben küldjek rá eseutil-t. Az valahogy olyan… természetellenes. (Önmagában az RSG is hordoz magában egy csomó bizonytalanságot, nem véletlen, hogy egy csomó adatbázisfunkcióra képtelen… az eseutilról meg hadd ne beszéljek, szvsz minden Exchange admin fél tőle.)

  9. Nezd, perverzitas avagy sem, az RSG-nek megvan az a kellemes tulajdonsaga, hogy altalaban nem kap levelet meg user-kapcsolatot. Valamint recovery celokra talaltak ki. Egy lemountolt adatbazisra meg meg egy RSG sem lehet tul nagy hatassal – jelen esetben ugyis csak azert kell az egesz, hogy a gyerek karjara ra lehessen csatolni valami szalagot valami nevvel – ideiglenesen.
    Az eseutil… tudjuk, ismerjuk, jelen esetben azonban a gyogymod cimket ragasztottuk ra, tehat hasznalata kenyszeru. En is utalom a keseru pirulakat, ne aggodj 🙂

  10. Amugy meg talan meg RSG sem kell. Asszem a mailbox store-nak maganak (meg az adatbazisnak) alapvetoen mindegy, milyen storage group alatt van. Ha nem sikerult a storage group hatart kifesziteni, akkor meg ott van az a lehetoseg hogy valami nagyon csunya nevu storage group alatt csattintsuk fel hasonlo nev alatt a serult mailbox db-t. Mivel az Exchange tudtommal a teljes utvonalat letarolja a homeMDB-ben, igy nem erhet az a felelem sem, hogy oda belepotyoghatnak kosza levelek. De ez mar csak fantazmagoria, akar nem is mukodhet.

  11. Ize, a felcsattintast virtualisan ertettem, termeszetesen mountolni nem szabad… Ilyenkor este mar nem kommentelni kellene, tudom…

Leave a Reply to JoeP Cancel reply