Statistics_level = ALL

Question

On 10.2.0.3:
I have this delete statement. It takes 40 seconds to execute 1500 times with statistics_level parameter set to ALL.
Compared to 4 seconds with statistics_level parameter set to TYPICAL.
Here is a tkprof report with statistics_level = TYPICAL:
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1500 4.33 4.23 20 57852 1570 500
Fetch 0 0.00 0.00 0 0 0 0
total 1500 4.33 4.23 20 57852 1570 500
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 109 (DBFRONT) (recursive depth: 1)
Rows Execution Plan
0 DELETE STATEMENT MODE: ALL_ROWS
0 DELETE OF 'SONG_LIST_JUK_DETAIL'
0 HASH JOIN (ANTI)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'SONG_LIST_JUK_DETAIL_PK' (INDEX (UNIQUE))
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'IDX_JUK_HD_SONG_HDIDSONID' (INDEX (UNIQUE))
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 20 0.00 0.00
BWT, how do i edit this thread so my tkprof report be readable to you?
And here is my tkprof report with statistics_level = ALL:
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1500 40.64 40.01 35 41741 2607 1467
Fetch 0 0.00 0.00 0 0 0 0
total 1501 40.64 40.01 35 41741 2607 1467
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 109 (DBFRONT) (recursive depth: 1)
Rows Execution Plan
0 DELETE STATEMENT MODE: ALL_ROWS
0 DELETE OF 'SONG_LIST_JUK_DETAIL'
0 HASH JOIN (ANTI)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'SONG_LIST_JUK_DETAIL_PK' (INDEX (UNIQUE))
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'IDX_JUK_HD_SONG_HDIDSONID' (INDEX (UNIQUE))
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 35 0.04 0.08
Same plan is used in both cases. I notice the following:
both have INDEX MODE: ANALYZED (RANGE SCAN) OF.
I cannot find documentation regarding INDEX MODE: ANALYZED (RANGE SCAN) OF.
Does anyone has a link that points to this?
Why does it says "mode:analyzed"
Anyone has an explication? Like the optimizer does more work when statistics_level = ALL , and thats why it took more time to execute. Should i have run something in the dbms_stats package on top of using statistics_level = ALL?
Here is the script for my stats gathering for my table:
execute dbms_stats.gather_table_stats(ownname=> USER, tabname=> 'SONG_LIST_JUK_DETAIL' , estimate_percent=> DBMS_STATS.AUTO_SAMPLE_SIZE, cascade=> DBMS_STATS.AUTO_CASCADE, degree=> null, no_invalidate=> DBMS_STATS.AUTO_INVALIDATE,granularity=> 'AUTO',method_opt=> 'FOR ALL COLUMNS SIZE AUTO');
Should that ive run the stats differently so the query run fast with statistics_level set to ALL?

Answer 1

With statistics_level = ALL, Oracle will have to do a little more, so a slight increase in cpu time is expected, but not like you are showing here.
However, before investigating this myself, I see you have some odd differences. When you take a closer look at the tkprof output, you see the first delete statement had actually deleted 500 rows, while the second was deleting 1467 rows. So it looks like your delete statements cannot be compared.
Also the number of rows is missing from the row source operation. Are you sure you properly disconnected your traced session to make sure all cursors were closed?
> BWT, how do i edit this thread so my tkprof report be readable to you?
Just click the edit icon next to the reply icon and add the tags [pre] and [/pre] around the code and tkprof output.
Regards,
Rob.