I’ve had to look this up so many times because we don’t do it that often and the articles Microsoft provides us aren’t as great as they should be. So I’ve decided to write up a little how-to when searching for committed transaction logs within Exchange.
Why would you look for committed transaction logs? Mostly for space or an out of control Exchange Database, due to clients or corrupt store. Transaction logs can fill up a drive quickly if not monitored or if you don’t have a solid backup solution in place. Typically, your standard backup software will trigger an event to occur on the Exchange server, after a successful backup of the Information Store / Storage Group is completed. This basically tells Exchange (ESE) to wipe out all transaction logs that have been committed to the Database before the successful backup.
Only follow these instructions if you feel you are going to fill up a drive with transaction logs and you have no other option to recover. Beware, Exchange expertise is required while following these steps. Use this at your own risk. The drive letters used are just for example.
1. Locate the System Path for the Storage Group in Question.
Right Click on the Storage Group and Click Properties. Locate the System Path on the General Tab. (See Image Below)
2. Find the name of the CheckPoint File by Viewing the system path folder by going to a command prompt and doing a directory listing of this folder. ( Example: <<CMD Prompt:>> E:EXCHSRVRMDBDATASG1TEMPDIR *.chk )
3. Run the following Eseutil command from the Exchange Binary Folder to view the header of the database file: eseutil /mk (Storage Group CheckPoint PathCheckPoint File) (See Image Below)
4. Note the CheckPoint Value Highlighted below:
5. Take the first number in the parentheses for the Checkpoint field. The hexadecimal number is the file name of the first uncommitted log for the appropriate database; in this example:
Checkpoint (0x549C,1F00,0) = E000549C.log (In this example, you remove the 0x and replace it with E000. The Transaction log in question will always end with the number listed after 0x.)
6. E000549C.log is the most recent log file that has not been committed. Any file older then this log file for the Storage Group in Question has been committed. (This does not apply to any other storage group, only the storage group you listed the Checkpoint Attribute from.)
7. For Example, all of the log files highlighted by the red square have not been committed. All of the log files before E000549C.log have been committed. It is safe to say the log files with an older date then the file listed as the checkpoint value can be moved to an alternate drive** in the event of a drive space problem. Do not delete these files in the event of a required recovery or replay of the logs. You can safely delete the files you moved after you have a successful and confirmed backup of this storage group.
** Move committed transaction log files to an available local or network drive that will not interfere with a standard log file production drive.
