Share via

Verifying log file truncation…

  • Article

In support we see cases from customers regarding log file truncation.  One question that commonly comes up is how do you verify log file truncation actually occurs?

 

The most common method that administrators use when verifying log file truncation post backup is to review the log file directory and note the count of files within this directory.  In general, on servers under load that generate a large number of log files in-between backups, this is a safe method to verify log truncation.  If there were many logs in the log directory prior to backup and only a few remain post backup, log file truncation would be considered successful.

 

In a lab environment or servers that are not under load the directory method of verification may not actually work.  Take the following example:

 

  • I review the log directory prior to backup and the directory contains 10 logs.
  • I run a successful full backup.
  • I review the log directory after backup and the directory now contains 10 logs.

 

Visually it would appear that no log files truncated at all.  In actuality 1 or 2 log files truncated at the same time you generated 1 or 2 more.  Therefore there is no change in file count for the directory. 

 

How can I verify that log truncation was successful?

 

In general I recommend avoiding the directory file count to verify log truncation.  A reliable way to verify log file truncation is to record the log sequence both pre and post backup.  This can be done using the eseutil /ml command.  To dump an entire log sequence the administrator would run eseutil /ml ENN (ENN = log generation prefix).  This will dump all log files found in the directory and their order – the output can be piped to a text file for later review.  Let us take a look at an example.

 

  • Using a command prompt navigate to the log file directory.
  • Run eseutil /ml ENN.  This will provide a list of the log files found in the directory.  (Note that the error at the end of the command is expected since the current log file is locked for access).

 

[PS] P:\DAG\DAG-DB0\DAG-DB0-Logs>eseutil /ml E02

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.02
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...

Verifying log files...
Base name: E02

      Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A66C.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A66D.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A66E.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A66F.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A670.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A671.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A672.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A673.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A674.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A675.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A676.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A677.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A678.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A679.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67A.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67B.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67C.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67D.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67E.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E02.log
ERROR: Cannot open log file (P:\DAG\DAG-DB0\DAG-DB0-Logs\E02.log). Error -1032.

Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use) after 1.981 seconds.

 

[PS] P:\DAG\DAG-DB0\DAG-DB0-Logs>eseutil /ml E02

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.02
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...

Verifying log files...
Base name: E02

      Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A679.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67A.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67B.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67C.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67D.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67E.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A67F.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A680.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A681.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A682.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A683.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A684.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A685.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A686.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A687.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A688.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A689.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A68A.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A68B.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A68C.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A68D.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A68E.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A68F.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A690.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A691.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A692.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A693.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A694.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A695.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A696.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A697.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A698.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A699.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A69A.log - OK
Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A69B.log – OK

 

  • Compare the two files to note the first log file referenced in each file.
    • Pre-backup:  Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A66C.log – OK
    • Post-backup: Log file: P:\DAG\DAG-DB0\DAG-DB0-Logs\E020000A679.log – OK
  • Since there is a difference in the first log noted in each output then log truncation can be considered successful.

 

By using this method you can not only reliably verify log files both pre and post backup but also record diagnostic information that may be helpful when engaging support for potential issues regarding log file truncation.

Comments

  • Anonymous
    January 01, 2003
    @Domenico: Thanks! TIMMCMIC

  • Anonymous
    January 01, 2003
    @Roy...

    I'm glad you found this helpful.

    Tim

  • Anonymous
    January 01, 2003
    @Swimfan...

    Excellent

    TIMMCMIC

  • Anonymous
    May 21, 2012
    helpful and detailed information. Now it will be easy to describe to the clients. :)

  • Anonymous
    November 21, 2012
    Excellent explanation, Tim you should be hired to answer all the unanswered thread on Microsoft's Social Technet site :-)

  • Anonymous
    March 30, 2014
    Very Helpful! Thanks

  • Anonymous
    January 29, 2015
    Nice. I just verified the log truncation using the above trick and as mentioned the logs began with different file names before and after the full backup.

  • Anonymous
    December 04, 2015
    can i run eseutil command when db in mounted copy or passive copy

  • Anonymous
    December 06, 2015
    @Ameen:

    You can run eseutil to check the log files on any copy that is healthy or the active database. The one thing to consider is that it will always fail at the end with logs that are locked for reading etc.

    TIMMCMIC