January 10, 2009 at 11:36 am
Comments posted to this topic are about the item More Tips for New (and old) DBAs
Craig Outcalt
January 12, 2009 at 3:47 am
Craig, interesting article, particularly the just say no and passing on problems bit. As we all know when there are performance problems the database always gets blamed first, so having to refer on problems once we have checked things out is not uncommon.
On the just say no section, one of our main interview questions is to ask what the interviewee would do if they received a request over the phone to delete data, if they say they would do it and don't start going on about proper change procedures and backout plans we get worried.
Also management backing for refusing ad-hoc requests is needed all the way up the chain. In service companies this is not often forthcoming and someone will eventually cave in to keep the client happy, so you can end up getting it in the ear from both ends. That doesn't mean the DBA should just give in though, its part of the job to protect the data and take the brickbats.
Hopefully you will avoid any pork chops on the cursor comment, 🙂 as DBA housekeeping jobs are probably the one area they are a good way to do things, with the elapsed time being dominated by the dynamic SQL generated (backup,reindex, checkdb) rather than the loop process itself.
---------------------------------------------------------------------
January 12, 2009 at 5:29 am
Nice article!
Lots of good advice, I particularly like the advice about learning T-SQL... and the fact that Cursors have their place, and DBA code is one of the places where it could be ok to use a cursor...
Mark
January 12, 2009 at 6:18 am
Very nicely done and covers some difficult topics - primarily the topic about saying NO. It is just as much of an art, as it is a technical dance, to be an effective DBA and you bring that to light in this article.
January 12, 2009 at 6:49 am
Your organization needs to suppoort saying no; it's easy to say this from an ivory tower perspective but you have to have management and executive support. At some companies the culture simply is that you will do what you need to do to help. If you try to single handedly change this without the power to do it (and DBAs are often staff, not management) it can adversely affect your career.
However, the article was spot on in general. A DBA needs to think before the perform any task and that seems to be the main message, one that is often difficult for junior DBAs to pick up. Part of the value a DBA provides is adding the extra filter and layer of protection to the systems.
January 12, 2009 at 7:36 am
Andy Steinke (1/12/2009)
Your organization needs to suppoort saying no; it's easy to say this from an ivory tower perspective but you have to have management and executive support.
This is very true and in the case where management support does not exist, a case needs to be made to get the attitudes, procedures and culture shifted. By not supporting production stability and strongly defined processes the organization is stunting its capabilities (and may not know it).
Thanks for your comments!
~BOT
Craig Outcalt
January 12, 2009 at 7:53 am
SQLBOT (1/12/2009)
Andy Steinke (1/12/2009)
Your organization needs to suppoort saying no; it's easy to say this from an ivory tower perspective but you have to have management and executive support.This is very true and in the case where management support does not exist, a case needs to be made to get the attitudes, procedures and culture shifted. By not supporting production stability and strongly defined processes the organization is stunting its capabilities (and may not know it).
Thanks for your comments!
~BOT
couldn't agree more, but be prepared to be unpopular with the wrong people! So this is not a task that should be left to a junior DBA.
---------------------------------------------------------------------
January 12, 2009 at 7:58 am
is it just me or is this thread not appearing in 'active threads' or 'my posts'?
---------------------------------------------------------------------
January 12, 2009 at 8:32 am
... be prepared to be unpopular with the wrong people!
Some people say no and couldn't get the right people to stand behind them or support them even if they offered gifts and bribes. Some people however can say no and everybody lines up behind them to support their decision, regardless of whether management support currently exists or not. We've all seen this.
In my experience it's not a matter of having a good argument. You can talk X + Y = Z all you want but it rarely persuades. It's something else. I have some ideas. But I'm curious to see what other people think.
January 12, 2009 at 8:47 am
Rob Symonds (1/12/2009)
... be prepared to be unpopular with the wrong people!
In my experience it's not a matter of having a good argument. You can talk X + Y = Z all you want but it rarely persuades. It's something else. I have some ideas. But I'm curious to see what other people think.
gut reaction - if the management do not understand the technical issues or do not have respect for technical people per se, they are less likely to support them
Also, if they want to appear proactive to the client trying to circumvent procedures, it's easier to kick your own people. i.e. its a cop out.
---------------------------------------------------------------------
January 12, 2009 at 8:48 am
george sibbald (1/12/2009)
SQLBOT (1/12/2009)
Andy Steinke (1/12/2009)
Your organization needs to suppoort saying no; it's easy to say this from an ivory tower perspective but you have to have management and executive support.This is very true and in the case where management support does not exist, a case needs to be made to get the attitudes, procedures and culture shifted. By not supporting production stability and strongly defined processes the organization is stunting its capabilities (and may not know it).
Thanks for your comments!
~BOT
couldn't agree more, but be prepared to be unpopular with the wrong people! So this is not a task that should be left to a junior DBA.
One thing to remember is that changing attitudes and opinions is a sales job, I've had it take years to change minds of management and it doesn't need to be confrontational or make you unpopular if you chip away at the stone wall they have built around their paradigms. Post-mortems of production problems is a great time to bring up change if lack of good processes caused the outage. Management is typically reactive and also rational. Eventually good processes sell themselves as long as you advertise at the right time.
It also might not hurt to get a consultant to come and look at processes and standards. Management will listen to a consultant when they've stonewalled the exact same advice from staff for years. It's unjust and frustrating, but realize that management has its processes for decision making, and getting an outside opinion is part of that process sometimes.
~BOT
Craig Outcalt
January 12, 2009 at 9:54 am
From various projects what ever I had learned, the most important thing is the say " NO " very diplomatically. First I use to say " NO " very bluntly but after getting fired from one project I learned to say NO convincingly.
Most of the time person who knows some SQL Server technically would understand it but a person in upper hierarchy in management would never understand it and all he expect from everyone is a big YES.
SQL DBA.
January 12, 2009 at 11:55 am
Awesome article, especially the part at the end.
One things that might be worth pointing out is that while there are genuinely good times to use cursors, most of the time you can take things that look like they require a loop and do it in pass. If you are generating dynamic sql for instance it is often possible to use a select statement that generates all the commands at once and then just pass that as a batch to an exec statement instead of looping through.
Also, it is sometimes it is worth putting some of that logic inside a different language, such as C# or python, that connects to SQL Server instead of doing it all in T-sql scripts.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
January 12, 2009 at 4:37 pm
Closely related to the concept of saying "no" effectively, is the concept of saying "yes" realistically. I have seen countless instances where DBAs and similar IT professionals will commit in meetings to timelines that seem OK at first glance, but when considered in context of other planned and unforeseen work, cannot be met.
The reason this is so prevalent is, in my view, related to a "problem avoiding" psychology. Many people want to avoid being seen as unhelpful. In a meeting situation where your boss and other bigwigs look imploringly at you to come up with the goods, it can be awfully hard to commit to four weeks instead of two.
The best DBA I know often comes across as difficult in meetings because he doesn't like giving an answer on the spot. But his deadlines once set, are nearly always met, and he generally delivers what he commits to.
January 13, 2009 at 2:45 am
I just wanted to add my thanks for a well-written article. I didn't quite agree with it all, since rigidity can be just as detrimental to an organisation as complete flexibility (although to be fair to you I know you addressed this). In some cases I found myself sympathising with the junior DBA who is trying 'to do a good job' and impress people. I suppose the important thing for the junior DBA to do is to ask a senior DBA, who would point out the consequences of an action.
As regards saying 'no' you are spot on. If there are clear and sensible reasons then you should never be afraid to say no. Besides if you say 'yes' all the time people start to expect it, and then you can never surprise them!:D
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply