Database Transaction Logs Are Not Truncated

Situation

A backup plan is completed successfully, but database transaction logs are not truncated on passive nodes within DAG. The following event is reported: A backup plan is completed successfully, but database transaction logs are not truncated.

Solution

Database transaction logs record all changes to an Exchange database. These logs currently have a fixed size of exactly 1MB. When a transaction log is complete, the transaction log is renamed with a numeric sequence number, and a new current log is generated. Microsoft Exchange Server uses a write-ahead approach to commit new data to the database. This means that when you create new Exchange items (emails, calendar events, etc.), data is written to the log file. After some time, these logs are committed to the database, and Exchange then truncates logs by marking them as recyclable. Normally, the logs are truncated (which makes them shorter and saves space) whenever you run a full backup of Exchange.

Over time, these log files accumulate and use all the available disk space if they are not periodically removed from the hard disk. Exchange automatically removes unnecessary log files by using one of the following methods:

• If circular logging is enabled, Exchange removes transaction logs soon after they have been written to the database file. This is slightly more complex in a Database Availability Group [DAG] scenario where Continuous Replication Circular Logging is used instead of “basic” circular logging, but that is not the point for this article;
• If circular logging is disabled, Exchange removes excess logs after a full or incremental backup. This is known as Log Truncation, the process whereby unwanted transaction logs are deleted.

For truncation to occur on highly available (non-lagged) mailbox database copies, the following must be true:

• The log file has been backed up, or CRCL is enabled.

• The log file is below the checkpoint.

• The other non-lagged copies of the database agree with deletion.

• The log file has been inspected by all lagged copies of the database.

For truncation to occur on lagged database copies, the following must be true:

• The log file is below the checkpoint.

• The log file is older than ReplayLagTime + TruncationLagTime.

• The log file is deleted on the active copy of the database.

But in some cases, related to configuration issues, the transaction logs get piled and fill up the volume or disk that they reside in. This can result in the dismounting of the database.

If you face up with this case, you should perform the following steps:

1. Perform log truncation on the passive node manually as described in the Microsoft Log Truncation Guide. Consider, if you use backup simulation to trigger Exchange logs truncation, event ID 2046 will be recorded instead of event ID 9780.

2. Resolve network connectivity issues. Refer to the following article for instructions on how you can troubleshoot and then resolve the network connectivity issues.

3. Perform health check for every node.

4. Resolve access issues. Grant required permissions and security descriptors for every node.

5. Check for and resolve possible Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. A quick adjustment to the security settings for the Volume Shadow Copy Service as described in the following KB can help correct the issue.

6. Restart nodes.

7. Check whether the following processes are running on active and passive nodes:

   • Cluster Service
   • Microsoft Exchange Active Directory Topology
   • Microsoft Exchange DAG Management
   • Microsoft Exchange Information Store
   • Microsoft Exchange Replication
   • Microsoft Exchange RPC Client Access
   • Microsoft Software Shadow Copy Provider
   • Volume Shadow Copy

8. Start full backup on the active node to trigger log truncation.

9. The following messages in Windows Event Viewer help you to check whether the log truncation will be started successfully:

   • Event ID 2046: The Microsoft Exchange Replication service VSS Writer instance ... has successfully completed the backup of database '...'. Database log truncation has been requested for this database. Log truncation will occur on the active copy after the next log generation is created. Log truncation will occur automatically on the passive copies after that log file is copied.

10. After the logs are truncated on the active node, and the result is replicated to the passive one, check if the log truncation is performed successfully on the passive node.