SQL Server Architecture - SQL Server 2012 Internals and Troubleshooting - page 21

Recovery Interval
Recovery Interval is a server coni guration option that can be used to inl uence the time between
checkpoints, and therefore the time it takes to recover a database on startup — hence, “recovery
interval.”
By default, the recovery interval is set to 0; this enables SQL Server to choose an appropriate
interval, which usually equates to roughly one minute between automatic checkpoints.
Changing this value to greater than 0 represents the number of minutes you want to allow between
checkpoints. Under most circumstances you won't need to change this value, but if you were
more concerned about the overhead of the checkpoint process than the recovery time, you have the
option.
The recovery interval is usually set only in test and lab environments, where it's set ridiculously
high in order to effectively stop automatic checkpointing for the purpose of monitoring something
or to gain a performance advantage. Unless you're chasing world speed records for SQL Server, you
shouldn't need to change it in a real-world production environment.
SQL Server evens throttles checkpoint I/O to stop it from affecting the disk subsystem too much, so
it's quite good at self-governing. If you ever see the SLEEP _ BPOOL _ FLUSH wait type on your server,
that means checkpoint I/O was throttled to maintain overall system performance. You can read all
about waits and wait types in the section “SQL Server's Execution Model and the SQLOS.”
Recovery Models
SQL Server has three database recovery models: full, bulk-logged, and simple. Which model you
choose affects the way the transaction log is used and how big it grows, your backup strategy, and
your restore options.
Full
Databases using the full recovery model have all their operations fully logged in the transaction log
and must have a backup strategy that includes full backups and transaction log backups.
Starting with SQL Server 2005, full backups don't truncate the transaction log. This is done so that
the sequence of transaction log backups isn't broken and it gives you an extra recovery option if
your full backup is damaged.
SQL Server databases that require the highest level of recoverability should use the full recovery
model.
Bulk-Logged
This is a special recovery model because it is intended to be used only temporarily to improve the
performance of certain bulk operations by minimally logging them; all other operations are fully
logged just like the full recovery model. This can improve performance because only the information
required to roll back the transaction is logged. Redo information is not logged, which means you
also lose point-in-time-recovery.