While presenting a session on Common Backup Problems both at SQL Saturday in Orange County and at SQL Connections in Las Vegas, questions came up regarding whether, when, and how your databases should be configured in FULL recovery mode and what that means for your recovery plans.
To boil the questions down to as simple a single statement as possible:
Should your database be in FULL recovery mode at all times which requires you to run log backups on a regular schedule?
The same question came up while Brad McGehee(blog|twitter) was presenting a session on using the settings on your SQL Server instance and your database to ensure you got proper performance. We both answered the question the same way, but our emphasis was slightly different.
Brad’s answer was that, yes, you should, by default, set your databases to FULL recovery in order to plan for the possibility of a point in time recovery. I agree with him.
But, my answer was different. What I said was, you need make a choice here. Yes, you should have your production databases in FULL recovery in order to arrive at the best possible recovery process. However, that means you’re dedicating yourself to maintaining log backups. If, for whatever reason, you can’t maintain log backups, then you should set your recovery to SIMPLE.
My point was not to disagree with Brad, or, more accurately, I don’t think he disagreed with me (since he went on 2nd). Rather, I’m trying to tell you that you must make that choice. You need to either commit to the process of setting up an appropriate recovery process for your production systems, which, in the majority of circumstances should include log backups, or, you need to admit that you can only recover your databases to the last FULL or DIFFERENTIAL backup and make that part of your documented plan, setting your databases to SIMPLE. What you can’t do, at least not any more since SQL Server 2008 was released, is rely on BACKUP LOG WITH NO_LOG or WITH TRUNCATE_ONLY as a means for leaving your database in FULL recovery, but also throwing away the log data (and I’ve never understood why people do that except through ignorance of how Log backups & recovery works).
Now, you have to commit. I believe you should set up the Log backups, but if you don’t, fine, turn off FULL recovery. Just do so with the complete knowledge of what that means.
Good Debate!
But do we can highlight the Performance Problem with FULL Recovery Models?
Thanks!
I’ve seen very few, if any, issues with databases in FULL recovery mode, so I’m not sure where we’re going with that.
I don’t disagree but I do think that this is primarily a business decision and, as such, needs to be made in consort with management. For a given database (or given instance), what data loss can be tolerated?
I’m actually right there with you. It is a business decision. The only caveat I’d place on top of that is that business people don’t always understand what they’re deciding and we, as data pros, need to be sure they understand.