Why Learn Database Administration?

Data is at the center of today's applications; today's organizations simply cannot operate without data. In many ways, business today is data. Without data, businesses would not have the ability to manage finances, conduct transactions, or contact their customers. Databases are created to store and organize this data. The better the design and utility of the database, the better the organization will be positioned to compete for business.

Indeed, one of the largest problems faced by IT organizations is ensuring quality database administration. A survey of IT managers conducted by Information Week in December 2000 showed that the top two database management execution issues faced by companies are ease of administration and availability of qualified administrators.

Both of these issues were cited by 58% of survey respondents. Additionally, the 1999 Market Compensation Survey conducted by people3, a Gartner Company, shows that DBA positions take longer to fill than any other position. Clearly, there is no lack of demand for DBA skills in today's job market.

A Unique Vantage Point

The DBA is responsible for designing and maintaining an enterprise's databases, placing the DBA squarely at the center of the business. The DBA has the opportunity to learn about many facets of business and how they interrelate. The DBA can explore groundbreaking technologies as they are adopted by the organization. Exposure to new technology keeps the job stimulating—but frustrating if you are trying to figure out how a new technology works for the first time. The DBA is often working alone in these endeavors; he does not have access to additional expertise to assist when troubles arise. Therefore, a good DBA needs to enjoy challenges and be a good problem solver.

DBA Salaries

You can find no more challenging job in IT than database administration. Fortunately, DBAs are well paid. DICE.com, a career planning and research Web site, provides valuable statistics on DBA compensation. For example, database administration is one of the top ten contract jobs when ranked by salary, as well as one of the top ten jobs for full-time employment. The mean compensation for DBA consultants is $81 per hour; the mean level of experience just 4.98 years. For full-time employees with four or more years of experience, the mean salary ranges from the low $60,000s to over $80,000. Figure 1-1 shows the mean salary for full-time DBAs broken down by years of experience.

Another Web site, searchdatabase.com, a portal of database information for IT professionals, conducted a salary survey of database professionals. As of late January 2001, the average annual salary for all database professionals was more than $62,000. As might be expected, as the years of experience and the number of people managed increases, so does the salary. Of course, DBA salaries, as with all salaries, vary by region of the country. In the United States, DBA salaries are usually higher in the Northeast and on the West Coast than in other regions.

So, DBAs are well paid, have challenging jobs, and are likely to be engaged in the most visible and important projects. What's not to like? Well, DBAs are expected to know everything, not just about database technologies, but about anything remotely connected to them. Database administration is a nonstop job, and DBAs work long days with lots of overtime, especially when performance is suffering or development projects are behind schedule. DBAs frequently have to work on weekends and holidays to maintain databases during off-peak hours. A DBA must be constantly available to deal with problems, because database applications run around the clock. Most DBAs carry pagers or cell phones so they can be reached at any time. If there is a database problem at 2:00 A.M., the DBA must get out of bed, clear his head, and solve the problem to get the applications back up and running. Failure to do so can result in database downtime, and that can completely shut down business processes. DBAs frequently spend weekends in front of the computer performing database maintenance and reorganizations during off peak hours. You can't bring mission-critical databases down during the nine-to-five day to maintain them. According to industry analysts at the META Group, the average DBA works more than fifty hours per week, including an average of six hours on weekends.

So, database administration is technically challenging and rewarding; it can also be exhausting and frustrating. But don't let that scare you. The positive aspects of the job far outweigh the negative.

Database Technology

This book assumes a basic knowledge of relational database technology and DBMS fundamentals. For readers needing to review these concepts, please refer to Appendix 1. This is not a trivial matter; people sometimes think they know more than they actually do. For example, what is a database? I'll bet most readers believe they know the answer to that question. However, some (perhaps many) of you would be wrong. Oracle is not a database; it is a database management system. You can use Oracle to create a database, but Oracle, in and of itself, is not a database.

So, what is a database? A database is an organized store of data wherein the data is accessible by named data elements (for example, fields, records, and files). And what is a database management system? A DBMS is software that enables end users or application programmers to share and manage data. It provides a systematic method of creating, updating, retrieving, and storing information in a database. A DBMS is also generally responsible for data integrity, data security, data access control and optimization, automated rollback, restart, and recovery. Figure 1-2 shows the relationship between a DBMS and a database.

You might think of a database as a file folder, and a DBMS as the file cabinet holding the labeled folders. You implement and access database instances using the capabilities of the DBMS. Your payroll application uses the payroll database, which may be implemented using a DBMS such as DB2, Oracle9i, or SQL Server.

Why is this important? If we don't use precise terms in the workplace, confusion can result. And confusion leads to over-budget projects, improperly developed systems, and lost productivity.

In addition to database management fundamentals, DBAs must be experts in the specific DBMS in use, and there may be many in the organization. For example, a large organization might use DB2 on the mainframe, Oracle and Informix on several different UNIX platforms, and SQL Server on Windows 2000. Older legacy systems might use IMS databases, and then there is that one crazy application out there that uses a fringe DBMS like Adabas or Ingres1

The DBA group, therefore, must have expertise in each of these different management systems and platforms. Furthermore, the DBA must be capable of determining which DBMS and platform is best suited to the needs of each application. This can be a difficult job fraught with politics and conflicting opinions. The DBA group must be able to act impartially and implement decisions based on the best fit of application, DBMS, and platform.

Once again, for a short introduction to DBMS concepts, refer to Appendix 1.

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:

Full article...