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
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


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

Featured Database Articles

MS SQL

Posted Jun 21, 2002

SQL Server 2000 Administration in 15 Minutes a Week: Creating a Disaster Recovery Plan (Part 1)

By Michael Aubert


Welcome to the eighth article in my series SQL Server Administration in 15 Minutes a Week. A few weeks back we took our first look at Database backups. This week we will quickly review the recovery models before discussing how to prepare a disaster recovery plan. The topics for this week include:

- Recovery Models Review
- Creating a Disaster Recovery Plan


Recovery Models Review

Something you will start to notice as we get further into SQL Server is that most settings and options tend to be more of a balancing act than they are right or wrong. In other words, you will need to weigh the benefits and drawbacks of using one option over another. A good example of this would be the recovery models that we looked at in the last article. Some models allow for fast backup and use less disk space, but they don't provide the recovery options of other recovery models. Because this is an important part of your backup strategy, I would like to do a quick review of the three recovery models available with SQL Server 2000.

Simple

  • Uses full and differential backups
  • Recommended for development only, not for production databases
  • Bulk copy operations are fast and do not require large amounts of log space
  • Once log entries are no longer needed for recovery (after a checkpoint), log file space can be reused to keep log files small
  • If a failure occurs you can recover up to the point of the last full or differential backup, all data after the last full or differential backup will have to be redone

Full

  • Uses full, differential, and log backups
  • Recommended for production databases
  • Bulk copy operations must be logged row by row resulting in slower bulk operations and the requirement of more log file space
  • Log file space can't be reclaimed until the log file is backed up
  • Transaction log backups 
  • If a failure occurs you can recover to any point in time
  • If a data file is lost or damaged, no work is lost

Bulk_Logged

  • Uses full, differential, and log backups
  • Recommended for production databases when you need to perform many bulk operations
  • Bulk copy operations are not logged row by row resulting in faster bulk operations and lower log file space requirements
  • Log file space can't be reclaimed until the log file is backed up
  • If a failure occurs and no bulk operations have occurred since the last full/differential backup, you can recover to any point in time of a log backup. If bulk operations have occurred, you can recover to the end of any backup.


Page 2: Creating a Disaster Recovery Plan


 » See All Articles by Columnist Michael Aubert



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


















Thanks for your registration, follow us on our social networks to keep up-to-date