[Exch03]Wat doen na de reparatie van een EDB corruptie

[Anoniem: 25534]

Onlangs hebben wij te kampen gehad met een database corruptie. Deze was destijds opgelost door een reparatie uit te voeren (eseutil en isenteg).

De database in kwestie heeft toen circa een maand gedraaid en is afgelopen weekend, na een succesvolle online defragmentatie (volgens event viewer), er toch weer uitgeklapt. Wat weer resulteerde in een vastlopende server.
De server is in veilige modus gestart, exchange services uitgezet, en de database weer gerepareerd. Ditmaal op de meeste snelle manier (eseutil /p), om hem zo snel mogelijk weer up en running te krijgen.

Dit werkte.. voor de volle 5 minuten en daarna klapte hij er weer uit.

Conclusie.. we moeten een nieuwe .EDB gaan maken. Geen probleem, maar wat te doen met de data in de vorige database.
We kunnen natuurlijk Exmerge gebruiken, maar deze maakt er .PST bestanden van, houdt dit in dat ik per mailbox een .pst moet gaan maken? Of zijn hier andere methoden voor?

Verschrikkelijk irritante situatie waar ik nu tijdelijk werk op een database van eerder deze week, en een gerepareerde database met de laatste mails heb, die hoogstwaarschijnlijk nog uitgelezen kunnen worden, maar niet lang meer zal draaien.

O/S: Windows SBS 03

[Anoniem: 108274]

Als je geen back-up meer hebt die je makkelijk terug kan zetten zou je eens naar Ontrack Powercontrols moeten kijken. Deze doet denk ik precies wat je wil (super om te hebben trouwens) maar kost wel een paar duiten.....

[Anoniem: 25534]

Ik heb wel diverse back-ups, maar er ligt mij iets bij dat Microsoft melding maakt dat men na het repareren van een corrupte database een nieuwe database moet maken omdat de fout terug kan komen. Ofwel alle back-ups zijn bruikbaar maar zijn gedoemd om weer mis te gaan binnen een bepaalde tijd.

Maar als ik dit zo napluis kan ik er weinig over vinden.. iedereen heeft het maar over de database repareren en daarna hoor je er niets verder over, het kan dus zijn dat ik me ergens mee verwar, maar dan is het alsnog raar dat de database weer corrupt raakte als hij vorige maand volledig is gemaakt, gedefragmenteerd, gecheckt en etc.

[ Voor 36% gewijzigd door Anoniem: 25534 op 17-05-2010 16:11 ]

[Anoniem: 120725]

http://msexchangeteam.com/archive/2004/06/18/159413.aspx

Als je database weer corrupt raakt, dan zou ik persoonlijk je event logs eens napluizen op errors, met name hardware (disks..). Ook zorgen dat je antivirus goed geconfigureerd is (dus dat deze niet de exchsrvr folders scant).

Verder, als je database lang genoeg in de lucht blijft om exmerge te gebruiken moet je dat doen, anders kan je zoals al aangegeven OnTrack of zoiets gebruiken. Maar ik zou eerst maar eens gaan kijken waarom je corruptie krijgt....

[Caeruleus]

idd antivirus en dat soort dingen checken.
Maar als je verder wil met je nieuwe database, kun je dan niet een Recovery Storage Group gebruiken? En dan de backup / database die je niet vertrouwt in de recovery storage group en de inhoud mergen met de nieuwe database?

Zie halverwege de pagina, "merging the databases" : http://www.msexchange.org...Restore-Method-Part3.html

[ Voor 6% gewijzigd door Caeruleus op 17-05-2010 16:20 ]

[Anoniem: 25534]

Anoniem: 120725 schreef op maandag 17 mei 2010 @ 16:14:
http://msexchangeteam.com/archive/2004/06/18/159413.aspx

Als je database weer corrupt raakt, dan zou ik persoonlijk je event logs eens napluizen op errors, met name hardware (disks..). Ook zorgen dat je antivirus goed geconfigureerd is (dus dat deze niet de exchsrvr folders scant).

Verder, als je database lang genoeg in de lucht blijft om exmerge te gebruiken moet je dat doen, anders kan je zoals al aangegeven OnTrack of zoiets gebruiken. Maar ik zou eerst maar eens gaan kijken waarom je corruptie krijgt....

In event viewer komt er gewoon niets terug. Nou, bijna niets, ik zie dat een kwartier voor me allerlaatste event viewer melding, de stores zijn gedefragmenteerd.
Maar dit was succesvol.

Als ik dit vergelijk met de logbestanden van vorige week, komt dit exact overeen. Ik zie ook geen event die iets met de services doet oid.. het blijft dus weer eens gissen.

