Exchange 2007 – első adatbázis törlése

Két hete volt egy rendszerátállásunk. Mintegy háromszáz felhasználó költözött egy hétvégén Windows Server 2003/Exchange 2003-ról Windows Server 2008/Exchange 2007-re.

A költözés mondhatni sikeresen, láthatóan buktatók nélkül zajlott le. Két nappal az átállás után a helyi informatikus hívott, hogy valami (azóta is relytéjes) okból elkezdett nőni az Exchange adatbázis mérete 100% processzor terhelés mellett úgy, hogy közben senki sem dolgozott. Sikerült óránként kb. 10GB-ot hozzátenni az adatbázishoz.

Az Event Log-tól nem lettem okosabb és miután még igazán fontos adatok nem kerültek az adatbázisba megkockáztattam a gép teljesen szabályos újraindítását.

Elindult, a store is. Nem nőtt tovább a mérete (ekkor potom 42GB volt). Miután ez egy esti időpillanat volt, arra gondoltam, hogy majd másnap foglalkozom vele.

Ezt a számításomat keresztül húzta a következő telefon. Elkezdtek store hibaüzenetek keletkezni az Event Logba.

Na ez két lehetőséget adott:

1. A mindig fennálló gyűlölt csoda: eseutil

2. Miután a store még valamilyen szinten élt, átköltöztetni az összes fiókot egy új adatbázisba.

Ez utóbbit választottam. Létrehoztam egy új storage group-ot, benne egy új store-t és hiba nélkül átpakoltam mindenkit.

Ez rendben is van. Kaptam egy 2GB-os adatbázist, örülök. De mi legyen a régivel. Régi Exchange ismereteim arra figyelmeztetnek, hogy az infrastruktúra első adatbázisa, első szervere, első anyámtyúkja mindig tartalmaz valami olyan információt, amit meg kell őrizni.

Végigtúrtam a netet és azt találtam, hogy az egyetlen dolog, ami az első adatbázisban van és a mozgatás során nem költözik el az a System Attendant mailbox. Ennek a költözésével pedig nem kell foglalkozni, mert amikor megszüntetjük azt az adatbázist, amelyikben volt, akkor automatikusan újragenerálódik egy másik adatbázisban (az eredeti cikk linkjét idetenném, ha nem dobálna 500-as hibákat a Microsoft fóruma).

Kipróbáltam. Működik. Probléma megoldva. Az eredeti hiba azóta nem fordult elő.

