Exchange Transaction logs not truncating for a database which was enabled with circular logging

Issue:

Exchange transaction logs not truncating for a database which was enabled with circular logging.

Cause:

One of the database copy on the passive server was failed and suspended because of which the log files started to accumulate as those logs were still waiting for replication to the passive copy.

Lets see some information about Circular logging and steps taken to prevent the database from dismounting:

Circular logging is of two types JET circular logging and Continuous replication circular logging (CRCL). JET circular logging is performed by Information Store, and CRCL is performed by the Microsoft Exchange Replication Service.

• If the mailbox database is not replicated, it will use JET circular logging. In this case, enabling or disabling JET circular logging will require a dismount and mount of the database.
• If the mailbox database is replicated, it will use CRCL. In this case, enabling or disabling CRCL takes effect dynamically; there is no need to dismount and re-mount the database.

You enable and disable both features the same way; either by using the checkbox on the Maintenance tab of the database Properties dialog that says Enable circular logging, or by using the Set-MailboxDatabase cmdlet with the -CircularLoggingEnabled parameter

Here in our case CRCL type was enabled as the mailbox database is replicated.

We noticed that the disk space of the logs stored drive for the database DB1 on the mounted server EXserver1 and another healthy server EXServer2 decreased drastically. On checking further, we noticed that the transaction logs keep on accumulating and not truncating though circular logging is enabled.

When we checked the database copy status we have found that the database copy DB1 on the server EXserver3 was failed and suspended. This is the reason why the logs keep on accumulated .

When one of the database copy on the passive server is failed the Microsoft Exchange Replication Service which manages CRCL maintains the log continuity and won’t delete it if they are still needed for replication. The Microsoft Exchange Replication Service and the Microsoft Exchange Information Store service communicate by using remote procedure calls (RPCs) regarding which log files can be deleted.

Use the command Get-Mailboxdatabasecopystatus to check the database copy status

[PS] C:\Windows\system32> Get-Mailboxdatabasecopystatus DB1

Name                                Status                      CopyQueue Length      ReplayQueue Length

—-                                    ——                              ———                                ———–

DB1\EXServer1          Mounted                             0                                   0

DB1\EXServer2         Healthy                                0                                   1

DB1\EXServer3         Failed and Suspended      2776986                       0

Before reseeding the database we need to make sure the disk space of the drive where logs are stored should be reclaimed to prevent the database from dismounting.

In exchange Power Shell go to the folder where log files are located and run eseutil.exe /mk .\E00.chk to find the log files which were committed and currently in use.

Here the checkpoint value is 4DFA1F which means that log files lower than E08004DFA1F were committed and are no longer required by database. Select those log files and move it to another drive where enough space is available to gain some disk space.

Then update the failed database copy using the Power Shell command below and make sure it becomes healthy.

Update-MailboxDatabaseCopy “DB1\EXServer3” -DeleteExistingFiles:$true

Once the database become healthy we could see enough disk space on the log drive of the affected database DB1 in all the servers, because the mailbox replication service provides confirmation for deleting the replicated logs.

What we have learned from the scenario above is if any of the database copy is failed or failed and suspended the messaging administrator must act fast to make the copy healthy and also must check the disk space associated with the affected database log drive on the mounted server and other servers which holds the healthy copy of the database to prevent the database from getting dismounted.

If you enjoyed this post, I’d be very grateful if you’d help it spread by emailing it to a friend, or sharing it on Twitter or Facebook.

Please do comment for any queries

Sharing is caring!