SQL Server 2005 Recovery Models Full Recovery, Bulk Logged Recovery, and Simple Recovery Models

y y y y y

Full Recovery Model Bulk-Logged Recovery Model Simple Recovery Model How To See What Recovery Model SQL Server 2005 is Using Database Recovery Models Comparison Chart

Full Recovery Model

The Full Recovery Model is the most resistant to data loss of all the recovery models. The Full Recovery Model makes full use of the transaction log all database operations are written to the transaction log. This includes all DML statements, but also whenever BCP or bulk insert is used. For heavy OLTP databases, there is overhead associated with logging all of the transactions, and the transaction log must be continually backed up to prevent it from getting too large.
Benefits:
y y

Most resistant to data loss Most flexible recovery options - including point in time recovery

Disadvantages:
y y

Can take up a lot of disk space Requires database administrator time and patience to be used properly

(back to top)

Bulk-Logged Recovery Model

The Bulk-Logged Recovery Model differs from the Full Recovery Model in that rows that are inserted during bulk operations arent logged yet a full restore is still possible because the extents that have been changed are tracked. The following transactions are minimally logged in a Bulk-Logged Recovery Model:
y y y y

SELECT INTO bcp and BULK INSERT CREATE INDEX Text and Image operations

Benefits:
y y

Transaction log stays small Easier from an administration standpoint (don t have to worry about transaction logs)

Disadvantages:
y y y

Not for production systems Point in time recovery not possible Least data resistant recovery model

(back to top)

Simple Recovery Model

The simple recovery model is the most open to data loss. The transaction log cant be backed up and is automatically truncated at checkpoints. This potential loss of data is makes the simple recovery model a poor choice for production databases. This option can take up less disk space since the transaction log is constantly truncated.
Benefits:
y y

Transaction log stays small Easier from an administration standpoint (don t have to worry about transaction logs)

Disadvantages:
y y y

Not for production systems Point in time recovery not possible Least data resistant recovery model

(back to top)

How To See What Recovery Model SQL Server 2005 is Using

What recovery model is my SQL Server 2005 database using? It is easy enough to find out by following the steps below. The recovery model can be determined in SQL Server 2005 by accessing the properties of the database. To do this, you can right click on the database in Object Explorer and select "properties" as shown below.

After right clicking on properties, the SQL Server 2005 Database Properties window appears. Left click on options. The recovery model will be revealed to the right. In the screenshot below, you can see that the database is using the Full Recovery Model.

(back to top)

SQL Server 2005 Recovery Models Comparison Chart

sSQL Server 2005 System Databases System Databases: resource, distribution, master, model, tempdb, msdb
There are six system databases in Microsoft SQL Server 2005: master, msdb, model, tempdb, resource, and distribution. The distribution and resource databases are new system databases that were introduced for SQL Server 2005.
y y

master Database msdb Database

y y y y

model Database temp Database resource Database distribution Database

master Database
The master database records database-wide information for SQL Server 2005. This information includes user logins, configuration settings, user created databases and the physical location of files for those databases. SQL Server will not start unless you have a master database.

Do I need to back up the master database?

Yes, you must be regularly backing up your master database in SQL Server 2005. SQL Server needs this database for configuration settings and to be able to locate databases on the server.
(back to top)

msdb Database
The msdb database is used by SQL Server Agent for alerts and jobs, and also for Database Mail (among other things). Backup information is stored in the msdb database.

Do I need to back up the msdb database?

Absolutely. The msdb database must be put on a very regular schedule for backups in order to preserve all of your jobs and your backup information.
(back to top)

model Database
This database serves as a template whenever a new database is created in SQL Server 2005. The model database must always exist on a SQL Server 2005 database. If you modify a model database, all databases created going forward will inherit those modifications.

Do I need to back up the model database?

It is a probably a good idea to periodically back up the model database. The size isnt all that large, and if you make changes, those changes will be preserved.
(back to top)

tempdb Database

The tempdb database stores temporary objects (like temporary tables, cursors, temporary sprocs). The database is available to all users. Every time SQL Server 2005 starts, a clean copy of this database is generated.

Do I need to back up the tempdb database?

No. You are actually prevented from performing backup or restore operations on tempdb by SQL Server 2005.
(back to top)

resource Database
The resource database is a read only database that contains all SQL Server 2005 system objects. There is no user data in the resource database that needs to be preserved.

Do I need to back up the resource database?

No. You are actually prevented from performing backup or restore operations on the resource database by SQL Server 2005.
(back to top)

