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

  • 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?

  • 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

  • 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

  • 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)

  • 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 🙂

  • 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
  • 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

  • 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)

  • 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

  • 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
  • This was removed by the editor as SPAM

  • 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

  • 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
  • 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 ?

  • 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

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

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