January 23, 2014 at 9:29 am
Hi there, I have inherited a DB (well about a million of them) and one of them (A DPM database) is having corruption issues.
now when I run this I get the following messages *sometimes* more often than not it will report no errors though .....
The last good backup is a few weeks old, I am very confused as to why this is only reporting consistancy errors everynow and then. If I backup the database and restore it to another instance, the errors are reported all the time, so that points to the server it is on, CHKDSK comes back OK though and I've got the DPM guy to test the memory.
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 962102468, index ID 1, partition ID 72057594068271104, alloc unit ID 72057594048741376 (type LOB data). The off-row data node at page (1:739312), slot 28, text ID 7643890057216 is not referenced.
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 962102468, index ID 1, partition ID 72057594068271104, alloc unit ID 72057594048741376 (type LOB data). The off-row data node at page (1:739312), slot 29, text ID 7643890253824 is not referenced.
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 962102468, index ID 1, partition ID 72057594068271104, alloc unit ID 72057594048741376 (type LOB data). The off-row data node at page (1:739312), slot 30, text ID 7643890515968 is not referenced.
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 962102468, index ID 1, partition ID 72057594068271104, alloc unit ID 72057594048741376 (type LOB data). The off-row data node at page (1:739312), slot 31, text ID 7643891892224 is not referenced.
CHECKTABLE found 0 allocation errors and 4 consistency errors in table 'tbl_RM_RecoverySource' (object ID 962102468).
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKTABLE (DPMDB.dbo.tbl_RM_RecoverySource).
any help would be appreciated
January 23, 2014 at 1:12 pm
It might be OK. I remember in SQL 2000, if you ran DBCC checkdb against a database that was actively being updated, there was a chance you could get inconsistent results that were not really inconsistent. The fact that you do not get the same error each time leads me to think that you do not have actual inconsistencies on disk. Does the table/index keep changing? Or is it the same one each time? Are you running the checkdb at a time when the user traffic is lower than normal?
January 23, 2014 at 1:18 pm
Matt Crowley (1/23/2014)
It might be OK. I remember in SQL 2000, if you ran DBCC checkdb against a database that was actively being updated, there was a chance you could get inconsistent results that were not really inconsistent. The fact that you do not get the same error each time leads me to think that you do not have actual inconsistencies on disk. Does the table/index keep changing? Or is it the same one each time? Are you running the checkdb at a time when the user traffic is lower than normal?
i don't think that's possible in the new checkdb, since it does take an internal snapshot now, and checks that for inconsistencies, which lets it avoid active updates.
Lowell
January 23, 2014 at 1:26 pm
It might not be possible. The changing nature of the inconsistency bothers me, though. Is it possible that the corrupt pages are being replaced from a (good) mirror copy? What do you get from this query:
select *
from msdb..suspect_pages
January 24, 2014 at 2:28 am
select *
from msdb..suspect_pages
returned nothing, and also CHECKTABLE has returned nothing in the half a dozen times I have ran it.
I'll wait a bit and try again later....
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply