Database Administration (DBA), is a function within the Information Technology (IT) field. But just what does a DBA do?
I've been a DBA since 1986, before that I was a programmer for 8 years. During all that time people regularly ask this question. Probably the reason it nevers seems to be answered is because the DBA role appears differently to different people.
The number one priority for a DBA is, and always has been, to establish and maintain the data integrity for an organization.
Flowing from this prime duty are a braod array of functions that must be performed. Consider Wikipedia's current offering (expand the tabs below), which interestingly mentions data integrity almost as an after thought:
Wikipedia's answer to the DBA question is fairly representative of what I have heard through the years. Given its coming from
Wikipedia, I can see that it may now be perceived as definitive.
I find wikipedia's answer somewhat non-responsive to the question, What does a DBA do?
So I decided to offer a practical answer from my decades of experience.
The job of the DBA is to "provide for the organization's data integrity". This means to protect the data from inappropriate
destruction or loss, to prevent inappropriate access to the data while providing proper access levels to appropriate people and processes for the organization to function well.
The functions a DBA needs to perform to fulfill this duty are as varied as suggested by wikipedia, but really depend on context.
The practical truth is that in any organization there exists many ad-hoc
sub categories of DBA. These categories are usually a reflection of the nature of the organization.
Beyond the sub categories of the various database software being used, there are organizational structures that engender the "subject area DBA", sometimes called a "business DBA" which distingishes from the "technical DBA".
There may also be the DBA that only deals in protecting the meta-data, sometimes called a "data modeler". Then there is the wide variety of skill levels within each category which engender still more categories; the "database engineer", "database developer", and the "support DBA". All these titles, or sub-categories are often spoken of as the DBA.
All the various subcategories hold in common a responsibility to protect the data, but then so does every IT professional have responsibilities to protect and defend the data - indeed every member of the organization has some responsibility regarding data integrity. So the answer to the question is actually; it depends on the context of the organization, but it is always to be the organization's "go to" person on matters of data access and protection.
As a "technical DBA", I believe TechRepublic gets it more accurately in their article "What does a DBA do all day?", portions of which are cited below: (expand the tab below)
The above referenced TechRepublic's article manages to suggest some of the contextual nuance I observed over the years, but it also gave prominent consideration to the number one job: "protect the data integrity".
Perhaps the essential "take away" is; job one is to protect the data, but beyond that the DBA is a broadly demanding job which encompasses too many areas to lend itself to a static definition!
But speaking as a "technical DBA", thats the joy of it ;-)
Speaking of Joy
Recently I have been enjoying the pleasures of web development.
Back in the beginning of the century (I know I'm suppose to be old but the joy of my work keeps me young), I was on contract
at a major bank supporting Sybase and Microsoft dataservers. I was one of 6-8 DBAs supporting 900+ databases spread across 120+ servers in various parts of the world (Singapore, New York, London, etc). In addition to my team role, I also had an individual role ( as each of the 3 senior DBAs did).
My individual role was to improve the tools that the DBA team used - hardening the production scripts by enhancement or rewrite and making the overall tools more "usable" with an eye toward improving productivity, especially for those with lower skill levels.
During this process it was determined that providing "upper" management with on-demand visibility was desired. This would be a "proof of concept", skunkworks" effort. So I wrote an intranet web site using classic ASP, with Sybase Adaptive Server on the back end - technologies not of my choosing, simply the resources available at the time.
This produced a functioning "proof of concept", which "upper" management liked alot; they began to seek a similar application to buy but to my knowledge were not able to secure the funds. For those who are not familar with big banks, you should be aware that banks almost never put "skunkwork" applications in production.
I did enjoy the complexity of pulling all the disparate scripts and data together, as this was necessary work to improve productivity and it significantly reduced the number of database emergencies which often generated chaos as well as sleepless nights for the DBA team. The production of the user interface on the browser was also enjoyable, even though classic ASP was on its way out.
JSON as a concept was written about in a tech rag, and I decided to employ that concept for exchanging data over the wire. It was another fun "side project" in which I learned alot, while the DBA side was beginning to get very busy.
The DBA staff was dimishing because of job attrition so I had to fill in the holes of support, moreover I was tapped to be the lead DBA implementing a new stock trading system in Microsoft SQL server
The stock trading application was being implemented in 2 main phases. After phase 1 was completed I had more free time to finish the dashboard, which worked better than I had hoped. But my direct manager was now leaving, and there was a general organizational shift taking place (it happens regularly in big banks) causing still more chaos in the DBA group.
With the management changeover finished I was induced to leave the DBA team and work in development side of the shop on phase 2 of the stock trading application. So now I was a "development DBA", though the "title" they gave me was "Environment Manager". Phase 2 implementation went well; implemented on time and on budget.
In describing these aspects of that particular DBA contract/job, you'll notice I was quite busy and barely mentioned the "standard" DBA work, I guess because it was standard - kind of like breathing, you just don't say much about it because you just do it without thinking it unusual. But its really the unusual aspects that I enjoy most about being a DBA because its always an opportunity to learn. Learning is what keeps it fun and what keeps me young!
Jumping ahead several years to today. I'm now exploring web development with C#, asp.net, Visual Studio 2013, SQL Server 2008 R2. Developing several databases and a couple of web sites for certain civic organizations - just for the fun of learning.
So thats a little of my story as a DBA. Do you remember the answer to the question; What does a DBA do?
DBA's --> we provide for data integrity and data access. In doing so, we perform a great many tasks!
I hope this little rant offered you more insight into the workings of a DBA.
a DBA in the USA