From Craig Mullins' Database Administration: The Complete Guide to Practices and Procedures, Addison Wesley Professional; ISBN: 0201741296; 1st edition (June 14, 2002).

Part 1  |  Part 2  |  Part 3  |  Part 4  |  Part 5  |  Part 6

Every organization using a database management system (DBMS) to manage data requires a database administration group to ensure the effective use and deployment of the company’s databases. Since most modern organizations of any size use a DBMS, the need for a database administrator (DBA) is greater today than ever before. However, the discipline of database administration is neither well understood nor universally practiced in a coherent and easily replicated manner.

The DBA: Revered or Reviled?

An oft-repeated story about database administration underscores both the necessity for database administration and the lack of understanding of a DBA’s function. It goes something like this:

The CIO of Acme Corporation hires a management consulting company to streamline their information technology (IT) operations. The consultant, determined to understand the way Acme works, begins by interviewing the CIO. One of his first questions is: “So, I see that you have a DBA on staff. What does he do?”

The CIO replies, “Well, 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. 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. DBMS software is so complex these days that very few people understand more than just the basics (like SQL). However, 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 DBA, often respected as a database guru, is just as frequently criticized as a curmudgeon with vast technical knowledge but limited people skills. Just about every database programmer has his or her favorite DBA story. You know, those anecdotes that begin with “I had 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. However, this perception probably has more to do with the nature and scope of the job than with anything else. The DBMS spans the enterprise, effectively placing the DBA on call for the applications of the entire organization.

The truth is, many database problems require periods of quiet reflection and analysis for the DBA to resolve. Therefore, DBAs generally do not like to be disturbed. However, due to the vast knowledge most DBAs possess (the guru, again), their quiet time is usually less than quiet; constant interruptions to answer questions and solve problems is a daily fact of life.

DBAs, more than most, need 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 to their coworkers and customers.

However, we have not yet answered the question: What is a DBA? The short answer 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—this book. This text will define the management discipline of database administration and provide practical guidelines for the proper implementation of the DBA function. ongoing operational functionality and efficiency of an organization’s databases and applications.

The Management Discipline of Database Administration

Database administration is rarely approached as a management discipline. The term discipline implies a plan, and implementation according to that plan. When database administration is treated as a management discipline, the treatment of data within your organization will improve. It is the difference between being reactive and proactive.

All too frequently, the DBA group is overwhelmed by requests and problems. This ensues for many reasons, such as understaffing, overcommitment to supporting new (and even legacy) application development projects, lack of repeatable processes, or lack of budget. The reactive DBA functions more like a firefighter than an administrator; he attempts to resolve problems only after problems occur. The reactive DBA is focused on resolving the biggest problem confronting him.

In contrast, the proactive DBA implements practices and procedures to avoid problems before they occur. A proactive database administrator develops and implements a strategic blueprint for deploying databases within the organization. This plan should address all phases of the application development life cycle. A data specialist, usually the DBA, should be involved during each phase of the cycle, as shown in Figure 1-3. During the initiation and requirements gathering phase, the DBA must be available to identify the data components of the project. He can help to determine if the required data already exists elsewhere in the organization or if the data is brand new. During the analysis and design phases, the rudimentary data requirements must be transformed into a conceptual and logical data model.

Before development can begin, the logical data model must be translated to a physical database design that can be implemented using a DBMS such as Oracle or DB2. Sample data must be populated into the physical database to allow application testing. Furthermore, the DBA must develop and implement a process to refresh test data to enable repeatable test runs.

When the application moves from development to operational status, the DBA ensures that the DBMS is prepared for the new workload. This preparation includes implementing appropriate security measures, measuring and modifying the storage and memory requirements for the new application, and anticipating the impact of the new workload on existing databases and applications. The DBA is also responsible for migrating the new database from the test environment to the production environment.

While the application is operational, the DBA performs a host of duties including assuring availability, performance monitoring, tuning, backup and recovery, and authorization management. However, no application or database remains static for long. Because business needs change over time, the IT systems that support the business will also change. When maintenance is requested, the DBA becomes engaged in the entire process once again, from requirements gathering to implementation.

Finally, when the application reaches the end of its useful life, the DBA must help to determine the final status of the data used by the application. Is the data no longer required, or do other applications and processes use the data, too? Are there regulations that require the data to be stored longer than the life of the application? Does the business have any privacy policies that impose special rules for handling the data? See the sidebar “Privacy Policies and Data” for further information.

Privacy Policies and Data

The recent bankruptcy of e-business toy seller Toysmart.com provides a good lesson in the impact of privacy policies on corporate data. In May 2000, Toysmart filed for bankruptcy and announced its intention to sell its database of customer information. Toysmart’s customer list was estimated to contain information on 250,000 former customers, including their names, phone numbers, street and e-mail addresses, and product preferences. However, Toysmart’s own privacy policy, previously posted on its Web site, promised that it would not disclose the personal information of its customers to third parties.

The FTC and a group of state attorneys general blocked the sale on the grounds that the sale would violate Toysmart’s privacy policy. They argued that Toysmart’s customers conducted business with Toysmart.com under the conditions of the privacy policy. The court ruling further stipulated that the company had to provide an affidavit describing how the list was destroyed.

This is just one example of how privacy policies can impact database administrators and corporate data experts. Of course, you may never work for a company that goes bankrupt, but your company may decide to retire applications and data due to legal regulations, business conditions, or mergers.

The DBA is responsible for managing the overall database environment. Often this includes installing the DBMS and setting up the IT infrastructure to allow applications to access databases. These tasks need to be completed before any application programs can be implemented. Furthermore, ad hoc database access is a requirement for many organizations.

Additionally, the DBA is in charge of setting up an ad hoc query environment that includes evaluating and implementing query and reporting tools, establishing policies and procedures to ensure efficient ad hoc queries, and monitoring and tuning ad hoc SQL.

As you can see, a good DBA is integral to the entire application development life cycle. The DBA is “in demand” for his knowledge of data and the way in which data is managed by modern applications.

A Day in the Life of a DBA

A day in the life of a DBA is usually quite hectic. The DBA maintains production and test environments, monitors active application development projects, attends strategy and design meetings, selects and evaluates new products, and connects legacy systems to the Web. And, of course: Joe in Accounting, he just resubmitted that query from hell that’s bringing the system to a halt. Can you do something about that? All of this can occur within a single workday.

To add to the chaos, DBAs are expected to know everything about everything. From technical and business jargon to the latest management and technology fads, the DBA is expected to be “in the know.” And do not expect any private time: A DBA must be prepared for interruptions at any time to answer any type of question—and not just about databases, either.

When application problems occur, the database environment is frequently the first thing blamed. The database is “guilty until proven innocent.” A DBA is rarely approached with a question like “I’ve got some really bad SQL here. Can you help me fix it?” Instead, the DBA is forced to investigate problems where the underlying assumption is that the DBMS or perhaps the DBA is at fault, when the most common cause of relational performance problems is inefficiently coded applications.

Oftentimes the DBA is forced to prove that the database is not the source of the problem. The DBA must know enough about all aspects of IT to track down errors and exonerate the DBMS and database structures he has designed. So he must be an expert in database technology, but also have semiexpert knowledge of the IT components with which the DBMS interacts: application programming languages, operating systems, network protocols and products,transaction processors, every type of computer hardware imaginable, and more. The need to understand such diverse elements makes the DBA a very valuable resource. It also makes the job interesting and challenging. If database administration still sounds intriguing to you, read on. Actually, the job isn’t as bad as it sounds. The work is interesting, there is always something new to learn, and, as previously mentioned, the pay can be good. The only question is: Can anyone do this type of job for twenty or more years without needing a rest? And, oh, by the way, I think I hear your pager going off, so you might want to pause here to see what is wrong.

Evaluating a DBA Job Offer

As a DBA, it is almost inevitable that you will change jobs several times during your career. When making a job change, you will obviously consider requirements such as salary, bonus, benefits, frequency of reviews, and amount of vacation time. However, you also should consider how the company treats their DBAs. Different organizations place different value on the DBA job. It is imperative to your career development that you scout for progressive organizations that understand the complexity and ongoing learning requirements for the position. Here are some useful questions to ask:

• Does the company offer regular training for its DBAs to learn new DBMS features and functionality? What about training for related technologies such as programming, networking, e-business, transaction management, message queueing, and the like?
• Does the company allow DBAs to regularly attend local user groups? What about annual user groups at remote locations?
• Are there backup DBAs, or will you be the only one on call 24/7?
• Are there data administration and system administration organizations, or are the DBAs expected to perform all of these duties, too?
• Does the DBA group view its relationship with application development groups as a partnership? Or is the relationship more antagonistic?
• Are DBAs included in design reviews, budgeting discussions, and other high-level IT committees and functions?

The more “yes” answers you get to these questions, the more progressive the DBA environment is.

Next — Database, Data, and System Administration

--

Craig Mullins is an independent consultant and president of Mullins Consulting, Inc. Craig has extensive experience in the field of database management having worked as an application developer, a DBA, and an instructor with multiple database management systems including DB2, Sybase, and SQL Server. Craig is also the author of the DB2 Developer’s Guide, the industry-leading book on DB2 for z/OS, and Database Administration: Practices and Procedures, the industry’s only book on heterogeneous DBA procedures. You can contact Craig via his web site at http://www.craigsmullins.com.