- The DBA: Revered or Reviled?
- Why Learn Database Administration?
- The Management Discipline of Database Administration
- Database, Data, and System Administration
- DBA Tasks
- Types of DBAs
- Staffing Considerations
- Multiplatform DBA Issues
- Test and Production
- New Technology and the DBA
- DBA Certification
- The Rest of the Book
- Review
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
)
Figure 1-3 The application development life cycle
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 semi-expert 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.