Day: January 13, 2009

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.

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.