What's a 'Development DBA'?

'What's a Data Warehouse DBA?'

A development DBA looks after the development (and test) databases.

It truly is as simple as that, but depends on the nature of the project you're working on and the attitude and approach of the project managers. I also think the role has changed over time. I'd suggest that when I first started working with Oracle, development DBA roles were good for someone who was training and in their first few years on the job. The reason was simple - you have to be able to trust that your Production DBAs are up to the job, because your critical business systems are dependant on them. If something goes wrong in a development environment, time might be lost, but customers shouldn't be affected directly.

As a result, I concentrated on being a Production DBA for a while. The roles aren't always strictly defined and a lot of sites don't have sufficient DBAs to split the responsibilities in any case, but I enjoyed the high-pressure, big system on-call world of Production support in big companies and (if I'm honest) the associated appreciation and rewards. (I can't say I'm enjoying the call-out this week, but that's for another time)

After a while, though, it occurred to me that I was only using a fraction of my skills because, if you do your job right and configure things well, then what's left to fix should be small intermittent problems with the occasional recovery. Once a system's implemented, things should die down a bit until the next implementation. Massive hardware resources and better tools have also made the job easier. In some cases performance problems are solved by just throwing more money at them.

Feeling bored, I went through a phase of consulting, teaching and development DBA roles. Ah, this felt more like it! The vast majority of developers I worked with didn't seem to have much clue about how to get the best out of Oracle so I could help. Extremely enjoyable.

Then something changed and I suspect a few of the driving forces were

• Greater availability of Oracle information on the internet
• Tom Kyte's Expert One-on-One book. (The reason I mention this book specifically is I know how many developers have come to depend on it as their primary resource. Quite right, too)
• Good DBAs teaching developers about Oracle
• Natural evolution

I'm sure there are tons of other reasons, but the end result was that developers started to understand more about Oracle. That's definitely a good thing. However, it also means that developers often don't see any need to ask for a DBAs help any more and see DBAs as an obstruction. Maybe they have a point some of the time with some DBAs and the lowering of DBA standards hurts us all, but I think they're missing out.

I still see shocking code regularly and developers re-inventing the wheel because they don't know enough about supplied functionality. A little knowledge can be a dangerous thing and I still rarely see evidence of developers who know more about Oracle than the DBAs I work beside, just as I don't know more about Java or C than they do (although I probably know Z80 better ) When things get really difficult, they finally ask for help and most of the time, I hope they go away feeling glad that they did.

Actually, DBAs, that's a good way of creating interesting work for yourself - be good but, most of all, be helpful.

The DBAs? Well, the end result for development DBAs is that, instead of acting in an interesting consulting role as a core part of the development team with some design responsibility and improving the skills of the entire team, they're reduced to constant test environment refreshes, restoring 'backups' (otherwise known as exports - snigger) and running schema alteration scripts. They've become highly-paid operators with the neccessary privileges to follow the developer's strict instructions. On top of that, because they're excluded from the process, they know virtually nothing about the application and so it's easy for them to come across as stupid.

Don't get me wrong, there are some interesting development DBA roles. Guess where most of those are? Yep, Data Warehouses again, and I've worked in that role a few times, on the DW team rather than as part of the DBA team. It's a compliment to DW development teams - they know that the most important factor is skilled Oracle people and the development/designer/DBA roles start to blur into one. On all development projects there are likely to be some interesting problems to deal with. It depends on the complexity of the project and these things aren't black and white.

So, it's taken a while, but it's starting to dawn on me. Being a DBA really is the lowest of the low these days, isn't it? I make a point of saying 'DBA' in my signature file because I thought it was the most senior Oracle role you could perform. I thought I was the guy in the company who knows Oracle, acting as a consultant, designer, architect and has the biggest extinguisher when the big fire is ablaze. But I'm not, am I? I'm just some bloke who obstructs the legitimate activities of star development teams while waiting for an export to finish. (Actually, at the moment I don't because I'm on the Production team, but you get my drift.)

Sure, there's a bit of selfishnes and sour grapes about this, but I can't help thinking that we're all losing out here. I end up having work thrown at me that I could teach a trainee to do, which is a waste of my talents, and the development team's Oracle skills might be 'good enough' but could be so much better.

<sigh />

I think I'm going to have to start calling myself a RAC consultant or a Data Warehouse DBA

Shrek's blog title says it all. (I'm due to update my blog-roll soon)

Here are some very sensible words in the same vein from Stephen Barr.