[Exchange 2000] Offline defrag uitgevoerd zonder resultaat

[Verwijderd]

We hebben zojuis op de exchange server een defragmentatie uitgevoerd op de mailbox store.

Dit hebben we gedaan aan de hand van dit artikel

How to defragment with the Eseutil utility (Eseutil.exe)

Alleen het jammere is de priv1.edb is hetzelfde gebleven en de priv1.stm bestand is iets geslonken.

We hebben in totaal 500 mb aan ruimte gewonnen, terwijl we van te voren mailboxen hebben opgeschoond van meerdere GB's.

De commando die we hebben uitgevoerd is:

"c:\program files\exchsrvr\bin\eseutil /d d:\exchsrvr\mdbdata\priv1.edb t/f:\temp.edb"

De commando hierboven heeft gewerkt maar als resultaat dat de priv1.edb niet is geslonken, alleen de priv1.stm.
Is er iets dat we missen dat er nog een /c bijvoorbeeld om de priv1.edb te laten verkleinen.
Ik heb de hierboven genoemd artikel doorgelezen maar hier staat verder niks over in.

Mijn vraag is dus, heeft iemand een tip of een idee hoe en wat?

[Verwijderd]

Wat staat er in je event id 1221, want die geeft aan hoeveel whitespace er in de database zit.
Verder is http://msexchangeteam.com/archive/2004/07/08/177574.aspx een goed artikel om eens door te lezen. Normaal gesproken is een offline defrag namelijk niet nodig, de whitespace in de database wordt gewoon automatisch weer gebruikt.

Titel ook nog even aangepast

[ Voor 7% gewijzigd door Verwijderd op 13-03-2007 16:47 ]

[Verwijderd]

Verwijderd schreef op dinsdag 13 maart 2007 @ 16:09:
We hebben zojuis op de exchange server een defragmentatie uitgevoerd op de mailbox store.

Dit hebben we gedaan aan de hand van dit artikel

How to defragment with the Eseutil utility (Eseutil.exe)

Alleen het jammere is de priv1.edb is hetzelfde gebleven en de priv1.stm bestand is iets geslonken.

We hebben in totaal 500 mb aan ruimte gewonnen, terwijl we van te voren mailboxen hebben opgeschoond van meerdere GB's.

De commando die we hebben uitgevoerd is:

"c:\program files\exchsrvr\bin\eseutil /d d:\exchsrvr\mdbdata\priv1.edb t/f:\temp.edb"

De commando hierboven heeft gewerkt maar als resultaat dat de priv1.edb niet is geslonken, alleen de priv1.stm.
Is er iets dat we missen dat er nog een /c bijvoorbeeld om de priv1.edb te laten verkleinen.
Ik heb de hierboven genoemd artikel doorgelezen maar hier staat verder niks over in.

Mijn vraag is dus, heeft iemand een tip of een idee hoe en wat?

hehe het opschonen van mailboxen en zelfs weggooien van mailboxen betekent niet dat ze ook verdwijnen uit de database. Kijk eens naar de retentie tijden voor "deleted items" en voor "deleted mailboxen" zou ik zeggen

[Verwijderd]

Verwijderd schreef op dinsdag 13 maart 2007 @ 16:47:
[...]


hehe het opschonen van mailboxen en zelfs weggooien van mailboxen betekent niet dat ze ook verdwijnen uit de database. Kijk eens naar de retentie tijden voor "deleted items" en voor "deleted mailboxen" zou ik zeggen

Oke, daar is te zien, dat er nog genoeg data is verwijderd, we hebben nu de online defragmentatie erop los gegooit en we wachten geduldig af wanneer de eventid 1221 te voorschijn komt.

[Verwijderd]

De online defragmentatie is afgerond, we hebben de eventid 1221 binnen gekregen en daarin staat dat er maar 21 mb vrij is gemaakt, terwijl als ik kijk bij exchange system management --> mailbox store -->(verschillende mailboxen met als kolom "verwijderde items") in die kolom verwijderde items is bij elkaar meer dan 4 GB aan data dat verwijderd is, maar niet is meegenomen door de online defragmentatie..........

Hoe kunnen we deze verwijderde data "vrijmaken" om de priv1.edb kleiner te maken.

[mookie]

