On Wed, 15 Sep 2010 20:00:50 +0000, Smith1974 wrote: > > >Hmm, does seem like another option. But I'm worried about excess transaction log growth to be honest. > >Some questions if that's ok? > >1. Do you recommend circular logging when moving the mailboxes to avoid the possibility of our t-logs filling up the drive? Nope. But take a couple of days to move the mailboxes, with backups to truncate the log files every day, and you should be okay. >2. If we do use circular logging, do we enable that on the source db, the target db, or both? On the target database. >3. I am correct in thinking that to enable/disable circular logging, you need to remount the store? You do. >4. Just in terms of the offline defrag, do you know why people advise to run isinteg afterwards? Is that necessary? It's not necessary, but it's advisable. If you're going to take the database offline why not make sure you're not putting bad stuff back online when you're finished? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi We recently had a large number of mailboxes deleted from some of our Exchange 2007 databases due clean up after people leaving the company etc. I now understand that the space previously taken up by their mail has become 'white space'. Online defrag shows that there is a significant amount of white space within a few databases where these users' mailboxes resided. We were thinking of running an offline defrag. From what I understand, this will reclaim the white space and therefore reduce the overall size of the database. Our plan was: 1. Make a copy of the database. 2. Dismount production version 3. Run offline defrag on copy 4. Assuming defrag works fine, run ISInteg -fix on the copy 5. Assuming no problems, mount the copy as the production database I just wanted to check that this was the best course of action. Also, I've read that ISInteg -fix should generally be run after an offline defrag, however I've never been quite sure why? Could someone explain? Many thanks

How big are the stores and how much free space?

As an example, we have one store that is about 70GB and we can get back about half of that?

WHy not simply move mailboxes from that store to other stores and then remove it? No downtime.

Hmm, does seem like another option. But I'm worried about excess transaction log growth to be honest. Some questions if that's ok? 1. Do you recommend circular logging when moving the mailboxes to avoid the possibility of our t-logs filling up the drive? 2. If we do use circular logging, do we enable that on the source db, the target db, or both? 3. I am correct in thinking that to enable/disable circular logging, you need to remount the store? 4. Just in terms of the offline defrag, do you know why people advise to run isinteg afterwards? Is that necessary?

1. You can do that temporarily during the moves, yes. I dont necessarily recommend it, but you can do it if you are concerned about space. 2. Target. 3. Yes 4. Well, whenever you perform disk level operations agains the store, its always a good thing to run isinteg which checks and fixes logical issues. In the past, (Exch 5.5) if you didnt run isinteg after an offline defrag, the store sometimes wouldnt mount. But, since offline defrags are discouraged, you hopefully wont be in that position!

================= Just in terms of the offline defrag, do you know why people advise to run isinteg afterwards? Is that necessary? =============== Its highly advisable or necessary to run isinteg after you run the defrag of databases. Isinteg will help in searching through the offline database for integrity weaknesses and then fixing it. Thanks------Exchange, OCS------