Reducing Exchange 2003 database size + Email Replication + Eseutil.exe

[ridha121]

Hi Guys

I currently manage a site which uses Exchange 2003 and the total size of it is over 1TB.

They have had many users leave and I have recently deleted and purged several mailboxes however this has not reduced the total exchange size. I am aware that the utiity eseutil.exe is used to clear away white space in the database and thus reduce the overall exchange database size.

My question is how best is it to run this tool? Is it safe? is there a third party software that can remove white space more efficiently? Will I have to dismount the store?

Regards replication - How does exchange manage emails in the database?
example

User A sends email with 50GB file to Users B, C and D

will exchange store 4 copies of the 50GB file or will there only be one instance of the 50GB email?

Your help and feeback is much appreciated.

 

[ntinlin]

To take your last question first Exchange 2003 performs single instancing within a database.
So if all users are in same database there will be only one copy of the file held. If on 2 databases then 2 and so on.

As to your initial question how much White Space do you actually have in your databases? Check for event 1221's in application log.

And is this a single database or spread over several databases?

It is generally best practise nowadays NOT to run ESEUTIL except under EXTREME circumstances. There are NO 3rd party utils, some companies do a fancy GUI for it but they all call ESEUTIL in the end.
And yes the DB would have to be dismounted. Assuming you actually do have a single 1TB database it could take ESEUTIL days to actually run.

Neill

 

[58sniper]

Neil is right on everything. To add to what he mentions, keep in mind that Exchange actually performs better when there is some whitespace in the db than when there isn't. The only time you'd want to try and reclaim space is if the amount mentioned in the 1221 event IDs is > 30% of your database size, AND you don't expect to ever resuse that space. This generally is the case after a fair amount of mailbox purging, such as in a corporate resizing.

Keep in mind than a defrag of the database requires downtime, and the larger the database, the longer the downtime. You also need 110% of the size of that database available for temp space while defragging.

Since you mention database as singular, I'm *assuming* you have a single database that is ~1TB. I would absolutely recommend you get away from a single database that big IMMEDIATELY, as it't not best practice. A simple solution to that and your white space issue would be to create multiple databases and spread the mailboxes across them. This will result in new databases that are much smaller (keep them < 100GB if you can), and no white space. Once you're done moving them, you can delete the original database. Keep one thing in mind when you do this: data in the dumpster is deleted when you move mailboxes to a different database.

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/

 

[ridha121]

Hi Guys

Thank you for your excellent replies makes alot of sense.

yes I only have one store which is 1TB and i guess that is very bad practice, so if i ever attempted to perform eseutil it would be a nightmare.

58Sniper - So I should create 2 or 3 Mailbox stores and then move the mailboxes there? whats the best practice for creating these stores? should i do it based on departments?

Kind Regards

Ridha

 

[58sniper]

Best practices now days is to randomize who's on databases. I don't put entire departments on a single database because if that database ever dismounts, you've idled and entire department.

If you do some simple planning, you'll see how many databases you should have. It'll be more than 2-3.

See

http://technet.microsoft.com/en-us/library/bb124123(EXCHG.65).aspx

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/

 

[ridha121]

Ahh ok thanks for that.

When you say randomize, what exactly do you mean?

You create your mailbox stores and then randomly allocate users to databases?

Hmmm I was thinking of create 3 stores for my site instead of the 1, so you would reccomend creating more than 3? What is ideal for a store that is currently 1TB

 

[58sniper]

You should have databases that are no larger than 100GB.

Yes - randomize your users across databases. HOWEVER, if you have multiple levels of mailbox limit settings in your org, you may opt to put everyone with the same limit on the same database to make management a little easier.

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/

 

[ntinlin]

Pat is also right as usual. And I second and third his recommendation to spread things out right away.

Since we are obviously dealing with 2003 Enterprise here, I did notice it but forgot to address it explicitly, you can have up to 20 databases split over 4 storage groups.
Recommendation is to expand over storage groups first then go back and expand over databases.
i.e. Create another 3 storage groups with one DB in each, if you then need more DB go back to SG1 and add one and so on.
Reason - More efficient in memory use and since the storage group is the holder of log files it means if you have to restore an individual database you have a lot less log files to move.

Only thing to watch with Pat's recommendation of moving all mailboxes and deleting original DB is if you have a Blackberry service account in that DB. BES can get a bit upset if it's mailbox moves to a different server or DB.
Additionally earlier versions of BES don't handle intra-server moves gracefully but there are plenty of docs available online to help you with that.

Neill

p.s. When Pat says no store bigger than 100GB that would INCLUDE the dumpster even though it doesn't get moved across on a mailbox move. So remember to view the Deleted Items column in ESM when exporting the user list to Excel to do your calculations.