DBA Rules of Thumb - Part 7 (Diversify)
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.
Jack-of-All-Trades
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 and Rational Rose
- 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, OS/390 and MVS, 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 (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 such as BMC PATROL and CA Unicenter
- 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 such as CORBA, COM, OLE DB, ADO, and EJB
- PDAs such as Palm Pilots and PocketPCs
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!
© 2005, Mullins Consulting, Inc.
