How to remove Exchange Server transaction log files

Exchange Server database transaction logs record all changes to an Exchange Server database. Over time, these log files accumulate and use all the available disk space if they are not periodically removed from the hard disk.

Exchange transaction log files have a fixed size. For Microsoft Exchange Server 2003 and all earlier versions of Exchange Server, this size is exactly 5 megabytes. When a transaction log is full, the transaction log is renamed with a numeric sequence number, and a new current log is generated.

The current transaction log is the one most recently created by Exchange Server. In Microsoft Exchange Server 5.5, the current transaction log is always named Edb.log. In Microsoft Exchange 2000 Server and in Exchange Server 2003, the current log is named with the storage group prefix. For more information, see the �Storage groups� section.

Exchange automatically removes unnecessary log files by using one of the following methods:

• If circular logging is enabled, Exchange Server removes transaction logs soon after they have been written to the database file. This process may cause a delay on some idle systems until the current Exx.log file of the relevant storage group or the Edb.log file in Exchange Server 5.5 becomes full and has to be renamed. To speed up new log file creation and the automatic deletion process, you can send yourself an e-mail message with a 5-megabyte (MB) attachment.
  
  Note By default, circular logging is enabled in Exchange Server 5.5. By default, circular logging is not enabled in Exchange 2000 Server or in Exchange Server 2003.
• If circular logging is disabled, Exchange Server removes excess logs after a full or incremental online backup of all the databases in a storage group is performed.

For more information about how the Exchange logging mechanism works and about how to change it, click the following article numbers to view the articles in the Microsoft Knowledge Base: If 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 anticipate running 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 a log that contains data that has not yet been written to the database files, the databases will no longer be mountable after an abnormal stop. Therefore, you must determine which logs are safe to remove before you manually remove any Exchange Server transaction log files.

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, depending 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.

Manually removing transaction log files that are not required

To correctly remove excess transaction log files, follow these steps:

1. Stop all the databases in the storage group.
2. Verify the state of each database file in the particular storage group. For information about how to verify the state of each database file, see the "Database states" section.
3. Perform one of the following actions:
   • If one or more of the databases are in a Dirty Shutdown or Inconsistent state, determine which transaction log files can be removed without affecting database consistency. For more information, see the "Log files" section.
   • If all the databases are in a Clean Shutdown or Consistent state, you may remove all the transaction log files except for the current transaction log file. Removing the current log file when all databases are in a Clean Shutdown state 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.
4. Copy all the transaction log files that you want to remove to a different location before you permanently remove them from the transaction log hard disk. Do not permanently delete the transaction log files until you have successfully completed a full online backup of all the databases in the storage group.

The following sections describe the relationship between transaction log files and the Exchange Server database. The sections also provide detailed instructions about how to determine which log files are safe to remove.

Database states

If an Exchange Server database has not been shut down correctly, the database remains "attached" to its transaction log stream. This means that not all the data from the transaction log file has been secured to the database files. During the next startup of the database, Exchange Server detects this condition. Exchange Server then applies the missing data to the database files. If the log files that contain this data are not available, the database cannot be started.

When an Exchange Server database is shut down correctly, that database "detaches" from its transaction log stream. In this situation, the database does not require the previous transaction log files when that database next starts. However, these log files could be useful if a backup or an earlier version of the database were to be restored. The log files will be used to roll the database forward from the time of backup. Therefore, transaction log files should not be permanently deleted until you are sure that you will not want to replay them into an older version of the database.

Before you manually remove any transaction log files, you should determine the state of any database that used the particular transaction log files. In this situation, determine the "attach" or "detach" state of each database that used the particular transaction log files. You can determine whether a database is attached or detached by examining the database file header by using the Eseutil utility's /MH command switch. For example, run the following command at a command prompt where database_name is the name of the database that you want to examine: For example, to examine the Mailbox Store (Server1) database, typeNote To examine the header of a database by using the Eseutil command, the database must be stopped.

