SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Craig Outcalt / More Tips for New (and old) DBAs / Latest Posts

RE: More Tips for New (and old) DBAs

dbychen — Mon, 06 Jun 2011 09:00:58 GMT

This is a great article pointing some important areas leading to team work spirit within a DBA team and providing superior professional services to an organization for a DBA team.A DBA team needs to establish proven and consistent procedures to perform support. The purposes for these are to inform the involved parties for a database change to take place, to obtain required responsible parties' approval for a change, and finally to ensure a change to be well integrated into the current application.Any DBA team members who can solve tough architectural and technical problems are certainly great asset for a DBA team. However, heroes building up with "short-cuts", "back-door" practices, and the like are certainly leaving changes without necessary tracking, undesirable for applications of established organizations, and away from team spirits as well.Thanks Craig for your nice article!

RE: More Tips for New (and old) DBAs

SQLBOT — Mon, 06 Jun 2011 07:35:58 GMT

[quote][b]Lee Sloan (6/3/2011)[/b]... what I'm effectively asking for is suggestions of how we significantly improve this, rather than band-aid it.[/quote]I think it comes down to management recognizing issues within their staff and working to address them through training or correction.Many people don't like the idea, but metrics are a way to improve it.If person X closes 150 tickets per month and person Y closes 10, it gives management something to work from other than an anecdotal feeling or a group consensus. I understand (all too well) that not all tickets are created equal, so my oversimplification needs to harness some other value matrix that makes sense for your company.Deriving continuous improvement through measurement is the "next step" in the capability maturity model that many/most places never reach.~Craig

RE: More Tips for New (and old) DBAs

John Mitchell-245523 — Mon, 06 Jun 2011 06:27:32 GMT

[quote][b]Lee Sloan (6/3/2011)[/b][hr]My point may be tangential to the purpose of the article, but it nonetheless is valid: why do we build systems and processes that allow individuals to contribute minimal amounts to the organization? Why should I have to cover for the ineptitude of some colleagues and why should I, as a customer, have to accept poor service as a result of similar ineptitude elsewhere in the organization?The more we pander to this situation the more we promote it. I am pragmatic enough to understand that there are certain realities that need to be catered for in the workplace but what I'm effectively asking for is suggestions of how we significantly improve this, rather than band-aid it.[/quote]LeeIt's not a question of ineptitude or lowest common denominator. If I bypass process in order to provide what appears to the customer to be exceptional service, I am setting expectations that may not be able to be met next time a similar request is made. This may indeed be because other members of the team are lazier or less talented than I am, but it is just as likely that the next person who attempts it (even if it happens to be me again) may not be able to repeat the level of service due to different priorities or workloads.You are right that some people hide behind process, but that in itself is not a reason to do away with process. How to stop this from happening is a discussion that needs to be had, but I don't think that it negates anything that was said in the article.John

RE: More Tips for New (and old) DBAs

el-slo — Fri, 03 Jun 2011 16:55:09 GMT

[b]venoym[/b]My point may be tangential to the purpose of the article, but it nonetheless is valid: why do we build systems and processes that allow individuals to contribute minimal amounts to the organization? Why should I have to cover for the ineptitude of some colleagues and why should I, as a customer, have to accept poor service as a result of similar ineptitude elsewhere in the organization?The more we pander to this situation the more we promote it. I am pragmatic enough to understand that there are certain realities that need to be catered for in the workplace but what I'm effectively asking for is suggestions of how we significantly improve this, rather than band-aid it.

RE: More Tips for New (and old) DBAs

Jeff Torres — Fri, 03 Jun 2011 08:44:02 GMT

Craig,You are welcome. I look forward to your next article.Jeff "Woody" Torres

RE: More Tips for New (and old) DBAs

SQLBOT — Fri, 03 Jun 2011 08:17:58 GMT

