Database size 260 GB and growing

[jpnt]

Environment: W2K, Exch 5.5 SP4 Enterprise, Connected to a SAN

We have a DB that is 260 GB and growing. Many of our users have mailboxes that exceed 4 GB some even as high as 9 GB +.

Does anyone know how big is too big for Exchange 5.5 or even Exchange 2003 for that matter? Are we headed for danger? Our feeling is yes, but we need some kind of documentation that we need to break this thing up.

 

[alfie1noakes]

I think you will find that there is no limit to the priv.edb in Exchange 5.5, but for sanity's sake, 260Gb sounds huge, especially as I would imagine you haven't that many users.

How do you back all that up? Have you tried running the 'eseutil'. This will reclaim any white space in your database. Make sure you make a backup of the edb first though..

Andy

 

[zbnet]

The Enterprise version of exchange is limited to 16TB (a TB is 1024 GB). I think you'll agree you will reach the limits of your server archetecture (disks and tapes) before you reach the database limit.

alfie is right, your biggest constraint is going to be your backup (and restore) speed - the larger your database, the longer it takes to backup and to restore, and you need to consider the SLA of your service when disaster strikes.

Splitting your user data up would be best achieved by adding additional mailbox servers to the site, and moving some of the users to the new server(s). This won't actually reduce the overall size of the priv.edb on your first server, but it will increase the 'white space' inside it, and after you finish your moves you could always run an offline defrag to remove the white space and shrink the file down.

 

[jpnt]

Thanks. Our backup times are 2 hours for backup and we estimate at most 5 hours for restore. We haven't actually had to restore this. We regularly run an isinteg on the database and do a eseutil defrag bi-annually. Neither have indicated any errors.

 

[zbnet]

Then it sounds like you are managing okay. Just make sure your backups are of the online variety, and keep an eye on the success or failure of these, and you will get early indication of any database corruption.

 

[ebimprov]

I'd recommend you set some limits for your users. Setup personal folders for email they want to keep forever; move all their inbox subfolders there, set their deleted items to empty on exit, set their inbox and sent items to archive things older than 3-6 month w/o prompting every day, set maximum limits on their disk space on the server. Have a standard naming convention and location for the personal and archive pst files. back up those PST files to CD or tape if necessary. We've taken these steps and keep all our users to under 300 MB each; most under 100 MB.

 

[Excalibur1701]

Another thing to remember, is if you ever have to do an offline defragmentation of your information store, then you will need more then double the disk drive space (in your case, 550 gig free) I ran the eseutil over the weekend and it shrunk my priv.edb from 15.9 gig to 12 gig.

Definitely put storage limits on your users as well.

 

[jpnt]

We actually have no Executive buy in for email limits and therefore can not enforce anything. I ran an eseutil a few weeks ago and it took around 12 hours to complete. The temp db did not grow more then the size of the origianl database, so I created an array that was around 300 GB and directed the defrag to that space.

We have in the past had people use archiving and PSt's to clean up their mailboxes. But once the PST reaches 2 GB, which happens to us a lot, it corrupts. Then we have to watch how big their PST's are getting and warn them to start a new one. We eventually stopped recommending PST and archiving. Another offshoot of a large mailbox is people who try to synchronize also have problems. An OST also corrupts at 2 GB.

 

[Peepo]

Another possible tip, if your clients use Outlook 2003 you can create a PST that will not corrupt at 2GB and can be made a lot bigger (can't remember how big and haven't got time to look). Only drawback is that the new PST format is only compatible with Outlook 2003 but it could be an option for your users with MEGA size mailboxes.

Also be aware though that you need to run a hotfix for Exchange 5.5 server if you are going to connect to it with Outlook 2003 as there is an issue where connecting with Outlook 2003 can crash the 5.5 server.

Just some thoughts.

 

[dennisbbb]

http://support.microsoft.com/default.aspx?kbid=830336&product=out2003

