SQL Server Performance Forum – Threads Archive

Table Error :: Possible chain linkage problem.

Hey guys … I have a "not that enormous" table (400.000 regs) with 100 users accessing it … I am receiving continously (and even after repairing it several times) the following error [
Table error: Object ID 1787153412, index ID 1. Page (1:43470) is missing a reference from previous page (1:97087). Possible chain linkage problem.
]
At this time, I am kinda desperate with it, as I am doing the DBCC CHECKTABLE(XXX, repair_rebuild), and when i manage to get a new and clean table (or the database gets "consistent") the problem appears again … Is it possibly a problem with indexes, in this case the primary key? We have a cluster with w2003 and sql 8.00.760 (SP3) I am lost!

---

I think I have seen this before.
Can you post the exact error message? ———————–
–Frank
http://www.insidesql.de
———————–

---

hey Frank,<br /><br />[<br />Error : 8908, Severity 22, State : 6<br />Table error: Database ID nn, object ID xxxx, index ID 0.<br />Chain linkage mismatch (1: 97087)-&gt;next=(1:9708<img src=’/community/emoticons/emotion-11.gif’ alt=’8)’ />, but (1:9708<img src=’/community/emoticons/emotion-11.gif’ alt=’8)’ />-&gt<img src=’/community/emoticons/emotion-4.gif’ alt=’;p’ />rev=(1:43470)<br />]<br /><br />That’s the system log<br /><br />

---

Books online refers:
Action
HARDWARE FAILURE Run hardware diagnostics and correct any problems. Also examine the Microsoft® Windows NT® system and application logs and the SQL Server™ error log to see if the error occurred as the result of hardware failure. Fix any hardware related problems. If you have persistent data corruption problems, try to swap out different hardware components to isolate the problem. Check to ensure that your system does not have write caching enabled on the disk controller. If you suspect this to be the problem, contact your hardware vendor. Finally, you might find it beneficial to switch to a completely new hardware system, including reformatting the disk drives and reinstalling the operating system. RESTORE FROM BACKUP If the problem is not hardware related and a known clean backup is available, restore the database from the backup. DBCC CHECKDB If no clean backup is available, execute DBCC CHECKDB without a repair clause to determine the extent of the corruption. DBCC CHECKDB will recommend a repair clause to use. Then, execute DBCC CHECKDB with the appropriate repair clause to repair the corruption. Caution If you are unsure what effect DBCC CHECKDB with a repair clause has on your data, contact your primary support provider before executing this statement.
This error cannot be repaired automatically.
Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided “AS IS” with no rights for the sake of knowledge sharing.

---

Try dropping & recreating the clustered index (all other noncl. ones too). Then rerun checkdb. If that doesn’t work, run dbcc checkdb with the repair_allow_data_loss clause. May be an idea to DTS or bcp all the data out of the table first to insure against data loss. And, like satya said, check your hardware, run disk consistency checks. Tom Pullen
DBA, Oxfam GB

---

I would first have a look athttp://support.microsoft.com/default.aspx?scid=kb;en-us;308886 ———————–
–Frank
http://www.insidesql.de
———————–

---

I am dealing with the problem and I am doing quite well (sigh!), although I have had to stop the dabatase several times (single user, repairing the table) I smelled it was something related to hardware, anyway. Unfortunately the "systems" manager is the one who can access servers (not me, my job description doesn’t specify having rights to access servers, nor the event log …(!) ) Actually I have something to report: . copying the table to another location worked once. (Select * into x2 from x, weird statement), but NOT ALWAYS, and it copied the entire table correctly. . reconstructing the index (primary key) and set it to NON CLUSTERED worked fine as well. Now it’s working this way. (Desperate solution) . the SHOWCONTIG parameters are okay, and we perform an index reconstruction every night . I am "checking DB" continuously … and now backing up the database every 30 minutes . As you see, I am working as a true artist, technology here doesnt help much "This error cannot be repaired automatically." . I’m praying as well…
The question is, in any case:: should the disk be corrupted or any other hardware failure should occur, it is VERY strange that it is JUST HAPPENING with THAT particular table. Checking the link provided by Frank :: "NOLOCK Optimizer Hint May Cause Transient Corruption Errors in the SQL Server Error Log", as it looks more serious than expected …. actually, when you read this :: SYMPTOMS ::: —————————-
When you use the NOLOCK hint, you may experience transient 8908 errors in the SQL Server error log on tables that experience high volumes of SQL Server activities. CAUSE
An error may occur when you use the NOLOCK optimizer hint to query tables in the database. There is a small timing window during page splits in conjunction with parallel nolock scans and concurrent updates that can generate transient 8908 messages. ———————————————————————————— should I assume that the "error" is only "virtual", a "message" in the "SQL Server error log "???

---

Try to export the data to a new table and drop this table alone, rename the exported table then recreate the indexes freshly. Take help from the NEtwork authority about hardware issues that will fix the issue.
Refer to the SQL error log for more information; Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided “AS IS” with no rights for the sake of knowledge sharing.

---

Every time I have had this error it has been due to bad sectors on disk. Doesn’t matter what type of disk either, I’ve worked with many kinds. SQL Server is simply complaining as the conduit of the symptoms of the underlying disk problem. If you run disk check utilities, and disk is your problem, then rerunning checkdb, etc will do nothing to really help. You should repair/replace the disk.

---

I’VE COMPLETELY SAME PROBLEM, WHAT’S YOUR LAST SITUATION ?

---

Hi there hgurolaksu,
yes, the problem was solved when I discovered that it was occurring on other tables, in different indexes than the primary key. That gave me a clue about the real source of the problem: currently I am truly convinced about putting the blame on indexes. Actually it was not a hardware problem (clusters here are a bit tricky) and the actions I took were as follows: 1. backup the table (select * into …). That is subject to fail.
2. stop the database
3. Re-build the indexes
4. DBCC checkdb
5. Give extra disk space to the MDF file. In that case, I had made the mistake of giving a dynamic growth to that database, and I think that probably was an additional problem. If you can stop the service, much luckier you are, I think it will help a lot. (sorry about my tacky english this morning…)

---

Hi, I run on the same problem on SQL Server 2008 platform. The solution is similarly the same but the issue I had is all about index, so I just identify and drop the index that cause the problem. Rebuild and run update statistics and voila… Thanks for this old post help me solve it easily. Regards,
Arnel

---

]]>