Defrag Database Partition

[blubomber]

I am going to defrag my exchange 2003 database. I dont have enough room on the partition it is currently on so i am going to move it to another server and defrag there. While the store is dismounted and the database is being defragged on the other server, should i delete the old database from the exchange server and then defrag the partition? Or should i leave the database and defrag the partition with the database there?

I am thinking that i can just delete the old database, after makeing several backups, since i am just going to recopy the defragged database over it when it is done.

Thank you for any thoughts and suggestions.

 

[markdmac]

I am wondering if you are talking about 2 differnet kinds of defrag here.

If the partition is low on space, a normal disk level defrag will help with that. Stopping the information store service and moving the database to another partition will automatically defrag it from a file level perspective.

If however you are also looking to defrag the database itself to reover space used by deleted users, then you would need to use ESEUTIL /D. As far as I know, ESEUTIL will only run on an Exchange server (I think I recall it requiring the System Attendent to be running), I may be wrong on that (confirmation anyone?).

I hope you find this post helpful.

Regards,

Mark

 

[blubomber]

mark, thank you for the reply.

I was doing both really. I was thinking of copying the exchange database from the current location to the server i am going to do the defrag on. Then, delete the original database and and make sure that partition is defraged. But maybe i will do a move instead.

You can use eseutil on another server. I have found a microsoft article that supports doing it that way. The current partition is not big enough to do a database defrag.

Thanks for the reply.

 

[stupman]

Yes, no problem to defrag on another server. When dismounting the store, it will also apply all the transaction log files to it. After the defrag, you may delete the original database. However, it is perhaps best that you keep a copy of the original database and transaction logs somewhere safe, you never know ... better safe than sorry.

 

[markdmac]

Regarding keeping the log files, you can determine if they are needed or not. Just run ESEUTIL /MH Priv1.edb. Scroll up near the top and look for text Logs Needed or Log Files Needed. It should say 0/0. If it does you can safely delete *.log.

Just near that you should also see something that will say something to the affect of Shutdown: Clean or Shutdown Dirty. A dirty shutdown indicates the database did not close properly (such as a power failure).

I hope you find this post helpful.

Regards,

Mark