Data row does not have a matching index row in the index

Question

Post reply

Data row does not have a matching index row in the index

tony28

SSCertifiable

Points: 7112
More actions
October 18, 2017 at 7:06 am

#325892

Hello,
I have this problem.
At monday found this, so drop and recreate index, then execute dbcc check and without problem.
Today this problem appear again. Is possible to do some another action? It can be with data what are inserted there ?
This index is concists of from big columns ( 4x nvarchar(150), one 250 then 100, 80 and some int )
is possible to do some next action?
October 28, 2017 at 5:06 am

This was removed by the editor as SPAM

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply

Thomas Rushton SSC-Insane Points: 22649 More actions · Answer 1

Check your error logs. Do you see any error messages, specifically, any of errors 823, 824, 825, 829?

If so, then you'll need to get your storage team involved.

See, eg:
https://www.sqlskills.com/blogs/paul/a-little-known-sign-of-impending-doom-error-825/
http://sqlsoldier.net/wp/sqlserver/day10of31daysofdisasterrecoverymonitoringforcorruptionerror
https://sqlperformance.com/2015/04/sql-performance/dealing-with-high-severity-errors-in-sql-server

https://www.google.co.uk/search?q=sql+server+error+823+824+and+825

And good luck!

Thomas Rushton
blog: https://thelonedba.wordpress.com

tony28 SSCertifiable Points: 7112 More actions · Answer 2

got only
Error: 8646, Severity: 21, State: 1.

I will try drop and create again, execute dbcc, then select and force this index, and then again execute dbcc, will see result... needed do during night so next day will see

Jeff Moden SSC Guru Points: 1004290 More actions · Answer 3

tony28 - Wednesday, October 18, 2017 7:06 AM
Hello,
I have this problem.
At monday found this, so drop and recreate index, then execute dbcc check and without problem.
Today this problem appear again. Is possible to do some another action? It can be with data what are inserted there ?
This index is concists of from big columns ( 4x nvarchar(150), one 250 then 100, 80 and some int )
is possible to do some next action?

If you add up the width of all those columns (especially taking NVARCHAR as 2 bytes per character), you have greatly exceeded the maximum byte count for an index key. Figure out what the key for the index actually needs to be and just INCLUDE the other columns and then you won't have such problems.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

tony28 SSCertifiable Points: 7112 More actions · Answer 4

Jeff Moden - Wednesday, October 18, 2017 7:48 AM
tony28 - Wednesday, October 18, 2017 7:06 AM
Hello,
I have this problem.
At monday found this, so drop and recreate index, then execute dbcc check and without problem.
Today this problem appear again. Is possible to do some another action? It can be with data what are inserted there ?
This index is concists of from big columns ( 4x nvarchar(150), one 250 then 100, 80 and some int )
is possible to do some next action?
If you add up the width of all those columns (especially taking NVARCHAR as 2 bytes per character), you have greatly exceeded the maximum byte count for an index key. Figure out what the key for the index actually needs to be and just INCLUDE the other columns and then you won't have such problems.

Hello,

I was thinking about this, because when I dropped and recreated that was warning with max values, so my thinking was about that will se problem during update/insert some large data or something.
The drop, recreate was ok, but if something happen again I need to discuss with owner of db about change this index.

Thanks for advices 🙂

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 5

Too-wide an index WILL NOT cause this error. SQL does not cause its own corruptions.
Too-wide an index will just cause inserts to fail. (and an insert will not partially complete)

If you're getting frequent corruptions, there's likely something wrong with the hardware. Drives, caches, something like that.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

tony28 SSCertifiable Points: 7112 More actions · Answer 6

GilaMonster - Thursday, October 19, 2017 6:57 AM
Too-wide an index WILL NOT cause this error. SQL does not cause its own corruptions.
Too-wide an index will just cause inserts to fail. (and an insert will not partially complete)
If you're getting frequent corruptions, there's likely something wrong with the hardware. Drives, caches, something like that.

