Search
Home
Articles
Backup
Books
Certification
FAQ
Products
Replication
Scripts
Seminars
Training
TSQL

MSDN Fourms
Fort Worth SSUG
Oklahoma City SSDG

Resume

Champion Valley Pens

6.5 Disaster Recovery Plan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

601 error

This is a case of the internal memory structures being corrupted inside SQL Server. This occurs when the object descriptor for a system object gets reused. No data loss has occurred, but the SQL Server needs to be stopped and restarted to clean up this problem.

  1. Stop the SQL Server service
  2. Start the SQL Server service

You are getting duplicate identity values

This is a relatively common error that occurs when you have heavy insert activity on a table that contains an identity. This will normally occur if you have turned on insert row level locking or you run out of open objects. It is identified by getting an error message stating: attempt to insert a duplicate row. The resolution to this is simply to run a DBCC checkident. This should only be run when you encounter this error. Running this on a routine basis can cause you to overflow the range of allowed values for the datatype because the checkident has the possibility of skipping blocks of numbers.

  1. Start isql/w
  2. Connect to the database in question
  3. Execute a dbcc checkident(<tablename>)

Cross linked objects

Cross linked objects is a very serious internal error that has two possible recovery options depending upon the type of object. It has only been encountered with tables and indexes simply because they are the only ones that dynamically allocate more space, but it can possibly happen with other objects.

If the objects that have been cross-linked are indexes, the first thing to attempt is to drop and recreate the indexes. This will possibly work in about 40% of the cases. If the index will not drop, you will have to go to the next option noted below.

If the objects that are cross-linked are tables, you must restore. There are no other options to this problem. In this case the following procedure should be performed:

  1. If the database is replicated, stop replication
  2. Dump the transaction log using the no_truncate option
  3. Restore the most recent backup
  4. Apply all transaction logs
  5. If the database is replicated, remove replication for that database
  6. If the database is replicated, verify all replication components have been eliminated
  7. If the database is replicated, reinstall replication
  8. If the database is replicated, verify and test installation of all components

6.5 Disaster Recovery Plan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Michael R. Hotek

All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.