question

Grant and Timothy covered it pretty well, but I thought I'd chip in because I have a lot of experience in both roles over the last 14 years. I like to alternate my consultant jobs with production DBA work and development DBA work just because its more interesting and I like to understand both sides of the fence.

1) Covered well by Grant but I'll add some more. Production DBAs may also get involved with defining standards across an organisation which could include the development and naming standards across databases. This is never an easy thing to do esp. if you are responsible for third-party databases, but can make development and release management easier. Production DBAs will also do some development work generally scripting which will include writing VBScript, Powershell, Perl or whatever to do things like Standard SQL Server builds, monitoring, inventory gathering. They may also build SSRS reports to report to management on the state of the environment. They will also get involved in buying decisions for third-party packages from companies like Red-Gate, Quest, Microsoft, Idera, etc. They should get involved with dev teams and guide them on design and architecture of new systems at the database level, as most dev teams do not have the luxury of a development DBA and some are weak on set-based programming and database design skills.

2) This is usually controlled by other departments such as Change Management, Release Management, Incident Management, IT Helpdesk, Application Support, IT Operations. The production DBAs will take on an incident usually from a queue and try and fix issues as they arise. The incident has usually already been looked at by another party first if the issue was identified outside of the DBA team and the DBAs are called upon for their expertise. But as Grant and Timothy have said, it depends on the problem.

3) What Grant said. Sometimes an incident or problem manager will get involved to prioritise. Depends on the size of the organisation.

4) To add to Grant: bad code releases from developers, DBAs called in to fix or troubleshoot performance, disaster recovery in the event of a site outage, or network issue.

5) A production DBAs primary responsibility is to guarantee the availability, security and consistency of data for the company's applications. So whatever you can do to keep this high should be your goal. Things like building High Availability solutions such as clustering, database mirroring or log shipping, etc. Good monitoring is critical to know when something unusual has happened. Reporting and auditing are also critical to understand whether there has been unauthorised access to data which could compromise the availability or security of the data. Ensuring backups work on a regular basis is very important. Disaster recovery tests are also very important to do but are usually initiated by a Business Continuity team, however DBAs will always be heavily involved in this.

I agree with Grant on every point with one exception.

"They may or may not get involved with performance tuning and architecture."

From my point of view, performance tuning is a developer DBA responsibility. If you don't design and build your database with performance in mind, you will end up with a database that doesn't perform as expected and no production DBA in the world can tune the db without major changes in the datamodel and all the procedure code.

One of the production dba responsibility is to monitor the performance to find the cause of the performance loss. (hopefully he will have a performance baseline to compare with).

And yes i think the production DBA also should be involved in performance tuning, like index tuning, statistic updates, hardware configurations etc.

"Not planning for performance is planning for disaster"