<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Article Discussions
»
Article Discussions by Author
»
Discuss content posted by Nakul Vachhrajani
»
Never update systems tables directly - a...
11 posts, Page 1 of 2
1
2
»»
Never update systems tables directly - a study in Agent job scheduling
Rate Topic
Display Mode
Topic Options
Author
Message
Nakul Vachhrajani
Nakul Vachhrajani
Posted Sunday, September 16, 2012 4:30 PM
Ten Centuries
Group: General Forum Members
Last Login: Monday, June 10, 2013 6:56 AM
Points: 1,282,
Visits: 1,613
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://beyondrelational.com/modules/2/blogs/77/nakuls-blog.aspx
Be courteous. Drive responsibly.
Follow me on
Twitter:
@nakulv_sql
Google Plus:
+Nakul
Post #1359929
mtassin
mtassin
Posted Monday, September 17, 2012 7:11 AM
Hall of Fame
Group: General Forum Members
Last Login: Today @ 12:17 AM
Points: 3,250,
Visits: 65,579
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
For tips on how to post your problems
Post #1360177
WayneS
WayneS
Posted Monday, September 17, 2012 7:47 AM
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 9:21 PM
Points: 6,388,
Visits: 8,290
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
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
,
How to ask a question
,
Performance Problems
,
Common date/time routines
,
CROSS-TABS and PIVOT tables Part 1
&
Part 2
,
Using APPLY Part 1
&
Part 2
,
Splitting Delimited Strings
Post #1360209
Nakul Vachhrajani
Nakul Vachhrajani
Posted Monday, September 17, 2012 8:09 AM
Ten Centuries
Group: General Forum Members
Last Login: Monday, June 10, 2013 6:56 AM
Points: 1,282,
Visits: 1,613
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://beyondrelational.com/modules/2/blogs/77/nakuls-blog.aspx
Be courteous. Drive responsibly.
Follow me on
Twitter:
@nakulv_sql
Google Plus:
+Nakul
Post #1360229
Nakul Vachhrajani
Nakul Vachhrajani
Posted Monday, September 17, 2012 8:10 AM
Ten Centuries
Group: General Forum Members
Last Login: Monday, June 10, 2013 6:56 AM
Points: 1,282,
Visits: 1,613
Thank-you, all for taking the time out and reading my article. I really appreciate it!
Thanks & Regards,
Nakul Vachhrajani.
http://beyondrelational.com/modules/2/blogs/77/nakuls-blog.aspx
Be courteous. Drive responsibly.
Follow me on
Twitter:
@nakulv_sql
Google Plus:
+Nakul
Post #1360231
Nadrek
Nadrek
Posted Monday, September 17, 2012 8:50 AM
Say Hey Kid
Group: General Forum Members
Last Login: Monday, June 10, 2013 1:08 PM
Points: 679,
Visits: 2,038
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.
Post #1360255
Nakul Vachhrajani
Nakul Vachhrajani
Posted Monday, September 17, 2012 10:14 AM
Ten Centuries
Group: General Forum Members
Last Login: Monday, June 10, 2013 6:56 AM
Points: 1,282,
Visits: 1,613
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://beyondrelational.com/modules/2/blogs/77/nakuls-blog.aspx
Be courteous. Drive responsibly.
Follow me on
Twitter:
@nakulv_sql
Google Plus:
+Nakul
Post #1360309
thisisfutile
thisisfutile
Posted Monday, September 17, 2012 11:00 AM
Valued Member
Group: General Forum Members
Last Login: Friday, June 14, 2013 10:11 AM
Points: 56,
Visits: 492
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.
Post #1360346
BrandonChampion
BrandonChampion
Posted Tuesday, September 18, 2012 4:48 AM
Forum Newbie
Group: General Forum Members
Last Login: Wednesday, April 17, 2013 10:11 PM
Points: 4,
Visits: 65
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.
Post #1360677
Garry.McGibbon
Garry.McGibbon
Posted Thursday, October 04, 2012 2:42 PM
Forum Newbie
Group: General Forum Members
Last Login: Thursday, June 13, 2013 11:57 AM
Points: 4,
Visits: 362
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.
Post #1368724
« Prev Topic
|
Next Topic »
11 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