distribution Database
The distribution database in SQL Server 2005 stores history for all types of replication and stores transactions for transactional replication. You may actually have multiple distribution databases in your setup (one database for each publisher).

Do I need to back up the resource database?

Yes, you should be backing up distribution databases if you are engaging in replication.

SQL Server 2005 Backup Types Full, Transaction Log, Differential, Partial, Differential Partial, File and Filegroup, and Copy Only Database Backups
y y

Full Database Backup Transaction Log Backup

y y y y y

Differential Database Backup Partial Database Backup Differential Partial Database Backup File and Filegroup Backups Copy Only Database Backup

Full Database Backup

A full database backup captures the entire database in one fell swoop. It can be used to restore a database to the time when the backup completed. A full database backup is often used during restore operations as a first step in recovering a database. Other backups are applied after the full backup is restored to bring the database closer in time to the actual moment of failure. Data Loss: A full database backup will not on its own provide full recovery up to the point of failure. A full database backup for SQL Server 2005 restores the database up to the time when the backup was completed. If you have more stringent data loss requirements and most organizations will you need to supplement your full database backups with other types of backups. Your best chance at preventing data loss is to use the full recovery model with transaction logs. Size: A full database backup will be the largest type of backup that there is. Resources Required: A full database backup requires a lot of system resources and can negatively impact system performance. (back to top)

Transaction Log Backup

Only available under the full recovery model and the bulk logged recovery model. Transaction log backups allow for point in time recovery since each transaction is captured within the transaction log. Data Loss: The use of transaction log backups provides point in time recovery. As far as backups are concerned, the use of full backups combined with transaction logs can provide point in time recovery capabilities and minimize data loss. Size:

Compared to other types of database backups, transaction log backups aren't very large if they are scheduled regularly. Resources Required: Generally speaking, transaction log backups take up very little in the way of system resources. (back to top)

Differential Database Backup

A differential database backup captures changes (and only the changes) made to the database since the last full database backup. This full database backup which differential backups reference is also called the differential base, since the differential backups are recording changes since the last full database backup was performed. The differential database backup records the changes to the database up to the time when the differential backup was completed. Data Loss: A differential backup provides additional protection from data loss than a full database backup, but does not on its own guarantee that some data wont be lost. Your best chance at preventing data loss is to use the full recovery model with transaction logs. Size: The differential database backup will likely be a fraction of the size of the full database backup since only changes since the last full database backup are saved. However, if you have multiple differential database backups between each full database backup, each differential database backup will be larger than the one before it, since all differential database backups record ALL changes since the last full database backup.

Resources Required: The overhead required to perform a differential backup is significantly less than what is required for a full database backup since only the changes since the last full database backup are being backed up. (back to top)

Partial Database Backup

Partial backups were introduced for SQL Server 2005. Partial backups will backup the primary filegroup, any read/write file groups, and any read-only files that are specified during the backup. The partial backup is designed to not backup any data that is placed in a read-only file group. So, you can use a partial backup to backup your entire database except for the read only data. Partial backups are meant to be used in a simple recovery model situation, although they can be used in a full recovery model situation as well. Data Loss: The partial backup provides bare minimum protection from data loss. The partial backup serves as a base for differential partial backups which can be applied to the partial backup to bring the database closer to a point in time near the actual database failure. A full recovery model with transaction logs provides the best chance to restore the database up to the point of failure. Size:

A key advantage of using a partial backup as opposed to a full database backup is the reduced file size. The read only filegroups only have to be saved once, therefore the partial backups will be smaller than what would be required for a full database backup. Resources Required: The strain on the database will likely be much less for a partial database backup than it is for a full database backup since specified read only filegroups wont have to be backed up. (back to top)

Differential Partial Database Backup

Differential partial backups use the most recent partial backup as their differential base. They work very similar to a differential backup, except (with some exceptions) they capture only changes made to read/write filegroups . If you add, drop, or change the status of any of your filegroups, youre best off taking a partial backup prior to resuming differential partial backups. Filegroup changes can have unintended consequences with differential partial backups. Data Loss: Differential Partial provide a reduced chance of data loss from a partial backup alone, since the differential partial backups are performed between partial backups. Size: A differential partial backup should be relatively small given that it wont backup specified read only filegroups and uses the most recent partial backup as its base. Resources Required: The resources required for a differential partial backup will be relatively small compared to full database backups and partial backups. (back to top)

File and Filegroup Backups

This primarily applies to very large databases (VLDB) with multiple filegroups that have strict availability requirements. In these instances, sometimes it takes too long to perform a full backup, or the size of a full backup is extremely large.

If you add, drop, or change the status of any of your filegroups, youre best off taking a partial backup prior to resuming differential partial backups. Filegroup changes can have unintended consequences with differential partial backups. Data Loss: Data loss is minimized with file and filegroup backups through the proper use of transaction log backups. File and Filegroup backups can only be performed under a full recovery model or a bulk logged recovery model. Size: The size of individual file or filegroup backups will obviously be smaller than the size required for a full database backup which is one of the key advantages of using file and filegroup backups in VLDB situations. Resources Required: While there is overhead involved in backing up any portion of a VLDB, the resources will likely be much less than the resources required for performing a full database backup on a very large database. (back to top)

Copy Only Database Backup

Copy Only backups in SQL Server 2005 must be performed using T-SQL and are not logged in the backup and restore sequence for the database. In other words, you cant apply differential backups to this database backup, it is an independent copy separate from the original database. The transaction log is unaffected (will not be truncated) during this type of backup. You might consider making a copy only backup for a special purpose like database development or testing. Data Loss: Not applicable. A copy only database backup is used to make a copy of the database and isnt part of a backup and recovery plan. Size: Not Applicable. Not part of the overall backup and recovery plan. Resources Required: Resources required for a Copy Only backup would be similar to a full database backup.

SQL Server 2000 Backup Types Database, Differential, Transaction Log and File Backups
There are four main types of backups in SQL Server 2000: Database, Differential, Transaction Log, and File.

DATABASE
With this backup you are backing up the entire database and will be able to restore the entire database from just this backup. This backup will match the state of the database at the time the backup completes (except for uncommitted transactions which on restore of the backup will be rolled back). Generally this backup takes up the most time and uses up the most space out of all of the different types of backups.

DIFFERENTIAL
A differential backup will record all of the data that has changed since the last database backup. You must have a database backup in place to use a starting point for your differential backup. Like database backups, differential backups will match the state of the database at the time that the backup is completed. Differential backups aren't like transaction log backups because they aren't incremental. When a differential backup occurs, it does not pay any regard to any differential backups that occurred before, it looks back only to the last database backup and records any data changed since that database backup.

TRANSACTION LOG
Transaction log backups record all transactions that have been recorded against the database since the last transaction log backup. You must have either a differential database backup or a database backup to use as a starting point for your transaction log backups. Unlike database and differential backups, transaction log backups will match the state of the database at the time that the backup is started. These backups use less space and time than database backups, and should be taken frequently to avoid loss of data. Your transaction logs should also be located on a separate disk if possible from your data files.

FILE
File backups involve backing up individual files within a database. This can be the quickest way to restore, but it also has a lot of overhead associated with it. You must keep track of your file backups as well as use these file backups in conjunction with transaction log backups. Transaction log backups must be performed after a file backup is completed. You will restore your file backups first, and then all transaction log backups that occurred.

EXAMPLE

Let's say that a full backup occurs Sunday at 8AM. Transaction Log backups occur every day at 10AM and 4PM, and Differential backups occur every day at 6PM. In our scenario below, a failure occurs at noon on Wednesday. There are various ways to restore the database up to the point at which the 10AM transaction log backup started on Wednesday.

For all scenarios, the full backup must be restored first. Both the differential and transaction log backups both require the full backup to be restored first before they can be restored.

Quickest Restore
The quickest way to restore would be to restore: the full backup, followed by the most recent differential backup, followed by all transaction logs up to the most recent. That would result in

the following restore: F1, DIFF3, T7. You need to restore F1 as mentioned earlier. Then you would restore DIFF3. DIFF3 contains all changes since the last full backup. Then you would restore all transaction log backups that occurred after the last differential backup, which in our case is only T7.

Complication - Corrupt Backup File

Lets say that DIFF3 has somehow become corrupted and we can't use it for restore. In this case, we would restore F1, then DIFF2, then apply T5, T6, and T7.

Another Way
You could also just apply the full backup followed by all transaction logs that have occurred since the full backup was taken (F1, T1, T2, T3, T4, T5, T6, T7)

SQL Server 2000 Backups Overview Key Database Components for Backup and Recovery
The following diagram is used to illustrate the key components for backup and recovery. The diagram shows on a very simple level what happens when a record is modified in the database. Inserts, updates, and deletes will follow a similar process.

STEP 1: A user issues an update statement. If the record to be modified isnt already in the buffer cache, a SQL Server process reads the required data page and places it into memory within the buffer cache. STEP 2: The user modifies the record within the buffer cache. Modified pages within the buffer cache are marked as being dirty and they will have to be written to disk in the future. STEP 3: Immediately after the record is modified within the buffer cache, a corresponding record indicating the data change and the transaction that caused the data change is written to the log cache. STEP 4: A checkpoint occurs, and log and data information must be written to disk. First, the log cache information is written to the transaction log STEP 5: Dirty pages within the buffer cache are flushed to disk and written into the data files. As a Database Administrator, it is imperative that you backup the data files and transaction logs frequently. Getting backups to these files is the key to backup and recovery. How frequently you perform these backups is dependent upon the business requirements of your organization.

SQL Server 2000 Configuration Configuring a SQL Server 2000 Database to be Resistant to Disaster
Below is a disk layout designed with backup and recovery in mind. Note that we are using RAID 1 for each of the following files: Transaction Logs, Data Files, OS Files. All are stored on separate disks from each other with separate controllers.

OS (Mirrored disks 1 and 2)

y y

You should be able to store your OS files and page file on a single mirrored disk Never move the page file to a disk containing transaction log files or data files

Data Files (Mirrored disks 3 and 4)

y y y y

Data files should be located on separate physical disks with separate controllers than transaction log files and OS files If you have tables that are accessed frequently, consider putting them on separate physical drives If you can't afford to install all of the disks required for mirroring, you could also do data striping with striped parity (RAID 5) You will often times have multiple disks to store the data files

Transaction Log Files (Mirrored disks 5 and 6)

y y

Transaction log files should be located on separate physical disks with separate controllers than data files and OS files Transaction logs are written sequentially and will generally do just fine on one single mirrored drive

Tempdb (contained with data files on mirrored disks 3 and 4 in this example)
y y

Usually can go on the same physical disks as your data files If you have a large database with a lot of activity, may wish to break tempdb out on to its own separate disk

SQL Server 2000 Database Files Data Files and Transaction Logs
SQL Server utilizes two main files to store data and transactions on disks. Data File (.mdf or .ndf extensions by default) This is the physical storage for all of the data on disk. Pages are read into the buffer cache when users request data for viewing or modification. After data has been modified in memory (the buffer cache), it is written back to the data file. Transaction Log (.ldf extension by default) The transaction log records the modifications that have occurred in the database as well as the transactions that caused the modifications. Information that was in memory within the log cache is ultimately stored in the Transaction log.

SQL Server 2000 Database Recovery Models

Full Recovery, Bulk Logged Recovery, and Simple Recovery Models

Sql Server 2000 offers three recovery models: Full, Bulk-Logged, and Simple. The description of each model is displayed below. It is your responsibility as the DBA to put all of the components in place to make your recovery model possible. In other words, you must set up the appropriate backups to utilize your chosen model. Each of the recovery models incorporates different backup types, for more information on these backup types click here.
Full Recovery Model

The Full Recovery model makes use of database backups, differential backups, and transaction log backups. We'd recommend using this model for most production databases. This model provides the most flexibility and versatility for protecting data and recovering databases. It is also the most complex to maintain, but it is worth it for production databases.
Bulk Logged Recovery Model

This model is very similar to the Full recovery model with the exception that the following operations are minimally logged: SELECT INTO, BCP and BULK INSERT, CREATE INDEX, and text and image operations. This results in less log space being consumed during bulk operations, but eliminates the chance for point in time recovery when these operations are performed. You can still conduct database backups, differential backups and transaction log backups with this model, but the bulk operations will be minimally logged.
Simple Recovery Model

Basically, with the Simple Recovery Model, you use only complete and differential backups (no transaction log backups). Therefore, you are only as good as your last full or differential database backup.
What model is my database using by default?

Every database has a default recovery model in place. Every new database that is created on the server will take the recovery model of the MODEL database on the server. To see what your database recovery model is, right click on your database and choose properties. Midway down on the options tab the recovery model is displayed. In our example below, Full is the recovery model used for the Northwind database.

The table below shows the features of each of the recovery models. As mentioned previously, in most environments you'll probably want to be using the full recovery model for production databases.

