Exchange Server provides two mechanisms to prevent the transaction log drive from filling up:

• Circular logging. Transaction logs are automatically deleted after the database checkpoint has advanced past them. Disk space that is used for transaction log files will remain under 50 MB under most conditions. During backup, removal of transaction logs may be suspended until the backup is complete.
  
  

  Note:
  By default, circular logging is not enabled in Microsoft Exchange 2000 Server and later versions.

• Storage group backup. Exchange Server removes excess logs after a full or incremental online backup of all the databases in a storage group is performed by using a backup method that implements the Volume Shadow Copy Service (VSS) or streaming online backup APIs for Exchange Server.
  
  

If circular logging is not enabled and any one of the following conditions is true, the transaction log files will increase in number until the hard disk drive space is exhausted:

• The backup program does not remove the transaction log files.
  
  
• The backup program has stopped running.
  
  
• The transaction log files are not purged by using some other method.
  
  

You may occasionally have to manually remove transaction log files if you have run out of hard disk space. Or you may occasionally have to manually remove transaction log files if you expect to out of hard disk space before you can run a full or incremental online backup of all the databases in a particular storage group. If you remove logs that are still ahead of any database checkpoint, and the database is then stopped abnormally, the database cannot be mounted until the necessary logs are restored. Therefore, you must determine which logs are safe to remove before you manually remove any Exchange Server transaction log files.

The error may also be reported as JET_errDiskFull or error code 0xfffff8f0. This error applies to the following versions of Exchange Server:

• Microsoft Exchange Server 2007
  
  
• Microsoft Exchange Server 2003
  
  
• Microsoft Exchange 2000 Server
  
  

To resolve the error, select either of the following solutions:

• Run the Database Recovery Management tool. In Microsoft Exchange Server 2007, the tool is listed under Database recovery tools in the Toolbox in the Exchange Management Console. The Exchange Server Analyzer can automatically determine which log files can be safely removed and will copy them to a backup location for you. We strongly recommend that you use the Exchange Server Analyzer to move log files.
  
  

  Note:
  The Exchange Server Analyzer will not work in Exchange 2007 if the storage group that contains the database is enabled for cluster continuous replication (CCR).

• Check the State and Log Required values in each database header to determine which transaction log files are safe to be manually removed.
  
  

  Note:

  For the purposes of this article, removing a transaction log file means moving that transaction log file to another location where the transaction log file can be backed up, stored, or deleted. The action will depend on your requirements. For the purposes of this article, deleting a transaction log file refers to the kind of removal that does not let you to back up or restore that transaction log file.

Follow these detailed steps to determine which transaction log files are safe to be manually removed.

To examine the header of the database and remove unnecessary log files

1. Dismount the database whose header you want to examine.

2. Click Start, click Run, and then type cmd to open the Command Prompt window.

3. At a command prompt, move to the directory path where the databases file is located.

   Note:

   In Exchange 2000 Server and Exchange Server 2003, to determine the path and the file name of the .edb and .stm files for a database, use Exchange System Manager to view the Database tab of the properties dialog box for each database object. In Exchange Server 2007, to determine the name and path of the database file, expand the Exchange Management Console under Server Configuration, click Mailbox, and then view the Database Management tab.

4. Type the following Eseutil command together with the /MH switch at a command prompt:

   	Copy Code
   "eseutil /MH databasefilename.edb"

   Note:
   In the syntax, databasefilename is the name of the database that you want to examine.

5. Examine the State and Log Required values in the header information that appears.

   The State value provides the following information about whether the database has been correctly detached:

   • If the database has been correctly detached, the State value is either Clean Shutdown or Consistent. This value depends on the version of Exchange Server that is running. You may remove all the transaction log files except for the current transaction log file.
     
     

     Note:
     If you remove the current log file when all databases are in a Clean Shutdown state, you will cause a reset of the log file sequence. This does not prevent databases from starting. However, a reset of the log file sequence affects the ability to roll a database forward from a previous backup if the situation occurs.

   • If the database was incorrectly detached, the State value is Dirty Shutdown or Inconsistent. Determine which transaction log files can be removed by checking the Log Required field in the database header.
     
     

     Note:

     When the database is in a Dirty Shutdown or is Inconsistent, this means that some of the existing transaction log files contain outstanding transactions that are required by the database. If you remove the transaction log files in this situation, the database cannot be started again unless you restore the database from a backup. Alternatively, you can repair the database by using the Eseutil command and the Isinteg command.

     You should examine the Log Required values for each database in a storage group before you remove any logs for that storage group.
     
     The Log Required field lists the range of numbered log files that are required to start this database. If the range is 0 - 0, no log files are required to start this database. This indicates that the database is in a Clean Shutdown or Consistent state. If there are log files older than the checkpoint log, you can remove those log files excluding the checkpoint log.
     
     If you are running a version of Exchange Server that is earlier than Exchange Server 2003 Service Pack 1 (SP1), you must convert the decimal range that is listed in the Log Required field to hexadecimal values. For example, if the Log Required value is 28217 – 28221, log files from 06E39 to 06E3D are required by this database. In Exchange  2003 SP1, the Log Required field has been enhanced to report both decimal and hexadecimal values.
     
     

     Note:
     You can use the Scientific mode of the Windows Calculator to convert from decimal to hexadecimal. Start the Calculator, and then click Scientific on the View menu. Enter the decimal number, and then click Hex.

     Because you can have up to four storage groups in Exchange 2000 and in Exchange 2003 with each storage group having a particular set of log files, the Edb prefix does not appear in the transaction log file names. In Exchange 2000 and in Exchange 2003, the Edb prefix is replaced with E00, E01, E02, or E03. For a Recovery Storage Group, the Edb prefix is replaced with R00. The storage group log file name prefix appears in Exchange System Manager on the General tab of the properties dialog box for the particular storage group object. Therefore, if the storage group prefix is E01 and if the Log Required entry is 28217 – 28221 (0x06E39 – 0x06E3D), the actual logs that are required are E0106E39.log to E0106E3D.log.
     
     

6. You can safely remove all the numbered log files that are less than the lowest entry in any Log Required field for any database in the storage group.

   Note:
   Remember to move, not delete, the log files.

   Note:

   As a best practice, you should not remove the most recent transaction log file. This is the log file that has the most recent timestamp and that does not yet have a sequence number in its file name. Even if you have determined that it is safe to remove this file, let it remain to avoid resetting the log file sequence back to 0. If you reset the log file sequence, you will affect backup cycles. You may be unable to roll the database forward from a backup taken before the reset.