oracle 12c stored procedure increasing execution time when run in a loop

Question

Hi I have an Oracle 12c db, with a total SGA of 12 GB and shared pool area target set to 4 gb.

Application has a stored proc, which has intermittent performance issues as observed.

the execution path the stored procedure takes has been identified and the single query on that path, has a low cost plan for it.

I run the stored proc in a loop of 100, and I see it starts with an execution time of 74 ms and at the end of the 100th loop the execution time of the procedure is about 5000 ms.

Looking for pointers as to why could that be?

the query in the proc looks similar to

 SELECT a, b
  FROM (  SELECT a, b
            FROM tab
        ORDER BY c)
 WHERE ROWNUM = 1;

Oracle, as observed in this case didnt create multiple plans for the same query execution. I have set the optimizer mode to first_rows and also verified the indexes onf the where clause, without much effect.

Answer 1

If you have not commit inside the loop, what you observe could be caused by the fact that it takes more and more time to record your transaction in the Rollback segment(s) .

But in general, you should avoid running loops in PL/SQL . Good performance can be achieved with SQL queries alone, and the "loops" handled by Oracle, not you.

Answer 2

Is TAB growing (ie, is anything doing INSERT INTO TAB between executions of the SELECT you posted)? If so, it's clear why it is slowing down if the SELECT is doing a full table scan of TAB . As TAB grows, that will take longer and longer.

If you have an INDEX on column c , then try rewriting your SELECT this way:

SELECT a, b 
FROM (  SELECT a, b
        FROM tab
        WHERE c = ( SELECT min(c) FROM tab )
        ORDER BY c)
WHERE ROWNUM = 1;

The index will allow Oracle to find the min(c) very quickly using an INDEX FULL SCAN (MIN/MAX) access method. Then, that minimum value will be looked up very quickly using the same index via an INDEX RANGE SCAN access.

This query's performance should not degrade significantly as TAB grows in size.

Your post hints at other possible optimizations in the overall process, but this is probably going to get you most of the way to where you want to be.