waarom wil je uberhaupt nu defraggen?
Zit je aan je 16GB limiet? Zijn er verders geen leuke pagina's meer op internet om je tijd mee vol te brengen?

Offline defragmentatie doe je normaal alleen in geval van problemen en om whitespace uit de database te verwijderen.
Het feit dat er whitespace in zit is echter niet erg.
Als je éénmaal goed defragmenteerd is het juist erg prettig.
De hele database wordt namelijk door (een gewone, niet die van exchange zelf) defragmentatie goed op de schijf gezet, inclusief de whitespace.
Als iemand dan weer een mailtje ontvangt treedt er geen fragmentatie op de schijven op omdat de whitespace wordt hergebruikt.
Als je offline defragmenteert verwijder je de whitespace en nieuwe emails hebben dan nieuwe ruimte in de database nodig en de database raakt daardoor gefragmenteerd.

En verders kun je er altijd van uit gaan dat als je in exchange system manager een mailbox of iets ziet die zogenaamd deleted is dat hij dus niet deleted is maar na een retention period verwijdert wordt. Die zou je even op 0 dagen kunnen zetten bij de properties van je store, daarna mailbox management process laten lopen en daarna nog een keer defragmenteren...

[Verwijderd]

mookie schreef op woensdag 14 maart 2007 @ 12:26:
waarom wil je uberhaupt nu defraggen?
Zit je aan je 16GB limiet? Zijn er verders geen leuke pagina's meer op internet om je tijd mee vol te brengen?

Offline defragmentatie doe je normaal alleen in geval van problemen en om whitespace uit de database te verwijderen.
Het feit dat er whitespace in zit is echter niet erg.
Als je éénmaal goed defragmenteerd is het juist erg prettig.
De hele database wordt namelijk door (een gewone, niet die van exchange zelf) defragmentatie goed op de schijf gezet, inclusief de whitespace.
Als iemand dan weer een mailtje ontvangt treedt er geen fragmentatie op de schijven op omdat de whitespace wordt hergebruikt.
Als je offline defragmenteert verwijder je de whitespace en nieuwe emails hebben dan nieuwe ruimte in de database nodig en de database raakt daardoor gefragmenteerd.

En verders kun je er altijd van uit gaan dat als je in exchange system manager een mailbox of iets ziet die zogenaamd deleted is dat hij dus niet deleted is maar na een retention period verwijdert wordt. Die zou je even op 0 dagen kunnen zetten bij de properties van je store, daarna mailbox management process laten lopen en daarna nog een keer defragmenteren...

Ja we zaten voordat we de 1e keer hebben gedefragmenteerd
Al aan de 16GB grens, door een wijziging in de registry hadden we dit tijdelijk opgeschroeft naar 17GB.

En nee ik doe dit niet om me tijd te vullen, ik doe dit omdat als de 16GB weer wordt bereikt de mailserver eruit knalt.

Ik ben al in contact gekomen met mensen die meer ervaren zijn in de Exchange Server (leverancier van de servers) en die hebben ook al het een en ander voorgesteld (de offline defragmentatie), maar helaas zonder de verwachte resultaat (meerdere GB's die zijn vrijgemaakt bij de mailboxen van de gebruikers)

[Verwijderd]

Het is al genoemd, maar houd je er rekening mee dat Exchange normaal alle verwijderde items voor iets van 7 dagen (en minimaal één backup) vasthoudt?
Je zult dus pas na een week resultaat zien, tenzij je zelf de retention period omlaag schroeft.

[Verwijderd]

Verwijderd schreef op woensdag 14 maart 2007 @ 13:47:
Het is al genoemd, maar houd je er rekening mee dat Exchange normaal alle verwijderde items voor iets van 7 dagen (en minimaal één backup) vasthoudt?
Je zult dus pas na een week resultaat zien, tenzij je zelf de retention period omlaag schroeft.

De retenion period is van 7 dagen naar 0 dagen aangepast gisteren.

Zo te zien is dat nu pas tot effect gekomen, de kolom "deleted items" bevat nu geen data meer.
(system mangement -->mailbox store--> mailboxes---> "deleted items")

Moet ik als eerste de online defragmentatie uitvoeren om de event id 1221 en dan pas de offline defrag uitvoeren

of kan ik dat skippen, en de offline defrag uitvoeren om schijf ruimte te claimen.

[Verwijderd]

offline defrag kan je direct uitvoeren, maar op zich maakt het niet uit. Het enige wat een offline defrag doet is je ruimte terugwinnen op schijf. Maar als je naar de melding in de eventlog kijkt, heb je ook een hoeveelheid data vrij in je database file. Dit is (minimaal) de ruimte die je gaat terug winnen.

De offline defrag is derhalve overbodig, tenzij je monitoring wilt gaan inregelen, die een alert geeft als de file (edb en stm samen) weer groter wordt dan 15gb ofzo.

Overigens kon je je database niet vergroten naar 75GB met het laatste servicepack of was dat alleen exchange2k3? Mocht het kunnen, let wel op dat je database nooit groter mag groeien dan de disk toelaat (hou dus ook rekening met logs en andere files die evt op die disk staan), want als de limiet bereikt wordt gaat je server netjes plat. Wordt de limiet niet bereikt, maar zit de disk vol, dan stopt exchange minder netjes en heb je redelijk wat kans op datacorruptie.

[Verwijderd]

Verwijderd schreef op woensdag 14 maart 2007 @ 17:32:
offline defrag kan je direct uitvoeren, maar op zich maakt het niet uit. Het enige wat een offline defrag doet is je ruimte terugwinnen op schijf. Maar als je naar de melding in de eventlog kijkt, heb je ook een hoeveelheid data vrij in je database file. Dit is (minimaal) de ruimte die je gaat terug winnen.

De offline defrag is derhalve overbodig, tenzij je monitoring wilt gaan inregelen, die een alert geeft als de file (edb en stm samen) weer groter wordt dan 15gb ofzo.

Overigens kon je je database niet vergroten naar 75GB met het laatste servicepack of was dat alleen exchange2k3? Mocht het kunnen, let wel op dat je database nooit groter mag groeien dan de disk toelaat (hou dus ook rekening met logs en andere files die evt op die disk staan), want als de limiet bereikt wordt gaat je server netjes plat. Wordt de limiet niet bereikt, maar zit de disk vol, dan stopt exchange minder netjes en heb je redelijk wat kans op datacorruptie.

Bedankt voor de tip.

De offline defragmentatie hebben we uitgevoerd op me werk, nadat de eventid 1221 met de melding kwam dat er 7GB aan vrije data is gemaakt. En die ruimte hebben we inmiddels gewonnen.

Het verhaal dat je je database kan vergroten met de laatste service pack was volgens mij alleen op exchange 2003 van toepassing.

Wat ik nog wel moet uitvoeren is een online backup op de exchange database, ik heb daarover een artikel gelezen dat dit uitgevoerd word door de tool ntbackup.exe dat standaar erbij zit, deze online backup heeft geen invloed op de performance van de mailbox van de gebruikers, als deze wordt uitgevoerd. (dat is wat er staat in de artikel)

[sanfranjake]

Mag toch hopen dat je ook wel een regelmatige reguliere fullbackup hebt?
Met ntbackup is dat inderdaad te doen, want verwijderde content wordt ook niet verwijderd totdat er een fullbackup is gemaakt.
Verder klopt het dat voor Exchange 2000 de vergroting van de store niet opgaat. Het laaste service pack daarvoor is al veel eerder verschenen en er zal geen nieuwe meer komen.

[Verwijderd]

sanfranjake schreef op donderdag 15 maart 2007 @ 00:42:
Mag toch hopen dat je ook wel een regelmatige reguliere fullbackup hebt?
Met ntbackup is dat inderdaad te doen, want verwijderde content wordt ook niet verwijderd totdat er een fullbackup is gemaakt.
Verder klopt het dat voor Exchange 2000 de vergroting van de store niet opgaat. Het laaste service pack daarvoor is al veel eerder verschenen en er zal geen nieuwe meer komen.

Ja inderdaad de laatste release (service pack 3 roll up) voor exchange 2000 was in 2004

We hebben via Arcserve 2000 (backup op tape) een taak ingesteld, dat het de database bestand op tape zet.

Wat ik me afvraag is namelijk wat anders, tussen 1:00 en 5:00 in nacht wordt er een online maintenance uitgevoerd op de exchange server, 1 van de onderdelen van de maintenance is de esebackup ik neem aan dat dit niet de online backup is, die te vergelijken is met de ntbackup?

[Verwijderd]

Nee, dat is niet hetzelfde en je moet ervoor zorgen dat je je online ntbackup zo scheduled dat die klaar is voordat online maintenance begint (of schedulen dat deze na je maintenance periode begint)

Verder is er een hoop informatie op de MS Technet website te vinden over Exchange

[Verwijderd]

Verwijderd schreef op donderdag 15 maart 2007 @ 09:59:
Nee, dat is niet hetzelfde en je moet ervoor zorgen dat je je online ntbackup zo scheduled dat die klaar is voordat online maintenance begint (of schedulen dat deze na je maintenance periode begint)

Verder is er een hoop informatie op de MS Technet website te vinden over Exchange

Oke, verder informatie over de NTbackup heb ik al opgezocht. (niet via MS technet)

http://www.petri.co.il/ba...00_2003_with_ntbackup.htm

De online maintenance begint bij ons tussen 1:00 en 5:00 's nachts.

De NTbackup (online backup) kan zover ik gelezen heb uitgevoerd worden tijdens de werktijden, de perfomance van de exchange server wordt daardoor niet beinvloed. Ik wil het uiteraard wel zeker weten of dit daadwerkelijk zo is, anders voer ik het uit buiten de werktijd.

[Verwijderd]

Ik zou een online backup toch echt wel buiten werktijd schedulen

Begin verder eens met XADM: White Paper - Disaster Recovery for Microsoft Exchange 2000 Server

[Verwijderd]

Verwijderd schreef op donderdag 15 maart 2007 @ 14:34:
Ik zou een online backup toch echt wel buiten werktijd schedulen

Begin verder eens met XADM: White Paper - Disaster Recovery for Microsoft Exchange 2000 Server

Bedankt voor deze link, wat ik wel merk met exchange 2000 server is dat er niet 1 algemene procedure is om de database te onderhouden (zoals bijvoorbeeld online / offline defragmentatie)

Je komt in een web van informatie, en in die web moet je maar een weg zien te vinden.

[Verwijderd]

sanfranjake schreef op donderdag 15 maart 2007 @ 00:42:
Mag toch hopen dat je ook wel een regelmatige reguliere fullbackup hebt?
Met ntbackup is dat inderdaad te doen, want verwijderde content wordt ook niet verwijderd totdat er een fullbackup is gemaakt.
Verder klopt het dat voor Exchange 2000 de vergroting van de store niet opgaat. Het laaste service pack daarvoor is al veel eerder verschenen en er zal geen nieuwe meer komen.

We maken ook een fullbackup (dagelijkse) met het ArcServe een backup programma. In Arcserve is een taak aangemaakt dat alles op tape zet, dus ook de priv1.edb priv1.stm en de pub1.edb en de pub.stm

Alleen wordt dit niet geregistreerd in de event viewer wat ook logisch is, nu lijkt mij dat dit voldoende moet zijn. En om ook nog eens een online backup te maken is een beetje overbodig.

[Verwijderd]

Dus jij stopt elke avond je information store om je databases te backuppen? Geen goed plan, en als je het doet hoop ik dat je de log files ook backupt. Online backup is juist niet overbodig en voor Exchange de belangrijkste en beste manier om je database te backuppen. Ga die whitepaper nog maar eens doorlezen
XADM: White Paper - Disaster Recovery for Microsoft Exchange 2000 Server

[Verwijderd]

Verwijderd schreef op dinsdag 20 maart 2007 @ 10:26:
Dus jij stopt elke avond je information store om je databases te backuppen? Geen goed plan, en als je het doet hoop ik dat je de log files ook backupt. Online backup is juist niet overbodig en voor Exchange de belangrijkste en beste manier om je database te backuppen. Ga die whitepaper nog maar eens doorlezen
XADM: White Paper - Disaster Recovery for Microsoft Exchange 2000 Server

Laat ik het zo zeggen, ik ben hier 3 maanden aan de slag als Systeembeheer.
De taken in de Arcserve stonden er toen al in, dus er word al een soort van online backup gemaakt van de directory D:\exhsrvr\mdbdata. De information store blijft dus gewoon gemount.

De log files worden ook gebackupt.

De taken worden om 23.00 uitgevoerd zodat er niemand last van heeft.

Ben nu weer bezig met het lezen van de whitepaper.