SQL Server 2000 Failure Types Identifying the Different Types of Database Failure for SQL Server 2000
There are three major types of failure that you will have to be concerned about as a SQL Server DBA. 1. User error - This accounts for either an application or a user incorrectly modifying or destroying data within the database. In this case, the decision may be made to take the database back to a prior point in time. In the event that this occurs, the DBA must be

perform a recovery and restore the database to the state it was in prior to the user error occurring. 2. Media Failure - This occurs when one or more drives used by the database fail. 3. Catastrophic event - A major event destroys the data center. The DBA will be responsible for protecting the data from these events and restoring and recovering the databases if such an event occurs.

SQL Server 2000 Memory The Buffer Cache and Log Cache
Buffer Cache Within the buffer cache are a pool of buffer pages into which data pages are read. This is where data can be modified. Log Cache Within the log cache are buffer pages. Whenever a change is made to a record within the buffer cache, a corresponding log record is put into the log cache to record the modification as well as the transaction recording the modification.

SQL Server 2000 MSDB Tables

SQL Server 2000 msdb tables Important msdb Tables Provide Insightful Backup Related Information
There are a few system tables within the msdb database that you may wish to be aware of for backup and recovery operations. You can query these tables to obtain valuable information.

backupfile
This table keeps track of all of the data files and log files that have been backed up. The backup set id is identified in the table along with logical and physical information about each file that is backed up as part of the backup set.

backupset
This table contains information about each backupset. One of the key columns in this table is the "position" column, which is used as the FILE clause in a restore operation to ensure that you are restoring the right backupset from the backup device.

backupmediafamily

This table provides both physical and logical information for backup media. If you are using a backup device, you'll find its logical name, physical path, and media_set_id. The media_set_id column within this table can be used to join with the media_set_id column in the backupset table so that you can associate backup sets with the appropriate device by device name.

restorefile
Contains one row for each restored file.

restorefilegroup
Contains one row for each restored filegroup.

restorehistory
Contains one row for each system restore operation. Contains good information such as: database name, when the restore occurred, user, what backup set was used, what options were specified in the RESTORE clause, and whether or not it was a point in time recovery.

SQL Server 2000 System Databases The System Databases: master, model, tempdb, msdb
There are four system databases in Microsoft SQL Server 2000: master, msdb, model, tempdb

master
In order for SQL Server 2000 to even start, you must have a functioning copy of the master database. The master database also keeps track of all other databases on the server, including the location of their files on the operating system. You should backup this database frequently on a scheduled basis. Nightly if at all possible. These are some of the activities that will update the master database and require a master database backup:
y y y y

Creating/Deleting a user database Adding logins Changing configuration on the server Creating or removing backup devices

msdb
The msdb database keeps track of all jobs and backup activities. This database is essential for backup and recovery operations and should be backed up very frequently.

These are some of the activities that will update the msdb database and will require the msdb database to be backed up:
y y y y

New or already occurring Backup Activities New or already occurring Restore Activities New jobs or scheduled tasks Replication activities

model
The model database serves as a template for all new databases created on the server. You need only backup the model database when you make changes to it. It isn't a large database to back up, so it might be wise to just put it on a regular backup schedule and forget about it.

tempdb
The tempdb database is used for temporary storage in the database. It is recreated every time SQL Server is started and does not need to be backed up. It actually can't be backed up.

SQL Server 2000 Troubleshooting Before You Restore A Database, You Need to Understand the Situation

Before engaging in any restore activity, you're going to want to follow these general steps to try to figure out what is wrong with the database. You realize that the database has failed. What options are available to you? 1) Always start with the error logs. We looked at the Application log via the event viewer (in Windows 2000 "Start"-"Programs"-"Administrative Tools"-"Event Viewer". During one of our examples when we deleted the Northwind primary data file, we had the following errors on startup.

2) Double clicking on the errors reveals more specific information (that we are missing a data file):

3) Clearly, as we suspected, we are missing one of the data files. We can go into Enterprise Manager and see that our database is suspect due to this problem.

4) We can also go into Query Analyzer and use the DATABASEPROPERTYEX function to determine what state the database is in. Here, we confirm that the database is in fact suspect. Suspect means that there is possible corruption, in our case we know we are missing a data file.

5) At this point, if we still didn't know what the problem was, we might attempt to use the DBCC CHECKDB command to try to repair the database. Books Online provides a lot of detail on the versatility of using DBCC in such a situation. In our troubleshooting situation, we do know that we're missing a data file and we need to restore from backup. If you're using the full or bulklogged recovery model, now would be a good time to get a transaction log backup before kicking off the restore process.