Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

More Tips for New (and old) DBAs Expand / Collapse
Author
Message
Posted Monday, January 12, 2009 8:48 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Friday, January 3, 2014 10:59 AM
Points: 626, Visits: 836
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



Tips for new DBAs: http://www.sqlservercentral.com/articles/Career/64632
My other articles: http://www.sqlservercentral.com/Authors/Articles/Craig_Outcalt/560258
Post #634746
Posted Monday, January 12, 2009 9:54 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, July 17, 2014 10:56 AM
Points: 3,924, Visits: 1,607
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.
Post #634809
Posted Monday, January 12, 2009 11:55 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, April 4, 2014 4:40 PM
Points: 751, Visits: 917
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/
Post #634914
Posted Monday, January 12, 2009 4:37 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, July 11, 2010 5:43 PM
Points: 55, Visits: 224
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.
Post #635118
Posted Tuesday, January 13, 2009 2:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, August 21, 2012 5:26 AM
Points: 34, Visits: 49
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
Post #635232
Posted Tuesday, January 13, 2009 4:44 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, August 7, 2014 4:27 AM
Points: 324, Visits: 2,212
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!
Post #635271
Posted Tuesday, January 13, 2009 7:34 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, February 18, 2014 7:14 AM
Points: 1,344, Visits: 1,983
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 how to do it rather than whether 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.


Derek
Post #635406
Posted Tuesday, January 13, 2009 7:46 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 6:13 PM
Points: 33,198, Visits: 15,341
Great job, and good advice for all types of DBAs.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #635419
Posted Tuesday, January 13, 2009 7:13 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 3:52 PM
Points: 528, Visits: 1,258
interesting article with bonus of knowledgable discussion. keep it up mates.
Post #635952
Posted Tuesday, January 13, 2009 8:14 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, October 1, 2013 10:01 AM
Points: 7, Visits: 41
We define our levels of service at an organizational level to ensure that everyone can clear the bar every time

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.
Post #635975
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse