Splitting database 1

[disturbedone]

Currently I have 1x 740GB database. This was setup by a contractor and I would like to split it for various reasons (management, backup etc).

These are virtual machines on VMware ESXi5.0

I currently have the following:
* 2 mailbox servers - MS1 & MS2, 2x CA servers - CA1 & CA2
* Database is called '2010 DAG cluster', database & log files stored in D:\Program Files\Microsoft\Exchange Server\V14\Mailbox\2010* MS1 - C:\ (40GB, 17GB free), D:\ (1.8TB, 1.03TB free), E:\ (10GB, 3.85GB free)
* MS2 - C:\ (40GB, 12GB free), D:\ (2.0TB, 1.07TB free), E:\ (10GB, 3.85GB free)
* MS1/MS2 - C:\ (W2K8R2), D:\ (Exchange database & log files), E:\ (Page file)
* 1x DAG, witness directory (C:\DAG witness\ on CA1/CA2)

Firstly, why the log files were put on the same disk as the database I don't know. I think that is the first thing that should be sorted.

This is a school so I'm thinking of splitting the single database into the following:
* Staff
* Class of 2012
* Class of 2013
* Class of 2014
* etc
That way as each year of students leave the entire database can just be archived/deleted. It also allows for different policies eg size limits) to be applied to each database.

The database is currently 740GB. The log files are 500MB. CommVault Simpana does an incremental backup every hour to keep the log files to a minimum and reduce full backup times.

