IT tutorials
 
Database
 

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
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

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.

21.1

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.

21.2

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.
Note
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.
 
Others
 
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.