DBMS_SHARED_POOL.KEEP -- give nothing to performance ???

Question

I want to know, how significant is DBMS_SHARED_POOL.KEEP to performance, but I haven't got better performance.
I had tested before and after pinning it into shared_pool.
State is :
CREATE TABLE scott.test(fld1 number(2),fld2 number(2));
CREATE OR REPLACE PROCEDURE scott.p_millionrows IS
BEGIN
EXECUTE IMMEDIATE 'TRUNCATE TABLE scott.test';
FOR i IN 1..10000000 LOOP
INSERT INTO scott.test(fld1,fld2)
SELECT TRUNC(DBMS_RANDOM.VALUE(10,40)),TRUNC(DBMS_RANDOM.VALUE(10,40)) FROM DUAL;
END LOOP;
END;
My product component version :
PRODUCT_     VERSION_     STATUS_
NLSRTL      11.1.0.6.0     Production
Oracle Database 11g Enterprise Edition      11.1.0.6.0     Production
PL/SQL      11.1.0.6.0     Production
TNS for 32-bit Windows:      11.1.0.6.0     Production
BEFORE : EXEC scott.p_millionrows;
The query times is 17:07 min.
AFTER : ALTER SYSTEM FLUSH SHARED_POOL;
EXEC dbms_shared_pool.keep('SCOTT.P_MILLIONROWS','P');
SELECT NAME,KEPT FROM V$DB_OBJECT_CACHE WHERE TYPE='PROCEDURE';
EXEC scott.p_millionrows;
The query times is 17:03 min.
My Conclusion : DBMS_SHARED_POOL.KEEP = GIVING NO TO PERFORMANCE
My question :
1st. Is my query take too long ?
2nd. Do I need configure spfile.ora ?
Any Help Is Appreciated.
Regards,
Yohanes 林贤汉
Edited by: SigCle on Oct 12, 2010 5:45 PM

Answer 1

Your conclusion is just wrong. dbms_shared_pool.keep is geared at procedures and functions which you are calling over and over again, and which you can't afford to be reloaded often.
The only thing you avoid by pinning a procedure is the overhead of reloading.
Secondly in both cases you perform 10000000 inserts instead of 1 bulk insert and this is taking time.
What you should do is
SQL> l
1 insert into scott.test
2 select trunc(dbms_random.value(10,40)), trunc(dbms_random.value(10,40))
3 from dual
4* connect by level <= 1000000
I can insert 1 million rows in 14.51 seconds
Your method is the slowest possible.
And yes, you always should use a spfile, but this has nothing to do with the problem at hand.
Sybrand Bakker
Senior Oracle DBA