Insert Into Vs Insert through a Procedure

Question

Hi All,
I want to make a comparison between insertion into a table through normal insert into staement and through a procedure.
I create a table call test_table with 6 columns and a procedure to insert in that table.
I opened a session that make normal insert for 32 times and another session that uses the procedure to insert for 39 times. My experience says that insertion through a procedure is faster than normal insert into statement. but when i make trace for both sessions here is the results:
Session1(Normal Insert)
INSERT INTO TEST_TABLE
VALUES(:"SYS_B_0", :"SYS_B_1", :"SYS_B_2", :"SYS_B_3", :"SYS_B_4", :"SYS_B_5")
call count cpu elapsed disk query current rows
Parse 32 0.00 0.00 0 0 0 0
Execute 32 0.01 0.02 0 32 129 32
Fetch 0 0.00 0.00 0 0 0 0
total 64 0.01 0.03 0 32 129 32
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 125 (CALLCNTR44)
Rows Execution Plan
0 INSERT STATEMENT MODE: CHOOSE
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 32 0.00 0.00 0 0 0 0
Execute 32 0.01 0.02 0 32 129 32
Fetch 0 0.00 0.00 0 0 0 0
total 64 0.01 0.03 0 32 129 32
Misses in library cache during parse: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
32 user SQL statements in session.
0 internal SQL statements in session.
32 SQL statements in session.
1 statement EXPLAINed in this session.
Trace for Session2(Procedure Insert)
BEGIN sec1.INSERT_INTO_TEXT_TABLE (); END;
call count cpu elapsed disk query current rows
Parse 39 0.04 0.00 0 0 0 0
Execute 39 0.00 0.00 0 0 0 39
Fetch 0 0.00 0.00 0 0 0 0
total 78 0.04 0.01 0 0 0 39
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 125 (CALLCNTR44)
INSERT INTO TEST_TABLE
VALUES('TEST COL1', 'TEST COL2', 'TEST COL3', 'TEST COL4', 'TEST COL5', 'TEST COL6')
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 39 0.03 0.00 0 0 80 39
Fetch 0 0.00 0.00 0 0 0 0
total 39 0.03 0.00 0 0 80 39
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 474 (SEC1) (recursive depth: 1)
Rows Execution Plan
0 INSERT STATEMENT MODE: CHOOSE
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 117 0.04 0.02 0 0 0 0
Execute 117 0.03 0.03 0 0 0 78
Fetch 39 0.03 0.00 0 312 0 0
total 273 0.10 0.06 0 312 0 78
Misses in library cache during parse: 3
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 41 0.04 0.01 0 0 80 39
Fetch 2 0.00 0.00 1 5 0 2
total 45 0.04 0.02 1 5 80 41
Misses in library cache during parse: 2
118 user SQL statements in session.
2 internal SQL statements in session.
120 SQL statements in session.
1 statement EXPLAINed in this session.
So in session 2 parsing of the procedure it self is still done in each execution but for the statment inside it no and in session1 parsing for the insert is done for every execution. So does this proof my knowledge or it is wrong?
I see that instead of parsing the insert in session1 there is parsing for the procedure in session2 is that correct?
Thanks in advance

Answer 1

Tomy3k_Bakr, you are doing the comparison wrong. Are you running these from sqlplus over and over again? Sqlplus parses every statement you send, this is not the correct way to compare.
Try this instead.
YAS@10G>create table t (a number,b number,c number);
Table created.
YAS@10G>r
  1  create or replace procedure insert_t(pa number,pb number,pc number) as
  2  begin
  3     insert into t values(pa,pb,pc);
  4* end;
Procedure created.Run this and see the results.
exec RUNSTATS_PKG.rs_start;
begin
for i in 1..10000 loop
     insert /*+ sql */ into t values(i,i,i);
end loop;
end;
exec RUNSTATS_PKG.rs_middle;
begin
for i in 1..10000 loop
     insert_t(i,i,i);
