“Is it just me or does doing the “typical DBA” tasks like installing, patching, backing up, checking backups, monitoring databases, creating users, checking space and other mundane tasks get boring after doing it for a few years? In the first few years, it was cool since everything was new to me.
Now, 10 years later, only about 4-8 weeks per year are devoted to cool stuff like resolving performance problems and restoring data. I stay up to date with the latest Oracle technology, but I only get to use a small percentage of it and I get to use setup only a few times.
Tom, please advise on how one can get away from doing the typical DBA work to doing other types of DBA work that aren’t seen by the industry as DBA tasks like PL/SQL coding, data modeling, creating solutions with APEX, taking on web server tuning, etc.?”
There is a great deal of debate which follows over what it means to be a DBA, a Developer, a DBA/Developer and a Developer/DBA, but eventually one reviewer submits the following matrix which describes a sliding scale of skills from pure DBA (0) to pure Developer (10):
DBA DEVELOPER SKILLS SKILLS 0: X X X X X X X X X X 1: X X X X X X X X X O 2: X X X X X X X X O O 3: X X X X X X X O O O 4: X X X X X X O O O O 5: X X X X X O O O O O 6: X X X X O O O O O O 7: X X X O O O O O O O 8: X X O O O O O O O O 9: X O O O O O O O O O 10: O O O O O O O O O O
Given this matrix, I thought I would attempt to answer this question in my own way.
John speaks of becoming bored with the more mundane aspects of being a DBA and craves more interesting and creative things to do with his time. This is – in my humble opinion – a potential problem with any job. Even a pure developer can fall prey to this if all they are doing is porting old code to new operating systems or fixing bugs in someone else’s programs. You become trapped at one extreme of the scale or the other, stuck in a niche that can feel impossible to get out of. In my experience, the best way to fight this is to always be on the lookout for ways to make things better than they used to be. The best way to do that is to always be looking for opportunities to expand your skills into the middle of the scale and finding ways to improve your own little corner of the world.
I have been blessed to mostly work in small shops over the years, mostly as a contractor working for someone else. I will be the first to admit that this has afforded me a fair amount of flexibility in my job responsibilities compared to others, but I believe the lesson I learned applies just as well to more limited job descriptions as well. What I found is that in order to do the specific job I was hired to do well, I had to know a fair amount about the job next door as well.
For example: I started my career as a pure developer (the database was definitely a black box for me), but found quickly that in order to do that development work really well I had to know a fair amount about how the database worked too. After a year on the development team I had found a way to leverage the database in such a way that I could reduce the total lines of application code by over 95%, decrease maintenance time for changes from days or weeks to minutes, and improve system performance dramatically. Next thing I know I’m a DBA.
Turns out that what I learned as a developer about writing code helped me be a better DBA because I could create better automation while anticipating both the developer’s needs and their stupid mistakes. Before long I was able to tune disk I/O and memory configurations to increase performance by orders of magnitude. I introduced auditing that improved security and identified previously undetected issues with developer behaviors and software bugs in their tools that were causing unplanned system outages. Then I found out that to be a really good DBA I also needed to understand something of the operating system and storage arrays the database runs on, and the network. Pretty soon I was a system/network administrator.
What I knew about being a DBA helped me be a better sysadmin because I could scope/scale hardware more accurately and configure it more properly for database use. This allowed me to completely rebuild a corporate development and testing data center from scratch. The progression of jobs continued through a couple more layers of the IT industry, but now I’m back to being a production support DBA and I find that all of those other things continue to make me better at that as well: I can converse intelligently about system and network requirements when working through a tech refresh of our infrastructure; build a server, database, and application infrastructure that is highly available and secure on a shoestring budget; monitor and tune my databases and manage storage with ASM; run backups; install patches; create users; and advise developers competently on security and performance considerations because I have all of those other experiences to draw on. More recently I have used those experiences to help a customer rework much of their Oracle and corresponding *NIX infrastructure design into something much more flexible, reliable and secure than they had before.
While opportunities to expand your job role may be harder to come by in a large shop with more separation of duties, my advice would be to always be on the lookout for ways to improve the way you can perform your particular job responsibilities – through new automation, enhanced monitoring or shell scripting, introduction of new hardware or technologies like SSD storage, or whatever else you can think of. Aim for somewhere in that 4-6 range of the DBA/Developer Skills scale and really get to know more about other closely related jobs – even if for no other reason than to understand their requirements or frustrations – and it is hard to go wrong.
Never accept that you’ve learned all there is to learn or get stuck in that “this is the way we’ve always done it” mentality and you’ll never get bored.