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
> [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
