I caught a short post from Gary Bargsley on LinkedIn that had this quote: “Many people do not believe this is true. If there isn’t a fire to put out, then you are not doing a good job.” He included a repost from Shaik Ashraf with that quote and an image that explains better what things a DBA is doing because they aren’t always busy.
I would say that by busy we think of a DBA as rushed and always trying to fix something that isn’t working well. I’ve certainly walked into operational positions where this was the case. Things weren’t working smoothly or breaking regularly. My phone was always ringing, as I moved from crisis to crisis. For some systems, rebooting them regularly was the fix, not because I didn’t want to determine a root cause and fix them, but because I had too many other priorities. A reboot at least recompiled plans, cleared caches, and got the system working for a few days.
In those environments, it often took me about 6 months to make changes, implement some standards, find root causes and fix them, and change the way others worked. My approach was to find a problem, consider a solution, and present it to others in a rational way with evidence. I could almost always get approval to start making changes. Or I could convince a manager/director to get others to make changes to stabilize the environment.
Almost always.
Not always. And I’ve had a few jobs where things were broken, but everyone else wanted to keep their existing process and keep adding new features/apps/database/etc. and let the DBAs deal with the instability. After all, if I’m working for a salary, does my boss care how much I work? If he/she doesn’t, then I have learned I need to find a new job.
After 6 or so months, I often find that I’ve reached an improvement limit of some sort. There isn’t a lot I can continue to change and fix, usually because of dependencies and a lack of desire by someone else to change. New work can often be built better, but I’ve often found that I have to live with anything else I haven’t been able to change. Even something as simple as adjusting a query can be a problem when the app developers don’t have an incentive to help.
Have you reached an improvement limit in your job? Or maybe you have reached a limit to what you are willing to improve, given the environment in which you work.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
Voice of the DBA 
I often described this as fire-fighting versus fire-prevention. Sometimes one is too busy fighting the fires to get to the point where one can prevent them. It can be exceedingly frustrating.
As for the broken, don’t want to fix part, that’s one of the rare times I used alias. The client was basically creating an audit trail of every update, into the same database. The I/O overheard was atrocious, but they didn’t want to fix it. So I ended up creating a different database on a different set of spindles, aliasing the calls and bam, dropped their I/O by like a 1/2 right there. Immediate improvement. One their Devs should have done years ago, but were too busy creating new “improvements”.
LikeLike
That’s a great improvement. And I like the fight vs prevention. I tend to see it as an investment, but the prevention analogy might resonate more with lots of managers.
LikeLike