Each database has a recovery
model that determines how transactions will be written to the
transaction log. The recovery model you choose has a direct impact on
your ability to recover from a media failure. These following three
recovery models are available with SQL Server 2008:
You set the recovery
model via T-SQL or the Database Properties window in SSMS. The following
example shows the T-SQL command you can use to change the AdventureWorks2008 database to the bulk-logged model:
ALTER DATABASE [AdventureWorks2008] SET RECOVERY BULK_LOGGED WITH NO_WAIT
Figure 1 shows the Options page on the Database Properties window, which also allows you to select a recovery model.
Full Recovery
The full recovery model gives
you the most protection against data loss. A database set to full
recovery will have all database operations written to the transactions
log. These operations include insertions, updates, and deletions, as
well as any other statements that change the database. In addition, the
full recovery model captures any database inserts that are the result of
a BCP command or BULK INSERT statement.
In the event of a media
failure, a database that is in full recovery can be restored to the
point in time at which the failure occurred. Your ability to restore to a
point in time is dependent on your database backup plan. If a full
database backup is available, along with the transaction log backups
that occurred after the full database backup, you can recover to the
point of the last transaction log backup. In addition, if your current
transaction log is available, you can restore up to the point of the
last committed transaction in the transaction log.
This recovery model is the most
comprehensive, but in some respects, it is the most expensive. It is
expensive in terms of the transaction log space needed to capture all
the database operations. The space can be significant with databases
that have a lot of update activity or with databases that have large
bulk load operations. It is also expensive in terms
of server overhead because every transaction is captured and retained
in the transaction log so that they can be recovered in the event of a
failure.
Tip
A common problem in SQL
Server environments involves a database that is set to full recovery but
whose transaction log is never backed up. In this scenario, the
transaction log can grow to the point that it fills up the drive on
which the transaction log is located. You need to ensure that you have
regularly scheduled backups of the transaction log if you have set your
database to full recovery. The transaction log backups allow you to
recover from a media failure and also remove the inactive portion of the
transaction log so that it does not need to grow.
Bulk-Logged Recovery
The bulk-logged recovery model
is similar to full recovery, but it differs in the way that bulk
operations are captured in the transaction log. With full recovery mode,
SQL Server writes every row to the transaction log that is inserted
with BCP or BULK INSERT.
Bulk-logged recovery keeps track of the extents that have been modified
by a bulk load operation but does not write each row to the transaction
log. This reduces the overall size of the transaction log during bulk
load operations and still allows the database to recover after a bulk
load operation has occurred.
The biggest downside to
setting a database to bulk-logged recovery is that the log backups for
the databases can be large. The log backups are large because SQL Server
copies all the data extents that have been affected by bulk load
operations since the last backup of the transaction log. Remember that
data extents consist of eight data pages each, and each page is 8KB in
size. This may not seem like much by today’s standards, but it can be
significant when you’re bulk loading a large table. For example,
consider a table occupying 1GB of space that is truncated each week and
reloaded with a bulk insert. The bulk insert operation goes relatively
fast because the rows are not being written to the transaction log, but
the backup of the transaction log is much larger.
Note
In testing we did on a table with
approximately 2.4 million rows (that occupied 500MB of space), the log
file grew over 2GB during a bulk insert operation that reloaded all rows
in a full recovery mode database. In contrast, the same bulk insert
operation on the database with bulk-logged recovery grew the log by only
9MB. However, the backup of the 9MB transaction log was approximately
500MB. This is much larger than the actual log itself because the bulk
operation caused all the modified extents from the bulk insert operation
to be stored in the log backup as well.
The other downside to
bulk-logged recovery is that with it, you may sacrifice the ability to
restore to the most recent point in time. This situation occurs if a
bulk insert operation has
occurred since the last database backup and a media failure occurs. In
this case, the restores can occur for any backups that were taken that
do not contain a bulk insert operation, but any outstanding changes that
were retained in the transaction log cannot be applied. The reason is
that bulk operations are not written to the log directly in this model
and cannot be recovered. Only bulk operations captured in a backup can
be restored.
If transactions have
occurred in a database since the last backup, and no bulk insert
operations have occurred, you can recover those pending transactions as
long as the media containing the transaction log is still available. The
tail of the transaction log can be backed up and applied during a
restore operation.
Simple Recovery
The simple recovery model is
the easiest to administer, but it is the option that has the greatest
possibility for data loss. In this mode, your transactions log is
truncated automatically based on a checkpoint in the database. These
checkpoints happen often, and they cause the data in the transaction log
to be truncated frequently.
Note
Prior to SQL Server 2000, the trunc. log on checkpoint
database option was used to truncate the log on a checkpoint and
produce the same type of behavior as simple recovery. This database
option and the equivalent backup options NO_LOG and TRUNCATE_ONLY
are no longer supported. The only supported method for truncating the
transaction log in SQL Server 2008 is to switch the database to use the
simple recovery model.
The most important point to
remember about the simple recovery model is that with it, you cannot
back up the transaction log that captures changes to your database. If a
media failure occurs, you are not able to recover the database activity
that has occurred since the last database backup. This is a major
exposure, so simple recovery is not recommended for production
databases. However, it can be a good option for development databases
where the loss of some transactions is acceptable. In these types of
environments, simple recovery can equate to saved disk space because the
transaction log is constantly truncated. The administration in these
environments is reduced as well because the transaction log backups are
not an option and thus do not need to be managed.
