January 23, 2007 at 9:53 am
Table error: Database ID 5, object ID 1330103779, index ID 0. Chain linkage mismatch. (1:183527)->next = (1:183624), but (1:183624)->prev = (1:183623).
January 23, 2007 at 10:42 am
Sounds like you might have a serious problem with the underlying disk subsystem. You might be able to fix it by creating an exact copy of the data and INSERTing it all into there and dropping the original table, but I'd be concerned about what really is causing this issue in the first place (so that hopefully you can address it so it doesn't happen again). I assume you've run a DBCC CHECKDB on the database?
January 23, 2007 at 11:15 am
January 23, 2007 at 11:22 am
Be careful about defragging... it's usually not something you should do on SQL Server's usually (for a bunch of different reasons). If you have a maintenance window when you can take the server offline you might consider running chkdsk against the drive but I'd make sure to stop all SQL Server services first.
January 24, 2007 at 10:45 am
You might also want to check the Syste Event log to see if there are any errors hardware related. Another avenue to investigate would be your SAN (I assume SAN because the table is 2 Tb).
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
January 26, 2007 at 11:17 am
Have you tried creating the table with a select * into, duplicating the indexes, droping the old table and renaming the new table back to tb1?
I had a similar issue before and this worked for me.
Although my table wasn't 1TB in size, so it was a quick fix for me!
February 8, 2007 at 5:55 am
I implemented the suggestion Clive Strong provided. It's been nearly two weeks and I have not received the same error yet. I used to have to rebuilt the index at least once per week. Perhaps there was a bad sector on the disk. Thanks to Clive and all others who provided suggestions.
February 8, 2007 at 6:40 am
This message may have an underlying cause of logical memory corruption but not neccesarily any physical corruption. Hence, checkb will show no error as it checks the physical storage.
If operating system, driver, or hardware problems cause lost write conditions or stale read conditions, you may see data integrity-related error messages including 605, 823 or 3448 errors. Are you using a SAN ?
Many of logical memory corruption problems were corrected in SQL Server 2000 Service Pack 4.
SQL = Scarcely Qualifies as a Language
February 8, 2007 at 6:44 am
Yes, we are using a SAN. Also, the SQL server 2000 does have the SP4 installed from the beginning.
February 26, 2007 at 7:08 am
Hi,
Slightly off topic, but Microsoft don't recommend defragmenting a SAN disk...
Quote 'Physical Disk Fragmentation
Disk fragmentation can contribute to poor performance on some systems.
To determine whether disk fragmentation exists,
use system tools provided in Microsoft Windows or from third parties to analyze drives
on which SQL Server databases reside.
On small-scale environments with more conventional I/O subsystems,
it is recommended that you correct disk fragmentation before running index defragmentation tools.
On large-scale environments that benefit from more intelligent disk subsystems,
such as SAN (storage area networks) environments,
correcting disk fragmentation is not necessary.'
See http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx
Hope this helps.
Pete
Peter Gadsby
Business Intelligence Consultant
www.hgconsult.co.uk
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply