Never update systems tables directly - a study in Agent job scheduling

  • Nakul Vachhrajani

    SSChampion

    Points: 10151

    Comments posted to this topic are about the item Never update systems tables directly - a study in Agent job scheduling

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com
    Be courteous. Drive responsibly.

    Follow me on
    Twitter: @sqltwins

  • mtassin

    SSC-Insane

    Points: 23035

    Nice Article

    Just one of many many reasons that going after the system tables should be done with much trepidation.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • WayneS

    SSC Guru

    Points: 95341

    Nakul,

    Good Article. Thanks for pointing out other areas where updating system tables can cause issues.

    Out of curiosity, is the sp_configure option for Allow Updates set to 1 on your system? Does setting it to zero prohibit the direct of these system tables in the msdb database?

    Wayne
    Microsoft Certified Master: SQL Server 2008
    Author - SQL Server T-SQL Recipes[/url]


    If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
    Links: For better assistance in answering your questions[/url], How to ask a question, Performance Problems[/url], Common date/time routines,
    CROSS-TABS and PIVOT tables Part 1[/url] & [url url=http://www

  • Nakul Vachhrajani

    SSChampion

    Points: 10151

    WayneS (9/17/2012)


    Nakul,

    Good Article. Thanks for pointing out other areas where updating system tables can cause issues.

    Out of curiosity, is the sp_configure option for Allow Updates set to 1 on your system? Does setting it to zero prohibit the direct of these system tables in the msdb database?

    Thank-you for taking the time out and reading my article.

    The "Allow Updates" on the system was set to 0, and yet we were allowed to update these tables directly.

    Do let me know in case of any further queries.

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com
    Be courteous. Drive responsibly.

    Follow me on
    Twitter: @sqltwins

  • Nakul Vachhrajani

    SSChampion

    Points: 10151

    Thank-you, all for taking the time out and reading my article. I really appreciate it!

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com
    Be courteous. Drive responsibly.

    Follow me on
    Twitter: @sqltwins

  • Nadrek

    SSC-Insane

    Points: 20039

    I'd have to rate the particular example selected as "Implement all the requirements to get system table updates to act as expected."

    In this case, the failure wasn't in updating system tables and perhaps strange, dangerous, or difficult to deal with side effects, it was merely in failing to restart the agent service after the msdb tables were updated.

  • Nakul Vachhrajani

    SSChampion

    Points: 10151

    Nadrek (9/17/2012)


    I'd have to rate the particular example selected as "Implement all the requirements to get system table updates to act as expected."

    In this case, the failure wasn't in updating system tables and perhaps strange, dangerous, or difficult to deal with side effects, it was merely in failing to restart the agent service after the msdb tables were updated.

    @Nadrek: The system stored procedure does a lot of things besides simply "telling" the SQL Agent service that a configuration change has been made. The most important thing being - updating the meta-data. True, one may reinvent the wheel and do the same things externally, but, it doesn't really add value for money.

    Besides, in most hosted or large-scale enterprise environments, restarting the SQL Server may not be a feasible option because all interfaces and other systems which also have their databases hosted on the same instance would go down.

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com
    Be courteous. Drive responsibly.

    Follow me on
    Twitter: @sqltwins

  • thisisfutile

    Hall of Fame

    Points: 3451

    Thanks for taking the time to write such a detailed article. I feel I've learned something. I've always been of the mindset to not mess with system tables anyway but deep down I could see myself saying, "But it's just one, tiny 'enable' switch...what will it hurt to just flip it on?"

    ...now I don't have to make that mistake. 🙂

  • BrandonChampion

    SSC Journeyman

    Points: 84

    I've never changed a system table, but I did change a system stored procedure in SQL 2000. I had quite a few meticulously named DTS packages which, to my great frustration, were not sorted by name when viewed in the DTS package list.

    I found msdb.dbo.sp_enum_dtspackages and changed "ORDER BY id" to "ORDER BY name, id".

    It was one of the happiest days of my life.

  • Garry.McGibbon

    SSC Journeyman

    Points: 87

    Good example BrandonChampion. There are times when direct updates to msdb tables & objects are useful. Another example is changing the ownership of a maintenance plan. So be careful - yes. Never? well that's a long time.

  • Neha05

    Default port

    Points: 1494

    Good article.

  • Andy DBA

    SSCommitted

    Points: 1776

    Nakul Vachhrajani (9/16/2012)


    It may be appealing to most developers to directly update the system tables because of the adrenalin rush associated with working directly at the root level, but it is not a recommended approach.

    I've often wondered what additional tasks system sps were doing beyond updating tables and I appreciated the explanation, but I found the above comment to be somewhat silly and condescending.

    I think it's more likely that developers and dbas are striving to avoid the rbar approach that is required when using stored procedures to update system tables one object at a time (that's how I came across this article) versus looking for some sort of a high.

    But who knows, maybe some readers would get an "adrenalin rush" if they could do one efficient set-based insert instead of looping though hundreds of system stored procedure calls (and presumably hundreds of behind-the-scenes cache updates - each superceding the last). But for me it would be more of a lack of that nagging feeling of inefficiency I have every time I find myself writing yet another loop just to call sp_addthis or sp_deletethat repeatedly because SQL Server still doesn't officially support a set based update mechanism.

    Hopefully sp_MSforeachdb and sp_MSforeachtable will soon become "documented" and are a sign that Microsoft recognizes how much busy work it is for us to write all these loops (yes, I know sp_MSforeach is still a loop deeper down, but at least I'm not typing "WHILE etc.").

    Rant over, thanks for reading.

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

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