Questions:
1. Sorting the log file location out is what I think should be done first.
a. Create a new virtual disk and move them to it???? Need to unmount to do this???
b. Is having log files for each database on the same disk ok???? I would think so.
c. I'm thinking creating a single eg 5GB disk just for the log files. Big enough???
2. Leave D:\ as is. Moving 500MB of log files still leave ~1TB free on each server
a. I wouldn't think anything needs to be done to D:\. Am I missing something??
3. Creating new database seems straight forward - give it a name (eg 'Class of 2013), select server (MS1), select database location (D:\Program.....), select log location (new F:\Logs)
a. Any requirement for a new DAG or just let the single DAG manage it????

Any other thoughts/advice would be appreciated.

 

[disturbedone]

I may have answered one of my questions. Reading the 'Sybex Mastering Exchange 2010' book I saw the following:

"When creating additional mailbox databases that do not use database replication with a DAG, you should plan to place each database's transaction logs on separate disk spindles from the database files. This can help improve performance (due to the nature of the I/O differences), though it mainly improves recoverability. If you are using a DAG and have two copies or more, you can safely place the transaction logs and the database files on the same spindles/disks."

Given that I have a DAG with 2 copies it looks like there's no advantage to moving logs off the current disk. That makes it easier

It really comes down to the size of D:\ now. Splitting 1x 740GB database into 11 (10 yr groups, 1 staff) will still be around 740GB(ish). There's still ~1TB free and each year one DB will be deleted and another created. And also the question about multiple DAGs. And anything else I haven't thought of.

 

[ShackDaddy]

You would just use a single DAG.

Dave Shackelford
ThirdTier.net
TrainSignal.com

 

[disturbedone]

Don't see any issues with D:\ space? Splitting the database isn't going to blow it out from 740GB to 1.5TB or something like that is it? I expect it might go from 740GB to (maybe) 800GB.

I'm learning a lot with this I created a test DB and found that adding users would be placed in either the original or the new. Found that I needed to run Set-MailboxDatabase -Identity "New DB Name" -IsExcludedFromProvisioning $true so it would only go into the 'default' DB. This is fine because I use a PowerShell script to create users and I've altered that to place it in a specific DB based on the student's year group.

 

[ShackDaddy]

Splitting the database will initially cause space to balloon, since the existing database will not shrink as the new ones grow. But you have plenty of space, and once you have migrated all mailboxes off of the original database, you can delete that file and reclaim that 750gb of used space. I would recommend leaving that database behind and moving everything to the four databases that you named above.

The concern I have is that if the logs are on the D: drive as well, the sheer act of moving mailboxes will consume a lot of space (space equal to the amount of the data moved) until the next good backup. So I'd proceed with caution. You may even want to move half the data out and then do an offline defrag of the old database, just to free up 400gb of space to ensure that the rest of the migration will go without a hitch.

But if you are running Exchange 2010 Standard, you are limited to 5 databases including the PF database, so you may need to move everything to three other databases and then later on, move things out of one of those into a new one after you've cleaned out the old one and deleted it.

Dave Shackelford
ThirdTier.net
TrainSignal.com

 

[disturbedone]

Thanks for the tips. There's no great hurry for this so I can take my time.

You mention the 'PF database'. What's that? I can't find anything it might stand for.

We have Enterprise so I'm allowed 100 DBs from what I read.

Currently:
Database______________Who for
2010.edb_________________All staff & students

Planned:
Database______________Who for
staff-general.edb___________General staff
staff-important.edb_________Important staff (higher mailbox limits)
class-of-2013.edb__________Students completing in 2013
class-of-2014.edb__________Students completing in 2014
.
.
.
class-of-2022.edb__________Students completing in 2022


I can move 2013 students one night, let the incremental backup the logs, do 2014 students the next night, let the incremental backup the logs etc etc. I'm not worried if it takes a week or two. And when all users have been moved I can delete the old DB.

 

[ShackDaddy]

Public Folder database.

Dave Shackelford
ThirdTier.net
TrainSignal.com

 

[disturbedone]

Of course! Slight brain fade there for a second.

We don't have Public Folders at this stage anyway.

 

[Zelandakh]

staff-important Aren't they ALL going to want to be in that one???

Agree that instead of splitting them, you should create new DBs for everything, move everyone and then delete the "empty" DB which will be massive and solely white space.

 

[disturbedone]

staff-important smile Aren't they ALL going to want to be in that one???

Yes, but I won't tell them it exists. I'm a hard a$$ when it comes to email storage

At the moment there's the default 2GB storage and there are numerous requests from directors, housemasters etc (ie people who do actually need more space) for increases so they're individually adjusted which just makes a mess of things. The "important staff" database will have a higher limit eg 5GB and be I'll highly selective about who is classed as "important". 99.9% of staff only need 2GB. It's just the 0.1% who need more, a lot more.

 

[disturbedone]

Splitting is in progress. Taking my time and learning as I go. Keeping an eye on disk space and letting the incrementals clean up the transaction logs.

I've come across a issue that looks quite common and wanted some advice if you've seen it before. It looks like there's quite a simple fix for it but also want to confirm it is correct.

I first selected 6 mailboxes to move and they completed without issue. I selected another 6 and all completed with warning. The warning was:

The Microsoft Exchange Mailbox Replication service completed request <mailbox> with warnings.
Warning: Failed to clean up the source mailbox after the move.
Error details: MapiExceptionUnexpectedMailboxState: Unable to delete mailbox. (hr=0x80004005, ec=2634)

Initially I thought it may have been because there was an incremental backup in progress. I disabled them for further moves but still get the same issue. And it appears to be random - someones all give the warning, sometime some of them, and sometimes all move without issue.

I found this article which points to a fix at this Microsoft article using the following command (to do all affected mailboxes):

Get-MailboxStatistics -Database MBD01 | where {$_.DisconnectReason -eq "SoftDeleted"} | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState SoftDeleted}

Has anyone come across this issue and can confirm that the above command will resolve it?

 

[ShackDaddy]

I think that will resolve it, but there's something else that also resolves it: waiting till the mailbox retention period has past. So if you have a setting to allow deleted mailboxes to be purged after 14 days, then 14 days later the automated process will get rid of the debris. But if you don't want to wait that long, the script mentioned above should take care of them faster.

Dave Shackelford
ThirdTier.net
TrainSignal.com

 

[disturbedone]

Great. Is there a way to tell if they've been "cleaned up"?

At the moment all I can see is this warning in the Move Request area. Searching for a mailbox shows it correctly in the new DB. I'd like to know that they've definitely been "cleaned up". Is it the Disconnected Mailbox list? All mailboxes that I've moved, both with and without this warning, appear there.