|
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.
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.
|