its possible that is only on one index in one tables? there is some possibility how to check for proof to show to another team?

thanks

Jeff Moden SSC Guru Points: 1004290 More actions · Answer 7

Gail is correct and I didn't mean to imply that it was the cause of a row missing from an index. I meant it only as a bit of advice and my out of place comment of "and then you won't have such problems" was directed at the too-wide an index problem and not the post I quoted.

I also forgot to add that I'd like to see the precise code that makes you think that an index is missing a row as well as the code that creates the index. The reason being is just like Gail said. Unless there's some sort of latent problem with the SQL Server code itself (and that HAS happened and will happen again) or you do have some faulty hardware, what you're describing is impossible and that's why I'd like to see the exact code you used to determine a row is missing from the index and the code that created the index so that we can try to duplicate the problem (although it may still be a problem because I don't have a copy of 2005 anymore).

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

tony28 SSCertifiable Points: 7112 More actions · Answer 8

Hello,

so it was appear again.
I dont know query, becuase I got only error code in error log.

before this i found also , so is possible that there can be some memory problem ?
External dump process return code 0x20000001.
External dump process returned no errors.

So i can try recreate this index and prevent warning with less values and if still be problem it will be really HW ..
Thanks

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 9

You have a hardware problem. Corruption is mostly a hardware problem. It's got nothing whatsoever to do with the size of the index.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

tony28 SSCertifiable Points: 7112 More actions · Answer 10

GilaMonster - Thursday, October 26, 2017 9:47 AM
You have a hardware problem. Corruption is mostly a hardware problem. It's got nothing whatsoever to do with the size of the index.

Hello,

windows team test RAM with stress test and there was without errors . After 7.5h of ram stress (and 2 rounds) no error was detected (or corrected).

We changed this index and removed biggest columns (without warning message in create) and looks good.
So really could not be with this size of this index and size of this table? Or it can be that this machine is old and this RAM is DDR2 333Mhz ( 😀 ) , so it can be slow for these big operations?

Thanks

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 11

tony28 - Wednesday, November 8, 2017 1:29 AM
GilaMonster - Thursday, October 26, 2017 9:47 AM
You have a hardware problem. Corruption is mostly a hardware problem. It's got nothing whatsoever to do with the size of the index.
Hello,
windows team test RAM with stress test and there was without errors . After 7.5h of ram stress (and 2 rounds) no error was detected (or corrected).

Look at the IO subsystem. Memory corruptions are rare, because memory has its own error correction.

So really could not be with this size of this index and size of this table? Or it can be that this machine is old and this RAM is DDR2 333Mhz ( 😀 ) , so it can be slow for these big operations?

No. SQL does not corrupt its own indexes, and slow memory will just give you slow results.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

tony28 SSCertifiable Points: 7112 More actions · Answer 12

GilaMonster - Wednesday, November 8, 2017 2:07 AM
tony28 - Wednesday, November 8, 2017 1:29 AM
GilaMonster - Thursday, October 26, 2017 9:47 AM
You have a hardware problem. Corruption is mostly a hardware problem. It's got nothing whatsoever to do with the size of the index.
Hello,
windows team test RAM with stress test and there was without errors . After 7.5h of ram stress (and 2 rounds) no error was detected (or corrected).
Look at the IO subsystem. Memory corruptions are rare, because memory has its own error correction.
So really could not be with this size of this index and size of this table? Or it can be that this machine is old and this RAM is DDR2 333Mhz ( 😀 ) , so it can be slow for these big operations?
No. SQL does not corrupt its own indexes, and slow memory will just give you slow results.

ok , but do you think that will do only on one index and on another tables or databases will not do ?

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 13

tony28 - Wednesday, November 8, 2017 2:57 AM
ok , but do you think that will do only on one index and on another tables or databases will not do ?

You can get corruption anywhere. This index, because of its size and frequency of updates may be more likely to get hit by a problem with the IO subsystem, but it's whatever the error or fault hits.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass