Becoming an “Application DBA”?

Question

I have to admit, until recently I did not know there was such a thing as a "System DBA" and "Application DBA."

Currently, I am an Application/System Admin for a large CMS. I would like to pursue a track/training that would eventually lead to this role of "Application DBA", the ultimate goal being understanding how to best use Apps and DBs together.

Our Apps run on Oracle 10g. I do OK with basic SQL (selects, inserts, updates and can figure out a join or two, etc), but right now most of our DB support (e.g., generating and interpreting AWR reports, etc) is from the System DBA.

I came across several posts that talked about becoming a DBA, but I would appreciate any advice and pointers towards an "Application DBA" role.

Answer 1

You'll want to learn about how different programming languages and frameworks interact with databases. For example in the Java world, many developers use an ORM (Object Relational Mapping) framework called Hibernate, which itself is just an implementation of JPA (Java Persistence API). You'll especially want to get a feel for the SQL that the framework generates.

In particular you'll want to learn about their common performance pitfalls (for example Hibernate is terrible at deleting objects if you use its delete() naively).

You'll want to learn about transactions, in particular how distributed transactions work and how a transaction manager outside of the database can control transactions with in a database. You'll also want to learn about locking mechanisms in languages and how they map to locking mechanisms in databases (e.g. How does a Java Enterprise Edition read optimistic lock on a list of objects translate into a row/table lock in your DB).

You'll want to learn about the difference between design databases for CRUD work and reporting/data warehouse work.

Indexes, indexes, indexes!!

There's a whole heap more, but hopefully that's a start :-)

Answer 2

You could consider getting into Data Warehouses and business intelligence for another couple of ideas that I'd toss out there. These are using large amounts of data for various purposes that may be within the realm you are asking. Another way to think about your question is what would those Applications and DBs be used by organizations or individuals? I'm not sure I've seen "Application DBA" as a term as there are generally a few different areas this could cover:

1. DBA - These are the masters of knowing how to get the best out of a database and deal with production issues as DBs grow. While they are the top dog in a sense, they also have the challenge of dealing with non-technical people that don't understand, "Why doesn't this work faster?"

2. DB Developers - There are some developers that are good at knowing how to hook things into a relational database and optimize stored procedures or how data is stored. This is usually more about creating something new rather than tweaking an existing system though sometimes a developer may be called to make small changes to fix a problem some customer has.

3. Release engineers - There are also those that are responsible for moving code from an environment to environment. These could be what you mean by a "System DBA" to some extent as they know how to run build scripts and make other changes that may be needed as changes are promoted.

In a small company, all of these roles can be done by the same person but in larger companies, roles tend to get specialized, or at least that is my experience.

Answer 3

In larger companies this role tends to be split. In my company the platform DBAs have responsibility for dozens of databases and servers, and know very little about the applications running on them. Most application teams have at least one or two people who are database specialists, but they are part of the development team. So their work will involve database design and analysis. They will also usually manage change - they may not implement the change but they would manage revision control for the database, manage change to lookup tables and other functions. In some shops they would do most of the ETL programming as well - it depends on how much of that work exists.

Because these job descriptions can vary so much, and because the job often has little to do with the job description it can be hard to lay out a career path and its going to differ between companies. Karianna's suggestions are all good things to learn.