Classic fool who has default Full Backup model and out-of-control log file -— how to I get this controlled?

Question

Hey there I'm usually more of a development dba but the old dba left --- and he left about a year ago without a replacement.

I'm finally actually looking under the hood of some of these servers -- I'm not a production dba but I ran some diagnostics I found online and they say I have big problems.

Anyway I'm learning this stuff slowly but this seems like a common issue --- I have Full Recovery mode on a particular database, but never back it up -- as a result the log file grows exponentially -- I take it?

What are my options to get rid of this?

I'm guessing:

1. If I do a full back up or schedule one, the log file will get cleared after this?

2. Can I just change to the simple recovery model? I know that has recovery implications - I'm comfortable with data loss as this is a BI database. Will that flush out the log file immediately as well? Do I have to do anything OTHER than a switch to the simple recovery model?

Is there some way to monitor the progress of either of these two options? I'm guessing either will cause the database to start chugging resources doing something or other.

Thanks!

Answer 1

Do I have to do anything OTHER than a switch to the simple recovery model?

If you have a full backup, and don't need point-in-time recovery, simply switch the database to Simple recovery. After the next Checkpoint you should be able to shrink the log file. If the active VLF happens to be at the end of the file, rebuild an index or two, and try again.

Answer 2

Recovery mode allows for Point In Time recoverability. If you are in SIMPLE mode, then you can only restore back to your last FULL or DIFFERENTIAL Backup. If you are FULL, then you can recover back to a specific point in time based on the log backups you have taken.

Transaction log backups should be taken to meet a particular Recovery Point Objective (RPO). If the Business says that they will tolerate 1 hour's worth of data loss in a disaster, then you need to take transaction log backups at a minimum of hourly. These transaction log backups will be used in a recovery situation in conjunction with your FULL and DIFFERENTIAL backups. Taking transaction log backups will also keep your transaction log file in the database from growing exponentially.

If you do not have a backup strategy, look at this article by Paul Randal. https://www.sqlskills.com/blogs/paul/planning-a-backup-strategy-where-to-start/ https://www.sqlskills.com/blogs/paul/the-accidental-dba-day-8-of-30-backups-planning-a-recovery-strategy/

Once you have some understanding about what you should be doing, look at this site for a set of scripts that will automate the backup and maintenance of your databases. https://ola.hallengren.com/

Ola Hallengren has written a stellar set of scripts that most DBAs will use to set up backups of their environments. They are super simple, customizable, and powerful.