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.
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 …
"...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.
> 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.
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.
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.