Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Deadly sins againts database performance/scalability

Re: Deadly sins againts database performance/scalability

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 05 Dec 2003 11:03:53 -0800
Message-ID: <1070651064.470417@yasure>


Galen Boyer wrote:

> On Thu, 04 Dec 2003, damorgan_at_x.washington.edu wrote:
>
>

>>The division of DBAs and developers into different departments
>>with different budgets and different managers. Can't think of a
>>better way to NOT create a team atmosphere.

>
>
> We have this at my place of work. The wall between my database
> team and the DBA team of our parent company was such that I
> wasn't given a lick of access to any of our development database
> machines. I asked for dba access to the development machines
> they wanted us to use and they got all up in arms about security
> and other production concerns. These machines were to be used by
> my team and my team only. They have never once asked my about my
> designs or layouts or anything. The only thing they wanted to
> make sure of was that we were going through their layers to get
> anything done. Here is my answer in a thread that I was involved
> in. The thread I was involved in is probably reconstructed by
> many here from similar pleas for sane viewpoints from the DBA
> crews.
>
>
> To your question about dba access, I will answer from my
> personal viewpoint. (ie, I don't want to talk for our overall
> architect) . I don't understand how the database architect
> for the whole project isn't given full access to all
> databases designated for development purposes for the
> project. These are development instances. They shouldn't be
> locked down as production instances. The only thing that
> should be locked down is the way the app is interacting with
> the database, because we are building a production app. We
> need to be certain that we hamper the application in exactly
> the same way it will be hampered in production. But, we
> don't need to hamper the development process with the same
> restrictions. When a construction crew is building a new
> home, they don't put the locks on the doors and windows and
> make the construction crew knock on the door to get in to do
> their work, but they certainly make sure the home is put
> together, just like it will be when it is sold. Before it is
> put on the market and sold, the security against even the
> guys that built it is then, and only then, put in place.
>

So somehow the DBA team expects the developers to develop a good application without access to DBMS_PROFILER, without access to v$ magic views, and without access to other tables and views critical to understanding what is happening and optimizing performance and scalability. Good one.

Then I imagine they sit around drinking coffee and whining about the poor quality of apps developed by your team.

Once again the issue goes straight to management incompetence. The managers in charge of these teams are the root source of the problem. They are doing nothing to foster cooperation.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Fri Dec 05 2003 - 13:03:53 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US