Ten Ways To Lose Your DBA Job

  • It's just missing one thing - a disclaimer: "Unless you're a manager." At one job, had to teach all these to the self proclaimed "DBA Specialist." And then had to make hidden backups and recovery measures because when his self proclaimed "Best Practices" (don't confuse these with the normal industry best practices) didn't work and lost data, his employees, who followed directions to the letter, would get in trouble. Questioning his methods was seen as a challenge to his college education (2 semesters).

    Also made many hidden performance improvements. He just assumed the slowdown complaints stopped because people stopped streaming internet movies while running 3D games at work.

    Many thanks to this community and good articles like this. I learned many good techniques from here and "l33ted out" my resume.

    And thanks for letting me blow a little steam off.

  • I use KeePass as my Password Safe. It seems to have more features than the Password Safe you linked to. It also has up-to-date contributed builds for Mac/Linux/Mobile 🙂

  • One more small thing that should get you fired as a DBA: Letting the disk drives on your server get so full that your backups fail!!!  I've seen it happen!! 

    Karen

  • Hi Steve,

    Nice article! Being a one-man DBA/developer in a small company, where nobody really understands what a DBA is/does, an article like this really underlines the usefulness of this website in providing support to all us little guys out in the sticks. A little reality check for when you get carried away writing clever functions and DTS packages. I went through your checklist and am now in 'smug mode' , having managed to put a tick against all these items.

    I think it is essential to have a disaster recovery plan in place, with a description of the systems covered, the backup strategies, and scenarios for all the major failure points, identifying what actions should be taken in each case, and how long it is estimated it will take to restore the service (and what it will cost !). You should also include a list of who is responsible (with their contact numbers). 

    Review the DR plan every few months and make sure it is up to date. Practice the scenarios and keep a log of when you did it for the auditors. I like to include a history of actual failures as well, identifying exactly what went wrong, how it was fixed, and incorporating any lessons learned into the scenarios.

    I reviewed my DR plan recently and identified the requirement for a spare terminal services server to serve our remote offices, as it would take a significant time (during which the remote offices would be cut-off) to build a new one should our existing one fail. Shortly after we installed the new server, the old server failed and we we were able to switch everyone to the new one in a few minutes. As far as the user is concerned, a system is not just the database, it is an 'end-to-end' thing.

    David

    If it ain't broke, don't fix it...

  • Just re-reading my posting, I realise I should amend my signature to 'If it ain't broke, try and break it'.

    I ship logs every 15 mins to a warm start server, with a nightly full backup, and backup all the shipped files to a tape system just to be sure.

    David

    If it ain't broke, don't fix it...

  • I agree - how do I get accross to my management (which is far from stupid about these things) that I need the time / personell to do the 5 out of the 10 we don't get done?

    Roger L Reid

  • Great Article. I just followed a link in an email and wow this article from last year is still very relavant. I asked my director if he knew about dbcc commands (cause I didn't before this article) Good thing he didn't either! If you're a DBA like me go to http://www.sql-server-performance.com/dbcc_commands.asp for an education.

  • Great article..I've got most of the bases mentioned covered, however am a little weak in the tuning area.  This is mostly because in the time I've been here we've mostly bought off-the-shelf applications already professionally developed and tuned.  I've done spot checks here and there with profiler and tuning wizards, etc and not found anything of note.

    However we're in beginning stages of implementation of a application with a backend sql 2005 system that will include a lot of in-house development work by another business unit.   We'll be basking in the glow of that wonderful development/DBA relationship..  So there will be more need for keeping one eye on performance and tuning.  Does anyone have recommendations for a good book to better learn the in's and out's of tuning?

    thx

  • what really needs to be done regarding backups and several other of the issues raised here is documentation what the curent procedures do or do not do, and if they meet internal and external requirements.

  • Great Article!

    One thing I would add:

    You just got a new job as a DBA and inherit a poorly designed/maintained production database (ie NO referential integrity, no use of transactions, anonymous web uses assigned to sysadmin, custom stored procs beginning with sp_, poor backup strategies , etc). So, knowing all that you know, you inform your boss that the system is so bad it should be redesigned completely, and lucky for them, they hired you to change the world starting right away. See how well that blows over.

  • Besides technical skills, I think DBA should have people skills too.  I saw one DBA got fired because he thought he had the best skill set, he was arrogant and no developer wanted to work with him.   The manager began to see him as a baggage instead of an asset.

    One DBA got warning a lot from the manager when he started yelling at the developers when they asked him questions.  Most developers began to avoid him and went to other DBA for help.

  • I have one to add to the list:

    Being able to explain what you did (or need to do) to people who don't know much about database management systems.

    In my past life, I had to make 'suggestions' to developers, managers, consultants, and vendors regarding solutions to performance problems, or security problems, or .....

    Being able to translate the dbms-specific technical ideas into terms these folks could grasp made the sales part of the job a lot easier.  If you can't explain it, it ends up looking like magic, and most humans distrust magic.

     


    And then again, I might be wrong ...
    David Webb

  • Steve,

    Thanks for the article. I am not a DBA but an SMS Administrator. Having a list of what is in essence best practices, gives me the ability to ask the right questions of our DBA's to make sure we're protected in case of a disaster.

    Also, it gives me a list to use of what I can learn about SQL. This list will help put another arrow in my quill (resume).

    Thanks for keeping the article light without losing the urgency of the message.

     

     

     

  • Very nice and original approach.

    I Agree with the article, but still waiting for the complementary one, stating the 10 ways for a DBA to gain a promotion.

    It should be based on the way that the management see the function of the DBA, and the support they get considering Total Cost Management of the IT in the organization.

    I would like to see the DBA that reduce the overall cost of the organizational IT getting promoted. We have to remember that the best way of making the organization more profitable, is by reducing expenses - And management I S aware of it.

    Koby Biller

    Disklace

    (Dealing with fragmentation just for this purpose...)

  • I started reading SQL server 2000 concepts and I am looking for a good future in this area. This article serves to me as a good guidance to secure a job. I din't start working as s DBA but I came to know what can lead me in a miserable position. This has been a wonderful article for me.

    Thanks steve.

Viewing 15 posts - 31 through 45 (of 53 total)

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