ex_raise2: Exception raised

  • BLOB EATER

    SSChampion

    Points: 14564

    Hi,

    Has anyone experienced this before? The error log states the following:

    Message

    ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22, attempting to create symptom dump Possible schema corruption. Run DBCC CHECKCATALOG. Error: 211, Severity: 23, State: 70.

    I had no idea what database this related to on the server so I worked though each one running CHECKDB - I then got to ReportServer and CHECKDB failed to run so I ran CHECKCATALOG:

    Snippet OUTPUT of CHECKCATALOG on reportserver =

    Msg 3853, Level 16, State 1, Line 39

    Attribute (referencing_id=36254) of row (referencing_class=1,referencing_id=36254,referencing_minor_id=0,referenced_class=1,referenced_id=165575628,referenced_minor_id=0) in sys.sql_expression_dependencies does not have a matching row (object_id=36254) in sys.objects.

    Msg 3853, Level 16, State 1, Line 39

    Attribute (referencing_id=36254) of row (referencing_class=1,referencing_id=36254,referencing_minor_id=0,referenced_class=1,referenced_id=165575628,referenced_minor_id=2) in sys.sql_expression_dependencies does not have a matching row (object_id=36254) in sys.objects.

    Msg 3853, Level 16, State 1, Line 39

    Attribute (referencing_id=36254) of row (referencing_class=1,referencing_id=36254,referencing_minor_id=0,referenced_class=1,referenced_id=165575628,referenced_minor_id=4) in sys.sql_expression_dependencies does not have a matching row (object_id=36254) in sys.objects.

    Msg 3853, Level 16, State 1, Line 39

    Attribute (object_id=36254) of row (object_id=36254,parameter_id=1) in sys.parameters does not have a matching row (object_id=36254) in sys.objects.

    Msg 3853, Level 16, State 1, Line 39

    Attribute (object_id=36254) of row (object_id=36254,parameter_id=2) in sys.parameters does not have a matching row (object_id=36254) in sys.objects.

    Msg 3853, Level 16, State 1, Line 39

    Attribute (referencing_id=16036311) of row (referencing_class=1,referencing_id=16036311,referencing_minor_id=0,referenced_class=1,referenced_id=101575400,referenced_minor_id=1) in sys.sql_expression_dependencies does not have a matching row (object_id=16036311) in sys.objects.

    Msg 3853, Level 16, State 1, Line 39

    Means nothing to me... Im thinking about my backups now....

  • SoHelpMeCodd

    SSCertifiable

    Points: 5859

    You are facing a referential integrity error, here:

    sys.sql_expression_dependencies does not have a matching row [] in sys.objects.

    There may be hacks that could 'poison the database ' (i.e make SQL Server's errorlog report the database as being unsupported) and make SQL Server behave indeterminately, so best to restore from a known-good backup (i.e. a backup that does not report the same corruption, as verified by your restore strategy). But that is not the end of the story 🙂

    I recommend you dig into exception rasie2's error message 5242 a little more. Check the errorlog, system health records, and the system event log. A memory or disk error (in the system event log) does not need to coincide with the time when SQL Server raised the 5242 - the system events could be at any time since Windows was last rebooted (or even before that). A 5242 can be raised due to in-memory corruption that never makes it to disk. For example, both drivers and firmware (including BIOS) exist at a lower ring level than SQL Server (or Windows), so they can step on user mode or Windows memory, which makes Windows memory protection an effort in futility. Error 5242 is SQL Server's in-memory "sanity check". It could be that memory was read from a corrupted db file (into the bpool) or it could be that just SQL Server's memory was corrupted (the corruption never made it to disk). That is what 5242 recommends checking the dbs. IOW, a 5242 doesn't stop a lower ring level from corrupting the memory after SQL Server's sanity check (i.e. while the memory is on its way to disk), which is why RS' db could have been corrupted (even though that may not be the db that hit the in-memory 5242). Which means the killer could still be on the loose....

  • BLOB EATER

    SSChampion

    Points: 14564

    thanks for the reply - I have saved all the logs from that past week and still trying to perform RCA. Again, thanks for your advice.

  • Gail Shaw

    SSC Guru

    Points: 1004446

    When was the last clean checkDB on that database?

    Usually this kind of error is a leftover from SQL 2000, someone deleted rows from the system tables on SQL 2000 (where it was trivially possible) and it's only been picked up now. If that's the case, backups aren't going to help.

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

    SSChampion

    Points: 14564

    GilaMonster (11/10/2015)


    When was the last clean checkDB on that database?

    Usually this kind of error is a leftover from SQL 2000, someone deleted rows from the system tables on SQL 2000 (where it was trivially possible) and it's only been picked up now. If that's the case, backups aren't going to help.

    Last Checkdb for that DB was the previous Sunday (11th). I did find the following in the event logs: Kernel-Power: The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

    I was thinking about the validity of my backup, luckily not much changed ( in terms of SSRS ) so I was able to go back to a 7-day old backup file and recover that and run a successful checkdb, but I am nervous about the IO subsystem so I will be running a daily checkdb now.

  • Gail Shaw

    SSC Guru

    Points: 1004446

    An uncontrolled shutdown should not have caused errors. It feels like an update to the system tables was lost.

    Maybe check with the storage admins that any write caches are properly configured, battery backed and tested (working batteries)

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

    SSChampion

    Points: 14564

    GilaMonster (11/10/2015)


    An uncontrolled shutdown should not have caused errors. It feels like an update to the system tables was lost.

    Maybe check with the storage admins that any write caches are properly configured, battery backed and tested (working batteries)

    Ok thanks for the tip I will and have a conversation with them.

    cheers.

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

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