IT tutorials

SQL Server 2012 : Backup and Recovery Planning - Recovery Models (part 2) - Simple Recovery Model, The Full Recovery Model

2/10/2014 12:47:56 AM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Simple Recovery Model

The simple recovery model is suitable for databases that require that each transaction be atomic but not necessarily durable. The simple recovery model directs SQL Server to truncate, or empty, the transaction log on checkpoints. The transaction log keeps a transaction until it is confirmed in the data file, but after that point the space may be reused by another transaction in a round-robin style. This is the reason why a simple recovery model does not support a transaction log backup.

A simple recovery model has the benefit of keeping the transaction log small, at the cost of potentially losing all transactions since the last full or differential backup.

A recovery plan based on a simple recovery model might include performing full backups once a week and differential backups every weeknight, as shown in Figure 1. The full backup copies the entire database, and the differential backup copies all changes that have been made since the last full backup.

Figure 1 A typical recovery plan using the simple recovery model includes only full and differential backups.


When restoring from a simple recovery plan:

1. Restore the most recent full backup.
2. Restore the most recent (optional) single differential backup.

Best Practice
Simple recovery is mostly used for test and development databases or databases containing mostly read-only data. Simple mode can, and often is, used for databases which you don't necessarily want or need to log large transactions such as a data warehouse. Simple recovery should not be used where loss of data since the last full or differential backup is unacceptable. In these cases, full recovery model is recommended. Full recovery model is also a requirement for Database Mirroring and Log Shipping. The bottom line is: Know your data, and plan your recovery plan accordingly with what the business can accept.

The Full Recovery Model

The full recovery model offers the most robust recovery plan. Under this model all transactions, including bulk-logged operations, are fully logged in the transaction log. Even system functions such as index creation are fully logged. The primary benefit of this model is that every committed transaction in the database can be restored right up to the point when failure occurred.

Best Practice
Use full recovery model for production user databases where data loss since last full or differential backup is unacceptable. Although it can run on a single drive system, the transaction log should be located on a fault-tolerant disk subsystem, physically separate from the data files, to ensure a high level of transactional durability.

The trade-off for this high level of transactional integrity is a certain amount of performance:

  • Bulk-logged and select-into operations will be slower. If the database doesn't import data using these methods, this is a moot point.
  • Depending on the database activities, the transaction log may be huge. You can control this by performing regularly scheduled transaction log backups. Also, if copious drive space is available, this too is a moot point.
  • Backing up and restoring the transaction log can take longer than it does with the other recovery models. However, in a crisis, restoring all the data is likely more important than quickly restoring partial data.

The full recovery model can use all types of database backups. Figure 2 shows a typical backup schedule.

Figure 2 A sample recovery plan using the full recovery model, using full, differential, and transaction-log backups.


A sample full-recovery backup plan typically does a full database backup once or twice a week and differential backups every day or every other night. The transaction log is backed up throughout the day, from as little as two times a day to as often as every 15 minutes. Or you could do a daily full backup, with a differential backup every 6 hours and transaction log backups every 2 hours in between. The frequency of the transaction log backup is based around the maximum amount of acceptable data loss. For example, perform a transaction log backup every 15 minutes if you can afford to lose up to 15 minutes of data. You can mix and match options that make the most sense for your databases, your environment, and most importantly your resources (i.e. storage available for backup purposes).

To restore from the full-recovery model, do the following:

1. Perform a special kind of transaction log backup called a tail-log backup. This captures all the log records since the last transaction log backup and places the database in a restoring state.
If the disk subsystem containing the transaction log is lost, the database is marked suspect by SQL Server, and it is not possible to back up the current transaction log. In this case, the best recovery option is to restore to the last transaction-log backup. Other reasons for a database being marked suspect would be that the database file itself has been removed or renamed.

2. Restore the most recent full backup.
3. Restore the most recent single differential backup, if one has been made since the last full backup.
4. Restore, in sequence, all the transaction-log backups made since the time of the last full or differential backup. If the last backup were a full backup, then restoring it is sufficient. If the last backup were a differential backup, you need to restore the most recent full backup before restoring the most recent differential.
Top 10
Technology FAQ
- Microsoft ebs security server configuration
- IIs7 on Windows server 2003
- How to Configure Failover Clusters With Win 2008 Server R2?
- Windows 2008 Network Load Balancing
- Windows Server 2008 - Group Policy Management - Remove Computer Management
- Remove shortcuts possibility in a web page or to put in favorite
- HTA Dynamic Drop Down List
- IIS host header and DNS
- VMware or MS Virtual Server?
- Adobe Acrobat 9 inserting tab pages
programming4us programming4us