Introduction
This article will examine the Recovery Model options used by
SQL Server 2008 and the various methods that can be used to backup a database
such as Differential and Transaction Logging. In addition, Transaction Logs,
the mechanism that makes Recovery Models possible will be introduced. Backups,
Transaction Logs, and Recovery Models are interlinked and the settings of one
effect the options of another.
In a previous article (SQL
2008 Backup and Restore), Full Backups and many of the available
configuration options available were introduced. Backups from both the command
line and SQL Server Management Studio were detailed. In addition, Backup
Compression, new in SQL Server 2008 was introduced.
Transaction Logs
Every SQL Server database consists of at least two physical
files on the hard drive, an MDF file and an LDF file. The MDF file contains
all of the actual data being stored. The LDF file, or Log file, contains a
record of each data change. This logging of each data change makes undo
operations and “point in time” backups possible. A point in time backup gives
us the ability to restore a database to literally any point in time we wish,
yesterday, two hours ago, or two minutes ago. By default, both the MDF and LDF
files are located in the SQL Server Server\Version\MSSQL\Data directory on the
hard drive.
This recorded history doesn’t remain in the transition log
forever though. If it did, the size of the log file over time would become
huge and unmanageable. Instead, the log file is periodically cleared, or
“Truncated”. The amount of time the log file is allowed to grow before being
truncated is determined by the database “Recovery Model”.
Recovery Models
A “Recovery Model” determines how a database’s transaction
logs are maintained. Each database has its own Recovery Model setting.
Meaning a SQL Server can contain multiple databases, each with its own Recovery
Model, separate of how other database are configured.
To View a database Recovery Model setting, open the SQL
Server Management Server, right click a database, and then select Properties.
Once the properties dialog box opens, select “Options” from the left menu.
The Recovery Model can be either Full, Simple, or Bulk –
logged.
Simple Recovery
When a database is set to Simple Recovery, it means log
files are not kept permanently. So when a TSQL statement executes, changes
are written to the data and log files, but they are not kept in the log file
for long before being Truncated (cleared). This truncating is caused by SQL
Server issuing a “Check Point”. For a complete description of the events that
cause a Check Point, see the Microsoft article: http://msdn.microsoft.com/en-us/library/ms188748.aspx
. What this Truncating of the log file means to us is that the log file
cannot be used for a database Restore. This is because we are not in control
of when the log is cleared, SQL Servers checkpoints are. Therefore, when a
database is set to Simple Recovery, the only backup type available is a Full
Backup.
A Full backup restores all your data, you can’t tell it to
restore all my data at a specific point in time. For point in time, we need a
transaction log.
Full Recovery
Not to be confused with “Full Backups”, Full Recovery refers
to a database that keeps a transaction log file history. Because the log file
will now be an integral part of the database, thought must be taken as to its
creation. When creating a database, there are two file options to consider,
“Initial Size”, and “Auto-growth”, both of which can be configured from the SQL
Server Management Studios Database Properties screen. Under the Files page,
there are settings for both Size and Growth.
If a database is set to Full Recovery, then the history of
each data change operation is saved. If the log file files up or runs out of
physical disk space, the database will stop working. This risk can be
mitigated by SQL Server’s ability to Auto Grow the log file. To enable Auto
Grow, give the log file an initial size in Megabytes. Next, select the “Autogrowth”
check box and enter a growth size. The max size of the log file can also be
restricted or left to grow indefinably. Without auto-growth, a fixed size for
the log file has to be guessed. If the log file fills up, the database stops
working. Auto-growth avoids this, but comes with some added overhead. When
SQL Server increases the log file size dynamically, it can be resource (memory,
CPU, and hard disk) intensive, and database performance may suffer while this
happens. Once the log has been adjusted, performance will return to normal.
Differential Backups
When a database is running in “Full Recovery” model, so a
transaction log is being kept, we have a couple of new backup options. There are
now Differential and Transaction Log backups in addition to Full Backups.
A Differential backup copies all the data changes since the
last Full backup. So these backups are usually faster and smaller than Full
backups. Over time though, as more data changes happen, the Differential
backups will get larger and larger. A Full backup creates a Check Point
meaning that new Differential backups will start from that point.
Transaction Log Backups
A Transaction Log Backup will copy all the data changes
since the last Full or previous Transaction Log backup. Transaction log
backups are typically very fast and small. The downside to them is the
recovery. For example, if you create a full backup Monday and Transaction Log
backups Tuesday through Friday, and then need to restore on Saturday, the
restore procedure would be to recovery Mondays Full, then Tuesday log,
Wednesdays Log, Thursdays Log, and finally Fridays Log. While this works, it’s
very labor intensive. In addition, if one of the log backups should be bad or
unusable for some reason, then the entire chain is broke and not recoverable
past the last good Log backup.
Conclusion
SQL Server 2008 offers several Recovery Methods, including Full
and Simple. The Recovery Method selected will determine if Transaction Log
files are kept, and if so, which type of Backups can be performed, such as
Full, Differential, or Transaction Log.
»
See All Articles by Columnist Don Schlichting
» 
