Post reply

Need HELP: [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928

  • April 18, 2005 at 5:40 pm

    #163366

    Hello:

    I am new to SQL database integrity problem (Error 8928), and I need some help!

    I ran a integrity check over the weekend and the following consistency problem was found. Any idea how to resolve it?

    Our scenerio is that. We are using Windows2000 Advance Server with SQL Server 2000. I moved the database from the existing SCSI disk to our new external SCSI disk. After the move, I did an integrity check and this error was reported. Two weeks or so ago, when I did an integrity check, the database was ok.

    I read from the MS site that it could be a hardware problem. But how to check if our new SCSI disk is good? I looked at the device manager in Windows, and it is said the SCSI disk is working properly.

    I read from the SQL Server documentation that we can use DBCC to correct it, but would result in data loss. Would it be possible to know exactly what data is loss. If I can find out what exactly will be lost, then I can run the DBCC to repair it, and reload the lost data.

    [4] Database Order_Data: Check Data and Index Linkage...

    [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC SQL Server Driver][SQL Server]Object ID 1077578877, index ID 0: Page (5:183991) could not be processed. See other errors for details.

    [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID 1077578877, index ID 0, page (5:183991), row 0. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 36 and 13.
    [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 2 consistency errors in table 'tblData2' (object ID 1077578877).
    [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 2 consistency errors in database 'Order_Data'.
    [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Order_Data ).

    The following errors were found:

    [Microsoft][ODBC SQL Server Driver][SQL Server]Object ID 1077578877, index ID 0: Page (5:183991) could not be processed. See other errors for details.
    [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID 1077578877, index ID 0, page (5:183991), row 0. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 36 and 13.
    [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 2 consistency errors in table 'tblData2' (object ID 1077578877).
    [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 2 consistency errors in database 'Order_Data'.
    [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Order_Data ).

    Thanks!

    Joe(UserID=231116)

  • April 18, 2005 at 9:56 pm

    #553311

    Same issue. hopr you will get some idea from this

    http://qa.sqlservercentral.com/forums/shwmessage.aspx?forumid=5&messageid=117472




    My Blog: http://dineshasanka.spaces.live.com/

  • April 20, 2005 at 4:15 pm

    #553938

    I have been battling this same problem for a while now.  I have hardware people checking into our hardware configuration and have implemented  several patches from Microsoft.  In the mean time I have had to recover from corrupt data on a system that is under moderate use 24/7

     

    The good news is:

    1.      So far I have not lost any data to consistency errors. Allocation errors are another story.

    2.      You can probably get around putting the system in single user mode and running dbcc checkdb repair_allow_dataloss.

     

    Tips & Tools:

    If you want to see the table and index that are throwing the errors run this, replace

    XXXX with the table id number in the error.

     

    select O.[id], O.name, i.indid, i.name

    from sysobjects O left join sysindexes I on O.[id] = I.[id]

    where o.[id] = XXXXXXXXXXXX

     

    If the index number is something other than 0 you can usually just drop and recreate the index to solve the immediate problem.  If, as in your case, the index is zero try rebuilding all the indexes in the table using DBCC DBREINDEX.  See BOL for details.  This can get you around indexes with constraints, clustered indexes, etc.  Rebuilding indexes either way under production conditions can bring the system to a crawl.

     

    Good luck

     

  • April 21, 2005 at 1:21 am

    #553994

    To check your drives you can use SQLIOStress utility which can be dowloaded from MS:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;231619

  • April 22, 2005 at 12:38 am

    #554259

    Thanks for all your help!

    Any idea the difference between rebuilding the index and delete the index and recreate it?

    Thanks again!

    Joe

Viewing 5 posts - 1 through 4 (of 4 total)

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