46 thoughts on “Exchange 2007 – első adatbázis törlése

  1. Zoli, adatbázisok nem szoktak csak úgy maguktól bekattanni. Szerintem nézzél utána, milyen forgalmaitok voltak.

    Mi épp most, aranyvasárnap jártunk úgy, hogy a frissen migrált Exchange szerveren az egyik adatbázisnál bevadultak a logok és – annak ellenére, hogy kínunkban már körkörösre állítottuk – így is pár óra alatt felzabálták a 20 GB helyet.
    Ott is azt mondta az ügyfél, hogy senki nem dolgozik… aztán később derült ki, hogy valami ügyfélszolgálati modult teszteltek és véletlenül ráküldtek száznyolcvanezer(!) levelet néhány postafiókra.

  2. Rollop 5-ben nem tudom még él-e a hiba, de RU3-ban még biztosan benne volt. Egy bizonyos karaktersorozat bekerülése miatt bolondul meg a store, pontosabban a logok. Találni nem fogtok róla semmit, mert csak interim fix volt rá Premier Support-nál. Ha ugyanaz a hiba jelentkezett.

  3. Hello
    Aha 🙁 nem egy szep latvany 🙁
    most mar a magyar premier suppoort is tudja a megoldast ra… az exhange-esek ismerik a hibat es allitolag a 6-os rollup-ba fogjak beleteni a hotfixet.

    Udvozlettel:Sneff Gabor

  4. Hali,

    Érdekes, hogy mi kerekedett ebből a cikkből. Az eredeti cél az volt, hogy tudassam, az SA mailboxot nem kell költöztetni, költözik magától.
    A hotfixre kitérve. Ha valaki tud egy KB számot mondani akkor felteszem, ha nem akkor megvárom a következő elszállást, vagy a rollupot.

    üdv,
    Zoli

  5. Azért van abban némi pikantéria, hogy pont a legpörgősebb bejegyzés pörgése alatt tört rám a skin lecserélésének kényszere. 🙂

    Elnézést, ha valakit megzavartam volna.

  6. ha arra gondolsz, hogy win2008 megpatchel, aztan offline defrag minden adatbazison, akkor igazabol az nem workaround, hanem maga a megoldas, az interim fixes moka a workaround – attol fuggetlenul, hogy 500 giganyi store-nal azert ez eltart egy ideig, ha pedig meg ccr clusterben is volt, akkor lehet ujraseedelni az egeszet, es az addigi menteseket kidobni. nem tul lelkesito feladat, de egyszer tul kell lenni rajta…

  7. Így van. Annyival egészíteném ki a folyamatot, hogy CCR környezetben az offline defrag és reseed után rá kell küldeni még egy mentést is, hogy lepucolja az aktív node-on beragadt logokat. (Legalábbis nálunk eddig ez a tapasztalat, de még csak egy, meglehetősen beteg adatbázison vagyunk túl.)

  8. Hello! Teljesen véletlenül találtam ezt a blogbejegyzést, látszólag mi is ugyenezzel szívunk.2008+exch2007sp1.Amit snefi irt,a kb955612-esre a patch-et feltettük, szerver újraindít, stb.
    Ma estére újra elindult a rejtélyes másodpercenként kb 2megás hízás.
    Jól látszik ilyenkor a logokban, hogy egy “szétrobbant” levélfejléc töredék ismétlődik a végtelenségig, ezt folyamatosan tömi az adatbázisba. Közintézmény lévén hivatalos supportunk gyakorlatilag nincs, viszont meg kellene oldanunk a helyzetet. Nagyon hálás lennék,ha valaki minimálisan tudna segíteni.

  9. Szia,

    Jó úton jártok. Az első lépés a patch, utána pedig javítani kell a sérült adatbázist. (Ha már egyszer bekapta a legyet, akkor akár naponta is meghülyül.)
    A javítás legegyszerűbb módja az offline defrag. (Elméletileg működhetne az is, hogy létrehozol egy új adatbázist és oda mozgatsz át mindenkit – de ekkor félő, hogy mozgatás közben vadul be az adatbázisod.)

    Egyébként hamarosan lesz erről egy részletesebb írás is, csak most még mi is várjuk, mi lett a hétvégi műtét eredménye.

  10. Köszönöm a választ, akkor még reménykedem!

    Bár az a “naponta”, kb 3 óra összesen, ahogy eddig is ez ment, tehát a patch látszólag semmit nem javított.
    Mintha snefi említett volna valami “másikat”, ezekszerint nem elég egy patch?

    Megint ez megy, kitölti ami helyet adok, majd leomlik a store. Adok neki még helyet, mountolom, megy egy kicsit, max pár órát, paff, hízás, omlás.
    Az offline defrag azért mókás, mert legutóbb mikor belekezdtünk 3 óra alatt lépett a 250gigás adatbázison 2%-ot.
    Azóta erősebb gépre és nagyobb hdd-re pakoltuk az egészet, de ha 150óráig nincs levelezés, akár a felmondólevelünket is írhatjuk…

    Egyszer már megcsináltuk az online költöztetést uj adatbázisba pont ezért, persze túrót nem ért, azóta megint 250gigánál tartunk vagy 8-10 omlással és sok napos-félnapos kimaradással.

    Kinunkban már azon töprengünk, végleg vagy esetleg csak ideiglenesen visszatesszük az egész szajrét 2003alá 🙁

  11. Csapjatok az asztalra. Sajnos más esélyetek nincs… és ezt a döntéshozóitoknak is meg kell érteniük. A leállás nélküli javításhoz egy nem hivatalos, ún interim fixet kell kérni az MS-től – de ilyet csak akkor kaptok, ha van PSS szerződésetek. (Másét nem tudjátok használni, mert személyre, pontosabban, rendszerre szabott.)

    Ha a másolás nem működött – bár a fentebbi írásban Gömöri Zolinak bejött – akkor csak az offline defrag marad. Az MS szerint erre úgy kell kalkulálni, hogy 5-10 GB/óra. (Nekünk sokkal gyorsabb volt, de ehhez olyan hardver is kell.)
    Egész egyszerűen, ha ki akartok mászni ebből a szutyokból, akkor ennyi leállásra szükségetek lesz. (Na meg plusz 250 GB helyre is a szerveren.)

    Apropó, hogyan lehettek ennyire trehányak? Az Exchange-ben szigorú ajánlás, hogy adatbázis nem lehet 100 GB-nél nagyobb! Többek között, pont az ilyen szívások elkerülése végett..

  12. Oké, köszönöm, bízzunk benne, hogy ennyi leállás elég lesz.
    Az igazán izgalmas szituáció akkor jön, ha több nap leállás és defrag után is újfent hisztizni kezd.
    MS PSS ? Hol vagyunk mi attól… 🙂
    Nem kezdem el telemesélni a blogot evvel, kb arról van szó, van a campusban olcsóér’ ezaz, plusz mindíg kitalált valami főokos valamit, lett egykét új(abb) szolgáltatás, vele egykét ujabb épphogymegáll-a-vason szerver plusz 5* annyi szívás.
    Aztán mostanra ebben a helyzetben billeg az egész intézmény, két csóró közalkalmazott fillérekért kéne, hogy naprakészen életbentartson egy 400gépes hálózatot, szoftverice, hardverice, kapcsolódó 300+600user nyűgjeivel, hadnesoroljam 🙂
    Egy külsős amint bejönne az ajtón, röhögőgörcsöt kapna, és mondana egy olyan összeget erre az informatikai szolgáltatásra kiindulásnak, ami a teljes intézményi keret duplája.
    Na, mostmár sejtheted mi okozza a “trehányságot” 😉
    Habár kicsit lazán értelmezve a “korlátot”, most a legújabb karácsonyi PPS és hasonló “levélszemét” áradattal léptük át azt a bizonyos 100gigát épphogy, már a postafiókok tényleges métetét tekintve.
    Mert a “titokzatos hízás”, ami a maradék 150et hozzárakta, korlátlannak tűnik. Ha engedném, 2000gigát telecsócsálna 1-2 nap alatt, közben félig haldokolva.
    Gyanítom ha az emberek felét másik store-ba nyomom át karácsony előtt, akkor annyit “nyertem” volna ezen, hogy most két store hízna amikor megbolondul, esetleg felváltva, hol az egyik, hol a másik.

  13. Ha ez vigasztal, nálunk szombat este volt meg az offline defrag és azóta nem volt semmi bevadulás. Emellett a PSS szerint is ez a korrekt megoldás.

    Csak a vicc kedvéért, legközelebb kérdezd már meg a főnöködet, hallott-e már olyasmiről, hogy ITIL? 😉

  14. Ha hallott is róla, kb annyira megy vele, mintha valaki indiában kezdené el a helyi iszappal borított ladikosoknak magyarázni, a norvég halászhajókon érvényben lévő munkavédelmi előírásokat 😉
    Tetszik a blog egyébként, kissé dezsavüm támadt néhány bejegyzést olvasgatva, plussz átérzem azt a mázlit, hogy eddig az évek során többékevésbé fennakadás, adatvesztés, stb mentesen pörgött az exchange.
    Azért is van most extra balhé, mindeki természetesnek és magátólértetődőnek tekinti a 99,99%-os rendelkezésreállást.

  15. Nos, végül az történt, amitől tartottam, este 9 körül 33%-ig elközdötte magát az offline defrag, majd magáhozrántotta az összes ramot, a prociterhelése lezuhant 1% alá, és reggel 10ig ebben az állapotban töprengett az élet értelmén. 12óra alatt egyetlen további byte-ot nem tudott az uj adatbázishoz tenni.
    Miután nem tudtam reggel 8kor várható befejezési időt mondani, sőt azt sem, hogy egyáltalán csinálja vagy sem, tehát újfent vissza a kályhához. Adatbázis visszapakol 2003alá, egy másodlagos mailszerverre, -remélhetőleg ott nem jön elő a behülyülés-, majd egy habtiszta (immár megpatchelt) 2008-on futó adatbázisba az összes postafiók átmozgat…cross your fingers..:D

  16. Te, MasK, nagyon betegnek kell legyen az a szerver, ha ilyeneket produkal. En elgondolkodnek egy memtest-en, meg ugy altalaba felnezni az MS oldalara, hogy a minimum system requirement-et azert teljesiti-e. Esetleg par szolgaltatast ki kell paterolni onnnan…

    Tudom, hogy az Exchange nagyon jol skalazodik, nekem egy p1 128mb-s gepen szaladgalt a ex2k3 egy win2k3 rc alatt tesztgepkent stabilan, de ettol fuggetlen ez nagyon messze van a kivanatostol.

  17. A szerver (amin a defragot próbáltam) köszöni jólvan, semmiféle P1, hanem egy corequad 2,4-es vas 4gig rammal.. gyakorlatilag nem szerver konfig, az tény, de a lehetőségekhez képest brand cuccokból van összedobva.

    Inkább olyan a jelenség, mintha bizonyos fokú összeomlás után maga az eseutil sem boldogulna az adatbázissal, holott az mountolható és valódi adatvesztés nincsen.
    Az összes offline edb mutyizó ugyanígy reagál egyébként, megnyitja, analizál 33%ig, majd ott elkezd a memóriafoglalás növekedni, 3gig környékén megakad, és itt meghalt.
    No nem maga a program fagy széjjel, az a szál fut tovább, hanem valahol a mélyben összeakadnak a fogaskerekek. A megállt folyamatot szabályosan megszakítva 2mp alatt hibátlanul kilép, (memóriát is felszabadítja!) mintha mi sem történt volna.

    Beszédes adat, hogy az eredeti postafiókok kb 102gig adattarttalmával szemben ez az edb mintegy 6-8 “menetben” 260gigára növekedett az őrület által belepakolt ciklikus szeméttel.

    Egyébként 2003ra visszatelepítve a beteg adatbázis is hibátlanul ketyeg, újabb megőrülés legcsekélyebb jele nélkül!!

    Tehát a 2008-nak még mindíg van valami gixere szvsz, ami miatt nem elég a patch, hanem új “tiszta” edb-t kell gyártani.
    Ilyen szimpla esetben mint a miénk, ez a legegyszerűbb megoldás szerintem: feldobni egy szabad gépre a 2003-at, átpakolni az adatbázist oda, elindítani, innentől értelemszerűen online módon gyógyítható a dolog: postafiókok átpakolása tiszta adatbázisba, ideiglenes szerver megszüntetése.

  18. A patch után a w2k8 már tiszta, az adatbázisban marad benne az őrület. Ennek az ignorálására kell az interim fix, vagy az adatbázis gyógyítása.

  19. Elvileg. Gyakorlatilag meg napok óta ketyeg a beteg kihízott adatbázis 2003 alatt, és semmiféle jelét nem mutatja, hogy újra hízni kezdene.
    Tévedés ne essék, én messze nem vagyok M$ guru, még normáális supportom sincsen, csak azt tudom leírni amit tapasztalok.
    Kérdés mi lesz, ha a system attendant cucca is visszakerül a 2008 szerveren futó adatbázisba…nekem gyanus, hogy ez valahogyan
    reméljük a legjobbakat:D

  20. Nem, én úgy gondoltam, hogy a már ‘fertőzött’ adatbázisod _W2k8-on_ produkálja a hibát, függetlenül attól, hogy patchelt az oprendszered vagy sem. A patch csak abban segít, hogy a még egészséges adatbázisaid ne romoljanak el.

  21. Igen, ez világos is, illetve félhomályos, mi különbözik ennyire a 2003 és a 2008 közt, még a patch után is! 😀
    Az sem egészen érthető, miért nem tudom a beteg adatbázist 2008 alatt offline javítani.. talán 2003 alatt megcsinálná, de mivel így már online is helyreállítható, semmi értelme nincsen végigvárni.

    Az előbb azt akartam írni még, mintha a system attendant postafiókot érintené csak a dolog, tehát valamiért az az edb csavarodik össze, amiben az található, a többinek semmi baja…(??)
    Ezzel még kisérletezgeni fogok.

    Lehetett volna még dialtone recovery-t is játszani, tehát normálisan olyan nem lehetne, hogy a levelezés napokon keresztül döglött…

    Ez a mizéria nekem mindenesetre jó tanulság volt, hogy mindíg több lábon kell állni, több szerver, több oprendszer, vészesetre mindeféle B terv, nem szabad a hibátlanban bízva hűbelebalázs módjára migrálni.

  22. Hali,

    Elsősorban Mask-nak. Az a rendszer amiről az eredeti cikk szólt, újra produkálta a hibát. Most másodszor is sikerült online javítani. Szerintem próbáld meg te is.
    Tehát:
    – Hotfix felrak
    – Store újraindít (ekkor egy ideig valószínüleg nem produkálja a hibát
    – Új Storage Group és Store létrehoz
    – Összes mailbox átmozgat
    – Régi Storage Group töröl
    – örül. 🙂

    üdv,
    Zoli

  23. Zoli! Ez történik most, avval a különbséggel, hogy win2003 alá visszatelepítve ketyeg a beteg adatbázis.
    Ott ugyanis _nem tud_ megőrülni. Naponta 70-80 postafiók megy át, jellemzően későeste, amikor már nem dolgoznak, tehát nem zavarja őket, hogy a másolás idejére elérhetetlen a cuccuk.

  24. Szia,

    Elméletileg a RUP7 már kint van, de ha frissen telepítesz Exchange 2007-et Windows Server 2008-ra, akkor az írásban is említett Windows patch felrakásával megelőzheted a bajt.
    (A RUP7-et nem teszteltem ilyen szempontból.)

  25. Nálunk tegnap Win2008 alatt, RUP8-cal hasalt el az Exchange ugyanezekkel a tünetekkel. A kb955612-ben írt két hotfix még nem volt telepítve, így most az lesz a következő lépés. Reméljük, hogy a mailboxok átmozgatása sikeres lesz, nem álldigálhat a levelezés még egy napot…

Leave a Reply

Your email address will not be published. Required fields are marked *