There is something like 80GB of white
space and the rest is the real stuff, so right now I don’t think it
justifies splitting it into two.
Good thing you brought up circular logging
because I probably would have missed that.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael B. Smith
Sent: Wednesday, August 17, 2005
7:56 PM
To: [email protected]
Subject: RE: [ActiveDir]
OT:Exchange 2003 SP1 bloat
Al makes an excellent point - I just
presumed I hadn't been paying attention and it had been discussed earlier, with
a conclusion that you need to do an offline defrag. :-)
White space is actually at the file level
(a store is composed of two files, an EDB file and an STM file), which is
approximately the DB level. Both files may or may not have whitespace. Moving
to a new store does not carry along the whitespace, it's left behind. You'll
still be left with the original 91 GB store, "empty" but
still there -- you'll still need to either defrag it (if you don't/can't move
everyone) or delete it (if you are certain everyone has been moved) to recover
the space. However, the defrag is very fast if you just have white space.
Do remember that if you don't turn on
circular logging temporarily that a 91 GB store which is move-mailboxed will
result in LOTS of log files. (I'm thinking it's 2x<actual
data>, but I'm fuzzy on cold medicine right now.)
What is the size of the white space? (And
thus the <actual data>...) "Many" MS folks will recommend
that you consider splitting up stores when they hit the 35 - 50 GB range.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long
Sent: Wednesday, August 17, 2005
7:21 PM
To: [email protected]
Subject: RE: [ActiveDir]
OT:Exchange 2003 SP1 bloat
I was thinking about that today and
thought “there must be reason not to do it that way since no one else has
mentioned it.” Does the white space in a DB exist in the mailbox, or the
DB level? Moving to a new mailbox store will definitely get rid of the white
space?
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Wednesday, August 17, 2005
5:15 PM
To: [email protected]
Subject: RE: [ActiveDir]
OT:Exchange 2003 SP1 bloat
I don't believe I've seen the reason that
you want to defrag in the first place. Any reason you would choose to
defrag vs. just moving the users to a new db?
Safer and faster IMHO than taking 3-10 hours to defrag and
backing up the mail while doing so.
From:
[EMAIL PROTECTED] on behalf of Medeiros, Jose
Sent: Wed 8/17/2005 4:13 PM
To: [email protected]
Subject: RE: [ActiveDir]
OT:Exchange 2003 SP1 bloat
Keep in
mind that this was a DELL Server Xeon 4 way 800 MHZ system with a Perc 2
controller with U160, 10,000 rpm drives and the database resided on the DAS
external array. I am sure that it will run much faster on the newer 3.0 GHZ
Xeon's with Ultra 320 15,000 rpm Drives.
While your at it you may want to also run ISINTEG which takes even longer.
Jose :-)
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Douglas M. Long
Sent: Wednesday, August 17, 2005 12:06 PM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
Ah man, don't tell me that it took 10 hours for a 30GB database...the one I am
defragging is 91GB.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Medeiros, Jose
Sent: Wednesday, August 17, 2005 2:32 PM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
I am not sure I understand your point.. if he is trying to fix his bloat issue,
this tool will do the same thing as Esutuil in compacting the database with out
having to take down his exchange servers.
Last time I ran Esutuil on a 30gb data base it took nearly 10 hours to finish.
Jose
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Michael B. Smith
Sent: Wednesday, August 17, 2005 11:08 AM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
I would never recommend a tool that does offline defragmentation as preventive
maintenance.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Medeiros, Jose
Sent: Wednesday, August 17, 2005 1:56 PM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
Want a simpler method? Try http://www.goexchange.com/,
( GOexchange is painless to use and saves you time by running automatic expert
preventive maintenance while you attend to more important things )
You won't even have to take your Exchange servers offline to defrag the
information and public folder stores.
Jose :-)
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, August 17, 2005 10:28 AM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
KB192185 has good info on this. You are on the right path, IMO.
Sincerely,
Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I
Microsoft MVP - Directory Services
www.readymaids.com - we know IT
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
________________________________
From: [EMAIL PROTECTED] on behalf of Douglas
M. Long
Sent: Wed 8/17/2005 10:06 AM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
I guess I was thinking of using the /p switch because of a paragraph"
"Run ESEUTIL with the /p switch to configure ESEUTIL to create the new
defragmented database on an alternate location (for example, to a location on a
different hard disk). This switch lets you preserve your original defragmented
database (which lets you revert back to your original database if necessary).
This switch also significantly reduces the amount of time it takes to
defragment a database, because you are rebuilding to a new location, rather
then rebuilding the database in place."
I was thinking...hmmm, it takes less time, and I have a little more protection
from something going wrong...sounds good to me. Comments?
And now that I think of it, my command probably needed a PATH for the new DB
unless there is a default, but I won't know that till I run eseutil.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Peter Johnson
Sent: Wednesday, August 17, 2005 12:17 PM
To: [email protected]
Subject: RE: [ActiveDir] OT:Exchange 2003 SP1 bloat
Well IIRC /p is a hard repair whilst /d is for defrag. If you have a working,
mountable store that you want to defrag you don't need the /p switch.
Anyone got any comment?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Douglas M. Long
Sent: 17 August 2005 18:13
To: [email protected]
Subject: [ActiveDir] OT:Exchange 2003 SP1 bloat
OK, so I have scheduled a window this weekend to run an offline defrag of the
mailbox store. Now I am looking for the best way to do this, and since this
list seems to have more/better experience with Exchange than the Exchange list,
I am looking for comments.
Here are the steps I am planning on taking:
1. Full backup of "General" store
2. Dismount "General" store
3. > eseutil /d /p
F:\Exchsrvr\mdbdata\General.edb
*Is it a good idea to use the /p switch (I have enough
space)
**If using the /p switch, what is the mounting procedure for the new DB?
4. Full backup of new DB
Any comments are very welcome, and appreciated.
