Consistency error in sql2000

Hi,
I just found a lot of these errors in the errorlog and eventlog:
2006-04-01 20:55:13.84 spid83 Error: 605, Severity: 21, State: 1
2006-04-01 20:55:13.84 spid83 Attempt to fetch logical page (1:420416)
in database 'confirm' belongs to object '6488161', not to object 'XXXXX'..
I did as the BOL suggests and ran a dbcc checktable ('XXXXX') (with no
repair option). This returned:
There are 4889992 rows in 70072 pages for object 'XXXXX'.
CHECKTABLE found 0 allocation errors and 1 consistency errors in table
'XXXXX' (object ID 1781581385).
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKTABLE (XXXXXX ).
Not looking good at all.
Then I ran a dbcc checkdb ('yyyyy') with this result
...
...
CHECKDB found 0 allocation errors and 0 consistency errors in database
'yyyyy'.
A new dbcc checktable reported no errors.
How could this be. Was this a transient error after all?
Any insight is appreciated.
TIAIt is quite possible to run into transient DBCC errors in SQL2000, though
it's pretty rare. If your database is not huge, I'd re-run DBCC CHECKDB when
there isn't much activity. If that returns clean, you are probably okay.
Transient errors are more lickly when there are heavy activities.
Linchi
"Gurba" wrote:
> Hi,
> I just found a lot of these errors in the errorlog and eventlog:
> 2006-04-01 20:55:13.84 spid83 Error: 605, Severity: 21, State: 1
> 2006-04-01 20:55:13.84 spid83 Attempt to fetch logical page (1:420416)
> in database 'confirm' belongs to object '6488161', not to object 'XXXXX'..
> I did as the BOL suggests and ran a dbcc checktable ('XXXXX') (with no
> repair option). This returned:
> There are 4889992 rows in 70072 pages for object 'XXXXX'.
> CHECKTABLE found 0 allocation errors and 1 consistency errors in table
> 'XXXXX' (object ID 1781581385).
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKTABLE (XXXXXX ).
> Not looking good at all.
> Then I ran a dbcc checkdb ('yyyyy') with this result
> ...
> ...
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'yyyyy'.
> A new dbcc checktable reported no errors.
> How could this be. Was this a transient error after all?
> Any insight is appreciated.
> TIA
>sqlsql