Re: why administrator refuse to give permission on PLUSTRACE

From: DA Morgan <damorgan_at_psoug.org>
Date: Sat, 03 Nov 2007 07:14:12 -0700
Message-ID: <1194099250.480387@bubbleator.drizzle.com>

Hasta wrote:
> 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 ?

Irrelevant: It was. Solving the problem is the only issue.

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

The coding is 100% in compliance with all specifications except it is too slow.

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

Nonsense. I just gave you the real problem ... can you solve it is the only question left on the table.

>> 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.

Actually I don't. That is not the best solution.

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

The only part of the spec it does not meet is speed. It takes too long to complete. There is nothing else to know.

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

It is called only once and it takes too long. It is called 100 times and it takes too long. It doesn't matter. It performs an essential function, is used appropriately, but it too slow.

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

At this point I think a reasonable person would say that you don't know the answer and you are looking for excuses. I'm not trying to be harsh here but there is a remarkably simple solution that should have jumped off the page at you.

> I dont think that a dba will find out alone.

Just did. Just gave it to you. It is still waiting to be fixed.

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

Now you are just delaying the inevitable. Your boss is getting a bit upset at the delay in fixing the problem. Customers are getting impatient. The website is timing out. Where's the fix?

>> 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.

Where's the fix?

> 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

You failed. <g>

The proc was poorly coded in Oracle 7.3.4, in 8.0, 9i, 10g, and 11g. What's the problem? Where's the fix?

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Received on Sat Nov 03 2007 - 09:14:12 CDT