One of the biggest challenges I see these days for DBAs is the ongoing redefinition of their job roles and responsibilities. Oh, most people know the rudimentary aspects of the job, namely keeping your organization’s databases and applications running up to par. The DBA has to be the resident DBMS expert (whether that is DB2, Oracle or SQL Server, or most likely a combination of those). He or she has to be able to solve thorny performance problems, ensure backups are taken, recover and restore data when problems occur, design physical databases from logical models, make operational changes to database structures and, really, be able to tackle any issue that arises that is data-related.
All of these roles continue to be requirements of the job, but that is no longer sufficient for most organizations. The DBA is expected to take on numerous additional — mostly technical — roles. These can include application development, managing the application server, enterprise application integration, managing Web services, network administration and more.
Who manages the application server at your shop? The transaction processor? Other middleware? Who do you go to with SAP and other packaged application issues? Usually the DBA, right?
But I would guess that if you compare the job description of DBAs across several organizations, no two of them would match exactly. This is both good and bad. It is good because it continually challenges the technically-minded employees who tend to become DBAs. But it can be bad, too; because the job differs so much from company to company, it becomes more difficult to replace a DBA who leaves or retires. And no one can deny that database administration is a full-time, stressful job all on its own. But the stress level just keeps increasing as additional duties get tacked onto the DBA’s “to do” list.