A Good DBA Should be a Jack-of-all-Trades

A good DBA must diversify instead of just focusing narrowly on the database management system. He or she must become a Jack-of-All-Trades.

You can’t just master one thing and be successful in this day-and-age. 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 even the DBA) is at fault, when the most common cause of performance problems in database applications is inefficient or improper program code.

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.

Getting to the heart of the matter, a DBA has to diversify. Why?

Databases are at the center of modern applications. If the DBMS fails, applications fail, and if applications fail, business can come to a halt. And if business comes to a halt often enough, the entire business can fail. Database administration is therefore critical to the ongoing success of modern business.

Databases interact with almost every component of the IT infrastructure. The IT infrastructure of today comprises many tools:

• Programming languages and environments such as COBOL, Microsoft Visual Studio, C/C++, and Java
• Database and process design tools such as ERwin, ER STudio, and others
• Analytics and Business Intelligence tools (at least inasmuch as how they interact with the DBMS and how they are configured)
• Transaction processing systems such as CICS and Tuxedo
• Message queueing software such as MQSeries and MSMQ
• Networking software and protocols such as SNA, VTAM, TCP/IP, and Novell
• Networking hardware such as bridges, routers, hubs, and cabling
• Multiple operating systems such as Windows, z/OS and MVS, UNIX, Linux, and perhaps others
• Virtualization software and techniques
• Regulatory compliance and governance requirements
• Data storage hardware and software such as enterprise storage servers, Microsoft SMS, IBM DFHSM, storage area networks (SANs), and NAS
• Operating system security packages such as RACF, ACF2, and Kerberos
• Other types of storage hardware such as tape machines, silos, and solid state (memory-based) storage
• Non-DBMS data set and file storage techniques such as VSAM and B-tree
• Database administration tools
• Systems management tools and frameworks
• Operational control software such as batch scheduling software and job-entry subsystems
• Software distribution solutions for implementing new versions of system software across the network
• Internet and Web-enabled databases and applications
• Client/server development techniques such as multitier, fat server/thin client, thin server/fat client
• Object-oriented and component-based development technologies and techniques
• Personal devices like smart phones and tablets
• And I probably missed some others (add your comments below)

Although it is impossible to become an expert in all of these technologies, the DBA should have some knowledge of each of these areas and how they interrelate. Even more importantly, the DBA should have the phone numbers of experts to contact in case any of the associated software and hardware causes database access or performance problems.

So, being a DBA is sorta like structuring a well-invested portfolio: to be successful at either, you will need to diversify!