if we move the locking in the example at a record level in pl/sql then we are able to process 99 records in the second session.

try this code in the second session.

create or replace procedure pr_prcess_first_row
as

cursor c2 
is select 
rowid
from t1
where 
rownum < 100;

l_rowid rowid;

type typ_2 is table of c2%rowtype index by binary_integer;

tab_2 typ_2;

begin

    open c2;
    fetch c2 bulk collect into tab_2 ;
    for i in tab_2.first..tab_2.last
    loop
	begin 
		select rowid 
        	into l_rowid
		from
		t1 
	        where rowid = tab_2(i).rowid 
		for update skip locked; 

		dbms_output.put_line(' i is ' || i || ' row id ' || l_rowid);	
	exception
		when no_data_found
		then 
			null;
	end;
	

    end loop;
end;

Interesting side effect. That was an optimisation introduced in 10g for implicit cursor loops in pl/sql. You can disable the feature by setting plsql_optimize_level to 1 (or possibly zero) from the default of 2, then you will really fetch 1 row at a time.

The level is stored with the object when you recompile it, so future recompile (but not “create or replace” should continue to use the lower level.

Is there any way to lower the amount PL/SQL prefetches for us or turn it off altogether?

Thanks,
-Roger

We are using the same skip locked with rownum <= 30 rows. This is a single table select with two indexes. The table size is around 25M and indexes less than 10M.

There are 20 sessions running the same sql. I understand from the blog that we can get less than 30 rows on each execution. I see different issue, that the buffer gets per execution is around 1-3 Million. All this cause 100% cpu on the box.

Our DB version is 10.2.0.4.0.

I am not able to understand how come it is using 1-3M buffer gets per exec. It happens only when there is some data in the table otherwise buffer gets arr less than 900/exec.

Insufficient information to be certain – but since you have concurrency 6 and initrans 8 it seems unlikely. It’s possible, of course, that someone changed the initrans after the table was created and put into service, leaving some older blocks with too few ITL slots, and no space to grow them.

The first guess, though, would simply be that your six sessions have overlapping requests as described by Chen Shapira in her comment.

I am facing similar problem. SKIP LOCKED query is not returning specified number of records, but returns random number of records each time when multiple threads are run.
In my scenario,
Number of concurrent threads = 6
DB Block size = 8K
INITRANS = 8
PCTFREE = 10
Average row length (according to dba_tab_statistics.avg_row_len) = 260

Do you think that INITRANS value should be increased ?

Thanks.

The clue is in Gwen’s comment (repeated in the opening line of my comment). The “rownum <= 100" predicate takes precedence over the locking. Oracle stops after attempting to lock 100 rows, not after locking 100 rows. It's just the way it behaves – maybe at some point release it will just change.

“The first two sessions will return 100 rows, the third session will (should) return no rows – even though there are no locked rows for the given value of modded – but the first hundred rows that will be scanned cannot be locked because an ITL entry cannot be acquired….”

As per your example theree are 693 rows in the first block and I assume the same for the rest of the blocks so there will be 231 rows per modded value

so why not oracle goes to another block where it could find rows where modded=2 since the intent is to return 100 rows matching the condition also we donot have any order by clause?

could please clarify

Many Thanks