Re: why administrator refuse to give permission on PLUSTRACE

In article <1194071445.120813_at_bubbleator.drizzle.com>, damorgan_at_psoug.org says...
> Subject: Re: why administrator refuse to give permission on PLUSTRACE
> From: DA Morgan <damorgan_at_psoug.org>
> Newsgroups: comp.databases.oracle.server
>
> Hasta wrote:
> > In article <em3ni3576un5bov34b5hgm2u34t8gr4pa1_at_4ax.com>,
> > sybrandb_at_hccnet.nl says...
> >> On 2 Nov 2007 09:47:04 -0500, Galen Boyer <galen_boyer_at_yahoo.com>
> >> wrote:
> >>
> >>>> If there is a situation where the developer is truly more qualified
> >>>> than the DBA ...
> >>> Daniel, sadly, this is more normally the case.
> >> Really?
> >> So why do I always have to deal with fully unqualified, not to say
> >> completely incompetent developers?
> >> Do these rarities actually exist?
> >>
> >
> > Are you called in to solve performance problems ?
> >
> > If so, one hypothesis is that you dont meet good programmers,
> > because they solve these problems by themselves
> >
> > IOW why do you think you deal with a representative sample ?
>
> I don't think the issue is, or has ever been, good or bad developers.

Daniel, I am just answering Sybrandb's (recurrent) question above.

> The question has been developers with sufficient skill that you grant
> the DBA role to them and turn them loose on a production database.
> Again ... look at the subject of this thread ... above.
>
> But lets give you an opportunity to test those developers around you to
> see how good they really are.
>
> What would you do if the stored procedure "test" was identified as the
> issue?

But, *how* was the stored procedure "test" identified as the issue ?

*Who* can assess whether it is behaving within specification ?

The bulk of the job is not to solve the problem. It is to find the *real* problem.

> CREATE OR REPLACE PROCEDURE test IS
> BEGIN
> FOR r IN (SELECT * FROM parent)
> LOOP
> r.part_num := r.part_num * 10;
> INSERT INTO child
> VALUES
> (r.part_num, r.part_name);
> END LOOP;
> COMMIT;
> END test;

I guess you want to hear BULK COLLECT, Daniel.

But without context, you dont know, and I dont know, whether BULK COLLECT is the correct solution.

Perhaps procedure test is called 100 times when it should be called only once.

Perhaps there are wayyyys too many rows in the table because of a bug elsewhere. Worse, perhaps customer activity is hugely outside specification.

I dont think that a dba will find out alone.

And I dont think that a dba/developper team will find out within reasonable time, if developpers are not allowed to look.

> And no Hasta it is not my intent here to intimate
> that you, personally, are incompetent. But if you gave
> this challenge to your co-workers how
> many of them do you think could identify
> the issue and come up with one, or more, solutions?

Some have been trained and I know they will find out. Having been trained, they know enough to be safely given access.

Some have not been trained and wont find out. Lacking training, they are not given access. But then, they wouldnt learn anything from access anyway.

Regards

• Raoul