• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 671
  • Last Modified:

Exchange 2003 Keeps Going Offline

Recently our Exchange database reached its limit and went offline. I brought it back online and we archived the emails to reduce the size. But the database still goes offline and in the event log it show that the database is over the 18gb limit. The database is now 10gb.

How do I resolve this issue?
0
mail2clk
Asked:
mail2clk
  • 6
  • 3
  • 2
  • +2
1 Solution
 
Alan HardistyCommented:
If you increase the maximum database size in the registry, you can prevent this from happening until the database gets too big again (details in the link below):

http://support.microsoft.com/kb/912375

Set something like 40Gb to give yourself some time to play and some room to grow.

Once you hit 75Gb - you can't get any bigger and would either need to archive or upgrade.
0
 
mail2clkAuthor Commented:
We are already down to 10gB. I am concerned there is a corruption somewhere. Offline defragmentation took nearly 6.5hrs.
0
 
Alan HardistyCommented:
The store will retain deleted items for the duration of the setting on the database for deleted item retention.

If you edit the registry to allow the database to be actually larger than the default 18Gb limit, then your problem will go away.
0
Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

 
mattyb_Commented:
There shouldn't be any corruption with the actual database due to the fact that when you complete an offline degrag, there is a new database created and the old one removed.
Any corruption could stop that process.

6.5 hours does not seem an overly long time for a defrag as this will normally take an hour for every 5 -7 gb of data.

The database reporting is the combination of both the edb file + the stm file - any free space.

Exchange Database size calculation

Have a look through your event logs for an 1221 event. You should have one of those for each database (private and public). This will show you how much free space is available.

If your STM database is quite large, that may show that you are being used as an open relay, so check that out.

Personally, if not done already patch your exchange to SP2, you can then increase your database size limit upto 75Gb.

Exchange 75Gb database limit
0
 
TheGeezer2010Commented:
Are you running Full or Incremental Backups regularly to truncate the Transaction Logs - if not you are going to experience big problems recovering.
0
 
Alan HardistyCommented:
How is that relevant to the issue being discussed?
0
 
mail2clkAuthor Commented:
I've applied the fix and increased the database size. Would enabling " Zero out deleted pages" help with the issue?
0
 
TheGeezer2010Commented:
>>I brought it back online and we archived the emails to reduce the size<<
0
 
Alan HardistyCommented:
If you have increased the database size - that should be all you need to do to stop the store dismounting.  You should now have time and space to grow into the database some more before having further problems and I would leave it at that.
0
 
Alan HardistyCommented:
TheGeezer2010 - And?
0
 
mail2clkAuthor Commented:
Attached is a screenshot of the file size.
Screen-shot-2012-03-23-at-11.52..png
0
 
SurajCommented:
Ask users to make pst and move large emails to them.
Run online maintenance.
then dismount and then run offline defrag. This will help you for sure.
http://support.microsoft.com/kb/324358
http://support.microsoft.com/kb/328804
0
 
Alan HardistyCommented:
You don't need to perform an offline defrag - what good is that going to do?  The database size has been increased and the problem will now be resolved.

Event ID 1221 will advise how much space an offline defrag will be able to reclaim and if you want to take the store offline to perform a slow defrag and have users unable to access their emails whilst the defrag takes place, then fair enough - but it will be offline for about 4-5 hours, which is utterly pointless.  After 30 days (default), the space will be reclaimed in the database from the messages that have been archived.

If disk space is an issue and you need to shrink the database, then perform an offline defrag, but it currently a waste of time.
0

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

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