[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1208
  • Last Modified:

SBS 2003 Exchange Database Limit - what happens when it you exceed it?

I'm hoping someone can help me.  My company has a Microsoft SBS 2003.  We use Exchange and I recently became aware that the Exchange database limit is 75 GB.  When I became aware of this, our Exchange database was already close to 80 GB (and actually working fine...not issues or mounting problems).  

I have an engineering compnay telling me that once you go over the 75 GB limit, you run the risk of corruption and that it's quite dangerous to go over that patricular limit.  I have another company telling me that, frankly, nothing bad will happen if you go over the 75 GB limit except for the fact that the database will dismount every night, which will then require me to remount it in the morning.  

From what I'm told, if we upgrade to a SBS 2007, then the Exchange database limit goes away but I'm not sure if we're in a position to upgrade our server at this point in time.  Can someone clarify which story is true?  I don't want to run the risk of corruption.
0
InlandEraser
Asked:
InlandEraser
  • 3
  • 3
  • 3
  • +1
1 Solution
 
Alan HardistyCo-OwnerCommented:
SBS 2003 has a 75Gb limit but it is not a physical limit - it is a virtual limit.  The size of the databaase can be calculated by the Size of the .EDB file, plus the size of the .STM file, minus the Free Space (or white space) which is held within the file and makes up deleted items that have passed their retention period.
If you upgrade to Exchange 2007 or SBS 2008, then this limit does go away.
If you hit the 75Gb virtual limit - the store will dismount daily.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
I've never experienced an information store that large, but I see no reason that it should corrupt (Exchange 2003 Enterprise has no limit and it uses the same database format).

I have heard and fully expect the database to go offline daily.  I'm not sure why this would be acceptable to you, considering that when the database if offline, you'll have issues receiving e-mails.  It looks like an upgrade is a requirement for you.

Exchange 2007 on SBS 2008 does not have database size limits and allows you multiple storage groups.
0
 
InlandEraserAuthor Commented:
Thanks for your answers.  I'll elaborate more on what happened.  We recently had a server crash and it happened just a couple of days after we were set up on a new backup solution.  The new backup system is a separate computer that backs up our network every fifteen minutes.  And is a departure from how we used to back up data (traditional tape backup).

We had a RAID failure and we ended up using the data that was kept on this new backup system to restore our network.  Within several hours, engineers told us that our Exchange database was corrupt and that is was caused by us exceeding the database limit.  This Exchange corruption issue has cost us quite a bit of money and it's been two weeks later and we still don't have all of our Exchange boxes restored.  

Long story short: the engineers that we have employed are telling me that we caused the corruption issue by having a 79 GB database.  I've been told that this may not be true at all and perhaps the corruption issue was caused by the new backup system that they set up for us.  It has been implied to me that if the backup solution wasn't backing things up properly, that may've caused the corruption issue.

Any insight that you have is greatly appreciated.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows PowershellĀ® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
Alan HardistyCo-OwnerCommented:
Having too large a Database will not cause corruption.  Having a RAID failure will most likely cause database corruption.
I doubt the backup system would have caused the corruption.  Sounds like your engineers are not too au-fait with Exchange!
0
 
InlandEraserAuthor Commented:
Thanks, alanhardisty.  So in this scenario it sounds like the fact that our Exchange datbase being 79 GB would not have caused the massive issues that we're now having?

We have solid snapshots of all of our data for several days prior to the RAID failure.  For various reasons the engineers are saying that these prior Exchange Databases are corrupt as well which doesn't make sense to me (it was working prior to the RAID failure...no hint of problems).  Their explanantion is that the database has been corrupt all along and the backup system has no way of knowing this.  They're teling me all it does it back up data.  Therefore when they restored the data, it was corrupt.
 
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
It's possible it was corrupt - or had corruption.  It sounds like you're looking for someone to blame... The engineers may not be that good and might be incorrectly pointing a finger at the size limit as the reason for the corruption... but that doesn't mean they were the ones (or their product) that caused the corruption instead.
0
 
InlandEraserAuthor Commented:
Thank for the response, leew.  No, I'm not necessarily looking for someone to blame it's just that we've had some outside engineering companies tell me that they thought the way the backups were being done were "not according to standard Microsoft protocol".  This other engineering company obviously is trying to win our business so I don't know how objective they are (are they feeding me flase information trying to lure me away from my current engineering company?).

My main concern was that because of this corruption issue, it has cost us thousands of dollars to restore the data and we're still having major problems (including apparent corruption on files restored that are not part of Exchange).  

I'm not trying to pigeon-hole anyone here but is the consensus that it's likely that the RAID failure may've caused the Exchange database corruption?  Meaing that the moment the RAID failed, it would've zapped the Exchange database, right?  If I had a solid image of the Exchange database two or three days prior to this RAID failure, I should have no problems restoring it to its normal functionality without any corruption, right?  Or am I wrong making this assumption?  

I guess it would make more sense if corruption could've settled in before the RAID failure.  If that was a possibilty, then it would make more sense to me.  
0
 
milikadCommented:
Hi
1. Your DB can increase to any size the limit is only limited to space available on your HDD.
2. Yes, as you are already aware store will dismount once every 24 hours
3. DB size increase cannot cause corruption.
If you cannot go for enterprise edition or if you are not planning to upgrade your existing version then you need to think about how to shrink the size of DB, since it has already hit the max threshold.
a. Ask users to delete the unwanted data or ask them to keep it in PSTs on their workstation and then delete that data from the PSTs
b. Delete the unwanted mailbox which are not used by anyone after exporting data from those mailboxes to PSTs
c. Dismount store. Take one offline copy (priv1.edb/stm and pub1.edb/stm) to another drive
d. Mount store. Go to properties of store and to limits tab. Set the retension settings to 0. You will found that it is set for 7 days and 30 days. Please note that by default every night on DB files online maintenance runs and basis the retentions settings it delete the items from the mailboxes and mark that space as white space
e. Next day morning check for the event ID 1221 for both Mailbox Store and Public store and look for the white space available
f. Remember that whatever value you see in these events is the amount of white space in your DB. To recover this white space you have to actually run offline defrag on (eseutil /d) on stores
If you or the engg at your end don't know how to run offline defrag, then let me know and I will assist you further.
Milind
 
0
 
milikadCommented:
Please read the above point (a) end part as "delete that data from the mailbox" instead of "delete the data from PSTs"
Milind
0
 
Alan HardistyCo-OwnerCommented:
  • Outside engineering companies tell me that they thought the way the backups were being done were "not according to standard Microsoft protocol".  This other engineering company obviously is trying to win our business so I don't know how objective they are (are they feeding me false information trying to lure me away from my current engineering company?).  What were you using to backup and why do they say this would have corrupted the Exchange Store?
  • My main concern was that because of this corruption issue, it has cost us thousands of dollars to restore the data and we're still having major problems (including apparent corruption on files restored that are not part of Exchange). Ontrack PowerControls would have been cheaper by the sounds of it!
  • I'm not trying to pigeon-hole anyone here but is the consensus that it's likely that the RAID failure may've caused the Exchange database corruption?  Meaing that the moment the RAID failed, it would've zapped the Exchange database, right?  If I had a solid image of the Exchange database two or three days prior to this RAID failure, I should have no problems restoring it to its normal functionality without any corruption, right?  Or am I wrong making this assumption?  I would lay the blame at the feet of the RAID card causing the problems, possibly before it failed and / or when it failed.  If the RAID started to corrupt the DATA as it was about to die then that would cause corruption but not just to the Exchange Store - is your other data okay?
0
 
milikadCommented:
Hi
To answer about corruption in DB.
1. Corruption in the database are of two types (Physical and Logical). Physical corruption 95% times has been found due to faulty hardware, rest 5% attributed to power failure or human errors such as switching off running exchange server
2. If your database had/got corruption earlier then check previous dates logs if you could see any error events in application log which can attribute for "ESE"  and check the system logs for any error events pointing to "disk" or "ntfs" which can tell us that if there was corruption in disk present or not
3. If we found these events then yes we can confidentaly say that backup which you had taken using any backup might also have corrupted copy of DB files
4. So yes, in such scenarios, there are multiple solutions to recover from corrupted database
a. Yes, as you understood restore the old good copy of store from backup tape
b. If you found that there is corruption in DB file but if you are still able to mount these stores, then you can move DB to recovery storage group, mount blank store in production and merge data from RSG to production, which will give you brand new database with old data
c. The above option is not recommended if you still have issues in your RAID or any disk system that you are using. You need to first fix the hardware before working on exchange database files.
Further there is no way to detect corruption unless you are monitoring events in app and sys logs at regular intervals or checking regularly if backup operation is completing successfully or not. Unfortunately people only start looking at exchange DB files only when they start facing issues accessing mails
Milind
0

Featured Post

Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

  • 3
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now