end loop;
end;
exec RUNSTATS_PKG.rs_stop;
Run1 ran in 124 hsecs
Run2 ran in 139 hsecs
run 1 ran in 89.21% of the time
Name                                  Run1        Run2        Diff
LATCH.list of block allocation           1           0          -1
STAT...redo ordering marks              92          91          -1
STAT...table scans (short tabl           3           2          -1
LATCH.session idle bit                  27          26          -1
LATCH.In memory undo latch               0           1           1
LATCH.file cache latch                   3           2          -1
LATCH.redo allocation                    8           7          -1
LATCH.archive process latch              1           0          -1
LATCH.Consistent RBA                     2           3           1
LATCH.lgwr LWN SCN                       3           2          -1
LATCH.mostly latch-free SCN              3           2          -1
LATCH.KMG MMAN ready and start           1           0          -1
LATCH.compile environment latc           3           2          -1
LATCH.session timer                      0           1           1
LATCH.shared pool                        2           3           1
STAT...change write time                11          12           1
STAT...table scan blocks gotte           6           4          -2
STAT...messages sent                     2           4           2
STAT...data blocks consistent            3           1          -2
LATCH.channel operations paren           8           6          -2
STAT...rollbacks only - consis           3           1          -2
STAT...cleanout - number of kt          27          31           4
STAT...index fetch by key                6           2          -4
STAT...cluster key scans                 6           2          -4
STAT...active txn count during          27          31           4
STAT...deferred (CURRENT) bloc           6           2          -4
STAT...consistent changes               20          24           4
STAT...consistent gets - exami          39          35          -4
STAT...session cursor cache hi          11           7          -4
STAT...CR blocks created                 6           2          -4
STAT...commit cleanouts succes           6           2          -4
STAT...commit cleanouts                  6           2          -4
STAT...workarea memory allocat           5           1          -4
STAT...calls to kcmgcs                  27          31           4
STAT...execute count                10,014      10,009          -5
LATCH.active checkpoint queue            5           0          -5
STAT...opened cursors cumulati          14           8          -6
STAT...db block changes             20,324      20,318          -6
LATCH.redo writing                      14           8          -6
STAT...parse count (total)              14           8          -6
STAT...CPU used when call star         131         138           7
STAT...calls to kcmgas                 101          94          -7
LATCH.undo global data                  50          43          -7
STAT...no work - consistent re          15           7          -8
LATCH.dml lock allocation               12           4          -8
STAT...DB time                         132         140           8
STAT...cluster key scan block           12           4          -8
LATCH.library cache lock                16           8          -8
STAT...buffer is not pinned co          12           4          -8
LATCH.messages                          27          17         -10
STAT...db block gets from cach      10,484      10,473         -11
STAT...db block gets                10,484      10,473         -11
STAT...enqueue releases                 24          13         -11
STAT...enqueue requests                 24          13         -11
STAT...recursive cpu usage              96         107          11
STAT...Elapsed Time                    127         140          13
LATCH.enqueues                          35          22         -13
STAT...redo entries                 10,181      10,195          14
STAT...CPU used by this sessio         124         138          14
LATCH.library cache pin             20,072      20,056         -16
LATCH.cache buffers lru chain          135         153          18
STAT...table scan rows gotten           54          36         -18
STAT...calls to get snapshot s          37          19         -18
LATCH.library cache                 20,094      20,073         -21
LATCH.enqueue hash chains               50          26         -24
STAT...bytes received via SQL*       1,210       1,185         -25
STAT...consistent gets                  91          63         -28
STAT...consistent gets from ca          91          63         -28
STAT...free buffer requested           118         152          34
STAT...session logical reads        10,575      10,536         -39
LATCH.row cache objects                153         106         -47
LATCH.checkpoint queue latch            57           0         -57
LATCH.SQL memory manager worka          73           6         -67
LATCH.cache buffer handles              16          84          68
STAT...recursive calls              10,132      10,053         -79
LATCH.object queue header oper         334         437         103
LATCH.cache buffers chains          51,652      51,526        -126
LATCH.session allocation               258         104        -154
STAT...free buffer inspected           448         188        -260
LATCH.simulator lru latch              440         865         425
LATCH.simulator hash latch             458         892         434
STAT...hot buffers moved to he       1,222         276        -946
STAT...undo change vector size     684,064     682,932      -1,132
STAT...redo size                 2,586,108   2,583,908      -2,200
Run1 latches total versus runs -- difference and pct
Run1        Run2        Diff       Pct
94,017      94,489         472     99.50%For runstats see http://asktom.oracle.com/tkyte/runstats.html.