Re: Stored Procedure Performance Problem --- Please Help

On Friday 31 August 2001 13:40, Stephane Faroult wrote:
> > Procedure:
> >
> > CREATE OR REPLACE PROCEDURE transform_prc IS
> > CURSOR cur_main
> > IS
> > SELECT distinct idserver,
> > to_char(dtreadingtime, 'DD-MON-YYYY HH24:MI') dttime
> > FROM tblcounter_reading a
> > WHERE ysntransformflag IS NULL
> > AND to_char(a.dtreadingtime, 'DAY') NOT IN ('SUNDAY ',
> > 'SATURDAY ');

>
> All right, mandatory table scan (functions make index usage impossible
> unless, as somebody suggested, you create an index-based index). In your
> case, I would not advise it since I guess that the bulk of your activity
> occurs from Monday to Friday inclusive, so you are going to exclude with
> the date criterion a ridiculously small fraction of your data - you are
> better off scanning. Concerning the flag, you may be aware that NULL
> value are often not stored at all, and are therefore not indexed. If the
> number of rows you expect to fetch with this restriction is small (i.e.
> the flag is not null in say 95% of cases) I suggest you make the column
> NOT NULL and set a default (unused) value, say '#' - which will make you
> able to index the column. If few rows contain this value and if it is
> indexed, WHERE YWNTRANSFORMFLAG = '#' will fly.

Since this cursor is the main loop, I don't see a problem with the full table scan, unless the where clause actually limits the return set to a small percentage of the total. In any case, it doesn't take 20 hours to read 13 million rows. It's not *that* big.

>
>   I have trouble understanding your logic. Why the PL/SQL table?
> Wouldn't it be possible to do a join or whatever to retrieve the column
> name you want? Why do you want to scan the array? If Oracle can do it
> for you, do not hesitate, it may do it more efficiently.
>

I'll agree to that, for sure. I read this code for a few minutes and decided that was enough. It appears very convoluted to me. What are you really trying to accomplish here?

And as others have said, get rid of the dynamic SQL. Or at least use bind variables.

Jared

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).