Every organization that manages data using a database management system (DBMS) requires a database administration group to ensure the effective use and deployment of the company’s databases. And since most modern organizations of every size use at least one DBMS, the need for database administrators (DBAs) is greater today than ever before. However, the discipline of database administration is not well understood or universally practiced in a coherent and easily replicated manner.
There is a frequently repeated joke about database administration that helps to underscore both the necessity for DBA and lack of understanding of the DBA function. It goes something like this:
The CIO of Acme Corporation hires a management consulting company to help them streamline their IT operations. The consultant, determined to understand the way Acme works, begins by interviewing the CIO. One of the questions he asks is “So, I see that you have a DBA on staff; what does he do?”
The CIO says “Well, we use Oracle and I’m told that we need the DBA to make sure our Oracle databases stay online. I know that some of our critical business processes like order entry and inventory use Oracle, but I really don’t know what the DBA does,” says the CIO. “But please don’t tell me I need another one because we can barely afford to pay the one we have!”
This is a sad, but too often true, commentary on the state of database administration in many organizations. Frequently the DBA is viewed as a guru or magician who uses tricks to make databases and systems operate efficiently. DBMS software is so complex these days that very few people understand more than just the basics (like SQL). But DBAs understand the complexities of the DBMS, making them a valuable resource. Indeed, sometimes the only source of database management and development knowledge within the organization is the DBA.
The role of the DBA is as the guardian of the data as a corporate asset. So DBAs, in trying to protect the data, often are perceived as slow moving and risk adverse. Developers, on the other hand, are charged with building new applications and are constantly being challenged to build things fast and move on to the next project. Obviously, the difference between these two roles and expectations—with DBAs saying “change control, change management” and developers saying “deploy it now, deploy it now”—can create friction.
Another frequent criticism of the DBA staff is that they can be difficult to deal with. Sometimes viewed as prima donnas, DBAs can be curmudgeons who have vast technical knowledge but limited people skills. Just about every database programmer has a favorite DBA story. You know, those famous anecdotes that begin with “I have a problem . . .” and end with “. . . and then he told me to stop bothering him and read the manual.” DBAs simply do not have a “warm and fuzzy” image. This probably has more to do with the nature and scope of the job than anything else. The DBMS spans the enterprise, effectively placing the DBA on call for the applications of the entire organization.
The fact that DBAs often must sit down and work things through on their own can be a mitigating factor in this poor reputation. Many database problems require periods of quiet reflection and analysis to resolve. So DBAs do not generally like to be disturbed. But even though many problems will require solitude, there are many other problems that require a whole team to resolve. And due to the vast knowledge most DBAs possess, their quiet time is usually less than quiet; constant interruptions to answer questions and solve problems is a daily fact of life.
DBAs should not be encouraged to be antisocial. In fact, DBAs should be trained to acquire exceptional communication skills. Data is the lifeblood of computerized applications. Application programs are developed to read and write data, analyze data, move data, perform calculations using data, modify data, and so on. Without data there would be nothing for the programs to do. The DBA is at the center of the development life cycle—ensuring that application programs have efficient, accurate access to the corporation’s data. As such, DBAs frequently interface with many different types of people: technicians, programmers, end users, customers, and executives. However, many DBAs are so caught up in the minutiae of the inner workings of the DBMS that they never develop the skills required to relate appropriately with their coworkers and customers.
But we have not yet answered the question that is the title of this chapter: What is a DBA? The short answer to that question is simple: A DBA is the information technician responsible for ensuring the ongoing operational functionality and efficiency of an organization’s databases and the applications that access those databases.
The long answer to that question requires a book to answer – and I wrote one, which you can buy through amazon at this link: Database Administration: The Complete Guide to DBA Practices and Procedures. The book defines the management discipline of database administration and provides practical guidelines for the proper implementation of the DBA function. So if you are looking for more details, consider picking up a copy of Database Administration: The Complete Guide to DBA Practices and Procedures.