Test (ColumnOffsets <= (nextRec - pRec)) failed

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

General SQL Server Forums

Data Corruption Issues

Test (ColumnOffsets <= (nextRec - pRec)) failed

Author

Topic

Kristen
Test

22859 Posts

Posted - 2006-05-08 : 04:19:12

Any advice on the best way to cure this would help, thanks


ALTER DATABASE MyDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

-- NOTE: There is normally NO reason NOT to use the "NO_INFOMSGS" option
DBCC CHECKDB  
(
	'MyDatabase' 
)
WITH
	NO_INFOMSGS	-- Suppresses all informational messages and the report of space used.

Server: Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 1360932120, index ID 0, page ID (1:66056). The PageId in the page header = (1:66088).
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1360932120, index ID 0: Page (1:66056) could not be processed. See other errors for details.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1360932120, index ID 0: Page (1:88992) could not be processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 1360932120, index ID 0, page (1:88992), row 1. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 18176 and 217.
CHECKDB found 0 allocation errors and 4 consistency errors in table 'MyTable' (object ID 1360932120).
CHECKDB found 0 allocation errors and 4 consistency errors in database 'MyDatabase'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (MyDatabase ).

EDIT: Nothing in Event Log, but one of the disks in the RAID failed 10 minutes before the first corruption was logged in the SQL Log - I thought RAID was supposed to be REDUNDANT

EDIT2: Restored the latest FULL backup and all subsequent TLOG backups [including one made after the database was set to SINGLE USER] to a spare server, using STANDBY, and DBCC CHECKDB says its fine. The TLogs were on a different channel ...

So I'm going to put that LIVE whilst we work out what to do with this crap RAID system ...

EDIT3: See http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=65733 for my checklist of the steps I went through for "disaster recovery" - if you are interested!

QUESTION:

We've replaced the dead disk in the RAID.

My MDF file clearly has a corruption in it.

Can I just RESTORE the database, or will that only write to the pages necessary to restore the backup, possibly leaving some corrupted pages elsewhere in the reserved space for the original file? In which case would I be better off to pre-delete the old database so that it creates, and presumably initialises the whole of, a new file?

Kristen

paulrandal
Yak with Vast SQL Skills

899 Posts

Posted - 2006-05-08 : 14:44:07

You should just restore the database. If you've replaced the drive and there are no other hardware issues, then any parts of the disks that contain corrupt pages will either be overwritten by the restored database, or will no longer be part of the database once its restored, or will still exist, but as unallocated pages in the restored database. Does this make sense?

Paul Randal
Lead Program Manager, Microsoft SQL Server Storage Engine + SQL Express
(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.)

Kristen
Test

22859 Posts

Posted - 2006-05-08 : 17:06:56

"Does this make sense"

Yup, thanks.

We are running on the "other server" just now, so at a quiet time I will take the web site offline; backup the other-server; restore to the main-server; and then reconfigure the web site and bring it back online.

Thanks for your help and reassurance.

Still bemused that failure of one RAID disk could muck up the rest of the array ...

Kristen

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources