Quite some time ago, I read a fascinating article, co-written by easily the best Oracle instructor I ever had the pleasure of being taught by in Joel Goodman, which talked about the skills required to be a “DBA 2.0”.
They even mentioned Exadata needing its own “version”, though they suggested it would be “DBA 2.1”. I’m not sure Exadata had made it out into the wild at this point.
The article was written five or six years ago and was tremendously prescient. With the data industry at such a fascinating crossroads with Big Data, engineered systems and extreme performance, how will the DBA role change to keep up with the demands of the ever-increasing volume and mission-critical exploitation (hopefully the beneficial kind) of enterprise data?
Working in IT requires constant learning and adaptation. In order to remain current (and employable), you need to grasp new products and tools at a much faster rate than in most other professions. For me, it’s part of what I really like about my job – constantly having to learn (quickly and by ones self, mostly) and solve the most mundane and the most bizarre problems has got to be good for the intellect, if not the waistline.
The DBA role is perfect example of this: in the last 10-15 years, DBAs have needed to add storage, system and network administration to their skill set in order to be able to support larger and more powerful databases.
Looking at the DBA profession as a whole, it seems that there are three “versions” of DBAs out there at the moment:
- Responsible for single-instance Production databases
- Monitored by OEM
- Online backups via RMAN
- No high-availability
- No disaster recovery – in a disaster, the database is restored from a backup
- Responsible for RAC and Data Guard Production databases – this appears to be today’s “standard” environment for Production databases
- Manages the clusterware through CRS or HAS
- Manages storage through ASM (redundancy)
- High availability with RAC
- Disaster recovery with Data Guard
- Adept at performance tuning for OLTP and EDW workloads
- Responsible for engineered systems (Exadata, Exalogics, Hadoop, ZFS)
- Should be called “Database Machine Administrator” or “Data Management Administrator”?
- Could/should be part of a “Engineered Systems” or “Data Management” team, instead of the ubiquitous DBA team.
- Manages the database, ASM, clusterware, storage cells, network switches and operating systems
Supports the system as an administrator and as an architect (infrastructure and integration)
Creates and maintains specialized support processes, policies, etc
Implements advanced features such as EHCC, Smart FlashCache, SmartScans, etc
- Uses OEM, exachk and customized monitoring scripts for capacity planning and performance tuning
Configures advanced workload management features: DBRM, services, IORM (if required), instance caging (if required)
Expert at performance tuning
I do think that there is a clear distinction between the “versions” and it is important for IT management to understand this. I have known of DBAs being expected to jump from “1.0” to “3.0” without mastering “2.0” first – with invariably bad results.
What do YOU think makes up a DBA 3.0?
Should we even be called “DBAs” as our responsibilities continue to expand within the enterprise?
Should those who are DBA 3.0 be moved into a specialized support group, which could even include network and systems administrators?