You would have to dismount the database to copy it first of all. But if you are going to move all the mailboxes out of that database there is no need to copy the database before defragging it. If it has trouble mounting after the defrag and it is empty, worst case scenario is you delete it and mount the database and a new one will be created. That actually is the fastest thing to do anyway. As far as defragging goes, you are correct, you do not have to stop any services to dismount and defrag a mail store. As far as downtime, again if you have moved all mailboxes out of that store then there will be no downtime to the end users while that database is being defragged (at that point just delete it and re-mount the store to create a new one, why waste time defragging it at all?) If there are mailboxes in the store then the downtime depends on the size of the database and how much white space is going to be reclaimed. I can't give you a rule of thumb here. Too many variables, including how many processors, how much memory, how much throughput on the system during the planned defrag etc. The larger the database the longer a defrag will take, that much I can tell you. Try to keep your mailstores to a reasonable size, 60GB or less is a reasonable size. ================= First, you have to be careful of performing transfer of database to another database. You can use a third party defragmentation software which has the feature of defragging your database. However, I think it would be better if you will hire a professional programmer before you do the defragmentation yourself.

You would have to dismount the database to copy it first of all. But if you are going to move all the mailboxes out of that database there is no need to copy the database before defragging it. If it has trouble mounting after the defrag and it is empty, worst case scenario is you delete it and mount the database and a new one will be created. That actually is the fastest thing to do anyway. As far as defragging goes, you are correct, you do not have to stop any services to dismount and defrag a mail store. As far as downtime, again if you have moved all mailboxes out of that store then there will be no downtime to the end users while that database is being defragged (at that point just delete it and re-mount the store to create a new one, why waste time defragging it at all?) If there are mailboxes in the store then the downtime depends on the size of the database and how much white space is going to be reclaimed. I can't give you a rule of thumb here. Too many variables, including how many processors, how much memory, how much throughput on the system during the planned defrag etc. The larger the database the longer a defrag will take, that much I can tell you. Try to keep your mailstores to a reasonable size, 60GB or less is a reasonable size. ================= First, you have to be careful of performing transfer of database to another database. You can use a third party defragmentation software which has the feature of defragging your database. However, I think it would be better if you will hire a professional programmer before you do the defragmentation yourself.