A life spent in constant labor is a life wasted, save a man be such a fool as to regard a fulsome obituary notice as ample reward. ~George Jean Nathan
It is impossible to enjoy idling thoroughly unless one has plenty of work to do. ~Jerome K. Jerome
Slow down and everything you are chasing will come around and catch you. ~John De Paola
Back to reality: often problems occur when DBA managers are interested in the following three topics: costs savings, cost saving and cost savings. While rotating them in a round-robin fashion, some do consider in between which one to pick up next. It is not surprising for any DBA to have one of the following incentives for the year to come: automation, efficiency, do more with less, etc.
Very nice indeed but in several cases such extreme requests for perfection and efficiency are a call in the dark for the DBA’s biggest enemy. The Stress.
When Atlas Stumbles: Lessons for Preventing DBA Burn Out by Michael Corey is one of the most interesting articles on the topic one can find online. Let me quote him:
“Lesson 5: Stress is your biggest enemy. The world of the DBA is an incredibly stressful one and it is even worse in smaller organizations. If you have only one DBA, he or she knows that they alone have to keep the database up and running, or the business will stop running. This causes the Atlas Syndrome, named after the Greek myth of the Titan condemned by Zeus to hold up the heavens on his shoulders.”
In his blog, in an article entitled DBA Stress and retaining DBAs, Kirk Brocas says: “I couldn’t agree more with this bit though – Lesson 5”. Me too!
Why is that? How is the DBA profession different than any other? Here is how I see it:
1. Frustration and responsibility: DBAs get often blamed for problems that are beyond their control: “Why is the database slow”? Try to explain that those “additional” Siebel joins on 15 tables are not that easy to tune. Or than putting critical databases on RAC is not always the solution. And how important is to patch in order to avoid and fix the bugs but this somehow does not happen with zero downtime. You explain, explain.. but who believes you is rather unclear. Another thing: a small mistake/typo made by the DBA can bring systems down and cause huge financial losses. And how about arriving late at the party: always called upon after everything has gone wrong rather than before things were started so the DBA could recommend problem avoidance tactics!
Solution: listen very carefully to what the DBAs have to say.
2. Visibility, rewards and recognition: “The best DBA is the invisible one”. I used to hear that years ago. “No news is good news”. Yes but often no visibility and no news leads to no rewards and no recognition. Often DBAs are noticed and there names are in the headlines when downtime occurs or at least when systems are slow/hang.
Solution: give the DBAs the visibility they deserve.
3. On-call and overtime: Most DBAs work day and night. Or at least are available around the clock. I for one am not at all interested in smart phones, iphones, you name the phone. That is after 10.000+ hours of DBA on call. Connect the dots please. Do respect the DBA’s wish to quit on-call duty when enough is enough.
Solution: plan the DBA resources well in advance in order to avoid DBAs snowed with work around you.
4. Communication: all databases are down because of OS patching. Oh, the sysadmins forgot to mention that to the DBA team. Just one more example: have you ever tried to convince someone that having the downtime will probably be cheaper than investing in expensive systems created for infinite availability and zero downtime? Mission impossible!
Solution: as the database is part of every IT application, always involve/inform the DBAs for all incoming IT activities.
5. Fire fighting: no time left for proactive work. Because there are not enough DBAs for supporting all the databases. Or too many changes being constantly made? DBAs tune a system but new build comes to production and then you start tuning from scratch. I am far from pointing fingers to developers but someone must be behind those endless bugs in the database software!
Solution: the DBAs should be *always* involved when planning the new systems.
And finally: DBADD – Database attention deficit disorder. Give a dozen things superficial attention or one thing full & proper attention. Guess which one produces proper fixes and which one produces quick workarounds?
More on the topic:
How Do You Handle the Stress of Being a DBA by Brad M. McGehee
How To Prevent DBA Burnout, Suggestions Anyone by Michael Corey