Hello Members, I inherited an exchange environment that is in a bit of a mess. Exchange database of 250 GB got filled and staredt to dismount. Logical drive is 480 GB in size with 50GB free space. Been running the eseutil /d on database for a few hours now, of which is really slow. Now about 10% completed after about 5 hours. With the above info., do you guys foresee this defrag completing successfully? If not what is the next step. Thanks in advance. D

If it Exchange 2003 defrag Take 5 GB per hour Exchange 2007 defrag takes 5 to 7 GB per hour Exchange 2010 - No defrag should be ran -- Whats your Exchange Version ? ,, if you looking only to reduce the DB size. there is not next step. just mount it back ---Satheshwaran Manoharan | Exchange 2003/2007/2010 | Blog:http://www.careexchange.in | Please mark it as an answer if it really helps you

Thank you for the speedy response Satheshwaran. It's Exchange 2007. Can you clarify if the logical disk size being that small would cause the defrag to fail? If the defrag does not complete successfully, what's the next step? D

Hi, It's impossible to tell how long an Offline Defrag will take (it very much dependes on the hardware) but you should know that it's not recommended to run one. IF you decide to run one anyway, you must have free disk space that is at least 110% the size of the database that you want to process on the local disk for the new defrag file that is created. It's also possible to let the defrag create the temporary file on a network share that has the required free space available, but as I guess you can imagine that will not make the process run faster. Did you check how much white/free space your database has, before you started? EventID 1221 in the application will give you an idea. Maybe it's time to give your server new disks or replace it. Martina Miskovic

Hi, It's impossible to tell how long an Offline Defrag will take (it very much dependes on the hardware) but you should know that it's not recommended to run one. IF you decide to run one anyway, you must have free disk space that is at least 110% the size of the database that you want to process on the local disk for the new defrag file that is created. It's also possible to let the defrag create the temporary file on a network share that has the required free space available, but as I guess you can imagine that will not make the process run faster. Did you check how much white/free space your database has, before you started? EventID 1221 in the application will give you an idea. Maybe it's time to give your server new disks or replace it. Martina Miskovic

Hi If you only had 50GB of when you started this defrag will fail for sure. As Martina said you need 110% of the EDB size free. Do you have other disks in the server that you could use, maybe even one to create a new database on and move the mailboxes over to? Steve ETA: where are the log files stored, is it on the same disk? Are they being truncated properly by your backups?

Steve, So would the defrag fail at the end (meaning I would have to wait that defrag process out) and secondly, providing that it fail, can I just mount the database back, provision new storage and and move over mailboxr do I need to run any other command before I mount? Thirdly, creating new storage group on new disk and moving over mailboxes to database on new storage group, would I not need to get the degrag done on the intitial database that I was trying to defrag to reclaim space? Thanks, D

The defrag process creates a temporary EDB file and copies data over to it, the original EDB is not touched until the process completes successfully, so you can remount that file without any additional steps should the process fail. The idea behind moving to new storage/database would be to move all of your mailboxes and then delete the original file. Did you find out how much white space you had, event 1221?

Stave, Thank you so much for your help. I should be at the office in a few hour and would check the white space. I figure there is quite a few GB to gain since a few mailboxes were migrated to another storage group as well as there was a company wide clean up of mailboxes of late. If I understand you correct, provision a new disk, create storage group with database, move mailboxes from first storage group database (filled database), then delete first storage group database (original)?

If it Exchange 2003 defrag Take 5 GB per hour Exchange 2007 defrag takes 5 to 7 GB per hour Exchange 2010 - No defrag should be ran -- Whats your Exchange Version ? ,, if you looking only to reduce the DB size. there is not next step. just mount it back --- Satheshwaran Manoharan | Exchange 2003/2007/2010 | Blog:http://www.careexchange.in | Please mark it as an answer if it really helps you There was never any reason to a defrag in 2007 or 2003 either. Or at least very little reasons to do this.

Note that its not 110% of the edb size. Its 110% of the actual logical database size. i.e, the store size on disk minus the white space.

Stave, Thank you so much for your help. I should be at the office in a few hour and would check the white space. I figure there is quite a few GB to gain since a few mailboxes were migrated to another storage group as well as there was a company wide clean up of mailboxes of late. If I understand you correct, provision a new disk, create storage group with database, move mailboxes from first storage group database (filled database), then delete first storage group database (original)? If the original database has the System Attendant mailbox for that server, you will need to restart the System Attendant service once the original store is deleted to recreate it on a new store for that server. Dont attempt to move the SA mailbox.

AD, Thank you I get your point. But if I am going to move mailboxes to new database, there would not be any need for me to defrag any database. Correct? D

AD, Thank you I get your point. But if I am going to move mailboxes to new database, there would not be any need for me to defrag any database. Correct? D Exactly!

On Sun, 15 Jul 2012 16:03:41 +0000, donald_123 wrote: > > >AD, > >Thank you I get your point. But if I am going to move mailboxes to new database, there would not be any need for me to defrag any database. Correct? That's correct. And, as an added bonus, the duration of any "mailbox unavailability" is limited to the mailboxes being moved, not to the entire database's worth of mailboxes while the eseutil works on the database defrag (which can take many hours). If you ever do run eseutil to defrag a database don't forget to run isinteg against the new database. That'll clean up any problems within the folder structure, attachment table, etc. It also adds hours to the time the database is offline. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Sun, 15 Jul 2012 16:03:41 +0000, donald_123 wrote: > > >AD, > >Thank you I get your point. But if I am going to move mailboxes to new database, there would not be any need for me to defrag any database. Correct? That's correct. And, as an added bonus, the duration of any "mailbox unavailability" is limited to the mailboxes being moved, not to the entire database's worth of mailboxes while the eseutil works on the database defrag (which can take many hours). If you ever do run eseutil to defrag a database don't forget to run isinteg against the new database. That'll clean up any problems within the folder structure, attachment table, etc. It also adds hours to the time the database is offline. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

The length of time required to complete defragmentation depends on how much of the database is empty and not on the size of the database file. For example, defragmenting a 100-gigabyte (GB) database containing 10 GB of data takes about the same time as defragmenting an 11-GB database containing 10 GB of data. By default, after defragmentation is complete, the temporary database automatically becomes the new production database, and the original production database file is deleted. The time that defragmentation takes can be significantly reduced if you have as much free space on the same logical drives as the size of the original database files. In this case, the temporary database can be placed on the same logical drive, and the final copy will complete almost instantly. We do not recommend that you use a network drive to hold the temporary database. When using a network drive for the temporary database, defragmentation takes longer, and any transient or permanent network error will end the defragmentation process. Because defragmentation cannot be resumed, you must start over from the beginning. You only need as much extra logical drive disk space as the final size of the files after defragmentation. Although it is impossible to precisely predict how much disk space will be reclaimed, you should leave a recommended 110 percent of free disk drive space. http://technet.microsoft.com/en-us/library/aa997972(v=exchg.80).aspxTerence Yu TechNet Community Support