none
log files filled up drive on Exchange 2003

    Question

  • I ran out of space on the log volume on Exhange 2003.  I then enabled circular logging and restarted the store service but the log files did not shrink.  So I moved few log files out of the directory and after restating store service the log files all went away.  My question is: have I lost some info from the Exchange DB?  Also, I am wondering how the log files work in regards to DB with Exchange: if circular logging is disabled does the info get commited to DB and written to log file (ie for recovery to roll things back) or does it wait until say full backup rolls around and then comits the files/info to DB.  If the latter how come Exchange was able to commit the log files with some missing?  And lastly since I still have the few log files I moved out of the directory can I replay them to DB somehow?

    Wednesday, September 12, 2012 4:30 PM

Answers

  • How to remove Exchange Server transaction log files

    Article ID: 240145 - View products that this article applies to.

    This article was previously published under Q240145

    This article is a consolidation of the following previously available articles: 259751, 315196

     

     

    This article also contains information about deleting the transaction log files. In a worst-case disaster scenario, you may not be able to recover all your data without the log files if the database becomes corrupted. Transaction log files provide a high level of recoverability. Therefore, you should only perform the procedure that is discussed in this article as a last resort in emergency situations if you cannot complete a full backup. A full backup permanently deletes the committed logs automatically after backing them up.

    Expand all | Collapse all

    On This Page

    SUMMARY

    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:

    147524 How circular logging affects the use of transaction logs

    258470 How to modify the circular logging setting

    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.

    Back to the top | Give Feedback

    MORE INFORMATION

    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.
    1. 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.
    1. 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 aClean       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.
    1. 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:

    eseutil /MH database_name

    For example, to examine the Mailbox Store (Server1) database, type

    eseutil /MH “Mailbox Store (Server1).edb”

    Note 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 Isintegcommand. 
               
                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 namedRes1.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 Eseutilcommand. 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:

    322756 How to back up and restore the registry in Windows

    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
    1. At a command prompt, move to the working path folder. View the      header of the Edb.chk file by using the Eseutilcommand:
               
      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.
    2. Convert the generation      number into hexadecimal. In this example, decimal 157 translates      to hexadecimal number9D. Exchange Server log files are numbered with five      hexadecimal digits. For example, a log file can be named asEdb12345.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.
    3. 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.
    1. 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.
    1. Run the following Eseutil command      to view the header of the database file:
               
      eseutil /mh database_file
    2. 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.
    1. 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 theLog 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:

    eseutil /ML log_prefix.log

    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:

    893083 Top support issues for the Exchange information store

     

    Pasted from <http://support.microsoft.com/kb/240145>

    • Marked as answer by wwodzien Wednesday, September 19, 2012 2:06 PM
    Wednesday, September 19, 2012 2:05 PM