back to article Automating repetitive tasks: If it moves, script it

DBAs can often fall into the trap of carrying out repetitive tasks and processes. The good news is that you can automate a lot of these tasks to save time, money, and above all, sanity. The bad news is that few database administrators (DBAs) are doing it. In its 2013 database manageability survey, the Independent Oracle User …

COMMENTS

This topic is closed for new posts.
  1. Longrod_von_Hugendong
    FAIL

    Automate...

    Yourself out of a job, if its easy then any one can do my job.

    No, its wicked complex and only I can do it.

    1. Philip Lewis

      Obligatory XKCD

      http://xkcd.com/1205/

    2. Steve Button Silver badge

      Re: Automate...

      "...Yourself out of a job"

      Wrong wrong wrong. With that attitude you are destined to become less and less valuable and skilled as time goes on. You can stick with your manual boring repetitive processes ... but eventually you'll be replaced by a script.

      Surely you want to be the one writing that script? It makes your job more interesting and productive and allows you to get more stuff done.

      That's the way the wind is blowing, and if you can't smell that then you are already dead (I can't mix in any more metaphors).

      If you aren't already doing DevOps, you are already dead (or mortally wounded) and you just don't know it yet. This is the same principal.

  2. Pete 2 Silver badge

    Speed kills

    > automation can also weed out errors that may creep in

    Automation can also apply the same cocked-up commands to all your databases in the blink of an eye. At least with manual operations, you know something's wrong after you've destroyed the first production instance. It's then possible (maybe even desirable?) to stop and investigate before breaking all the others.

    While I'm a great fan of automation (as previously discussed here), I do realise that it's a "force multiplier" rather than unconditionally good. It can help you do good or bad things much faster. However it's also prone to problems when someone changes something that knocks your automatoin off it's rails (maybe something as simple as changing a password - always hard to automate *and* keep secure) or "fixing" a misspelled table name.

    However automation can free up ones time to allow for more goofing around on IT forums. Sometimes that even gets mistaken for work.

  3. John Smith 19 Gold badge
    Coat

    Log management ?

    I try to keep well hydrated and not have too many heavy curries.

    Oh, that kind of log.

  4. Morten Bjoernsvik

    Learn yourselves a scripting language

    Most dbas I know use scripting, but they are quite simple. Cant be compared to scripts written by devops that dont do anything else. A few days ago I was asked about license for Toad to a new developer. I told him we mainly use the basic command line tools and script in perl/bash/python/powershell what is needed. One of my recent jobs was a cleanout of a overpopulated database with severe lack of bufferspace. I had only a period from 1500to 2400 every day to run deletion and intervalls had to be less than 50k in each commit, otherwhise the production jobs just hanged. Had to add timestamp, scheduler and load monitor modules to the scripts (basic modules in our primary software) and now they run every night to clean data older than 3years and results older than 1 year. That way we can live with an undersized database. I'm a perl developer and added full perldoc with examples so anyone can easily port this to all the other databases we support. Most dbas would probably just use toad or any gui tools and do the job every month, or shut down production to do the cleaning in one go with far less sophisticated scripts. So learn a widely awailable scripting language very well and use it all the time.

  5. Steve Medway

    When your a sysadmin as well as a dba a few bash scripts here and there are essential in almost any dynamic environment.... There have been times when I've automated something 'in case it needs to be done again' even though I've not had the need to run the script a second time.

    I call it 'playing it safe', at least the script will have been properly tested and could be used again if the need arose even if it does take a bit longer to deploy the 'first fix' than dicking around on a live system.

    I always make sure I've documented the potential consequences if dicking around in live systems instead of using a tested scripts.... If something goes wrong the management dick who ordered me to do whatever 'on the fly in live' will get the flak if it goes tits up instead of me.

    Funny thing is that Management always claim that 'script / test / deploy' MUST be adhered to right up until the point their manager is breathing down their back... Bloddy hypocrites springs to mind.

    Panarnoid? No, just looking after my back in environments ran by management type incompetents.

  6. bill 27

    Well gosh! All I can say is DOH.

This topic is closed for new posts.

Other stories you might like