[ Voor 9% gewijzigd door Anoniem: 25534 op 17-05-2010 16:43 ]

[Anoniem: 120725]

Je hebt ook in je system log gekeken? En je file level antivirus is goed ingesteld?
Overview of Exchange Server 2003 and antivirus software

[Anoniem: 25534]

De antivirus slaat specifiek de exchange folder over, tenminste deze staat als exclude aangegeven. En in de opties staat ook nog eens aangegeven de exchange folders over te slaan (optie in Trend Micro).
En Systeem, in event viewer laat me niets zien, tot het moment dat de server weer opkomt.. dus daar heb ik ook niets aan.

[Anoniem: 120725]

Wat bedoel je trouwens met een vastlopende server?

[Anoniem: 25534]

Anoniem: 120725 schreef op maandag 17 mei 2010 @ 17:14:
Wat bedoel je trouwens met een vastlopende server?

Een bij effect, van het inladen/mounten van de database.
Door het starten van de exchange services(information store), worden ook databases geladen, en dit heeft als directe gevolg dat de server vast loopt.

[Anoniem: 120725]

Vast lopen als in? Je kan er via rdp niet meer bij? Je kan niet meer interactief inloggen? Je kan niet meer pingen? Vastlopen is nogal een vage omschrijving .

[Anoniem: 25534]

Anoniem: 120725 schreef op maandag 17 mei 2010 @ 19:05:
Vast lopen als in? Je kan er via rdp niet meer bij? Je kan niet meer interactief inloggen? Je kan niet meer pingen? Vastlopen is nogal een vage omschrijving .

Vastlopen als in in bevriezen.. vastlopen, vastlopen dus.

[Anoniem: 120725]

Helemaal bevriezen? Je moet de server handmatig uit-en weer aanzetten? Dat lijkt me dan niet aan Exchange te liggen maar eerder hardware gerelateerd (geheugen zou heel goed kunnen). En dat zou dan je corrupte stores weer goed kunnen verklaren

[Anoniem: 25534]

Anoniem: 120725 schreef op maandag 17 mei 2010 @ 19:20:
Helemaal bevriezen? Je moet de server handmatig uit-en weer aanzetten? Dat lijkt me dan niet aan Exchange te liggen maar eerder hardware gerelateerd (geheugen zou heel goed kunnen). En dat zou dan je corrupte stores weer goed kunnen verklaren

Dat lijkt me niet echt logisch aangezien dit probleem opgelost is wanneer ik de database repareer.

[@r!k]

Anoniem: 25534 schreef op dinsdag 18 mei 2010 @ 08:56:
[...]


Dat lijkt me niet echt logisch aangezien dit probleem opgelost is wanneer ik de database repareer.

Maar je zegt zelf al dat dit niet goed blijft gaan. Als je nou echt wil troubleshooten zou ik zeggen installeer een nieuwe server en move alle mailboxes daarnaartoe en ga daarna naar hartelust troubleshooten op dat ding. Memtest enzo draaien.

[Anoniem: 25534]

@r!k schreef op dinsdag 18 mei 2010 @ 09:00:
[...]


Maar je zegt zelf al dat dit niet goed blijft gaan. Als je nou echt wil troubleshooten zou ik zeggen installeer een nieuwe server en move alle mailboxes daarnaartoe en ga daarna naar hartelust troubleshooten op dat ding. Memtest enzo draaien.

Dat is inderdaad een goede mogelijkheid. Ik zit er zelf aan te denken om de huidige omgeving virtueel te maken zodat ik op een andere server kan gaan werken. Het toevoegen van een nieuwe server in de live omgeving is ook niet bevoordelijk voor je netwerk.

Maar is het bij jullie bekend dat een database, na corruptie, totaal opnieuw gemaakt dient te worden om dit soort problemen te voorkomen? Ik kan er zelf maar bar weinig over vinden, en dat terwijl het ergens in me hoofd is blijven spoken.

[Anoniem: 120725]

Anoniem: 25534 schreef op dinsdag 18 mei 2010 @ 08:56:
[...]


Dat lijkt me niet echt logisch aangezien dit probleem opgelost is wanneer ik de database repareer.

Een harde reset is nou niet echt bevorderlijk voor de gezondheid van je database. Maar goed, als dit probleem terug blijft komen zou ik toch echt een 2e server ernaast zetten en je mailboxen moven om de hardware uit te sluiten.

En van de link die ik je al eerder gaf:

Whether you should leave a repaired database in production is a matter of philosophical disagreement, with your own tolerance for risk factoring in. If you want to be 100% sure that the database is completely OK after successful repair, rather than just being 99.9% sure, then I suggest moving all mailboxes to another database, and then deleting the repaired database. After deletion, next time you start the database, a new one will be automatically generated, and you can move the mailboxes back. If it's a public folder database, then replicate all folders, delete the database, and replicate them all back to a fresh database.

[Anoniem: 25534]

Anoniem: 120725 schreef op dinsdag 18 mei 2010 @ 09:36:
[...]

Een harde reset is nou niet echt bevorderlijk voor de gezondheid van je database. Maar goed, als dit probleem terug blijft komen zou ik toch echt een 2e server ernaast zetten en je mailboxen moven om de hardware uit te sluiten.

En van de link die ik je al eerder gaf:


[...]

Ik denk dat ik er zo inderdaad wel moet uitkomen. Laat jullie wel weten wat ik uiteindelijk heb gedaan.

[@r!k]

Anoniem: 25534 schreef op dinsdag 18 mei 2010 @ 09:19:
[...]


Dat is inderdaad een goede mogelijkheid. Ik zit er zelf aan te denken om de huidige omgeving virtueel te maken zodat ik op een andere server kan gaan werken. Het toevoegen van een nieuwe server in de live omgeving is ook niet bevoordelijk voor je netwerk.

Maar is het bij jullie bekend dat een database, na corruptie, totaal opnieuw gemaakt dient te worden om dit soort problemen te voorkomen? Ik kan er zelf maar bar weinig over vinden, en dat terwijl het ergens in me hoofd is blijven spoken.

Als er bij ons een database klapte was dat inderdaad de standaard procedure. 1e keer keken we afhankelijk van de gebruikers op die database soms nog even aan maar meestal maakten we meteen een nieuwe database aan en werden de gebruikers gemoved.

Sta overigens niet raar te kijken als je nieuwe database kleiner is dan je huidige op het moment dat alle users gemoved zijn. Je whitespace ben je ook meteen vanaf namelijk.

[Anoniem: 25534]

@r!k schreef op dinsdag 18 mei 2010 @ 10:19:
[...]


Als er bij ons een database klapte was dat inderdaad de standaard procedure. 1e keer keken we afhankelijk van de gebruikers op die database soms nog even aan maar meestal maakten we meteen een nieuwe database aan en werden de gebruikers gemoved.

Sta overigens niet raar te kijken als je nieuwe database kleiner is dan je huidige op het moment dat alle users gemoved zijn. Je whitespace ben je ook meteen vanaf namelijk.

Maakte jij een extra store aan op de huidige server? Of hadden jullie een extra server tot je beschikking?

Nog een korte vraag, kan ik een database van de ene server inladen in een nieuwe server als deze in hetzelfde domein zit? Ik weet dat een database normalitair alleen ingelezen kan worden in dezelfde omgeving (server) als waar hij vandaan komt.

[Anoniem: 120725]

Anoniem: 25534 schreef op dinsdag 18 mei 2010 @ 10:26:
[...]


Maakte jij een extra store aan op de huidige server? Of hadden jullie een extra server tot je beschikking?

Nog een korte vraag, kan ik een database van de ene server inladen in een nieuwe server als deze in hetzelfde domein zit? Ik weet dat een database normalitair alleen ingelezen kan worden in dezelfde omgeving (server) als waar hij vandaan komt.

Nee, database portability kan pas vanaf Exchange 2007.

[Anoniem: 108274]

Heb je trouwens de laatste Exchange servicepack en die van de server al eens opnieuw geïnstalleerd?

[Anoniem: 108274]

Anoniem: 25534 schreef op dinsdag 18 mei 2010 @ 09:42:
[...]


Ik denk dat ik er zo inderdaad wel moet uitkomen. Laat jullie wel weten wat ik uiteindelijk heb gedaan.

Welke procedure ga je doen? Een tweede server erin hangen, exchange installeren, en dan de mailboxen verplaatsen?

Besef dan wel dat je behoorlijk wat stappen zal moeten ondernemen om de eerste server (als deze defect is) weer uit het netwerk te "mogen" halen. Het is niet gewoon mailboxen verplaatsen, eerste server uit en draaien maar. Dan werkt je exchange installatie namelijk alsnog niet. Je mist dan je Public store, connectoren etc.

Als je hardware uit wilt sluiten kun je bijvoorbeeld met Vconverter (esx) de server virtueel zetten. Dat lijkt me een stuk simpeler. (just my two cents).

Tevens wil het (al heb ik dat niet meer verkeerd zien gaan sinds exchange 2000) nog wel eens gebeuren dat bij het moven van een mailbox naar een andere server de mail niet verplaatst worden. Je ziet dan de verwijzing wel veranderen maar de data staat niet in de nieuwe edb. (daarna heb je ontrack echt nodig )
Zeker als de eerste server al rot is, lijkt me dit niet lekker.

[Anoniem: 25534]

Anoniem: 108274 schreef op woensdag 19 mei 2010 @ 11:07:
[...]


Welke procedure ga je doen? Een tweede server erin hangen, exchange installeren, en dan de mailboxen verplaatsen?

Besef dan wel dat je behoorlijk wat stappen zal moeten ondernemen om de eerste server (als deze defect is) weer uit het netwerk te "mogen" halen. Het is niet gewoon mailboxen verplaatsen, eerste server uit en draaien maar. Dan werkt je exchange installatie namelijk alsnog niet. Je mist dan je Public store, connectoren etc.

Als je hardware uit wilt sluiten kun je bijvoorbeeld met Vconverter (esx) de server virtueel zetten. Dat lijkt me een stuk simpeler. (just my two cents).

Tevens wil het (al heb ik dat niet meer verkeerd zien gaan sinds exchange 2000) nog wel eens gebeuren dat bij het moven van een mailbox naar een andere server de mail niet verplaatst worden. Je ziet dan de verwijzing wel veranderen maar de data staat niet in de nieuwe edb. (daarna heb je ontrack echt nodig )
Zeker als de eerste server al rot is, lijkt me dit niet lekker.

Ik denk dat je uitgangs punt verkeerd is begrepen. Alleen de EDB is corrupt van die server, de server zelf is niets mee aan de hand. Het was een modje die dacht dat de hardware defect was, maar dit is niet zo.
Tevens is het nog even wachten op wat we nou verder gaan doen. Server is van een klant, die bepaald wat hij verder wilt gaan doen. Heb hem meerdere scenarios toegesplits.

[Anoniem: 120725]

Een corrupte MDB hangt echt je server zo niet op hoor dat je er totaal niks meer mee kan doen, er is wel degelijk iets meer aan de hand (ik heb ervaring met exchange sinds 5.5...), maar goed, zolang jij dat niet wil uitsluiten door hardware tests te doen houdt het op natuurlijk.

[sanfranjake]

Anoniem: 120725 schreef op donderdag 20 mei 2010 @ 10:26:
Een corrupte MDB hangt echt je server zo niet op hoor dat je er totaal niks meer mee kan doen, er is wel degelijk iets meer aan de hand (ik heb ervaring met exchange sinds 5.5...), maar goed, zolang jij dat niet wil uitsluiten door hardware tests te doen houdt het op natuurlijk.

Helemaal niks meer aan toe te voegen

[Anoniem: 355408]

lees hier even snel doorheen maar hoe groot is je exchange db? want daar zit natuurlijk ook nog wel een beperkende factor aan.
ene welke versie draai je van exchange 2003?

[Anoniem: 120725]

sanfranjake schreef op donderdag 20 mei 2010 @ 11:18:
[...]

Helemaal niks meer aan toe te voegen

Als dit nou weer gebeurt kan je met Windows feature lets you generate a memory dump file by using the keyboard een dump aanmaken en die debuggen.

[Anoniem: 25534]

Anoniem: 355408 schreef op donderdag 20 mei 2010 @ 11:21:
lees hier even snel doorheen maar hoe groot is je exchange db? want daar zit natuurlijk ook nog wel een beperkende factor aan.
ene welke versie draai je van exchange 2003?

Limiet is al hoger dan normaal. Database zit rond de 40 GB. Max staat op 60.

Anoniem: 120725 schreef op donderdag 20 mei 2010 @ 10:26:
Een corrupte MDB hangt echt je server zo niet op hoor dat je er totaal niks meer mee kan doen, er is wel degelijk iets meer aan de hand (ik heb ervaring met exchange sinds 5.5...), maar goed, zolang jij dat niet wil uitsluiten door hardware tests te doen houdt het op natuurlijk.

Anoniem: 120725 schreef op donderdag 20 mei 2010 @ 11:31:
[...]


Als dit nou weer gebeurt kan je met Windows feature lets you generate a memory dump file by using the keyboard een dump aanmaken en die debuggen.

Maar een mem dump maken als de server werkt, en dan niets zien, wat sluit dat uit?
Vergeet niet dat het probleem er pas komt als de .edb corrupt is geraakt en niet meer ingeladen kan worden. Dirty shutdown modus dus.

[lamko]

Vandaar ook zou ik eerst de hardware uitsluiten wat wil je aan een dump debuggen als er nog geen fout gebeurd is.