Moving the Exchange DB to a different drive

[stevenriz]

Hi, as you mya have read in another post, we have excessive disk io and cannot figure it out other then we just might be overwhelming the disk subsystem which is a simple RAID1 volume where all the logs, db and OS reside.

When I stop the Exchange Infomation Store service, disk IO basically stops so we now know Exchange is causing this IO.

I just mounted an iSCSI EqualLogic array and now have drive F: on the Exchange Server with 1.5TB available.

My question is this. When we initiate the db move using Exchange Manager, the database is dismounted. When the database is dismounted, is that the same as stopping the Information Store? I need to know this because if we initiate the move of the DB and the disk IO is still excessive, the db move will take days and not hours.

So in other words if we are comfortable knowing that the excessive disk IO will stop after this dismount routine, I would guess the copy would be quick. DB size is about 125GB.

Any thoughts on that would be appreciated.

thanks!
Steve

 

[brainblurb]

If this is the only exchange database on the server, disk IO should drop when the database is dismounted. Good luck, and be sure to get a good backup before you dig in!

Cheers,

Anony Moose

http://www.brainblurb.com

 

[58sniper]

It's not the same as stopping the Info Store. Moving a database only affects that database. Stopping the store stops everything.

If you're running Exchange Enterprise, create a new storage group, and a new mailbox database, and move the mailboxes - not the database.

If you're running Standard, you're going to have to move the database, which, as you mentioned, dismounts it. At that point, your clients can't connect to it any more, so you won't have user induced IO.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[stevenriz]

Good suggestion Pat. I am working with my Exchange folks on this. After adding the new SG, we would then need to add a "store" before we can drag individual boxes over to the new SG right?

 

[58sniper]

Correct.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[stevenriz]

this is sort of how I built this server. We were originally on SBS. Purchased Exchange Enterprise, put it on a new server and connected the two environments. Then we dragged the mailboxes from one server to the other.

I imagine moving boxes from one SG to the other is even more seamless. Can the user be logged in while the move takes place?

I just went through the motions and it seems pretty painless....

 

[stevenriz]

I did some research and couldn't find any info. Can we shut down the store, manually copy the MDBDATA contents to a new drive and remount that directory? or are the only options to either add a store or perform the move using Exchange Manager?

 

[58sniper]

If you're MOVING mailboxes, you need a new mailbox store to move them to. If you're MOVING databases, you change the path in the properties, it will dismount, copy the files, and remount automatically.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[stevenriz]

Hi everyone. We are still struggling with this. Performance has increased since we moved all the print queues off and archived many GBs or former employee email boxes. But we still aren't there yet. The plan was to move the DB to the EqualLogic array but I am having trouble getting the OK from the management team to shut down Exchange for however many hours to backup it up and perform the move.

So I am going back to what 58sniper mentioned in creating a new storage group on the EL array and moving mailboxes to it because it doesn't seem like we will need to shut the system down to do so... correct? any gotchas doing this? Or should I just wait it out for when we can shut down the system?

Steve

 

[58sniper]

Correct. But it will disconnect those users while they're being moved. So move them at night. Just remember something - data in the dumpster doesn't follow a mailbox move.

You're going to shut it down, and then back it up? Why? Do an online backup. When it's done, move it by going into the database properties and specifying a new path. Drastically shortens the outtage window.

I'd still move just mailboxes. And, based on your database size, I'd split the users into multiple databases. That way, you can leverage multiple volumes to distribute disk IO.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[stevenriz]

gracias! I was only going to perform the shutdown to do a cold backup as well. I suppose you're right, online is plenty and we do it daily so that will shorten our outage window by an hour or two. thank you Pat!
Steve

 

[stevenriz]

I haven't moved anything yet. But noticed a just a strange observation. Our exchange database is sometimes backed up in 90 minutes and sometimes it takes 6 hours. It is different every day. It is backed up at the same time each day at 630p. Maintenance starts at 3am each day so they shouoldn't conflict. I wish I could see just what is happening. Oh well... let's hope the move or additional storage groups does the trick.