|
Home > Archive > MS SQL Server > April 2006 > Consistency error in sql2000
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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_lo
ss 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
| |
| Linchi Shea 2006-04-03, 3:23 am |
| It 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_lo
ss 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
>
|
|
|
|
|