[quote][b]Jeff Torres (6/3/2011)[/b][hr]Craig,I have enjoyed reading the articles you submitted. I have read all four of the articles you posted on SSC and I would like to encourage you to continue. You have a very readable writing style and the content has sound advice that is very applicable for today's DBAs. Have you published any books? I would be interested in reading more of you insightful advice to help me become a better DBA. Thank you for your contributions to our society. Best regards.Jeffrey "Woody" TorresSQL DBA\BI Developer :-)[/quote]Thanks, Woody. I appreciate the encouragement.I've been getting the bug to write about a few different things but have been short on time.You might have just given me the nudge I needed.Thanks again!

RE: More Tips for New (and old) DBAs

venoym — Fri, 03 Jun 2011 07:12:37 GMT

[quote][b]Lee Sloan (1/14/2009)[/b][hr][b]SQLBOT[/b] with respect, I think you miss my point. What I'm trying (and obviously failing) to say is that the advice points toward setting the processes at the ability of the lowest common denominator. But if the lowest common denominator is useless then perhaps a more effective strategy is to get rid of them and employ a team that can do the job required.The IT industry seems to be populated by far too many people whose only notable ability is to read a step-by-step process manual and to hide behind those processes when they reach the limit of their intelligence, using phrases like "we have processes in place to best serve the organization". Sounds more like processes in place to best keep their jobs if you ask me.These people seemingly have no idea about thinking around a problem and developing proper solutions, or indeed servicing customers - many of whom probably have better ideas about fixing the problem than they do. I guess this is the problem with working in an industry where too many people have in the past seen an opportunity to make a quick buck. To be clear though, I do fully agree with you that solutions and processes should be properly documented to protect corporate knowledge. That is just common sense.[/quote]I believe that the point you made is at a tangent to the purpose of the article. The article is primarily about working [i]within[/i] the culture you are given, not changing personnel. If you have the power to replace 5 "useless" members of the OS team as a junior level DBA, your organization has many more problems that the issues laid out in the article. Teamwork means you work together as a team to, at a minimum, hit the standards laid out and then exceed them so that the bar can be set higher for [i]everyone[/i] on the team. If you set the bar too high you create a very bad reputation for the entire team because some can't, or won't, make the jump. I think you misread his context about setting the bar. You don't set it low and then [i]only[/i] meet it, you keep resetting it higher as everyone on your team jumps it every time.

RE: More Tips for New (and old) DBAs

Jeff Torres — Fri, 03 Jun 2011 01:33:46 GMT

Craig,I have enjoyed reading the articles you submitted. I have read all four of the articles you posted on SSC and I would like to encourage you to continue. You have a very readable writing style and the content has sound advice that is very applicable for today's DBAs. Have you published any books? I would be interested in reading more of you insightful advice to help me become a better DBA. Thank you for your contributions to our society. Best regards.Jeffrey "Woody" TorresSQL DBA\BI Developer :-)

RE: More Tips for New (and old) DBAs

Christian Buettner-167247 — Fri, 12 Feb 2010 05:21:41 GMT

Great Article!Regarding the "just say no" - I think this is a good general baseline.But I also think this problem mostly arises when the service level and / or job description is not defined well enough and therefore leaves too much room for interpretation.And instead of saying no, it makes sense to forward the "unofficial request" to the manager and let him/her sort it out or at least give advice.

RE: More Tips for New (and old) DBAs

el-slo — Wed, 14 Jan 2009 17:08:50 GMT

[b]SQLBOT[/b] with respect, I think you miss my point. What I'm trying (and obviously failing) to say is that the advice points toward setting the processes at the ability of the lowest common denominator. But if the lowest common denominator is useless then perhaps a more effective strategy is to get rid of them and employ a team that can do the job required.The IT industry seems to be populated by far too many people whose only notable ability is to read a step-by-step process manual and to hide behind those processes when they reach the limit of their intelligence, using phrases like "we have processes in place to best serve the organization". Sounds more like processes in place to best keep their jobs if you ask me.These people seemingly have no idea about thinking around a problem and developing proper solutions, or indeed servicing customers - many of whom probably have better ideas about fixing the problem than they do. I guess this is the problem with working in an industry where too many people have in the past seen an opportunity to make a quick buck. To be clear though, I do fully agree with you that solutions and processes should be properly documented to protect corporate knowledge. That is just common sense.

RE: More Tips for New (and old) DBAs

SQLBOT — Wed, 14 Jan 2009 15:38:28 GMT

[quote][b]Lee Sloan (1/13/2009)[/b][hr][quote]We define our levels of service at an organizational level to ensure that everyone can clear the bar every time[/quote]Hmmm... that sounds suspiciously like we need to cover for people in the organisation that don't know what they're doing. Mind you, since only about 25% of people that work in IT do actually know what they're doing I guess we shouldn't rock the boat, should we? Seems to contradict the point made that teams need "to hear about their mistakes if they are ever to learn from them". IMO, if useless members of staff could be identified because they were not allowed to hide behind organisational process then we would really create winning organisations.[/quote]I don't believe that is a contradiction.Process development and process improvement are two sides of the same coin.Say you have an uninformed Windows team that reboots whenever they want to.... let them hear about it so that they can develop a process that EVERYONE on their team (not just the "good ones") can follow so there is a consistency in service. This is what I'm meaning with my comments.It also follows my "no heroes" philosophy from the first article.~BOT

RE: More Tips for New (and old) DBAs

Anipaul — Wed, 14 Jan 2009 08:54:48 GMT

Excellent advice...:)

RE: More Tips for New (and old) DBAs

el-slo — Tue, 13 Jan 2009 20:14:07 GMT

[quote]We define our levels of service at an organizational level to ensure that everyone can clear the bar every time[/quote]Hmmm... that sounds suspiciously like we need to cover for people in the organisation that don't know what they're doing. Mind you, since only about 25% of people that work in IT do actually know what they're doing I guess we shouldn't rock the boat, should we? Seems to contradict the point made that teams need "to hear about their mistakes if they are ever to learn from them". IMO, if useless members of staff could be identified because they were not allowed to hide behind organisational process then we would really create winning organisations.

RE: More Tips for New (and old) DBAs

Anam Verma — Tue, 13 Jan 2009 19:13:28 GMT

interesting article with bonus of knowledgable discussion. keep it up mates.

RE: More Tips for New (and old) DBAs

Steve Jones - SSC Editor — Tue, 13 Jan 2009 07:46:25 GMT

Great job, and good advice for all types of DBAs.

RE: More Tips for New (and old) DBAs

Derek Dongray — Tue, 13 Jan 2009 07:34:08 GMT

Excellent article!The first two recommendations probably apply to anyone providing a service (which is probably most people!). I've known far to many situations where being asked for someone resulted in focussing on [b]how[/b] to do it rather than [b]whether[/b] to do it - particularly if it's an interesting technical challenge! :) This naturally leads to the 2nd recommendation of "Just say No!" once you've considered the "whether" aspect and concluded that, although you can, you shouldn't!I also agree with others that admin tasks are one of the areas where cursors make things clearer and the benefits of saving a few microseconds in executing the batch are often totally outwieghed by the execution of the action.

RE: More Tips for New (and old) DBAs

peter-757102 — Tue, 13 Jan 2009 04:44:16 GMT

I like the article, especialy the part about saying NO. While I don't like the rigid attitudes it is a valuable instrument that usually pays off. It helps to think twice (or even three times) and do some verifying before going for a "solution".From the angle of a developer I have to deal with such situations quite often and wihout the backing of management supported established procedures. I learned to say NO as a way so get people to think before they leap and assign myself a part of the design process as a final sanity/quality check before implementing "solutions". Often I end up with a better alternative on my own once the goal of the change is well expressed (this as I see it, is my real job too).In practice functional oversight or sudden new requirements for a running application quickly translate in cases that need to be implemented fast. Decissions are made by people without any knowledge of application development nor full awareness of the application and existing data in particular.If I would simply follow every request, things would turn into an unmanageable mess quite rapidly. Individuals working for customers don't check existing data, designs or the scope of their application, they just want their problems solved. Very often there are no procedures guiding this process, a problem hits one user and suddenly a new project/change request arrises affecting more then initially realised.Few people are asking questions like:1. Does this function really need to be in this (part of the) application (scope issue)?2. Is it worth spending N weeks developing, for just one person while the functionallity is available somewhere else and accessible already?3. What other effects are there on the existing design?4. Do we need to take a step back and redesign part of the application to make it a consistent functional whole again?One could argue that I just have to do what people tell me to, as that is my role (read the previous article). But that is what I ranted against for a reason...with deteriorating quality of design and code due to blind alterations without understanding of the data or scope of the application, my job would become impossible over time. Every additional change would take more time and increase the risk of side effects (resulting in more issues, cycle starts...).Just because a customer doesn't manage his IT and/or organisation well, doesn't mean we have to follow in that practice every time! A requirement for this attitude is however that you gained some experience and know the relevant application and existing data very well.For those not yet at that point, it stil pays off to ask questions and verify what people tell you before proceeding. If you do not you might end up having to repair something you did not fully comprehended in the first place and that means the problem got bigger instead of getting solved.Realize people often only have experience with part of an application. Ask 5 people working with the same application in different roles what the application does and its purpose.You likely get 5 different answers, so be paranoid!

RE: More Tips for New (and old) DBAs

Daniel Smith-480684 — Tue, 13 Jan 2009 02:45:39 GMT

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

RE: More Tips for New (and old) DBAs

GOC-481399 — Mon, 12 Jan 2009 16:37:39 GMT

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.

RE: More Tips for New (and old) DBAs

timothyawiseman — Mon, 12 Jan 2009 11:55:39 GMT

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.

RE: More Tips for New (and old) DBAs

SanjayAttray — Mon, 12 Jan 2009 09:54:23 GMT

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.

RE: More Tips for New (and old) DBAs

SQLBOT — Mon, 12 Jan 2009 08:48:16 GMT

[quote][b]george sibbald (1/12/2009)[/b][hr][quote][b]SQLBOT (1/12/2009)[/b][hr][quote][b]Andy Steinke (1/12/2009)[/b][hr]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.[/quote]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[/quote]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.[/quote]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

RE: More Tips for New (and old) DBAs

george sibbald — Mon, 12 Jan 2009 08:47:21 GMT

[quote][b]Rob Symonds (1/12/2009)[/b][hr][quote]... be prepared to be unpopular with the wrong people! [/quote]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. [/quote]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 themAlso, 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.

RE: More Tips for New (and old) DBAs

Rob Symonds — Mon, 12 Jan 2009 08:32:44 GMT

[quote]... be prepared to be unpopular with the wrong people! [/quote]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.

RE: More Tips for New (and old) DBAs

george sibbald — Mon, 12 Jan 2009 07:58:25 GMT

is it just me or is this thread not appearing in 'active threads' or 'my posts'?

RE: More Tips for New (and old) DBAs

george sibbald — Mon, 12 Jan 2009 07:53:12 GMT

[quote][b]SQLBOT (1/12/2009)[/b][hr][quote][b]Andy Steinke (1/12/2009)[/b][hr]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.[/quote]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[/quote]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.

RE: More Tips for New (and old) DBAs

SQLBOT — Mon, 12 Jan 2009 07:36:15 GMT

[quote][b]Andy Steinke (1/12/2009)[/b][hr]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.[/quote]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

RE: More Tips for New (and old) DBAs

Andy Steinke — Mon, 12 Jan 2009 06:49:24 GMT

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.

RE: More Tips for New (and old) DBAs

Scott Abrants — Mon, 12 Jan 2009 06:18:38 GMT

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.

RE: More Tips for New (and old) DBAs

SuperDBA-207096 — Mon, 12 Jan 2009 05:29:20 GMT

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

RE: More Tips for New (and old) DBAs

george sibbald — Mon, 12 Jan 2009 03:47:28 GMT

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.

More Tips for New (and old) DBAs

SQLBOT — Sat, 10 Jan 2009 11:36:26 GMT

Comments posted to this topic are about the item [B]More Tips for New (and old) DBAs[/B]