DBCC CHECKDB - error Msg 8992

  • shane2174 (10/23/2009)


    having the same issue when detach/attach databases from 2000 to 2005,

    error:

    Msg 8992, Level 16, State 1, Line 1

    Check Catalog Msg 3853, State 1: Attribute

    (referenced_major_id=498569310,referenced_minor_id=1) of row (class=0,object_id=235304048,column_id=0,referenced_major_id=498569310,referenced_minor_id=1) in sys.sql_dependencies does not have a matching row (object_id=498569310,column_id=1) in sys.columns.

    CHECKDB found 0 allocation errors and 1 consistency

    errors not associated with any single object.

    Check what objects have the IDs 235304048 and 498569310. Post back once you have done so, depending what it is the fix is easy or near-impossible.

    I know my source sql2000 databases were clean, so I need to know if this is happened on my new H/W sql2005 or is just a 2000 to 2005 compatibility issue.

    How do you know that?

    In SQL 2000 DBCC CheckDB did not run a check of the system catalog. Unless you were running both DBCC CheckDB and DBCC CheckCatalog, this problem could easily have existed in the SQL 2000 database for a long time and you wouldn't have known about it.

    This is usually the result of someone directly modifying the system tables in SQL 2000. Because CheckDB didn't run CheckCatalog, often people didn't realise there was a problem in their DB until they upgrade to SQL 2005 (where CheckDB does run checkCatalog)

    Do you have a backup of the SQL 2000 database? Would going back to that backup, fixing the problem there and then upgrading again to SQL 2005 be an option?

    p.s. Please in future post new questions in a new thread. Thanks

    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
  • well , I did not run checkcatalog in SQL2000 (I though checkdb will ran that too) well, luckily sql2005 is not in production yet so I fix the problem in SQL2005 with simply drop/create the SP that calls the UDF and it did fix the problem. just added one more step to my post-scripts after migration.

    Thanks fo quick respond.

  • shane2174 (10/28/2009)


    well , I did not run checkcatalog in SQL2000 (I though checkdb will ran that too) well, luckily sql2005 is not in production yet so I fix the problem in SQL2005 with simply drop/create the SP that calls the UDF and it did fix the problem.

    That's the easiest fix when one of the objects is a stored procedure, view or function.

    just added one more step to my post-scripts after migration.

    Which is?

    Perhaps better would be to run CheckCatalog pre-upgrade. Fixing problems in the system tables is moderately complex in SQL 2000, exceedingly complex in SQL 2005+

    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 3 posts - 31 through 32 (of 32 total)

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