Something that always bites me in the butt from time to time is restoring a database in full recovery model and forgetting to do a full right away. Then I find out shortly when my log backups start failing and spamming me with error messages. I’m fairly certain this has happened to you, as well. It’s an easy thing to forget, especially when you’re dealing with non-critical databases.
Humans are typically bad at remembering things. That’s why we make task lists, have calendar reminders, document processes, and script for automation. We either have to remind ourselves to do something or (my preference) build something that’s smart enough to correct our oversight. So when I found a way to do this with broken log chains, I was pretty happy.
The key was a new dynamic management view (DMV) I discovered. Most people who know me know I love the DMVs and all the information they can provide. My new discovery is the sys.database_recovery_status view, which provides recovery info for all the databases. The key field is the last_log_backup_lsn field, which will be NULL if the log chain has somehow been broken.
What’s cool about this is now we have a programmatic way we can use to validate if a full backup needs to be performed. By adding a quick check to a log backup script, we can make sure we never have a broken log chain. A quick and dirty way would be:
if (select last_log_backup_lsn from sys.database_recovery_status where database_id = db_id(‘foo’)) is NULL begin backup database [foo] to disk=<<path to full backup>> end backup log [foo] to disk=<<path to log backup>>
This is obviously the most simple approach you can use, but the pattern is the important piece. By combining this with your standard backup scripts (please tell me you have standard backup scripts), you can always ensure that you never get an error because you forgot a full backup.
Because your script will remember for you.