Re: What are your DBA subclasses?
- From: Michael Moore <michaeljmoore@xxxxxxxxx>
- To: Don Granaman <DonGranaman@xxxxxxxxxxxxxxx>
- Date: Wed, 16 Feb 2011 09:30:09 -0800
If all DBAs were "project/product specific" who would do the common tasks
such as install new releases? I think there is a lot of DBA work that is not
project specific. Still, I think you make a good point. In our shop, I take
requirements from my manager who works with the end-user. From the
requirements I design and create the tables / indexes /sequences /
materialized views and any other database objects. I don't create
tablespaces, but assign tables to existing tablespaces. Then I write and
test any PL/SQL code. If the SQL is non-trivial I do performance tuning.
When it's done, I put together migration scripts in Perforce. Lastly I
create a TeamTrack ticket that is essential a request for the DBA's to run
the migration scripts which push to our QA-TEST/STAGE/and PROD
environments.
So, our DBAs don't really know much about what is going into PROD unless our
developers (me) bring it to their attention. We DO bring it to the DBA's
attention if it's a heavy process or involves huge amounts of data. The
developers understand those issues that the DBAs are going to want to know
about.
So maybe I am kind of a DBA/Developer Hybrid.
Thanks for your input,
Mike
On Wed, Feb 16, 2011 at 8:48 AM, Don Granaman
<DonGranaman@xxxxxxxxxxxxxxx>wrote:
> Having been through this several times at small-to-medium sized shops
> (5-10 DBAs), my experience is that there are essentially two models:
>
>
>
> Function-specific divisions: "production DBA", "development DBA", etc.
>
> Project/product-specific divisions: "all-around DBA" assigned to different
> systems and following the system from inception to production.
>
>
>
> The former is far more common. In my opinion, the latter is usually
> better. In addition to developing better all-around DBAs, with the latter,
> the one(s) designing and building the system get to suffer (or benefit from)
> their own mistakes (or lack thereof). There is far less motivation for a
> "throw it over the wall - on time - and 'fix it later - when we have time'
> approach. [With rushed/half-baked design and implementation, there is never
> "more time to fix it later". All that time and more is spent on the
> gerbil-wheel of just keeping the system alive.] There is also the
> non-negligible advantage of having the production DBA being intimately
> familiar with the system.
>
>
>
> Don Granaman | Phone: 402-361-3073 | Cell: 402-960-6955 | Fax:
> 402-361-3173 |* Solutionary | Relevant . Intelligent . Security*
>
>
>
> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Michael Moore
> *Sent:* Tuesday, February 15, 2011 1:12 PM
>
> *To:* oracle-l@xxxxxxxxxxxxx
> *Subject:* What are your DBA subclasses?
>
>
>
> When we were a much smaller company, we had one class of DB, "generic-DBA"
> where DBA was an abbreviation for "Does 'Bout Anything". A given DBA was
> responsible for Installation, patching, configuration, disk management,
> PL/SQL code review, tuning SQL , application migration, development
> standards etc etc.
>
>
>
> Now that we've grown into a billion dollar company with over a hundred
> developers, we probably need to have more specialization. I'm thinking in
> terms of DA, DCA, DBA ... you get the idea.
>
>
>
> I'd be interested in how other medium sized organizations divide up their
> various DBA functions.
>
>
>
> I'm sure this has been disguised before, so if you wan't to link me to
> reading material, that would be appreciated.
>
>
>
> Thanks,
>
> Mike
>
Other related posts:
