Re: How do you feel about allowing non-DBA's on your database servers?

From: David Barbour <>
Date: Mon, 27 Jul 2009 12:13:39 -0400
Message-ID: <>

This topic/debate is one of the oldest repeating threads I can remember. Everybody thinks they absolutely cannot do their job without access to production servers, whether it be through administrative control of the application or, as you're facing here, access to the server at the operating system level.


Developers are paid to develop. They try new things and break stuff. It's their job. That's why we have development boxes. They can do whatever they want on those servers. If they break it, it gets restored. That's where they create stuff and do unit testing before it gets sent to ......

A QA server where integration and probably user acceptance testing occurs. If developers are part of the QA environment in the organization, they may require some user permissions, but they don't fix anything in QA. If it doesn't work, they fix it in development and put it back into QA for testing. When it passes muster, then it gets put into production. Developers need little or no access to production. If there's a problem, they should be able to replicate it on QA. If they can't, that's where the DAB and Sys Admin get ninvolved to see if there's something different with the data or OS.

Support personnel might have limited access to production for some tasks (re-setting printers comes to mind), but that is carefully controlled by the Sys Admin(s). Support personnel have no business looking at the data or the database. Usually, most of the problems support people encountered can and should be fixed at the application level.

If folks are worried about monitoring, there are a variety of user-friendly (pretty picture) products out there that can provide system-level monitoring to interested personnel with them having access to the production server. Some are free, some cost money.

Bottom line is that the decision rests with management. There are SOX implications if you are dealing with a public company. There are business issues regardless. Production is called that for a reason. We process $1M /hour in orders through our systems. Believe me, nobody from the development side of the house has any access, system or application, to any of the servers. For certain issues, support people have 'firefighter' access to the application, but they have to request it, it's approved by a manager, and their actions are logged. For other issues where advice from the development teams is need or wanted, an application administrator, DBA or Sys Admin sits with them while they have access.

There's a reason production is called production. It's generally the lifeblood of the firm. It needs to be as secure as possible.

On Mon, Jul 27, 2009 at 11:31 AM, Robert Freeman <>wrote:

> So, I've got a client that is being pressured by development and support
> types to allow access to their database servers. They claim that it's so
> they can use tools like ps, sar, topas, etc.... to monitor performance and
> deal with support issues.
> My position is that this is a huge risk and that I would want an very
> limited population of users (read DBA's and SYSADMIN's only) to have access
> to these servers.
> Anyone have an opinion on this?
> RF
> Robert G. Freeman
> Oracle ACE
> Author:
> Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON IT'S WAY
> OCP: Oracle Database 11g Administrator Certified Professional Study Guide
> (Sybex)
> Oracle Database 11g New Features (Oracle Press)
> Portable DBA: Oracle (Oracle Press)
> Oracle Database 10g New Features (Oracle Press)
> Oracle9i RMAN Backup and Recovery (Oracle Press)
> Oracle9i New Features (Oracle Press)
> Other various titles out of print now...
> Blog:
> The LDS Church is looking for DBA's. You do have to be a Church member in
> good standing. A lot of kind people write me, concerned I may be breaking
> the law by saying you have to be a Church member. It's legal I promise! :-)

Received on Mon Jul 27 2009 - 11:13:39 CDT

Original text of this message