A good DBA is 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 necessarily 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.
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, C#/C/C++, Java, etc.
- Database and process design tools such as ERwin, Rational, and ER Studio
- 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, UNIX, Linux, and perhaps others
- 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 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
- Big Data technologies such as Hadoop, HBase, Hive, and so on
- Analytics, BI and querying solutions
- Portable devices such as smart phones and tablets
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!