SUMMARY
Microsoft Office Outlook 2003 has both a different format and a larger overall size limit for the personal folders (.pst) file than the .pst files that are in the earlier versions of Microsoft Outlook. In Outlook 2002 and earlier, the .pst files are in the American National Standards Institute (ANSI) format, and the overall size has a limit of 2 gigabytes (GB).

In Outlook 2003 .pst files are in the UNICODE format by default, and the overall size of the .pst files has a limit that is more than 20 GB. Outlook 2003 supports both the UNICODE and the ANSI formats, but the versions of Outlook that are earlier than Outlook 2003 do not support the UNICODE format and have a smaller size limit.

 

[ChaosCreator]

Jesus - 260 GB!!

I've been doing Exchange 5.5 administration for 3 years now, and here's some advice:

1. Get your users under control - 4 GB mailboxes? Granted, you have a SAN with good spindle I/O, but unless you're subjected to data retention laws - keep the mailboxes under 1 GB - use Mailbox Manager if you must. Also, place some individual send/receive mail size restrictions so users can't just send out 100 MB Attachments. E-mail does strange things to people - two people sitting next to each other in an office will email 10, 50, 100 MB attachments (mostly BS jokes btw), versus sharing them on a network share. Drives me nuts.

2. Break out your information store using 1 of 2 methods: introduce more 5.5 servers into your site, and use the move mailbox wizard to move off some of the mailboxes. This spreads the size aka "don't keep all your eggs in one baskey", or - migrate to Exchange 2003 where you can take advantage of multiple information stores and storage groups, not to mention a revamped ESE.

3. Last - do you perform maintenance? 5.5 information stores need regular defrags to keep performance high and to reclaim space from deleted mailboxes. Again, a SAN is in your favor because spindle I/O is usually the weak link in the performance game when dealing with fixing Exchange, but @ 260 GB it's got to take you forever to defrag your information store. Not to mention disaster recovery. Do you perform bricks level backup? I'm sure the job is hella-long. It takes me 12 hours to backup a 42GB database using MAPI bricks.

Has your info store ever crashed and needed recovery? Depending on your backup software - sometimes you need to isinteg -patch up the priv and pub - that takes time, and @ 260 GB - I can't even predict how long it would take. God forbid if you had to run an eseutil repair.

I have 4000 mailboxes on 3 Exchange 5.5 SP4 mailbox servers, with 1 bridgehead Exchange 5.5 server. My information stores are 15 GB, 42 GB, and 18 GB, and I consider that too large. I lost the largest exchange server last year when it was at 30 GB - my backups were dirty at the time and I ended up performing a hard repair - took 13 hours and that was just a 30 GB database. Even with a SAN you should start to get the picture. Technically Exchange 5.5 Enterprise had "no limit" for information store size, but realistically the larger it gets, the longer it takes to perform maintenance and disaster recovery.

Good Luck.

 

[Alshrim]

Man - when I was doing a restore of a 25 GB Database - it was taking 6 hours... YOu must have SUPER drives to do a 260GB in 5hrs..

There's no way that can be possible can it??

Alshrim
System Administrator
MCSE, MCP+Internet

 

[jpnt]

The database is on an IBM FastT600 SAN and the backup unit is an HP MLS6060 with 4 drives fiber attached to the SAN. We use HP dataprotector as our backup software.

Before we moved to this config our database was about 160 GB and was taking 18 hours to back up. When we switched to the new hardware the back up was reduced to 1 h 18 min.

 

[Zelandakh]

jp - good choices of hardware. BAD choices of users.

They have got away with it for a long time. You need to get an email out to the Execs with a read receipt that says it will go down soon. You need to test the DR on it urgently.

Email all staff and ask them to have a clear out - contact you if they need help. I've found half of all space is taken up with 5% of emails. So sort the Inbox and Sent Items by Size (add size column to Outlook) then say "Do you really need these?". A few pointers and they start to come round.

It isn't the time, it is the chances of not restoring it.