What can you do if your information Store db is nearly at 75GB

[nichols]

We have just had a corrupted information store. We used eseutil to repair it on the instructions of microsoft and then ran isinteg to check the integrity. We then created a recovery storage group and merged the repaired mailboxes back into the database. The problem is that this has taken the size of our priv1.db from 45 GB to 72GB.

We are running Exchange 2003 standard edition service pack 2 and the limit on the size of the database is 75GB. Does anyone know what we can do when the database exceeds the 75GB threshold?

Hope someone can help!

 

[scottew]

You will need to upgrade to the Exchange Enterprise Edition.

Scott

 

[nichols]

Is there no other way?

 

[58sniper]

Upgrading to Enterprise will allow you to have larger databases, as well as more databases.

An alternative is to remove mail from the existing database. And that's rarely an option.

Your mailbox limits should be configured so that the database cannot reach that maximum limit.

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/

 

[xmsre]

Upgrade to Exchange 2007.

 

[58sniper]

At this point, prepare for 2010

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/

 

[baddos]

The problem is that this has taken the size of our priv1.db from 45 GB to 72GB.

Is 72gb actually used though? Just because the files add up to 72gb doesn't mean the database size is 72gb.

 

[theravager]

Theres a couple of registry keys you can change to make the size ok. Bigger problem you are going to have is unless you have insane backend disk everything is going to get ugly as maintence will have issues running.

Not sure how much whitespace is in there but maybe a offline defrag if the number is fairly large.

 

[58sniper]

maintenance isn't an issue if the server is properly sized. If drive space isn't an issue, then there is no need for an offline defrag - especially since it requires downtime.

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/

 

[strongm]

>Theres a couple of registry keys you can change to make the size ok

???

In the days of Exchange Server 2003 (and 2000) Standard Edition prior to SP2 there was a registry setting that used to allow you to temporarily extend the maximum size from 16GB to 17GB

SP2 bumped the default store size up to 18GB, and provided a registry setting to allow up to 75GB.

But I am not aware of any registry setting that allows you to increase the store size beyond this in Exchange Server 2003 Standard Edition

 

[nichols]

I am going to run a defrag to see if this will reduce the space any. Will post back if this makes any difference.

I would love to upgrade to 2007 or even later but unfortunatley Credit Crunch has hit!!!!

 

[scottew]

I would love to upgrade to 2007 or even later but unfortunatley Credit Crunch has hit!!!!

I was in the same position, but something had to be done. Upgrading to the 2003 Enterprise Edition was the cheapest solution.

Scott

 

[58sniper]

An offline defrag isn't going to change the amount of data in the database. If you look at the event 1221 logs, you'll see how much white space you have. Subtract that amount from the total size of the .edb+.stm and that's how much data you have. That cannot exceed 75GB.

As I mentioned earlier, your mailbox limits should be configured so as not to reach 75GB. If they aren't, then your organization WANTS the possibility of corrupted/lost data.

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/

 

[Zelandakh]

Credit crunch means decisions. Either you upgrade, impose limits or have email stop.

 

[mofusjtf]

Additional to imposing limits as Pat mentioned, implement and email archive solution.

 

[ShackDaddy]

All of the above are good ideas. Just to mix it up, here's an "out of the box" solution:

Try setting up some public folders with locked down permissions for some of the different users to use as archive stores, and have them move, let's say, maybe all their sent items that are older than a year into them. That will allow you to really make use of some of the space that is in the public folder database and not have to resort to .pst files.

If you go this route, I would also make the public folder database delete-proof, since you wouldn't be able to use a recovery-storage group to fix it in the future if users manage to delete some stuff that they needed.

Dave Shackelford
ThirdTier.net