Recently I have been getting a barrage of errors such as:
DESCRIPTION: Error: 8908, Severity: 22, State: 6
Table error: Database ID 16, object ID 1893581784, index ID 2. Chain
linkage mismatch. (1:17214)->next = (1:17060), but (1:17060)->prev =
(3:178).
and
DESCRIPTION: Error: 605, Severity: 21, State: 1
Attempt to fetch logical page (1:164756) in database 'Clients' belongs
to object 'activities', not to object 'entity_address_check'.
The problem began to originally manifest itself with a couple errors
similar to:
DESCRIPTION: Error: 605, Severity: 21, State: 1
Attempt to fetch logical page (1:4930) in database 'tempdb' belongs to
object '1732152167', not to object
'#allrowstable____________________________________ __________________________________________________ _________________000100003472'.
So far all of the errors have been isolated to indexes and I have been
able to repair the problems with CHECKDB fast_rebuild or by dropping
the index that is causing the error and recreating it. At times the
errors will appear for a couple hours overnight and then resolve
themselves before the morning. Originally the problem began to appear
on a single SQL Servers and now appears daily on all three SQL
Servers.
We've investigated whether the NOLOCK optimizer was the culprit but
out of all of our views and procedures there was nothing compiled with
that optimizer in any of the databases, so this seems an unlikely
cause (SEE http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B308886
)
We've reviewed IO on the servers, and nothing appears out of the
ordinary. We have even checked into the possibility of unreport IO
errors (SEE http://support.microsoft.com/default.aspx?scid=kb;en-us;826433&Product=sql2k
) but this still is inconclusive. HP did admit that their disc array
is not fully compatible with W2K Adv Server SP3, but the problem only
recently appeared and the upgrade to SP3 was completed nearly 2 months
ago.
We are running SQL Server 2000 EE, SP3 build 2195 on Windows 2000
Advanced Server. The server is setup as an A/P cluster on 2 HP
Proliant servers with a HP HTA200 disc array.
If anyone has any insight or suggestions, it would be great to hear
them.Did you do the whole database?
Fixing one doesn't guarentee all...
Did you do DBCC CHECKDB after the work was done to see if there are any other errors?
How big is the db?
So as to nor prevent an outage..take a dump, restore it to another box/instance, and do a full repair...see how long it takes...
Then schedule an outage...
MOO
and Good Luck...|||The largest of the affected databases is about 3 GB and the smallest 800 MB. I have done DBCC CHECKDB (with Fast_Rebuild) to fix some of the errors and have been running CHECKDB multiple times daily to watch for and catch the errors as they are showing up.
Also DBCC DBREINDEX has been running weekly to rebuild the indexes.
One thing I have been considering is rebuilding statistics and usage for all of the databases. On some previous projects I have seen statistics that are out of wack severly affect performance.
Jason Strate
Showing posts with label asdescription. Show all posts
Showing posts with label asdescription. Show all posts
Wednesday, March 7, 2012
Chain Linkage Mismatch Errors
Recently I have been getting a barrage of errors such as:
DESCRIPTION: Error: 8908, Severity: 22, State: 6
Table error: Database ID 16, object ID 1893581784, index ID 2. Chain
linkage mismatch. (1:17214)->next = (1:17060), but (1:17060)->prev =
(3:178).
and
DESCRIPTION: Error: 605, Severity: 21, State: 1
Attempt to fetch logical page (1:164756) in database 'Clients' belongs
to object 'activities', not to object 'entity_address_check'.
The problem began to originally manifest itself with a couple errors
similar to:
DESCRIPTION: Error: 605, Severity: 21, State: 1
Attempt to fetch logical page (1:4930) in database 'tempdb' belongs to
object '1732152167', not to object
'#allrowstable__________________________
____________________________________
________________________________________
_000100003472'.
So far all of the errors have been isolated to indexes and I have been
able to repair the problems with CHECKDB fast_rebuild or by dropping
the index that is causing the error and recreating it. At times the
errors will appear for a couple hours overnight and then resolve
themselves before the morning. Originally the problem began to appear
on a single SQL Servers and now appears daily on all three SQL
Servers.
We've investigated whether the NOLOCK optimizer was the culprit but
out of all of our views and procedures there was nothing compiled with
that optimizer in any of the databases, so this seems an unlikely
cause (SEE http://support.microsoft.com/defaul...t
=sql2k
) but this still is inconclusive. HP did admit that their disc array
is not fully compatible with W2K Adv Server SP3, but the problem only
recently appeared and the upgrade to SP3 was completed nearly 2 months
ago.
We are running SQL Server 2000 EE, SP3 build 2195 on Windows 2000
Advanced Server. The server is setup as an A/P cluster on 2 HP
Proliant servers with a HP HTA200 disc array.
If anyone has any insight or suggestions, it would be great to hear
them.>
> Recently I have been getting a barrage of errors such as:
> DESCRIPTION: Error: 8908, Severity: 22, State: 6
> Table error: Database ID 16, object ID 1893581784, index ID 2. Chain
> linkage mismatch. (1:17214)->next = (1:17060), but (1:17060)->prev =
> (3:178).
> and
> DESCRIPTION: Error: 605, Severity: 21, State: 1
> Attempt to fetch logical page (1:164756) in database 'Clients' belongs
> to object 'activities', not to object 'entity_address_check'.
> The problem began to originally manifest itself with a couple errors
> similar to:
> DESCRIPTION: Error: 605, Severity: 21, State: 1
> Attempt to fetch logical page (1:4930) in database 'tempdb' belongs to
> object '1732152167', not to object
>
'#allrowstable__________________________
____________________________________
________________________________________
_000100003472'.
> So far all of the errors have been isolated to indexes and I have been
> able to repair the problems with CHECKDB fast_rebuild or by dropping
> the index that is causing the error and recreating it. At times the
> errors will appear for a couple hours overnight and then resolve
> themselves before the morning. Originally the problem began to appear
> on a single SQL Servers and now appears daily on all three SQL
> Servers.
> We've investigated whether the NOLOCK optimizer was the culprit but
> out of all of our views and procedures there was nothing compiled with
> that optimizer in any of the databases, so this seems an unlikely
> cause (SEE
http://support.microsoft.com/defaul...Ben-us%3B308886
> )
> We've reviewed IO on the servers, and nothing appears out of the
> ordinary. We have even checked into the possibility of unreport IO
> errors (SEE
http://support.microsoft.com/defaul...3&Product=sql2k
> ) but this still is inconclusive. HP did admit that their disc array
> is not fully compatible with W2K Adv Server SP3, but the problem only
> recently appeared and the upgrade to SP3 was completed nearly 2 months
> ago.
> We are running SQL Server 2000 EE, SP3 build 2195 on Windows 2000
> Advanced Server. The server is setup as an A/P cluster on 2 HP
> Proliant servers with a HP HTA200 disc array.
> If anyone has any insight or suggestions, it would be great to hear
> them.
>
--
Hi Jason,
Here is my recommended action plan:
1. Turn off write caching in you disk controllers. They have been known to
cause these 605 errors. Monitor your database for a few weeks and see if
turning off the write caching has made a difference.
2. Run SQLIOStress.exe on your system to check how it can handle a typical
SQL Server load. Information about SQLIOStress follows:
HOW TO: Use the SQLIOStress Utility to Stress a Disk Subsystem Such As SQL
Server
http://support.microsoft.com/?id=231619
Hope this helps,
Eric Crdenas
Senior support professional
This posting is provided "AS IS" with no warranties, and confers no rights.
DESCRIPTION: Error: 8908, Severity: 22, State: 6
Table error: Database ID 16, object ID 1893581784, index ID 2. Chain
linkage mismatch. (1:17214)->next = (1:17060), but (1:17060)->prev =
(3:178).
and
DESCRIPTION: Error: 605, Severity: 21, State: 1
Attempt to fetch logical page (1:164756) in database 'Clients' belongs
to object 'activities', not to object 'entity_address_check'.
The problem began to originally manifest itself with a couple errors
similar to:
DESCRIPTION: Error: 605, Severity: 21, State: 1
Attempt to fetch logical page (1:4930) in database 'tempdb' belongs to
object '1732152167', not to object
'#allrowstable__________________________
____________________________________
________________________________________
_000100003472'.
So far all of the errors have been isolated to indexes and I have been
able to repair the problems with CHECKDB fast_rebuild or by dropping
the index that is causing the error and recreating it. At times the
errors will appear for a couple hours overnight and then resolve
themselves before the morning. Originally the problem began to appear
on a single SQL Servers and now appears daily on all three SQL
Servers.
We've investigated whether the NOLOCK optimizer was the culprit but
out of all of our views and procedures there was nothing compiled with
that optimizer in any of the databases, so this seems an unlikely
cause (SEE http://support.microsoft.com/defaul...t
=sql2k
) but this still is inconclusive. HP did admit that their disc array
is not fully compatible with W2K Adv Server SP3, but the problem only
recently appeared and the upgrade to SP3 was completed nearly 2 months
ago.
We are running SQL Server 2000 EE, SP3 build 2195 on Windows 2000
Advanced Server. The server is setup as an A/P cluster on 2 HP
Proliant servers with a HP HTA200 disc array.
If anyone has any insight or suggestions, it would be great to hear
them.>
> Recently I have been getting a barrage of errors such as:
> DESCRIPTION: Error: 8908, Severity: 22, State: 6
> Table error: Database ID 16, object ID 1893581784, index ID 2. Chain
> linkage mismatch. (1:17214)->next = (1:17060), but (1:17060)->prev =
> (3:178).
> and
> DESCRIPTION: Error: 605, Severity: 21, State: 1
> Attempt to fetch logical page (1:164756) in database 'Clients' belongs
> to object 'activities', not to object 'entity_address_check'.
> The problem began to originally manifest itself with a couple errors
> similar to:
> DESCRIPTION: Error: 605, Severity: 21, State: 1
> Attempt to fetch logical page (1:4930) in database 'tempdb' belongs to
> object '1732152167', not to object
>
'#allrowstable__________________________
____________________________________
________________________________________
_000100003472'.
> So far all of the errors have been isolated to indexes and I have been
> able to repair the problems with CHECKDB fast_rebuild or by dropping
> the index that is causing the error and recreating it. At times the
> errors will appear for a couple hours overnight and then resolve
> themselves before the morning. Originally the problem began to appear
> on a single SQL Servers and now appears daily on all three SQL
> Servers.
> We've investigated whether the NOLOCK optimizer was the culprit but
> out of all of our views and procedures there was nothing compiled with
> that optimizer in any of the databases, so this seems an unlikely
> cause (SEE
http://support.microsoft.com/defaul...Ben-us%3B308886
> )
> We've reviewed IO on the servers, and nothing appears out of the
> ordinary. We have even checked into the possibility of unreport IO
> errors (SEE
http://support.microsoft.com/defaul...3&Product=sql2k
> ) but this still is inconclusive. HP did admit that their disc array
> is not fully compatible with W2K Adv Server SP3, but the problem only
> recently appeared and the upgrade to SP3 was completed nearly 2 months
> ago.
> We are running SQL Server 2000 EE, SP3 build 2195 on Windows 2000
> Advanced Server. The server is setup as an A/P cluster on 2 HP
> Proliant servers with a HP HTA200 disc array.
> If anyone has any insight or suggestions, it would be great to hear
> them.
>
--
Hi Jason,
Here is my recommended action plan:
1. Turn off write caching in you disk controllers. They have been known to
cause these 605 errors. Monitor your database for a few weeks and see if
turning off the write caching has made a difference.
2. Run SQLIOStress.exe on your system to check how it can handle a typical
SQL Server load. Information about SQLIOStress follows:
HOW TO: Use the SQLIOStress Utility to Stress a Disk Subsystem Such As SQL
Server
http://support.microsoft.com/?id=231619
Hope this helps,
Eric Crdenas
Senior support professional
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to:
Posts (Atom)