After you run this command, examine the State value 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, depending on the version of Exchange Server that is running.
• If the database has not been correctly detached, the state value is Dirty Shutdown or 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 or unless you repair the database by using the Eseutil command and the Isinteg command.
  
  For more information about how to repair an Exchange Server database, click the following article number to view the article in the Microsoft Knowledge Base:
  812357 How to maintain your Exchange database after you repair by using the Eseutil /p tool in Exchange Server 5.5, in Exchange 2000 Server, and in Exchange Server 2003

Two reserve transaction log files that act as placeholders and that reserve hard disk space are also available in case the hard disk on which the transaction log files are stored becomes full. These reserve transaction log files are named Res1.log and Res2.log. If the hard disk where the transaction log files are located becomes full, Exchange Server will use these two reserve transaction log files to continue logging long enough to stop the database cleanly. When Exchange Server cannot create an additional transaction log file because the log disk is full, Res2.log is renamed and is used as the next log. If it is required, Res1.log will also be used.

Sometimes the capacity of both of the reserve transaction log files might be exceeded. This causes all the databases in the storage group to be stopped in a Dirty Shutdown or Inconsistent state.

Warning If you run out of disk space on the transaction log drive, the databases may not be able to shut down cleanly. If one or more of the databases are in a Dirty Shutdown or Inconsistent state and if you delete all the transaction log files in order to free disk space, no databases in the affected storage groups will be mountable again without being repaired or restored. You must not delete log files that are still required by one or more of the databases.

Storage groups

Exchange Server databases are organized into storage groups. A storage group is a set of databases that share a single transaction log file stream. In Exchange Server 5.5, there is a single Information Store storage group that contains up to two database files. These two database files are named Priv.edb and Pub.edb respectively. Additionally, Exchange Server 5.5 contains a single Directory Service storage group that contains a single database file that is named Dir.edb.

In Exchange 2000 Server and in Exchange Server 2003, there is no Directory Service storage group. In Exchange 2000 Server and in Exchange Server 2003, there can be up to four Information Store storage groups per server. Each of these storage groups can contain up to five databases. The names of these databases are configurable by the administrator.

If the transaction log drive becomes full, all databases in the storage group will be stopped immediately. When you start any database in a storage group, the state of all databases in the storage group is checked. Any required transaction log file replay is performed together for all databases before the first database can start. Transaction log file replay operations and events generally apply to all databases in a storage group, not to an individual database.

Important You should verify that each database file is in a Clean Shutdown or Consistent state. One or more databases in a particular storage group may be correctly detached even though another database in that same storage group is not correctly detached. Do not assume that all databases in a storage group are in a Clean Shutdown state based on the state of the first database that you examine.

Note For Exchange Server 5.5, you must examine each database that is contained in a single .edb file by using the Eseutil command. For Exchange 2000 Server and for Exchange Server 2003, each database is divided into two files. The two files are an .stm file and an .edb file. Examine the state of both the .stm file and the .edb file by using the Eseutil command.

Log files

To determine which transaction log files are required by the databases in a particular storage group, follow these steps.

For Exchange Server 5.5

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

1. In the Exchange Server Administrator program, view the working path for the database.
   
   Path locations are found on the Database Paths properties page of the Server object. The checkpoint file (Edb.chk) is located in this path. If the Administrator program is unavailable, you can view the working path in the system registry. Run Registry Editor and expand the following registry subkeys.
   
   For the information store:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Working Directory
   For the directory:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\DSA Working Directory
2. At a command prompt, move to the working path folder. View the header of the Edb.chk file by using the Eseutil command:
   eseutil /mk edb.chk
   Note that the screen output is similar to the following:

   Microsoft(R) Windows NT(TM) Server Database Utilities
   Version 5.5
   Copyright (C) Microsoft Corporation 1991-1998. All Rights Reserved.
   
   Initiating FILE DUMP mode...
   Checkpoint file: edb.chk
   
   LastFullBackupCheckpoint (0,0,0)
   Checkpoint (157,2860,500)    comment: Checkpoint is in log 157 decimal
   FullBackup (90,8,10)
   FullBackup time:1/15/1999 18:18:36
   IncBackup (0,0,0)
   IncBackup time:0/0/1900 0:0:0
   . . .
   						

   The three numbers on the Checkpoint line represent the log file generation number, a sector offset into the log file, and a byte offset into the sector. Write down the generation number.
3. Convert the generation number into hexadecimal. In this example, decimal 157 translates to hexadecimal number 9D. Exchange Server log files are numbered with five hexadecimal digits. For example, a log file can be named as Edb12345.log. Leading zeros are used to pad the log number out to five digits. Therefore, the checkpoint log file from the previous example is Edb0009d.log.
   
   Note You can use the Scientific mode of the Windows Calculator to convert from decimal to hexadecimal. Start the Calculator. Then, click Scientific on the View menu. Enter the decimal number, and then click Hex.
4. The checkpoint log and all logs generated after the checkpoint log are required to start a database when the database is in an Inconsistent state. You may not find a log file that corresponds to the checkpoint value that you calculated. This can occur if the checkpoint is in the most recent log file that is always named Edb.log. Until this log is full and until a new log is generated, the file name of the current log does not include the log sequence number.
   
   You can verify the actual internal sequence number of the Edb.log file by viewing the log file header by using the following Eseutil command:
   eseutil /ML Edb.log
   The lGeneration field of the log file header reflects the actual sequence number of the log file. You must convert the lGeneration value to hexadecimal.
5. You can safely remove all numbered logs less than the checkpoint log. However, do not remove the checkpoint log itself. In this example, you can remove Edb0009c.log, Edb0009b.log, and so on, but not Edb0009d.log or the current log.
   Remember to move, not delete, the log files. You do not have to stop the database service to remove log files that are older than the checkpoint.

If you must restore a backup, you must also restore all log files that are created after that backup if you want to completely roll the database forward. If there is a break in the sequence of logs, you cannot roll forward past the break.

For Exchange 2000 Server and for Exchange Server 2003

1. 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.
2. At a command prompt, move to the path of a database file.
3. Run the following Eseutil command to view the header of the database file:
   eseutil /mh database_file
4. Examine the Log Required field in the database file header. 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 means that the database is in a Clean Shutdown or Consistent state.
   
   Note To examine the header of a database by using the Eseutil command, the database must be stopped. However, in all versions of Exchange Server, you may examine the header of the checkpoint file when databases are running. The procedure for examining the checkpoint file is the same for all versions of Exchange Server and is described in the �For Exchange Server 5.5� section. Viewing the checkpoint value lets you determine which log files can be removed without having to stop the databases. Log files may be removed that are older than the checkpoint log and that do not include the checkpoint log.
5. 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 Server 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.
   
   Note In Exchange Server 5.5, log files are named Edbxxxxx.log, where "xxxxx" is a five-digit hexadecimal number. Because you can have up to four storage groups in Exchange 2000 Server and in Exchange Server 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 Server and in Exchange Server 2003, the "Edb" prefix is replaced with "E00," "E01," "E02," "E03." For a Recovery Storage Group, "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.
   
   You should examine the Log Required values for each database in a storage group before you remove any logs for that storage group.

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. Remember to move, not delete, the log files.

Note The Log Required field may report a range of one log, but the corresponding numbered log file cannot be found. For example, The Log Required field may report a range of 28221-28221, but the log file that is numbered 28221 cannot be found. This can occur if the checkpoint is in the most recent log file. The most recent log file is always named with only the storage group prefix. For example, the most recent log file may be named E01.log. Until this log is full and until a new log is generated, the file name of the current log does not include the log sequence number.

You can verify the actual internal sequence number of the current log file by viewing the log file header by using the following Eseutil command: For example, if the log prefix is E01, use eseutil /ML E01.log. The lGeneration field of the log file header reflects the actual sequence number of the log file.

If you must restore an Exchange Server database from a backup, and if you want to recover the Exchange Server database without losing data, you must also restore all the transaction log files that were created after that backup was performed. If there is a break in the sequence of the transaction logs, you cannot roll forward past that break. In this situation, you must remove all the higher-numbered logs after the break. This includes the current log file.

Note Even if all the databases in a storage group are in a Clean Shutdown or Consistent state, you should not remove the most recent log file. If you remove the most recent log file, a new set of log files is generated, starting with the sequence number 0x000001. This new set of log files will prevent an Exchange Server database from a previous backup from being rolled forward.

For more information about how to repair an Exchange Server database, click the following article number to view the article in the Microsoft Knowledge Base: