The DBA
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:
- Installation
- Administration
- Monitoring
- Maintenance
- Securing
- development and design of database strategies
- system monitoring and improving database performance and capacity
- planning for future expansion requirements
- may also plan, co-ordinate and implement security measures to safeguard the database
- Communication skills
- Knowledge of database theory
- Knowledge of database design
- Knowledge about the RDBMS itself, e.g. Oracle Database, IBM DB2, Microsoft SQL Server, Adaptive Server Enterprise,etc.
- Knowledge of Structured Query Language (SQL)
- General understanding of distributed computing architectures, e.g. Client/Server, Internet/Intranet, Enterprise
- General understanding of the underlying operating system, e.g. Windows, Unix, Linux
- General understanding of storage technologies, memory management, disk arrays, NAS/SAN, networking
- General understanding of routine maintenance, recovery, and handling failover of a Database
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)
- Installation, configuration, upgrade, and migration: Although system administrators are generally responsible for the hardware and operating system on a given server, installation of the database software is typically up to the DBA. This job role requires knowledge of the hardware prerequisites for an efficient database server, and communicating those requirements to the system administrator. The DBA then installs the database software and selects from various options in the product to configure it for the purpose it is being deployed. As new releases and patches are developed, it's the DBA's job to decide which are appropriate and to install them. If the server is a replacement for an existing one, it's the DBA's job to get the data from the old server to the new one.
- Backup and recovery: DBAs are responsible for developing, implementing, and periodically testing a backup and recovery plan for the databases they manage. Even in large shops where a separate system administrator performs server backups, the DBA has final responsibility for making sure that the backups are being done as scheduled and that they include all the files needed to make database recovery possible after a failure. When failures do occur, the DBA needs to know how to use the backups to return the database to operational status as quickly as possible, without losing any transactions that were committed. There are several ways the database can fail, and the DBA must have a strategy to recover from each. From a business standpoint, there is a cost to doing backups, and the DBA makes management aware of the cost/risk tradeoffs of various backup methods.
- Database security: Because databases centralize the storage of data, they are attractive targets for hackers and even curious employees. The DBA must understand the particular security model that the database product uses and how to use it effectively to control access to the data. The three basic security tasks are authentication (setting up user accounts to control logins to the database), authorization (setting permissions on various parts of the database), and auditing (tracking who did what with the database). The auditing task is particularly important currently, as regulatory laws like Sarbanes-Oxley and HIPAA have reporting requirements that must be met.
- Storage and capacity planning: The primary purpose of a database is to store and retrieve data, so planning how much disk storage will be required and monitoring available disk space are key DBA responsibilities. Watching growth trends are important so that the DBA can advise management on long-term capacity plans.
- Performance monitoring and tuning: The DBA is responsible for monitoring the database server on a regular basis to identify bottlenecks (parts of the system that are slowing down processing) and remedy them. Tuning a database server is done on multiple levels. The capacity of the server hardware and the way the operating system is configured can become limiting factors, as can the database software configuration. The way the database is physically laid out on the disk drives and the types of indexing chosen also have an effect. The way queries against the database are coded can dramatically change how fast results are returned. A DBA needs to understand which monitoring tools are available at each of these levels and how to use them to tune the system. Proactive tuning is an attitude of designing performance into an application from the start, rather than waiting for problems to occur and fixing them. It requires working closely with developers of applications that run against the database to make sure that best practices are followed so good performance will result.
- Troubleshooting: When things do go wrong with the database server, the DBA needs to know how to quickly ascertain the problem and to correct it without losing data or making the situation worse.
In addition to these basic responsibilities, some DBAs need special skills because of how the database is being used.
- High availability: With the advent of the Internet, many databases that could have been available only during the day are now required to be available 24 hours a day, 7 days a week. Web sites have changed from static, pre-defined content to dynamically created content, using a database to create the page layout at the time a page is requested. If the Web site is available 24x7, so must the underlying database. Managing a database in this environment requires an understanding of which types of maintenance operations can be done online (with the database available to users) and which must be scheduled for a maintenance "window" when the database may be shut down. It also requires planning for redundant hardware and/or software components, so that when one fails, others will keep the total system available to its users. Techniques like online backups, clustering, replication, and standby databases are all tools the DBA can use to ensure higher availability.
- Very Large Databases (VLDBs): As companies have found more and more uses for database technology, they tend to save more data. Also, the type of data stored in databases has changed, from structured data in neat rows and columns to unstructured data such as documents, images, sound files, and even fingerprints. Both trends have the same result: larger databases. Managing a VLDB requires special skills of the DBA. The time required to do simple operations like copying a table can be prohibitive unless done correctly. The DBA needs to understand techniques like table partitioning (Oracle), federated databases (SQL Server), or replication (MySQL) to enable a database to scale to large sizes while still being manageable.
- Data Extraction, Transformation, and Loading (ETL): In data warehouse environments, a key task is efficiently loading the data warehouse or data mart with large volumes of data extracted from multiple existing production systems. Often these production systems have different formats than the standardized definitions in the data warehouse, so data must be transformed (or "cleansed") before loading. Extracting the data may or may not be the DBA's responsibility in a given company, but making sure what is extracted is useful is, and the DBA is a key part of the team.
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.
My manager wanted me to add a dashboard capability which would display dataserver status in "near as real-time that you can make it". I decided to make it using javascript on the browser, to poll our Perl and C shell scripts.
I had just learned a little javascript during the "proof of concept" project - really simple things for input validation primarily. This was about 5 years before jQuery.js, and all the other javascript libraries that exist today, back when javascript code was largely written by hand as the need arose.
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.
Tim Jones
a DBA in the USA