As Kimberly blogged about recently, SQLskills is embarking on a new initiative to blog about basic topics, which we’re calling SQL101. We’ll all be blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.
One of the things that can catch people out is the effect of switching out of the full recovery model temporarily. In this post I’ll briefly describe the three recovery models and then the problems you can have switching from full to simple, and from full to bulk-logged.
There are three recovery models:
- Full recovery model (the default and the most commonly used)
- All modifications in the database a fully logged. This doesn’t mean that every modification has a separate log record, as some operations are logged with fewer log records while still logging the entire effect of the operation (for instance, TRUNCATE TABLE operations – see here for a deep explanation).
- The transaction log will not clear (i.e. portions are available for reuse) until a transaction log backup is performed (see here for a deep explanation).
- All recovery options are available when a database is in the full recovery model (and has been since the last backup).
- Bulk-logged recovery model
- Some modifications (like an index rebuild or a bulk load, but NOT regular insert/update/deletes) can be minimally logged, which reduces the amount of log records generated so the transaction log does not have to grow really large during the operation. Note that this doesn’t change the size of subsequent log backups. For full instructions on how to get minimal logging for your operation, see the Data Loading Performance Guide whitepaper, which lists all the various conditions that have to be met.
- The transaction log will not clear until a transaction log backup is performed (exactly the same as the full recovery model).
- Using bulk-logged, you trade off some recovery options (point-in-time restore and tail-of-the-log backups) for the performance gains associated with minimally logged operations.
- Simple recovery model
- Some modifications can be minimally logged (exactly the same as the bulk-logged recovery model).
- The log will not clear until a checkpoint occurs (usually automatically).
- Transaction log backups are not possible, so this is the most limited in terms of recovery options.
Most people use the full recovery model, to allow log backups and permit all possible restore operations. The main thing to remember is that if your database uses the full or bulk-logged recovery model, you must perform periodic transaction log backups or the transaction log will grow forever.
Some circumstances call for simple; if you don’t need the ability to do point-in-time restore or zero-to-minimal data loss restores using log backups. An example would be a scratch database that’s repopulated once per day and any changes can be lost or easily regenerated.
Switching to Simple
Often I hear of people who switch to the simple recovery model to try to avoid transaction log growth during a bulk load or index rebuild, when what they really mean to do is to use the bulk-logged recovery model. There are also persistent myths out there that some regular operations *require* being in the simple recovery model – this is simply (ha ha) not true.
Switching to the simple recovery model breaks the log backup chain, requiring a full or differential backup before any further log backups can be performed.
Furthermore, it limits your ability to recover during a disaster because you’ve now only got one full backup from which you can restore: the one you performed most recently. Think about it: your restore options become:
- Full backup after switch to simple, plus the latest differential backup after that full (if you’re using differential backups) and any log backups since the switch back; or
- Most recent full backup before switch to simple, plus the latest differential after the switch back from simple, plus any log backups
If that most-recent full backup (before or after the switch to simple) is damaged, you cannot restore – period. You can’t fall back on using the next older full backup, as that only allows the restore sequence up to, but not past, the switch to simple. Well, I guess you could do that, but then you lose all work since the switch to simple.
Switching to the simple recovery model is not something you automate or do repeatedly. About the only time when you would temporarily switch to simple is if your transaction log had run out of space and there is no way to allow it to clear (i.e. you cannot perform a log backup or add another log file) except by switching to simple and forcing a checkpoint operation. In that case you’re taking a drastic step to allow operations to continue, and being fully cognizant of the limited restore options available to you right then.
Unless you have this emergency situation, or you decide to use the simple recovery model permanently, you should not switch to simple ever.
Switching to Bulk-logged
Switching to bulk-logged during a load or index maintenance process is acceptable to avoid transaction log growth. In fact, switching back-and-forth between full and bulk-logged repeatedly doesn’t affect the log backup chain in any way. And doing so also doesn’t have any effect on log shipping or replication, but you can’t switch out of full when using database mirroring or an availability group as they mandate the full recovery model.
However, using bulk-logged can cause problems for disaster recovery, so even though its behavior may be desirable, you may need to avoid using it so you don’t risk compromising your disaster recovery options.
Problem 1: a log backup that contains a minimally-logged operation cannot be used during a point-in-time restore. This means the time you specify in the WITH STOPAT clause of the restore statement cannot be a time covered by such a log backup. You can use that log backup as part of a restore sequence, and stop at any point in time after it (as long as that point in time is not covered by another log backup containing a minimally-logged operation, of course), but just not during it.
Problem 2: if you need to perform a tail-of-the-log backup to capture all the log generated since the most recent scheduled log backup, the data files are inaccessible or damaged, and the log to be backed up contains a minimally-logged operation, that backup will fail prior to SQL Server 2008 R2, and from SQL Server 2008 R2 onward it will succeed, but be will corrupt the database when restored.
So if you’re going to use bulk-logged to save on log space during large operations, you need to make sure that a) there’s no possibility you’re going to want to restore between the last log backup and the next one, and b) there are no changes made to the database that you cannot recreate in case a disaster occurs and you can’t take a valid tail-of-the-log backup.
Switching recovery models between full and bulk-logged may not be as safe as you might think.
For every database that you’re responsible for, make sure that you understand the ramifications of changing the recovery model, as doing so could cause you problems with disaster recovery.
16 thoughts on “SQLskills SQL101: Switching recovery models”
Just when I’m thinking to put in place a script to do: switch to bulk-logged/indexoptimize/switch back to full/logbackup/fullbackup, this article help to understand what I’m about to do. Thanks!
You wrote in the section : simple recovery model
The log will not clear until a checkpoint occurs (usually automatically).
If I complete with : And the active transaction is completed, then after the checkpoint the log will be clear..
Is-it correct ?
No – as an active transaction may only be in the current VLF, which can never be cleared while it’s in use. See https://www.sqlskills.com/blogs/paul/worrying-cause-log-growth-log_reuse_wait_desc/
I just discovered the sql101 initiative and I love it.
Great initiative, thank you.
I didn’t read anything about switching from Simple Model to Full, what are the affects when doing this?
ty so much for answering my question.
Minimally-logged operations are no longer possible, and as soon as you perform a full backup, you must start performing regular log backups otherwise your log will not clear (and will grow forever).
Can you change your recovery model from simple to full during the day
or will it block.
Also – I had thought that you needed to do a full backup to get tlog backups started. Can we just do a diff to
get the backup chain setup for logs?
You can switch recovery models at any time without causing blocking. You must perform a full backup before you can perform log backups, UNLESS you’ve previously been in full or bulk-logged and performed a full backup and then switched to simple and back – then you can just performed a diff backup. But if this is the first time switching to full, you must perform a full backup before log backups are permitted.
Hi Jerri Betts,
I have same situation with you. Some of our databases are on SIMPLE mode and we would like to take tx logs backup. So we have to change to FULL mode. But we are still waiting for change request to approve. May i know your experience? Have you change from SIMPLE to FULL? Any issues?
What is a difference between bulk_logged recovery model and trace flag 610 at SQL Server 2014?
When a Bulk Insert action is in progress,
If we change the Recovery Model from Simple to Bulk-Logged,
Would it be helpful to reduce the writing of log file and improve performance?
No – logging is exactly the same in simple and bulk-logged, as it says in the post.
When we change the recovery model from simple to full, how sql server knows that information? When we try to take diff backup after changing the recovery model it gives an error saying that no full backup for the database. I am just wondering , sql server internally stores that information in any table?
I dont think it gets the information from backupset table because I have created one testdb took backup and dropped the database without clearing the history of backups and I have created DB with same name Testdb. For newly created db, its showing last full backup date(in db properties) as one i have taken backup for testdb before dropping it however, when i tried to take diff backup, i am getting error saying that, no current full backup of the db. How? Hope you got my situation? Any inputs on this please?
See https://www.sqlskills.com/blogs/paul/new-script-is-that-database-really-in-the-full-recovery-mode/ for the explanation.