Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Slideshows
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

MS SQL

Posted October 20, 2014

Backup and Restore Strategies in SQL Server – Part 2

By Arshad Ali

Introduction

There are several high availability solutions, which can be used with SQL Server like AlwaysOn, Failover Clustering, Database mirroring. While these high availability solutions ensure maximum uptime for your databases, you need to set up backup and restore strategies to recover the data or minimize the risk of data loss in case a failure happens. In this article series, I am going to discuss in detail backup and restore strategies in SQL Server.

In my last article of the series, I talked about Backup and Restore strategies in detail. I talked about why there is need for appropriate backup and restore strategies and different types of backup processes. In this article of the series I am going discuss different types of restore processes and backup and restore scenario.

Types of Restore

Just as there are different types of backup processes, there are equivalent restoration types as well. But before I can talk about different types of restore, I would like to first discuss the recovery process while restorating.

RECOVERY (default) or NORECOVERY

Recovery is the process to roll forward all the committed transactions (redo phase) and roll back all the uncommitted transactions (undo phase) and is usually done with the last restore. When you do restore you need to specify either RECOVERY (default) or NORECOVERY clause.

NORECOVERY indicates that no recovery should occur. This allows roll forward to continue with the next restore operations in the chain. This should be specified with all the restore operations except the last one.

RECOVERY clause indicates that roll back will be done after roll forward is completed for the current restore. This should be used with the last restore in the overall restore process chain.

Based on the different types of backup, these are different restore options you might have:

Full Database Restore

You can restore an entire database from a full database backup, starting with a full database backup restore, which may be followed by restoring the last differential database backup and then restoring all the transaction log backups, if you have any, in sequence as discussed next. You should do the recovery of the database with the last restore only.

Transaction Log Restore

You can restore transaction log backups onto a database in chronological sequence to reach to the desired recovery point in the overall restore process, if you have the necessary transaction log backups. You generally need to back up Tail-log before starting to restore the database and restoring it as the final log backup before recovering the database to avoid data loss after a failure. Once you are done with restoring your last full\differential backup, you need to restore all the transaction logs back in chronological order created after the last full\differential backup.

Piecemeal Restore

You can restore a part of a database at one time. It begins by restoring the database in stages, first restoring the primary filegroup and then followed by restoration of one or more secondary file groups. You need to use RESTORE DATABASE along with the PARTIAL clause and specifying one or more secondary file groups to be restored.

File or Filegroup Restore

You can restore specific damaged files or file groups to a database in a multi-filegroup database.

Page Restore

If a page is corrupted or damaged, you can restore a specific page (only database page) to the database without restoring the whole database. It requires your database to be under full or bulk-logged recovery models and supported only for read/write file groups. When SQL Server encounters an error while accessing the page it marks it "suspect," which can be identified in suspect_pages table in the msdb database. The goal of a page restore is to restore few individual pages for a faster restore than file restore and reduce the amount of data that would be offline during a restore operation. However, if you have more pages to restore, it is generally efficient to restore the file itself.

Backup and Restore Scenario

In a typical scenario, a database administrator sets up a process to take a full database backup occasionally, such as weekly, and takes a series of differential database backups at a shorter interval, such as daily. Next, the database administrator backs up the transaction log at frequent intervals, such as every 10 minutes or 1 hour.

This is just a recommendation not a rule as for a given type of backup, the optimal interval depends on factors such as the importance of the data, acceptance level of data loss, the size of the database, and modification being made to the database.

When you are restoring, you need to first restore the last full backup followed by the last differential back and then transaction log backup (taken after the last differential backup) in chronological order. Please note, you need to specify the NORECOVERY clause with all the restore operations other than the last one:

--Restore the last full database backup with NORECOVERY
RESTORE   DATABASE AdventureWorks2012
     FROM DISK = 'D:\backup\AdventureWorks2012.Bak'
     WITH NORECOVERY;
--Restore the last differential database backup with NORECOVERY
RESTORE   DATABASE AdventureWorks2012
     FROM DISK = 'D:\backup\AdventureWorks2012Diff.Bak'
     WITH NORECOVERY;
--Restore the transaction log backups in chronological sequence   and with the last restore use RECOVERY
RESTORE   LOG AdventureWorks2012
     FROM DISK = 'D:\backup\AdventureWorks2012Log.Bak'
     WITH RECOVERY;

Usually, you will use the RECOVERY clause with the last restore operation, as discussed above, but if you have not used it before, then you can execute the Restore command to recover a database without actually restoring a backup. This process is called recovery-only restore and can occur for an entire database or for one or more a files or file groups.

-- Restore database using WITH RECOVERY - Recovery-only restore
RESTORE   DATABASE AdventureWorks2012
     WITH RECOVERY;

If you want to do point-in-time recovery you can use STOPAT, STOPATMARK or STOPBEFOREMARK clause with the Restore command.

Conclusion

In this article of the series, I talked about different types of restore and discussed the backup and restore scenario.

Resources

Backup Overview (SQL Server)

BACKUP (Transact-SQL)

Restore and Recovery Overview (SQL Server)

RESTORE (Transact-SQL)

See all articles by Arshad Ali



MS SQL Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
MS SQL Forum
Topic By Replies Updated
SQL 2005: SSIS: Error using SQL Server credentials poverty 3 August 17th, 07:43 AM
Need help changing table contents nkawtg 1 August 17th, 03:02 AM
SQL Server Memory confifuration bhosalenarayan 2 August 14th, 05:33 AM
SQL Server Primary Key and a Unique Key katty.jonh 2 July 25th, 10:36 AM