Split 1 database into multiple 2

[disturbedone]

We have a single DB that's about 680GB and I'd like to split it into multiple to:
a) reduce the size/time of backups
b) ease administration - 1 DB for staff, and a separate DB for each year group of students

I'm looking for advice on gotchas as I haven't done this before.

The process itself looks pretty straight forward. Create the new DB, give it a name, select the server to store it on, tell it where to store the DB and log files, click save. Is it really that easy? Any gotchas to watch out for? Any downtime?

We have the current DB in a DAG (2x MBXs servers). Can I add the new DB to the existing DAG (that's what I think) or does it require a second? When adding it to the DAG I'd then add in the 2nd server (because I could only select 1 during the creation). Any gotchas with this? Is there any downtime required?

Then migrate users between databases, configure the backups to backup the new databases etc.

Any advice appreciated.
Cheers

 

[58sniper]

Your plan should work. Select a server to host the new database. Once it's created, create a copy of it on the other DAG node.

Something to keep in mind is that the original database won't get smaller when you do that. The solution is one of two tasks: create another database and move all remaining users to it, and delete the original; or take the original database offline and defrag it. I'm very much a fan of the first method over the second because it doesn't require many hours of downtime.

Do you have your Tek-Tips.com Swag? I've got mine!

Stop by the new Tek-Tips group at LinkedIn.

 

[Zelandakh]

Yup, agree with 58sniper's first method. Treat this as a full exercise and move EVERYONE rather than move some out.
In fact, as you create them, name them nicely!
Remember, logs and databases on separate spindles if at all possible.
Backup BEFORE you start.
Move some but watch the disk space as you'll create a load of logs...you may need to back up part way through.

Moves create IO - think about out of hours moves due to performance hit.

 

[disturbedone]

Thanks guys. I had thought of moving it all and starting afresh. It'll be a clean slate and we can work with databases the way they probably should've always been.

DBs will be named along the lines of students2012.edb, students2013.edb, staff_a-c.edb, staff_d-f.edb etc so we know what is what. The current DB is just 2010.edb (as in Exchange 2010) so that's another reason to ditch it and move everything to appropriately named new ones.

This is on a VM. It was configured by a contractor and the DB and logs are all in D:\Program Files\Microsoft\Exchange Server\V14\Mailbox\dbname\. I have read that logs/DBs should be separated so I don't know why they weren't.

 

[Zelandakh]

Laziness probably!
Yes, if you have separate spindles, move the DB and logs over. Be careful to get the size and performance right or you'll regret it! i.e. don't move the DB to a drive that is only just big enough and watch the log drive as it needs plenty of room.