Tips for New DBAs

  • Comments posted to this topic are about the item Tips for New DBAs

  • Good article to read, and I'd especially echo this:

    "The scary part about being a new DBA is that you don't know the extent of what you don't know".

    In reality, I believe this also applies to quite a few experienced DBAs.

  • Excellent article. Freshers should read the next version also. Great one Craig...

  • Good article!! I've been the "Hero" DBA and used the documenting route as a way out ... it not only adds to your own knowledge but gives others insight to what it is that DBAs do.

  • Nice article and mirroring other comments, it still amazes me how unaware non-DBA's are (especially if they are aspiring to be DBA's) about the bredth of skills a DBA needs to do the job properly.

    For new DBA's, I would certainly favour them getting the basics covered before they delve into a speciality. Although not covered in the article, I think too much credance is given to 'certification' in deference to the importance of 'experience'. As an analogy, it is relatively easy to pass a driving test, but it takes experience to better judge what to do in a given situation.

    I am keen to see what is covered next time.

  • Well done!

    Documentation is the key to getting out of the 'hero dba' dilemma!

    Mark

  • I've got a hell of a lot of comments to make about this article... but, let me summarize, instead...

    [font="Arial Black"]"Oh... very well done. Should be required reading for everyone in IT." [/font]

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Thank you so much! As a working-at-becoming DBA, I find items like this which as you say are not in the typical documentation immensely useful.

    Toni

  • I apologize in advance for my comments (a little bit), and mean no insult directly at any DBA but...

    Do you ever take a moment and think about how many DBA's go to work every day and work with the most mundane data? Are you aware that not everyone is going to work at the CIA every day? Have ever thought about men and women who are DBAs or workers using SQL Server who count widgets day-in and day-out? This is something that just drives me nuts about some DBAs and some of the authors who and pretend that every byte of data in the world is somehow 'vital' and at risk.

    Consider: I have a buddy who is a DBA for a convenience store company. As he likes to say, he counts Milkbones and the over-blown price for them that you pay when you forget to pick them up during your normal shopping. Yes, instead of 2 dollars at the supermarket, you are going to pay 5 dollars for forgetting them in your weekly shopping. God forbid that Al-Queda ever discover that you, a witless servant of democracy, are getting ripped-off royally should you forget these treats for your dog. My God, the whole great American/European society might come to a stand-still!!!

    I am all for prudence and good habits when it comes to data confidentiality. It should be a given for any DBA. But do we have to keep pretending that every DBA working in the world is somehow working with vital and sensitive data? Hello!!! Guess what - many are not. Many do great work, pay good attention to the tenets of confidentiality and security, and yet process some of the most boring, unsensitive and useless data - like counting widgets. Lord help us if some terror group every finds out that Acme company produced 1,000 extra widgets this month!!! Let alone that they should discover that this month's widget production run included a new 1 millimeter change in the diameter of the widget.

    This is why many DBAs are looked at as overly full of themselves by their co-workers. They puff up their chests in front of the boss, go on for hours about some new security thingy they just implemented, while people in the room scratch their heads wondering what evil force in the world is trying to crack into their systems to figure out how many widgets, or donuts, or Milkbones they are selling each month.

    Sheesh!!! Ever wonder why the world is paranoid?

    ...again, sorry for the rant - but this has to be said in respect for hard working DBAs who are not working with James Bond and MI6 or the CIA.

    There's no such thing as dumb questions, only poorly thought-out answers...
  • i've often felt less of a hero, more of a priest. i'd rewrite the 'hero' tip a little:

    Tip Number Two: No Priests

    I have had the privilege of working with many great DBAs who have used their skills and talents to overcome great challenges, and these are not the priests that I'm talking about. The DBA Priest that I will warn you about is a much more insidious sort. This is the DBA who has tremendous knowledge of source of all knowledge - the RDBMS; This priest has developed and designed all the support systems, processes, routines and rituals. S/he has been in the department long enough to have built relationships with all the customers and management, and has had his or her fingers in most projects. Furthermore, s/he is the ONLY PERSON who has done so. Many of you may be reading this and asking yourself: What's wrong with that DBA? Or: Hey! I'm that DBA!! The problem is not with the DBA, per se. The problem is the dependency which has built up around this one individual.

    What priest systems typically lack is what organizations truly need: Documentation, repeatable processes, managed solutions, and sharable and centralized institutional knowledge. Dependency on a priest can only cripple the efforts of the organization in its efforts to mature.

    As a new DBA, taking steps toward the "no priest" philosophy are some of the most important ones that you can take for yourself and for your organization.

    A great first step for a new DBA would be to volunteer to document the organization's existing processes. This kills two birds with one stone by giving you first-hand knowledge of the documentable processes and also helps the organization to exorcise its dependency on priests.

    the biggest problem you'll have is persuading the rest of the organisation to make the paradigm shift from the roman catholic model to the protestant model.

  • blandry (11/18/2008)


    Are you aware that not everyone is going to work at the CIA every day? ... sorry for the rant - but this has to be said in respect for hard working DBAs who are not working with James Bond and MI6 or the CIA.

    I hope that you realize that the author was not referring to USA's Central Intelligence Agency. You were probably saying this tongue in cheek. 😉

    Paul DB

  • Awesome article. 😎

    Petition

    I wish there was a collection of these articles we could give to newbies. I'm sure that most are already written and just waiting to be grouped. The requirement for admittance could be a need-to-know article with a minimum 4-star rating.

    Paul DB

  • Excellent article. CIA is the main purpose of a DBA.

    All future DBA's and all managers of DBA should read this.

  • sadara (11/18/2008)


    i've often felt less of a hero, more of a priest. i'd rewrite the 'hero' tip a little:

    Tip Number Two: No Priests...

    This kills two birds with one stone by giving you first-hand knowledge of the documentable processes and also helps the organization to exorcise its dependency on priests.

    the biggest problem you'll have is persuading the rest of the organisation to make the paradigm shift from the roman catholic model to the protestant model.

    I found this hilarious! Thanks.

    The most difficult DBA of all is the tribal shaman, with secret knowledge no one can ever divine. IMO the DBA should be a champion of good practices within IT, and a vital part of the team. I appreciate you have a lot of work to do; so do we all. I am a Data Architect, and I will tell you, I am NOT a DBA and there are things I don't know! I work on 4 different RDBMS and there is no way I can match the DBA on system specific knowledge. But I am always eager to learn and I need a solid DBA who will make my designs work, and will work with me when they don't.

    Can't wait to read the rest.

    😎 Kate The Great :w00t:
    If you don't have time to do it right the first time, where will you find time to do it again?

  • Paul DB (11/18/2008)


    Awesome article. 😎

    Petition

    I wish there was a collection of these articles we could give to newbies. I'm sure that most are already written and just waiting to be grouped. The requirement for admittance could be a need-to-know article with a minimum 4-star rating.

    It's my hope that my series can contribute toward this vision.

    Thanks for the kind words, everyone.

    Keep the faith all you SQL Priests, Shamans, Heroes and Legends 😉

    ~BOT

Viewing 15 posts - 1 through 15 (of 65 total)

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