Exchange 2003 Disk Space Issues

The intent of this article is to describe the different scenarios and methods for disk space issues in Exchange 2003. Most of this information applies to all versions of Exchange; however, the information\screenshots below specifically apply to Exchange 2003.

Scenario #1 - Log Disk is Full

The only log files that can be removed manually are log files that do not contain uncommitted data. If a log file that is needed by one of the stores (contains uncommitted data) is mistakenly erased the store becomes inconsistent and un-mountable.

1. The Checkpoint file method

The checkpoint file is used by the Exchange storage system to identify the point up to which log files have been committed to the stores. Using the ESEUTIL tool we can dump this information from the checkpoint file.

The exact command used to dump the file is
ESEUTIL /mk <path to checkpoint file>
The only information we are interested in is the line that looks similar to the following one: Checkpoint: (0x3B37,D00,0). On this line inside the brackets you have three pieces of information of which only the first interests us - 0x3B37. The first piece of information points to the log file which is borderline, everything before it can be removed and everything after it is needed to keep the databases consistent.

In our case 0x3B37 actually means that the log file prefix is E00 and suffix is 03B37. So the filename is E0003B37.log

Keep in mind that by erasing log files you lose the ability to restore the system to a point in time so my advice is to simply move the files to a different location. That way, if anything goes wrong you can always copy all log files back to their original location.

2. The database files method

Each database file used by the store contains information about the log files it needs to become consistent. This can be determined by using the command
ESEUTIL /mh <path to database file>
We are interested in two lines, State and Log Required.

State -- This line specifies the database state which can be either Clean Shutdown or Dirty Shutdown:

Clean Shutdown -- indicates that the database was dismounted in an orderly fashion or in other words it means that all outstanding transactions were committed to the database and it is consistent(no log files are needed to bring it to a consistent state).

Dirty Shutdown -- indicates that the database was shut down incorrectly outstanding transaction from log files were not committed and the database is inconsistent. The next time the store is mounted the database files will need specific log files to become consistent-without them the store will not mount.

Log Required -- this line specifies the log files needed to make the database file consistent.

State: Clean Shutdown – the Log Required line will show 0-0, meaning no log files are needed.

State: Dirty Shutdown -- The Log Required line will show a range of numbers such as 17-19. This is the range of log files needed to bring the database to a consistent state (17, 18, 19). To identify the log filenames the numbers have to be converted hexadecimal, in our case 11, 12, 13 adding the prefix to it (based on the log prefix for the storage group) E0000011.log, E0000012.log, E0000013.log.

After identifying the committed log files they can be manually erased. When you have enough space on the volume you can mount the stores.

Scenario #2 - Database Disk is Full

Proactive Approach – for use when database disk is near capacity

1. Free Space

After the nightly online defragmentation occurs the database reclaims unused space and allows it to be repopulated with new data. The actual size of the free space can be determined by examining the application event log pertaining to event ID 1221. Exchange will continue to fill up the free space before growing the physical size of the database file.

2. Mailbox Moves

To gain additional free space within the database file, we can move mailboxes from the selected information store to another less impacted information store.

Moving mailboxes in Exchange Server 2003
http://support.microsoft.com/kb/821829

3. Offline Defragmentation

In order for the database file to shrink in physical size and offline defragmentation must be performed. This maintenance will remove the free space from the EDB file and reflect the actual size of the database file thereby freeing physical disk space.

How to defragment with the Eseutil utility (Eseutil.exe)
http://support.microsoft.com/kb/192185

Reactive Approach – for use when database disk reaches full capacity

[step="" title="Relocation"]At this point, the information store cannot mount since there is no place for the database to commit the transaction logs. The only viable solution is to move the database file(s) to another disk.

In Exchange System Manager locate the Store whose files you would like to move.

Right click over the Store and select “Properties”. The Properties dialogue box for the Store will now be displayed.

Select the “Database” tab. You will now notice that we have the ability to alter the location for the “Exchange Database” which is the EDB file, and the “Exchange Streaming Database” which is the STM file. While it is recommended that both databases be at the same location, we can move the smaller of the two in order to resume services as soon as possible. Most of the time the STM file will be the smaller of the two.

It is important to remember that during the move process the Store will be dismounted and users who have mailboxes in that Store will be unable to access their email until the Store has been remounted.
[/step]

Reference:

http://www.msexchange.org/articles/Exchange-log-disk-full.html