Friday, February 8, 2013

Circular Logging Grammar - How to Keep Exchange 2010 Databases From Dismounting

Circular Logging Grammar 

Disk space down down baby, yo' database dismount (c'mon)
Circlular logging baby, enabled ready to stop the growth (Hot Stuff!)
Shimmy shimmy Master what? Listen to me now
Enabled it up, go take a puff, Replicate it now

Everyone likes database dismounting, right? All sarcasm aside and to put the issue back to debate for the next 200+ words let’s talk about Circular Logging and Exchange 2010.

This topic has come and gone multiple times and no one seems to agree on the same answer. What exactly DOES circular logging do, other than make a lumberjack dizzy? Do I really have to dismount the database to actually enable the setting?
Webster Dictionary defines Circular Logging as… yeah… I’m not checking the dictionary. Circular Logging (CL) helps keep log growth to a minimum and truncates logs that have been committed/written to the database.

This is not just Exchange but most kinds of databases. Circular Logging in SQL is called Simple Recovery, this keeps the Transaction Log file from exceeding the size limits (with exceptions). The space is reused once the transaction has been written to the database. Imagine this as a really, REALLY big white board… like bigger than the Cowboys Stadium Ginormous TV. As transactions are committed, they are marked as such and SQL knows that that part of the log can be reused.

Back over to Exchange, CL is more like a large recycle bin and each log (defaults to 1MB) is a crumpled piece of paper. Once the Exchange server knows that the log has been committed, the piece of paper is pulled out of the recycle bin and reused. This can be handy for large mailbox moves, migrations, journaling mailboxes, and actions that would generate a large amount of churn (enabling Managed Folder Policies or Retention Policies that delete mail…ouch).

Now for the debate…

You can enable Circular Logging on an Exchange 2010 database that has more than 1 copy (DAG) without having to dismount the database.

Here’s why

Exchange 2003 and 2007, and single copy databases in 2010 (think Public Folders, stand-alone servers) log truncation is handled by Information Store. This is local to the machine itself. There are two methods to flipping the switch:
1.       Enable CL on the database and restart the Information Store.
2.       Enable CL on the database, dismount and mount ONLY that database.
Guess which one is the “preferred” method… you got it… Who does #2 work for?
With the introduction of the Database Availability Group (DAG) and having multiple copies of databases on different nodes of a cluster, log truncation is moved to the Replication service. To enable Circular Logging, all you have to do is
Set-MailboxDatabase –identity DATABASE1 –CircularLoggingEnabled $true

After flipping the switch, navigate over to the Logs directory and watch the logs go *POOF*. There are a few exceptions to the statement above and I’ll get to them later.
You might be saying, “Hey Mike, why on earth would I even consider doing this? I’ve been told this is bad.” To you I respond with a scenario that keeps coming up… a backup is running/failing, drive space is down to critical levels and a dismount is imminent. This is where knowledgeable admins can shine. Make sure that replication is healthy, enable logging, cancel the backup and wait for the Replication service to do its magic.
There are some caveats to this where a dismount really does need to happen
·         Replication is unhealthy. This might be due to replay queue length, copy queue length or a failed database copy
·         A database reseed is in progress. The reseed needs the logs to make sure that the data that is copied to the other node is correct and in sync with the seeding copy.
·         Exchange tells you that the database must be dismounted for the setting to take effect… This one is pretty straight forward and if you miss it… I can’t help.
So, you’ve enabled CL and the drive is back up to 99% free. You’re not out of the woods yet.
You still need to do the following and then some
·         Disable Circular Logging
·         Start a Full backup of the database. Do not attempt to do an incremental; it will fail as it will be looking for the logs you just got rid of.
·         Figure out the root cause for the drive filling up
o   Check Replication health (test-replicationhealth)
o   Look for mailbox moves (get-moverequest)
o   Determine if there are migrations being performed with a third-party tool (sorry, no cmdlet for this)
o   Check the logs on the backup server for errors or indicators of the problem.
I’ll leave you with this final tidbit…
I’ve got a lovely bunch of coconuts… and… my database didn’t dismount…

1 comment: