SQL,Information,article,applies,Microsoft,Ser
Quick Search for:  in language:    
SQL,Information,article,applies,Microsoft,Ser
   Code/Articles » |  Newest/Best » |  Community » |  Jobs » |  Other » |  Goto » | 
CategoriesSearch Newest CodeCoding ContestCode of the DayAsk A ProJobsUpload
SQL Stats

 Code: 28,909 lines
 Jobs: 440 postings

 
Sponsored by:

 

You are in:

 
Login



Latest Code Ticker for SQL.
Link_SQLServer_ Oracle
By Daniel G. Menendez on 8/20


SQL Strip Alpha/Numeric
By Jay Gardner on 8/19


how to apply a filter to an Access 2000 form by using a combo box as a filter parameter
By David Nishimoto on 8/16


Click here to put this ticker on your site!


Add this ticker to your desktop!


Daily Code Email
To join the 'Code of the Day' Mailing List click here!





Affiliate Sites



 
 
   

Do you have to review your backup strategy?

Print
Email
 

Submitted on: 7/13/2000 9:58:08 PM
By: Found on the World Wide Web 
Level: Intermediate
User Rating: By 2 Users
Compatibility:SQL Server 7.0

Users have accessed this article 4884 times.
 
 
     Information in this article applies to: Microsoft SQL Server Version 7.0 Microsoft SQL Server makes many tasks easier. Especially organizing the backup and recovery process has become much easier, because no devices have to be created and the database itself can also be rebuild automatically. But if you plan to be able to recover your data up to the point of failure then be aware of some restrictions!

 
When you create a database you can specify one or more database and log files for the database. In SQL Server 7.0 every database uses at least 2 files: One for the data and one for the transaction log. With that in place you can backup the whole database and then continue with backing up the transaction logs.

In case of a failure in the data part you can save the latest transactions (that is all transactions that took place between the last backup and the point of failure) and then restore first the data, then all previously saved logs and finally the changes that occured between the last backup (either database, incremental or log).

Sounds good, but your database has to follow a certain layout to make this possible. If you have a look in Books Online you'll find the following description for backing up the active part of the transaction log: 

Backing Up the Active Transaction Log

It is possible to back up the currently active transaction log even if the database is inaccessible, for example due to media failure, ...

Do not stop reading! The important part comes now:

... providing both the primary data file and the transaction log files are accessible.

 

So, if you want to maintain a system that can be restored up to the point of failure, you need at least three files:
  • The primary file in filegroup PRIMARY for all system objects.
  • One or more datafiles for table data, indexes and text data in filegroups other than PRIMARY
  • One or more transaction log files

 

What you should do
Create one or more filegroups for all the data part of your database. Make sure you put all tables, indexes and text data on this new filegroup. You can use ALTER DATABASE to make this new filegroup the default. That will make things easier.

Here is an example script for doing this:


USE master
GO
/* Make Filegroup DATA the default filegroup in database Example: */
ALTER DATABASE example 
MODIFY FILEGROUP data DEFAULT
GO
USE example
GO
-- Check whether status has been update -- d in sysfilegroups:
SELECT groupname FROM sysfilegroups WHERE status  = 16

 

When you create new objects in Enterprise Manager, make sure you specify the correct filegroup. Enterprise Manager tends to put all objects on the PRIMARY filegroup even if you specified a different default filegroup.

Check the database for objects that have by accident been placed on the default filegroup. The following script will help you with this task:


PRINT 'The following objects are not set up for "POINT OF FAILURE" recovery:'

SELECT 'Warning' =
        CASE
          WHEN i.indid < 2 THEN 'Table ' + o.name + 
                                     ' is located on the primary filegroup'
          WHEN i.indid = 255 THEN 'Text data of table ' 
               + o.name + 
               ' is located on the primary filegroup'
          ELSE 'Index ' + i.name + ' (Table ' + o.name 
               + ') is located on the primary filegroup'
        END,
        o.name as Tablename, 
        i.name as Indexname, 
        s.groupname, 
        i.indid FROM sysfilegroups s 
          INNER JOIN sysindexes i
                ON s.groupid = i.groupid
                INNER JOIN sysobjects o
                      ON i.id = o.id
        WHERE o.type ='U' 
        AND s.groupname = 'PRIMARY'

 

If this scripts issues warnings, you should recreate the objects on a different filegroup (Enterprise Manager can here be helpful).

Now that you have got everything settled, plan your backup strategy. I suggest to include the following items.

  • Full backup (to start with)
  • Filegroup backups of PRIMARY and your own filegroups.
  • Regular transaction log backups

In case of a failure you can then recover up to the point of the failure:

Scenario 1: PRIMARY filegroup is damaged

Restore the filegroup backup and any transaction log backups you have

Could look like this:

-- First restore system tables from backup:
RESTORE DATABASE Example
        FILE = 'Example_SYS',
        FILEGROUP = 'PRIMARY' 
        FROM DISK='G:\mssql7\backup\primary.bak'
        WITH NORECOVERY, REPLACE

-- Then restore the log backup.
RESTORE LOG Example FROM DISK='G:\mssql7\backup\log.bak'

 

This should bring your database back to a consistent state.

 

Scenario 2: Your data filegroup(s) become corrupt

Save the active part of the transaction log, specifying the NO_TRUNCATE option.

Example:

BACKUP LOG Example 
       TO DISK='G:\mssql7\backup\lastlog.bak' 
       WITH NO_TRUNCATE

Then restore the database, logs and the final log that you have just saved.

 

 

6 rules you might find useful
  • Create at least three files/filegroups for every database
    (for System tables, User tables, Transaction log)
  • Do not store tables, indexes or text data on the primary filegroup
  • Make a filegroup other than PRIMARY the default filegroup for your database
  • Take care in Enterprise Manager when creating objects. EM usually defaults to PRIMARY when creating new objects
  • Use filegroup backup to backup the PRIMARY filegroup
  • Do not forget to backup the active part of the transaction log when your data filegroup(s) become damaged (WITH NO_TRUNCATE)

 

Additional reading:
Microsoft Knowledge Base Article Q218739
PRB: BACKUP with NO_TRUNCATE not possible with missing Primary Data File

If you have any suggestions, comments concerning this article, please mail to sven hammesfahr.


Other 5 submission(s) by this author

 

 
Report Bad Submission
Use this form to notify us if this entry should be deleted (i.e contains no code, is a virus, etc.).
Reason:
 
Your Vote!

What do you think of this article(in the Intermediate category)?
(The article with your highest vote will win this month's coding contest!)
Excellent  Good  Average  Below Average  Poor See Voting Log
 
Other User Comments
1/7/2002 3:21:32 PM:Edward Johnson
Rather than moving the user objects to another filegroup, can the system objects be moved instead? I have an ERP database that would be a huge task to do if the user objects had to be moved. Please reply egjohnso@hotmail.com. Thanks! Ed
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
Add Your Feedback!
Note:Not only will your feedback be posted, but an email will be sent to the code's author in your name.

NOTICE: The author of this article has been kind enough to share it with you.  If you have a criticism, please state it politely or it will be deleted.

For feedback not related to this particular article, please click here.
 
Name:
Comment:

 

Categories | Articles and Tutorials | Advanced Search | Recommended Reading | Upload | Newest Code | Code of the Month | Code of the Day | All Time Hall of Fame | Coding Contest | Search for a job | Post a Job | Ask a Pro Discussion Forum | Live Chat | Feedback | Customize | SQL Home | Site Home | Other Sites | About the Site | Feedback | Link to the Site | Awards | Advertising | Privacy

Copyright© 1997 by Exhedra Solutions, Inc. All Rights Reserved.  By using this site you agree to its Terms and Conditions.  Planet Source Code (tm) and the phrase "Dream It. Code It" (tm) are trademarks of Exhedra Solutions, Inc.