Re: So, What is a 'Production DBA'?

Peter Barnett wrote:
>
> We are having this debate. What is a 'Production
> DBA'? Right now all of the DBAs do some of
> everything. In an effort to focus more DBA time on
> infrastructure, damagement is floating the idea of
> Production and Applications DBAs. The DBA group has
> loosely translated this into the group that is always
> on-call and the group that gets their weekends off.
>
> I would appreciate some input from those of you who
> are Production DBAs.
>
> =====
> Pete Barnett
> Lead Database Administrator
> The Regence Group
> pnbarne_at_regence.com

Much of this may have already been said, but, here's my $0.02 ($0.012 after taxes):

Generally, the term "Applications DBA" (note the plural form of Application there), refers to one who is concerned with the Oracle Applications (or Oracle Financials, or the Oracle Cooperative Applications, or the Oracle E-Business Suite, or whatever they're calling the bundle this week).

That said, there is a pretty significant difference between an "Applications DBA" and a "Regular DBA". Mostly, the Applications DBA would tend to do less of the "data-modeling" and, in some degree, less of the "developer-handholding" than a "Regular DBA".

Also, prior to the advent of a simple little trick they decided to give a complex-sounding name "server-partitioning", the "Regular DBA" would probably have been much more familiar with the *newer* features of the RDBMS. (The Oracle Apps being such a behemoth that they generally don't (didn't) make use of many of those features). For example: Roles, Defined referential integrity constraints (relatively new to the Apps), partitioned tables/views, star schemas, replication, etc. Although, like anything, your degree of exposure to these features may somewhat depend on the systems you're supporting/implementing.

Now, as to a "Production" vs. a "Development" DBA ("Development" probably being a more appropriate term in most cases). A "Production" DBA is generally more concerned with the overall availability and stability of the system (Backup/Recovery, Performance [identifying bad code and bashing the developer over the head with it], datafile placement, Failover, etc.). A "Development" DBA probably has more direct input into the design of the system (Normailzation, ERDs, tuning bad code before it goes into production). The "Development" DBA also probably has to/gets to deal with the Developers more frequently.

So, IMHO, a good "Production DBA" would more likely have a Systems Administration background. While a good "Development DBA" would more likely have a Development background. And, a "Great" DBA should have some of both.

• James

  ---

  James J. Morrow E-Mail: jmorrow_at_warthog.com Senior Principal Consultant Tenure Systems, Inc. McKinney, TX, USA

"The reasonable man adapts himself to the world: the unreasonable man   persists in trying to adapt the world to himself. Therefore all progress    depends on the unreasonable man." -- George Bernard Shaw

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: James J. Morrow
  INET: jmorrow_at_warthog.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).