Post reply

Check Catalog Msg 3859, State 1: Warning: The system catalog was updated directly in database ID

  • March 22, 2010 at 7:24 am

    #212857

    Hello,

    we bought a software and part of this software was a sql server 2005 database, that we attached. Everytime we make a DBCC CHECKDB or DBCC CHECKCATALOG to this database we get the message:

    Check Catalog Msg 3859, State 1: Warning: The system catalog was updated directly in database ID 11, most

    recently at Dec 9 2009 3:55PM.

    That's OK so, but our Monitoring Tool reports this like an error message and generates a ticket every time. Because of we know of this direct catalog update now, we want delete/change this state in system catalog to "normal". How can we do that?

    Best regards

    Steffen

  • March 22, 2010 at 7:53 am

    #1137600

    You can't. That message is added when someone does a direct update to the system tables (which requires more than just sp_configure 'allow updates',1). It's there as a warning that someone has messed with the system tables in some way, to indicate that there may be problems as a result of that direct manipulation and that the DB is no longer supported.

    The only way you're going to get rid of that is to create a new database, migrate all the objects and data over and drop the one that's had the direct updates done in it.

    Do you know why someone was fiddling in the system tables back 9 Dec last year?

    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

  • March 22, 2010 at 9:09 am

    #1137637

    Hi Gail,

    thanks for your fast answer, no idea what happened to the system catalog in December. I will ask the software vendor for the reason. When i get an good answer i post it here.

    Kind regards

    Steffen

  • March 22, 2010 at 9:25 am

    #1137643

    It had better be a very good reason. Messing with the system tables, especially on SQL 2005 where they are not documented and not straightforward, is a quick way to break things badly.

    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 4 posts - 1 through 3 (of 3 total)

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