Re: What are your DBA subclasses?
Date: Wed, 16 Feb 2011 11:46:41 -0600
Message-ID: <4D5C0D81.8040504_at_gmail.com>
We work in a similar fashion. However the DBA (me) is very aware about what goes into PROD. I insert myself into design and code reviews. That way, I am aware of what is being put forward. I also have the opportunity to suggest tuning, monitoring, and structural items to the design/development team while it's still a work in progress. It's much easier to get these things in before the project is at implementation stage.
In general our 3 DBA's are product/project directed, but we are jack-of-all-trades DBA's. In a shop our size, we do it all.
--Rodd
On 02/16/2011 11:30 AM, Michael Moore wrote:
> 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
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Feb 16 2011 - 11:46:41 CST