Having been a DBA for quite a while, I often get asked on tips to become a great DBA, especially from novices in the IT world. Often times, it's the knowledge that a DBA is one of the most well-paid streams in IT; while other times it's the status symbol associated with being a DBA-due to their technical expertise-that prompts this question. I'll try to attempt answering this question in general, through this article.
Broadly speaking, IT environments can be classified into two-OLTP (online transaction processing and OLAP (online analytical processing) [a.k.a. DSS (decision support system) or BI (business intelligence) or DW (data warehousing)]. This article addresses the various roles of an information management (or data management) professional in a mainly OLTP environment. I have seen mainly four kinds of information management professionals in an OLTP environment - data architects, database architects, application DBAs and operational (or production support) DBAs. Let's examine these roles in detail.
Data architects attend business meetings and are engaged once a decision has been made to go ahead with a project, immediately after the impact analysis. When funding for the project has been finalized, data architects may be involved in the requirement analysis phase of an SDLC (software development lifecycle). They, along with business analysts, usually understand business requirements and analyze the data requirements. Data architects create the data model and the logical entity relationship diagrams. In most cases, it is the data architect that does the normalization of the data model. They are proficient in tools such as ER/Studio from Embarcadero or ERwin from CA.
The application DBAs get the normalized data model and do the first cut physical and subsequently would generate a finalized physical data model. It is this data model that they use to create the physical data structures (this may be done by the production DBAs in some organizations, as I have explained later).They may decide to denormalize the logical data model (supplied by the data architect) for various reasons including performance, database constraints and storage needs. They may decide compression, maintenance strategies, use CREATE TABLE or SELECT INTO for loading data (SQL Server). They may also decide to group all support (read-only) tables into common extent sizes or filegroups, decide whether more indexes are required to optimize performance.
The operational/production support DBA rolls out the physical structures, does routine maintenance and supports the objects thereafter. He or She analyzes the space usage and ensures that performance criteria and SLAs are met in an agreeable manner. Often times, the requirements and data volumes change over a period of time and existing indexes might need to be revisited. An index that was good when the project was rolled-out initially may not be the best index after a few years, or may not be used anymore. A production DBA analyzes worst performing queries (say, worst 10 queries by CPU or execution) and looks at various ways to make them more efficient and ensures that good backups are in place. To this end, a production DBA should often talk to the application DBAs to decide the best way of providing efficient support.
The database architect is not a common role, but they decide which platform/RDBMS is best for the data model or how the new data model has to be integrated to an existing environment. As an example, a database architect can decide whether a new .NET or Java environment should be housed in a SQL Server cluster, a multi-node RAC Oracle Cluster or an HADR-DB2 environment. The database architect might also decide on disaster recovery strategies and high availability clustering.
It is advisable for both the data architects and the application DBAs to have a good knowledge of the application that they are supporting. They should be aware of the underlying business objective and should try to familiarize themselves with the data flow. The database architect and operational DBA roles, on the other hand, require an in-depth technical knowledge. The database architects should have a broad knowledge of various database architectures while the operational DBAs should be highly proficient in installing, upgrading and troubleshooting database software.
Before becoming a DBA, I'd recommend spending a few years in the application development teams. This would help you in two ways: by helping you get well acquainted with your business, and by allowing you to gain technical exposure, both of which you may really need as a DBA. This would mean spending years in developing presentation and application layers before entering the database layer in the case of a distributed system (or three-tier architecture).It would be worthwhile to get accustomed to .NET, C# or J2EE, Websphere MQ or Weblogic for a few years before embarking on the data layer. If your niche is on the mainframe, ensure that you spend quality time developing or maintaining applications on VSAM, CICS, IMS or DB2 before accepting-or looking for-the role of a DBA. Remember that people go to the DBAs if they can't find an answer to their problems, even if it has nothing to do with the database!.
We're currently in a phase of the IT evolution where the distinction between business and IT is blurring-the expectation from IT staff is not just to create and maintain IT infrastructure, but also to contribute to the bottom-line of business. In the olden days, if you were an IT professional (or in data processing), it was not really required to know much about the business. And it was a common practice to blame the business for failures of IT projects, as long as you had a good IT skill set. Management and organizational structures of IT were kept siloed from the business. This is not the case anymore. Today, most organizations are trying to align associates so that both the IT and end-users of specific business functions are under the same senior management. Under current economic conditions, resources are being asked to do more for less and if you do know how to do this, you will become one of the point persons. Hence, it should be the aim of an information management professional to master all the four roles and seamlessly shift between them with ease. Once you are able to shift roles easily, be assured that you're adding to the revenue of your business and your company would appreciate your work! Besides, smaller shops - or, for that matter, even big companies-may not have the luxury of such well-defined roles. In most organizations, one position might have the roles and responsibilities of two of the roles I mentioned before. Management would expect you to be a jack of all trades (read jack of all roles!) and do multiple roles in your position.