Event 10053
Hi,
Yesterday I was reading one of the performance optimization book about event 10053 but could not understand what to look in that trace file.
Could only understand that it will show different execution plans.
Kindly tell me what I sould actually look in the 10053 trace.
Regards
MMU
Basically this is cost based optimizer trace. I usually look there for errors and other deficiencies that surround CBO calculation of the execution plans. But this comes after other steps of tuning and if you discovered that you don't like the current execution plan of an offending query.
Vlad Sadilovskiy
Oracle Database Tools
http://www.fourthelephant.com
Similar Messages
-
Optimizer parameters different in 10053 trace
Hello,
The optimizer settings and the ones reported in the 10053 trace does not match. Is this a known issue ? Version is printed in the code snippet.
Here, optimizer_mode is set to ALL_ROWS, but 10053 trace reports this as first_rows_100. Similarly, optimizer_index_cost_adj is 1. But, it is 25 in the trace.
The query is not using hints.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP and Data Mining options
SQL> show parameter opti
NAME TYPE VALUE
filesystemio_options string none
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 100
optimizer_index_cost_adj integer 1
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
plsql_optimize_level integer 2
SQL>Contents of 10053 trace
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
sort_area_retained_size = 65535
optimizer_mode = first_rows_100
optimizer_index_cost_adj = 25
optimizer_index_caching = 100
*********************************I can see the same used in here..
Content of other_xml column
===========================
db_version : 10.2.0.3
parse_schema : COT_PLUS
plan_hash : 733167152
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('10.2.0.3')
OPT_PARAM('optimizer_index_cost_adj' 25)
OPT_PARAM('optimizer_index_caching' 100)
FIRST_ROWS(100)
OUTLINE_LEAF(@"SEL$5DA710D3")
UNNEST(@"SEL$2")
OUTLINE(@"SEL$1")
OUTLINE(@"SEL$2")
FULL(@"SEL$5DA710D3" "CDW"@"SEL$1")
INDEX_RS_ASC(@"SEL$5DA710D3" "O"@"SEL$2" ("ORDERS"."STATUS_ID"))
LEADING(@"SEL$5DA710D3" "CDW"@"SEL$1" "O"@"SEL$2")
USE_NL(@"SEL$5DA710D3" "O"@"SEL$2")
END_OUTLINE_DATA
*/Rgds,
Gokul
Edited by: Gokul Gopal on 13-Jun-2012 03:14Gokul,
Please report the output of the following, which checks the V$SES_OPTIMIZER_ENV view for the current session:
SELECT
NAME,
VALUE,
ISDEFAULT
FROM
V$SES_OPTIMIZER_ENV
WHERE
SID=(SELECT SID FROM V$MYSTAT WHERE ROWNUM=1)
AND NAME IN ('optimizer_mode','optimizer_index_cost_adj','optimizer_index_caching')
ORDER BY
NAME;In the same session, execute the following (your SQL statement with 1=1 added in the WHERE clause to produce a hard parse):
ALTER SESSION SET TRACEFILE_IDENTIFIER='OPTIMIZER_TEST';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
select * from A where 1=1 AND col1 = (select to_char(col1) from B where status in (16,12,22));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';Take a look in the generated 10053 trace file. Are the values for the optimizer_mode, optimizer_index_cost_adj, and optimizer_index_caching found in the OPTIMIZER_TEST 10053 trace file the same as what was produced by the above select from V$SES_OPTIMIZER_ENV?
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
10053 - no trace file generated
Hi,
no 10053 trace file is generated in the diag directory.
sql_trace = true
trace_enabled = true
i set
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST';
ALTER SESSION SET EVENTS='10053 trace name context forever, level 1';
but there is no trace file generated.
Something seems to be missing.
Any help would be much appreciated!
Best Regards
user11368124thanks for your messages.
@Dom Brooks
the Oracle release is 11.2 running on Ubuntu.
Added flushing pool. That statement was missing.
But unfortunately the 10053 trace file is still not generated.
i am running the following query mentioned in the article "Examining the Oracle Database 10053 Trace Event Dump File" of Steve Callan:
alter system set TRACE_ENABLED = true;
alter system set SQL_TRACE = true;
alter session set statistics_level=all;
--alter session set max_dump_file_size = unlimited;
--oradebug setmypid
--oradebug unlimit
--oradebug event 10053 trace name context forever, level 1
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST';
alter session set events '10046 trace name context forever, level 12';
alter session set events '10053 trace name context forever, level 1';
-- plan_table exists
select * from plan_table
-- flushing pool
alter system flush shared_pool;
explain plan for
SELECT ch.channel_class,
c.cust_city,
t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM sh.sales s,
sh.times t,
sh.customers c,
sh.channels ch
WHERE s.time_id = t.time_id
AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id
AND c.cust_state_province = 'CA'
AND ch.channel_desc in ('Internet','Catalog')
AND t.calendar_quarter_desc IN ('1999-01','1999-02')
GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc
ORDER by 1,2,3,4;
Best Regards
user11368124 -
How to improve the query performance or tune query from Explain Plan
Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
21 FILTER
16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
243 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
SID
310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
VALUE
163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID CHILD_NUMBER
04mpgrzhsv72w 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
: call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
How to setup shortcut to insert a command in Oracle sql shell?
Hi,
Under sqlplus shell, if i want to frequently insert a long command while
tuning queries, is there any way I can press a couple of keys to insert the
command that is pre-prepared.
For example, I need to frequently insert:
sqlplus> alter session set events '10053 trace name context forever';
anyone knows some tips to avoid typing?
thanks,
Rickuser10217806 wrote:
i mean sqlplus command line input interface under linux.Well, Ivan showed how to just use some sql files to do it .. not exactly pasting your command at the command line, but useful, nevertheless.
As for actually pasting text at the command prompt, as I said, what you are asking has nothing to do with sqlplus itself and everything to do with the environment in which you are running it. For instance, if I use Putty to connect to my *nix boxes, it is a feature of putty to paste whatever is in the clipboard by simply right-clicking the mouse. I can do the same thing at a Windows command prompt window if I have the properties set for 'quick edit'. -
ORA-03113 : end-of-file on communication channel while running a SQL Query
Hi,
While executing the following query, we are facing ORA-03113 : EOF on communication channel error.
SELECT
FROM QDF_CLSS_SHENG_HIST
/*WHERE* a.FACT_TYPE_CODE='BS'
AND */
WHERE (SRCE_SYS_ID = 850 OR (SRCE_SYS_ID IN (1747,1764) AND GEO_ID IN (826,372) AND PRTTN_BY_FUNC_DATE>=to_date('20060701','YYYYMMDD') ))
When we remove one of the values in the SRCE_SYS_ID's 'IN' condition the error is not thrown, e.g.
WHERE (SRCE_SYS_ID = 850 OR (SRCE_SYS_ID IN (1747) AND GEO_ID IN (826,372) AND PRTTN_BY_FUNC_DATE>=to_date('20060701','YYYYMMDD') ))
The version of the Database we are using is 10.2.0.3.0 - 64bi. Is this a common error in this version of the database because when we ran the same query in a 9i database we got no such error.
P.S : QDF_CLSS_SHENG_HIST table is partitioned on SRCE_SYS_ID and PRTTN_BY_FUNC_DATE
Thanks,
PuneethYes, we get the same error and no dumps are getting created.It might be interesting to look at a trace file for this SQL statement with event 10046 at level 12 and event 10053 at level 1 enabled for the session. You may need to modify the query slightly to make certain that a hard parse is required (possibly by specifying a couple of the column names to be returned rather than *). Take a look through the raw trace file for something like this
cost: -1.#IND card: 1.#INFThere is at least one query in the ERP package that I use that will output the following in a 10053 trace when optimizer_features_enable is greater than 10.1.0.4, followed by an ORA-600:
Access Path: index (AllEqUnique)
Index: SYS_C004588
resc_io: 1.00 resc_cpu: 8341
ix_sel: 0.5 ix_sel_with_filters: 0.5
NL Join: Cost: 1.#J Resp: 1.#J Degree: 1
Cost_io: 1.#J Cost_cpu: 1
Resp_io: 1.#J Resp_cpu: 1
Best NL cost: 1797693134862315700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000.00
resc: 3.01 resc_io: 3.00 resc_cpu: 35947
resp: 3.01 resp_io: 3.00 resp_cpu: 35947
Outer Join Card: 1.#J = max ( outer (1.#J), (outer (1.#J) * inner (2.00) * sel (0.5) )
Join Card - Rounded: 1 Computed: 1.#JYou may be experiencing a similar problem that might become evident with both trace events enabled.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
The danger of memory target in Oracle 11g - request for discussion.
Hello, everyone.
This is not a question, but kind of request for discussion.
I believe that many of you heard something about automatic memory management in Oracle 11g.
The concept is that Oracle manages the target size of SGA and PGA. Yes, believe it or not, all we have to do is just to tell Oracle how much memory it can use.
But I have a big concern on this. The optimizer takes the PGA size into consideration when calculating the cost of sort-related operations.
So what would happen when Oracle dynamically changes the target size of PGA? Following is a simple demonstration of my concern.
UKJA@ukja116> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
-- Configuration
*.memory_target=350m
*.memory_max_target=350m
create table t1(c1 int, c2 char(100));
create table t2(c1 int, c2 char(100));
insert into t1 select level, level from dual connect by level <= 10000;
insert into t2 select level, level from dual connect by level <= 10000;
-- First 10053 trace
alter session set events '10053 trace name context forever, level 1';
select /*+ use_hash(t1 t2) */ count(*)
from t1, t2
where t1.c1 = t2.c1 and t1.c2 = t2.c2
alter session set events '10053 trace name context off';
-- Do aggressive hard parse to make Oracle dynamically change the size of memory segments.
declare
pat1 varchar2(1000);
pat2 varchar2(1000);
va number;
vc sys_refcursor;
vs varchar2(1000);
begin
select ksppstvl into pat1
from sys.xm$ksppi i, sys.xm$ksppcv v -- views for x$ table
where i.indx = v.indx
and i.ksppinm = '__pga_aggregate_target';
for idx in 1 .. 10000000 loop
execute immediate 'select count(*) from t1 where rownum = ' || (idx+1)
into va;
if mod(idx, 1000) = 0 then
sys.dbms_system.ksdwrt(2, idx || 'th execution');
select ksppstvl into pat2
from sys.xm$ksppi i, sys.xm$ksppcv v -- views for x$ table
where i.indx = v.indx
and i.ksppinm = '__pga_aggregate_target';
if pat1 <> pat2 then
sys.dbms_system.ksdwrt(2, 'yep, I got it!');
exit;
end if;
end if;
end loop;
end;
-- As to alert log file,
25000th execution
26000th execution
27000th execution
28000th execution
29000th execution
30000th execution
yep, I got it! <-- the pga target changed with 30000th hard parse
-- Second 10053 trace for same query
alter session set events '10053 trace name context forever, level 1';
select /*+ use_hash(t1 t2) */ count(*)
from t1, t2
where t1.c1 = t2.c1 and t1.c2 = t2.c2
alter session set events '10053 trace name context off';With above test case, I found that
1. Oracle invalidates the query when internal pga aggregate size changes, which is quite natural.
2. With changed pga aggregate size, Oracle recalculates the cost. These are excerpts from the both of the 10053 trace files.
-- First 10053 trace file
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
_smm_max_size = 11468 KB
_smm_px_max_size = 28672 KB
optimizer_use_sql_plan_baselines = false
optimizer_use_invisible_indexes = true
-- Second 10053 trace file
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
_smm_max_size = 13107 KB
_smm_px_max_size = 32768 KB
optimizer_use_sql_plan_baselines = false
optimizer_use_invisible_indexes = true
Bug Fix Control Environment10053 trace file clearly says that Oracle recalculates the cost of the query with the change of internal pga aggregate target size. So, there is a great danger of unexpected plan change while Oracle dynamically controls the memory segments.
I believe that this is a desinged behavior, but the negative side effect is not negligible.
I just like to hear your opinions on this behavior.
Do you think that this is acceptable? Or is this another great feature that nobody wants to use like automatic tuning advisor?
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================I made a slight modification with my test case to have mixed workloads of hard parse and logical reads.
*.memory_target=200m
*.memory_max_target=200m
create table t3(c1 int, c2 char(1000));
insert into t3 select level, level from dual connect by level <= 50000;
declare
pat1 varchar2(1000);
pat2 varchar2(1000);
va number;
begin
select ksppstvl into pat1
from sys.xm$ksppi i, sys.xm$ksppcv v
where i.indx = v.indx
and i.ksppinm = '__pga_aggregate_target';
for idx in 1 .. 1000000 loop
-- try many patterns here!
execute immediate 'select count(*) from t3 where 10 = mod('||idx||',10)+1' into va;
if mod(idx, 100) = 0 then
sys.dbms_system.ksdwrt(2, idx || 'th execution');
for p in (select ksppinm, ksppstvl
from sys.xm$ksppi i, sys.xm$ksppcv v
where i.indx = v.indx
and i.ksppinm in ('__shared_pool_size', '__db_cache_size', '__pga_aggregate_target')) loop
sys.dbms_system.ksdwrt(2, p.ksppinm || ' = ' || p.ksppstvl);
end loop;
select ksppstvl into pat2
from sys.xm$ksppi i, sys.xm$ksppcv v
where i.indx = v.indx
and i.ksppinm = '__pga_aggregate_target';
if pat1 <> pat2 then
sys.dbms_system.ksdwrt(2, 'yep, I got it! pat1=' || pat1 ||', pat2='||pat2);
exit;
end if;
end if;
end loop;
end;
/This test case showed expected and reasonable result, like following:
100th execution
__shared_pool_size = 92274688
__db_cache_size = 16777216
__pga_aggregate_target = 83886080
200th execution
__shared_pool_size = 92274688
__db_cache_size = 16777216
__pga_aggregate_target = 83886080
300th execution
__shared_pool_size = 88080384
__db_cache_size = 20971520
__pga_aggregate_target = 83886080
400th execution
__shared_pool_size = 92274688
__db_cache_size = 16777216
__pga_aggregate_target = 83886080
500th execution
__shared_pool_size = 88080384
__db_cache_size = 20971520
__pga_aggregate_target = 83886080
1100th execution
__shared_pool_size = 92274688
__db_cache_size = 20971520
__pga_aggregate_target = 83886080
1200th execution
__shared_pool_size = 92274688
__db_cache_size = 37748736
__pga_aggregate_target = 58720256
yep, I got it! pat1=83886080, pat2=58720256Oracle continued being bounced between shared pool and buffer cache size, and about 1200th execution Oracle suddenly stole some memory from PGA target area to increase db cache size.
(I'm still in dark age on this automatic memory target management of 11g. More research in need!)
I think that this is very clear and natural behavior. I just want to point out that this would result in unwanted catastrophe under special cases, especially with some logic holes and bugs.
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================ -
Help required on UNION ALL for select query
Hello all,
The execution plan for an SQL is impacted when another SELECT is concatenated with a UNION ALL. The two SELECTS are very efficient when run separately (< 100 buffer gets), but when run together (using a UNION ALL), the execution plan changes (for the first SELECT) and the buffer gets jumps to over 45000!
what customer says with the UNION ALL, Oracle instead of doing a Merge Scan (that allows the inner table to filter out the rows from the outer table), chooses to do a NL join. This results in a Unique Index scan for each one of the 15000 rows in the outer table, resulting in 46000 consistent gets.
Can you please suggest customer why plan changes when they use UNION ALL & also suggest better way of running query.
Please refer to below explain plan .
WITH THE UNIONS
===============
1 SELECT count(*)
2 FROM SOC_LIST SOC
3 WHERE
4 ( EXISTS( SELECT 1
5 FROM ELIGIBILITY_RELATION
6 WHERE SRC_CODE = 'SHDMM4215'
7 AND DEST_CODE = SOC.SOC
8 AND SRC_TYPE = 'P'
9 AND DEST_TYPE = 'S'))
10 UNION ALL
11 SELECT count(*)
12 FROM SOC_LIST SOC
13* WHERE ( = 'Y')
12:25:39 SQL> /
COUNT(*)
153
0
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=31 Card=2 Bytes=10)
1 0 UNION-ALL
2 1 SORT (AGGREGATE)
3 2 FILTER
4 3 TABLE ACCESS (FULL) OF 'SOC_LIST' (Cost=15 Card=749
Bytes=7490)
5 3 PARTITION HASH (SINGLE)
6 5 INDEX (UNIQUE SCAN) OF 'ELIGIBILITY_RELATION_PK' (
UNIQUE) (Cost=2 Card=1 Bytes=24)
7 1 SORT (AGGREGATE)
8 7 FILTER
9 8 TABLE ACCESS (FULL) OF 'SOC_LIST' (Cost=15 Card=1497
8)
Statistics
0 recursive calls
0 db block gets
46712 consistent gets <------large number
0 physical reads
0 redo size
215 bytes sent via SQL*Net to client
241 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
12:25:40 SQL> ed
Wrote file C:/PADDY/AFIEDT.BUF
PART 1 of the UNION ALL
========================
1 SELECT count(*)
2 FROM SOC_LIST SOC
3 WHERE
4 ( EXISTS( SELECT 1
5 FROM ELIGIBILITY_RELATION
6 WHERE SRC_CODE = 'SHDMM4215'
7 AND DEST_CODE = SOC.SOC
8 AND SRC_TYPE = 'P'
9* AND DEST_TYPE = 'S'))
12:25:54 SQL> /
COUNT(*)
153
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=34)
1 0 SORT (AGGREGATE)
2 1 MERGE JOIN (SEMI) (Cost=4 Card=149 Bytes=5066)
3 2 INDEX (FULL SCAN) OF 'SOC_LIST_1IX' (NON-UNIQUE) (Cost
=41 Card=14978 Bytes=149780)
4 2 SORT (UNIQUE) (Cost=3 Card=149 Bytes=3576)
5 4 PARTITION HASH (ALL)
6 5 INDEX (RANGE SCAN) OF 'ELIGIBILITY_RELATION_PK' (U
NIQUE) (Cost=10 Card=149 Bytes=3576)
Statistics
0 recursive calls
0 db block gets
56 consistent gets
0 physical reads
0 redo size
218 bytes sent via SQL*Net to client
241 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
12:25:55 SQL> ed
Wrote file C:/PADDY/AFIEDT.BUF
PART 2 of the UNION ALL
========================
1 SELECT count(*)
2 FROM SOC_LIST SOC
3* WHERE ( = 'Y')
12:26:15 SQL> /
COUNT(*)
0
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=15 Card=1)
1 0 SORT (AGGREGATE)
2 1 FILTER
3 2 TABLE ACCESS (FULL) OF 'SOC_LIST' (Cost=15 Card=14978)
Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
215 bytes sent via SQL*Net to client
241 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
12:26:20 SQL> spool off
Same results but with theUNION ALL, the buffergets is massive ...
Thanks
Krishnai am also attaching 10043/10053 trace file .
/opt/oracle/adm/STCUST/udump/stcust_ora_7919_10046_10053_trace_file.trc
*** TRACE DUMP CONTINUED FROM FILE ***
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /opt/oracle/product/9.2.0.8
System name: HP-UX
Node name: rcihp009
Release: B.11.23
Version: U
Machine: 9000/800
Instance name: STCUST
Redo thread mounted by this instance: 1
Oracle process number: 152
Unix process pid: 7919, image: oracle@rcihp009 (TNS V1-V3)
*** 2013-06-10 13:32:48.943
*** SESSION ID:(533.15875) 2013-06-10 13:32:48.943
APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240
=====================
PARSING IN CURSOR #1 len=69 dep=0 uid=33 oct=42 lid=33 tim=3017585934213 hv=2004533713 ad='4aa33998'
alter session set events '10046 trace name context forever, level 12'
END OF STMT
EXEC #1:c=0,e=209,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3017585933683
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:33:00.090
WAIT #1: nam='SQL*Net message from client' ela= 10884599 p1=1413697536 p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=69 dep=0 uid=33 oct=42 lid=33 tim=3017596819944 hv=2030017677 ad='3af92970'
alter session set events '10053 trace name context forever, level 1'
END OF STMT
PARSE #1:c=0,e=484,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3017596819933
BINDS #1:
EXEC #1:c=0,e=160,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017596820180
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:33:50.197
WAIT #1: nam='SQL*Net message from client' ela= 48932344 p1=1413697536 p2=1 p3=0
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
_OPTIMIZER_PERCENT_PARALLEL = 101
HASH_AREA_SIZE = 131072
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 65536
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
_ALWAYS_STAR_TRANSFORMATION = FALSE
_B_TREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
_COMPLEX_VIEW_MERGING = TRUE
_PUSH_JOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
_SYSTEM_INDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 1
OPTIMIZER_DYNAMIC_SAMPLING = 1
_OPTIMIZER_DYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = ENFORCED
_INDEX_JOIN_ENABLED = TRUE
_SORT_ELIMINATION_COST_RATIO = 0
_OR_EXPAND_NVL_PREDICATE = TRUE
_NEW_INITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
_OPTIMIZER_MODE_FORCE = TRUE
_OPTIMIZER_UNDO_CHANGES = FALSE
_UNNEST_SUBQUERY = TRUE
_PUSH_JOIN_UNION_VIEW = TRUE
_FAST_FULL_SCAN_ENABLED = TRUE
_OPTIM_ENHANCE_NNULL_DETECTION = TRUE
_ORDERED_NESTED_LOOP = TRUE
_NESTED_LOOP_FUDGE = 100
_NO_OR_EXPANSION = FALSE
_QUERY_COST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
_IMPROVED_ROW_LENGTH_ENABLED = TRUE
_USE_NOSEGMENT_INDEXES = FALSE
_ENABLE_TYPE_DEP_SELECTIVITY = TRUE
_IMPROVED_OUTERJOIN_CARD = TRUE
_OPTIMIZER_ADJUST_FOR_NULLS = TRUE
_OPTIMIZER_CHOOSE_PERMUTATION = 0
_USE_COLUMN_STATS_FOR_FUNCTION = TRUE
_SUBQUERY_PRUNING_ENABLED = TRUE
_SUBQUERY_PRUNING_REDUCTION_FACTOR = 50
_SUBQUERY_PRUNING_COST_FACTOR = 20
_LIKE_WITH_BIND_AS_EQUALITY = FALSE
_TABLE_SCAN_COST_PLUS_ONE = TRUE
_SORTMERGE_INEQUALITY_JOIN_OFF = FALSE
_DEFAULT_NON_EQUALITY_SEL_CHECK = TRUE
_ONESIDE_COLSTAT_FOR_EQUIJOINS = TRUE
_OPTIMIZER_COST_MODEL = CHOOSE
_GSETS_ALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 128
_NEW_SORT_COST_ESTIMATE = TRUE
_GS_ANTI_SEMI_JOIN_ALLOWED = TRUE
_CPU_TO_IO = 0
_PRED_MOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: SOC_LIST Alias: SOC
TOTAL :: CDN: 17584 NBLKS: 653 AVG_ROW_LEN: 260
Column: SOC Col#: 3 Table: SOC_LIST Alias: SOC
NDV: 17584 NULLS: 0 DENS: 5.6870e-05
NO HISTOGRAM: #BKT: 1 #VAL: 2
-- Index stats
INDEX NAME: I_SNAP$_SOC_LIST COL#: 1
TOTAL :: LVLS: 1 #LB: 64 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 699
INDEX NAME: SOC_LIST_1IX COL#: 3
TOTAL :: LVLS: 1 #LB: 47 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 14065
Table stats Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
(Using composite stats)
TOTAL :: CDN: 11982220 NBLKS: 125493 AVG_ROW_LEN: 71
-- Index stats
INDEX NAME: ELIGIBILITY_RELATION_1IX COL#: 3 4 5
USING COMPOSITE STATS
TOTAL :: LVLS: 2 #LB: 38360 #DK: 4164 LB/K: 9 DB/K: 740 CLUF: 3081860
INDEX NAME: ELIGIBILITY_RELATION_PK COL#: 2 3 4 5
USING COMPOSITE STATS
TOTAL :: LVLS: 2 #LB: 50740 #DK: 11873160 LB/K: 1 DB/K: 1 CLUF: 9158280
INDEX NAME: I_SNAP$_ELIGIBILITY_RELATI COL#: 1
TOTAL :: LVLS: 2 #LB: 49600 #DK: 11953600 LB/K: 1 DB/K: 1 CLUF: 8833300
_OPTIMIZER_PERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
Column: SRC_CODE Col#: 2 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 22087 NULLS: 0 DENS: 4.5276e-05
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: SRC_TYPE Col#: 3 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 2 NULLS: 0 DENS: 5.0000e-01
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: DEST_TYPE Col#: 5 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 2 NULLS: 0 DENS: 5.0000e-01
NO HISTOGRAM: #BKT: 1 #VAL: 2
TABLE: ELIGIBILITY_RELATION ORIG CDN: 11982220 ROUNDED CDN: 136 CMPTD CDN: 136
Access path: tsc Resc: 3072 Resp: 3072
Access path: index (iff)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 1243
IX_SEL: 0.0000e+00 TB_SEL: 1.0000e+00
Access path: iff Resc: 1243 Resp: 1243
Skip scan: ss-sel 0 andv 11970
ss cost 119700
index io scan cost 19180
Access path: index (scan)
Index: ELIGIBILITY_RELATION_1IX
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 789653
IX_SEL: 5.0000e-01 TB_SEL: 2.5000e-01
Skip scan: ss-sel 0 andv 11970
ss cost 11970
index io scan cost 2
Access path: index (index-only)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 10
IX_SEL: 2.2638e-05 TB_SEL: 2.2638e-05
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
BEST_CST: 1.00 PATH: 4 Degree: 1
SINGLE TABLE ACCESS PATH
TABLE: SOC_LIST ORIG CDN: 17584 ROUNDED CDN: 17584 CMPTD CDN: 17584
Access path: tsc Resc: 18 Resp: 18
Access path: index (iff)
Index: SOC_LIST_1IX
TABLE: SOC_LIST
RSC_CPU: 0 RSC_IO: 3
IX_SEL: 0.0000e+00 TB_SEL: 1.0000e+00
Access path: iff Resc: 3 Resp: 3
Access path: index (no sta/stp keys)
Index: SOC_LIST_1IX
TABLE: SOC_LIST
RSC_CPU: 0 RSC_IO: 48
IX_SEL: 1.0000e+00 TB_SEL: 1.0000e+00
BEST_CST: 1.00 PATH: 4 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: SOC_LIST[SOC]#0 ELIGIBILITY_RELATION[ELIGIBILITY_RELATION]#1
Now joining: ELIGIBILITY_RELATION[ELIGIBILITY_RELATION]#1 *******
NL Join
Outer table: cost: 1 cdn: 17584 rcz: 10 resp: 1
Inner table: ELIGIBILITY_RELATION
Access path: tsc Resc: 768
Join: Resc: 13504513 Resp: 13504513
Access path: index (iff)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 1243
IX_SEL: 0.0000e+00 TB_SEL: 1.0000e+00
Inner table: ELIGIBILITY_RELATION
Access path: iff Resc: 311
Join: Resc: 5464229 Resp: 5464229
Access path: index (unique)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 1
IX_SEL: 8.3457e-08 TB_SEL: 8.3457e-08
Join: resc: 177 resp: 177
Access path: index (join index)
Index: ELIGIBILITY_RELATION_1IX
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 750
IX_SEL: 0.0000e+00 TB_SEL: 2.0886e-05
Join: resc: 131881 resp: 131881
Access path: index (eq-unique)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 1
IX_SEL: 0.0000e+00 TB_SEL: 0.0000e+00
Join: resc: 177 resp: 177
****** trying bitmap/domain indexes ******
Access path: index (join index)
Index: ELIGIBILITY_RELATION_1IX
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 10
IX_SEL: 1.4217e-05 TB_SEL: 2.0886e-05
Join: resc: 1759 resp: 1759
Access path: index (index-only)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 4.5276e-05 TB_SEL: 4.5276e-05
Join: resc: 704 resp: 704
SORT resource Sort statistics
Sort width: 11 Area size: 628736 Max Area size: 31457280 Degree: 1
Blocks to Sort: 2 Row size: 21 Rows: 543
Initial runs: 1 Merge passes: 1 IO Cost / pass: 3
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
****** finished trying bitmap/domain indexes ******
Best NL cost: 177 resp: 177
Semi-join cardinality: 135 = outer (17584) * sel (7.6774e-03) [flag=12]
SM Join
Outer table:
resc: 1 cdn: 17584 rcz: 10 deg: 1 resp: 1
Inner table: ELIGIBILITY_RELATION
resc: 1 cdn: 136 rcz: 24 deg: 1 resp: 1
using join:1 distribution:2 #groups:1
SORT resource Sort statistics
Sort width: 11 Area size: 628736 Max Area size: 31457280 Degree: 1
Blocks to Sort: 1 Row size: 37 Rows: 136
Initial runs: 1 Merge passes: 1 IO Cost / pass: 2
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
Merge join Cost: 4 Resp: 4
HA Join
Outer table:
resc: 1 cdn: 17584 rcz: 10 deg: 1 resp: 1
Inner table: ELIGIBILITY_RELATION
resc: 1 cdn: 136 rcz: 24 deg: 1 resp: 1
using join:8 distribution:2 #groups:1
Hash join one ptn Resc: 4 Deg: 1
hash_area: 154 (max=7680) buildfrag: 48 probefrag: 1 ppasses: 1
Hash join Resc: 6 Resp: 6
Join result: cost: 4 cdn: 135 rcz: 34
Best so far: TABLE#: 0 CST: 1 CDN: 17584 BYTES: 175840
Best so far: TABLE#: 1 CST: 4 CDN: 135 BYTES: 4590
Join order[2]: ELIGIBILITY_RELATION[ELIGIBILITY_RELATION]#1 SOC_LIST[SOC]#0
SORT resource Sort statistics
Sort width: 11 Area size: 628736 Max Area size: 31457280 Degree: 1
Blocks to Sort: 1 Row size: 37 Rows: 136
Initial runs: 1 Merge passes: 1 IO Cost / pass: 2
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
Now joining: SOC_LIST[SOC]#0 *******
NL Join
Outer table: cost: 3 cdn: 136 rcz: 24 resp: 2
Inner table: SOC_LIST
Access path: tsc Resc: 18
Join: Resc: 2450 Resp: 2450
Access path: index (iff)
Index: SOC_LIST_1IX
TABLE: SOC_LIST
RSC_CPU: 0 RSC_IO: 3
IX_SEL: 0.0000e+00 TB_SEL: 1.0000e+00
Inner table: SOC_LIST
Access path: iff Resc: 3
Join: Resc: 410 Resp: 410
Access path: index (join index)
Index: SOC_LIST_1IX
TABLE: SOC_LIST
RSC_CPU: 0 RSC_IO: 1
IX_SEL: 0.0000e+00 TB_SEL: 5.6870e-05
Join: resc: 4 resp: 4
Best NL cost: 4 resp: 4
Join cardinality: 136 = outer (136) * inner (17584) * sel (5.6870e-05) [flag=0]
SM Join
Outer table:
resc: 2 cdn: 136 rcz: 24 deg: 1 resp: 2
Inner table: SOC_LIST
resc: 1 cdn: 17584 rcz: 10 deg: 1 resp: 1
using join:1 distribution:2 #groups:1
SORT resource Sort statistics
Sort width: 11 Area size: 628736 Max Area size: 31457280 Degree: 1
Blocks to Sort: 1 Row size: 37 Rows: 136
Initial runs: 1 Merge passes: 1 IO Cost / pass: 2
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 11 Area size: 628736 Max Area size: 31457280 Degree: 1
Blocks to Sort: 46 Row size: 21 Rows: 17584
Initial runs: 1 Merge passes: 1 IO Cost / pass: 51
Total IO sort cost: 48
Total CPU sort cost: 0
Total Temp space used: 0
Merge join Cost: 54 Resp: 54
HA Join
Outer table:
resc: 2 cdn: 136 rcz: 24 deg: 1 resp: 2
Inner table: SOC_LIST
resc: 1 cdn: 17584 rcz: 10 deg: 1 resp: 1
using join:8 distribution:2 #groups:1
Hash join one ptn Resc: 1 Deg: 1
hash_area: 154 (max=7680) buildfrag: 1 probefrag: 48 ppasses: 1
Hash join Resc: 4 Resp: 4
Final - All Rows Plan:
JOIN ORDER: 1
CST: 4 CDN: 135 RSC: 4 RSP: 4 BYTES: 4590
IO-RSC: 4 IO-RSP: 4 CPU-RSC: 0 CPU-RSP: 0
QUERY
SELECT count(*)
FROM SOC_LIST SOC
WHERE
( EXISTS( SELECT 1
FROM ELIGIBILITY_RELATION
WHERE SRC_CODE = 'SHDMM4215'
AND DEST_CODE = SOC.SOC
AND SRC_TYPE = 'P'
AND DEST_TYPE = 'S'))
=====================
PARSING IN CURSOR #1 len=278 dep=0 uid=33 oct=3 lid=33 tim=3017645761269 hv=183981413 ad='492d5bb0'
SELECT count(*)
FROM SOC_LIST SOC
WHERE
( EXISTS( SELECT 1
FROM ELIGIBILITY_RELATION
WHERE SRC_CODE = 'SHDMM4215'
AND DEST_CODE = SOC.SOC
AND SRC_TYPE = 'P'
AND DEST_TYPE = 'S'))
END OF STMT
PARSE #1:c=10000,e=8343,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3017645761258
BINDS #1:
EXEC #1:c=0,e=529,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017645761970
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
WAIT #1: nam='db file sequential read' ela= 9290 p1=2535 p2=142378 p3=1
WAIT #1: nam='db file sequential read' ela= 2098 p1=2535 p2=142379 p3=1
WAIT #1: nam='db file sequential read' ela= 11574 p1=2535 p2=33834 p3=1
WAIT #1: nam='db file sequential read' ela= 10290 p1=2536 p2=60958 p3=1
WAIT #1: nam='db file sequential read' ela= 11469 p1=2535 p2=61232 p3=1
WAIT #1: nam='db file sequential read' ela= 378 p1=2535 p2=61233 p3=1
WAIT #1: nam='db file sequential read' ela= 5493 p1=2535 p2=39498 p3=1
WAIT #1: nam='db file sequential read' ela= 7397 p1=2536 p2=68185 p3=1
WAIT #1: nam='db file sequential read' ela= 10037 p1=2536 p2=68520 p3=1
WAIT #1: nam='db file sequential read' ela= 16125 p1=2535 p2=68809 p3=1
WAIT #1: nam='db file sequential read' ela= 12426 p1=2535 p2=45162 p3=1
WAIT #1: nam='db file sequential read' ela= 12447 p1=2535 p2=178335 p3=1
WAIT #1: nam='db file sequential read' ela= 5974 p1=2535 p2=178798 p3=1
WAIT #1: nam='db file sequential read' ela= 1247 p1=2535 p2=178799 p3=1
WAIT #1: nam='db file sequential read' ela= 11010 p1=2535 p2=50826 p3=1
WAIT #1: nam='db file sequential read' ela= 5421 p1=2536 p2=260451 p3=1
WAIT #1: nam='db file sequential read' ela= 8230 p1=2536 p2=261538 p3=1
WAIT #1: nam='db file sequential read' ela= 350 p1=2535 p2=142380 p3=1
WAIT #1: nam='db file sequential read' ela= 346 p1=2535 p2=142381 p3=1
WAIT #1: nam='db file sequential read' ela= 343 p1=2535 p2=142382 p3=1
WAIT #1: nam='db file sequential read' ela= 480 p1=2535 p2=142383 p3=1
WAIT #1: nam='db file sequential read' ela= 10237 p1=2535 p2=142384 p3=1
WAIT #1: nam='db file sequential read' ela= 324 p1=2535 p2=142385 p3=1
WAIT #1: nam='db file sequential read' ela= 359 p1=2535 p2=142386 p3=1
WAIT #1: nam='db file sequential read' ela= 361 p1=2535 p2=142387 p3=1
WAIT #1: nam='db file sequential read' ela= 375 p1=2535 p2=142388 p3=1
WAIT #1: nam='db file sequential read' ela= 425 p1=2535 p2=142389 p3=1
WAIT #1: nam='db file sequential read' ela= 540 p1=2535 p2=142390 p3=1
WAIT #1: nam='db file sequential read' ela= 368 p1=2535 p2=142391 p3=1
WAIT #1: nam='db file sequential read' ela= 479 p1=2535 p2=142392 p3=1
WAIT #1: nam='db file sequential read' ela= 450 p1=2535 p2=142393 p3=1
WAIT #1: nam='db file sequential read' ela= 307 p1=2535 p2=142394 p3=1
WAIT #1: nam='db file sequential read' ela= 324 p1=2535 p2=142395 p3=1
WAIT #1: nam='db file sequential read' ela= 396 p1=2535 p2=142396 p3=1
WAIT #1: nam='db file sequential read' ela= 376 p1=2535 p2=142397 p3=1
WAIT #1: nam='db file sequential read' ela= 295 p1=2535 p2=142398 p3=1
WAIT #1: nam='db file sequential read' ela= 391 p1=2535 p2=142399 p3=1
WAIT #1: nam='db file sequential read' ela= 396 p1=2535 p2=142400 p3=1
WAIT #1: nam='db file sequential read' ela= 344 p1=2535 p2=142401 p3=1
WAIT #1: nam='db file sequential read' ela= 337 p1=2535 p2=142402 p3=1
WAIT #1: nam='db file sequential read' ela= 360 p1=2535 p2=142403 p3=1
WAIT #1: nam='db file sequential read' ela= 402 p1=2535 p2=142404 p3=1
WAIT #1: nam='db file sequential read' ela= 343 p1=2535 p2=142405 p3=1
WAIT #1: nam='db file sequential read' ela= 408 p1=2535 p2=142406 p3=1
WAIT #1: nam='db file sequential read' ela= 388 p1=2535 p2=142407 p3=1
WAIT #1: nam='db file sequential read' ela= 400 p1=2535 p2=142408 p3=1
WAIT #1: nam='db file sequential read' ela= 7999 p1=2536 p2=617 p3=1
WAIT #1: nam='db file sequential read' ela= 520 p1=2536 p2=618 p3=1
WAIT #1: nam='db file sequential read' ela= 294 p1=2536 p2=619 p3=1
WAIT #1: nam='db file sequential read' ela= 311 p1=2536 p2=620 p3=1
WAIT #1: nam='db file sequential read' ela= 316 p1=2536 p2=621 p3=1
WAIT #1: nam='db file sequential read' ela= 306 p1=2536 p2=622 p3=1
WAIT #1: nam='db file sequential read' ela= 303 p1=2536 p2=623 p3=1
WAIT #1: nam='db file sequential read' ela= 1776 p1=2536 p2=624 p3=1
FETCH #1:c=50000,e=216800,p=54,cr=54,cu=0,mis=0,r=1,dep=0,og=4,tim=3017645978865
WAIT #1: nam='SQL*Net message from client' ela= 2802 p1=1413697536 p2=1 p3=0
FETCH #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=3017645981803
WAIT #1: nam='SQL*Net message to client' ela= 1 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:34:28.160
WAIT #1: nam='SQL*Net message from client' ela= 36844121 p1=1413697536 p2=1 p3=0
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=54 r=54 w=0 time=216788 us)'
STAT #1 id=2 cnt=157 pid=1 pos=1 obj=0 op='MERGE JOIN SEMI (cr=54 r=54 w=0 time=216734 us)'
STAT #1 id=3 cnt=14296 pid=2 pos=1 obj=5769123 op='INDEX FULL SCAN SOC_LIST_1IX (cr=39 r=39 w=0 time=55399 us)'
STAT #1 id=4 cnt=157 pid=2 pos=2 obj=0 op='SORT UNIQUE (cr=15 r=15 w=0 time=141933 us)'
STAT #1 id=5 cnt=286 pid=4 pos=1 obj=0 op='PARTITION HASH ALL PARTITION: 1 4 (cr=15 r=15 w=0 time=130847 us)'
STAT #1 id=6 cnt=286 pid=5 pos=1 obj=5401812 op='INDEX RANGE SCAN ELIGIBILITY_RELATION_PK PARTITION: 1 4 (cr=15 r=15 w=0 time=130716 us)'
QUERY
BEGIN := 'N'; END;
=====================
PARSING IN CURSOR #1 len=23 dep=0 uid=33 oct=47 lid=33 tim=3017682828223 hv=16287806 ad='464edb18'
BEGIN := 'N'; END;
END OF STMT
PARSE #1:c=0,e=1569,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=3017682828214
BINDS #1:
bind 0: dty=96 mxl=01(01) mal=00 scl=00 pre=00 oacflg=03 oacfl2=200071100000000 size=8 offset=0
bfp=800003ffefe9f748 bln=01 avl=00 flg=05
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
EXEC #1:c=0,e=5494,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=3017682833795
*** 2013-06-10 13:34:44.174
WAIT #1: nam='SQL*Net message from client' ela= 15630899 p1=1413697536 p2=1 p3=0
QUERY
SELECT count(*)
FROM SOC_LIST SOC
WHERE ( = 'Y')
=====================
PARSING IN CURSOR #1 len=65 dep=0 uid=33 oct=3 lid=33 tim=3017698466665 hv=900106749 ad='43145458'
SELECT count(*)
FROM SOC_LIST SOC
WHERE ( = 'Y')
END OF STMT
PARSE #1:c=0,e=1409,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=3017698466654
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
_OPTIMIZER_PERCENT_PARALLEL = 101
HASH_AREA_SIZE = 131072
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 65536
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
_ALWAYS_STAR_TRANSFORMATION = FALSE
_B_TREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
_COMPLEX_VIEW_MERGING = TRUE
_PUSH_JOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
_SYSTEM_INDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 1
OPTIMIZER_DYNAMIC_SAMPLING = 1
_OPTIMIZER_DYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = ENFORCED
_INDEX_JOIN_ENABLED = TRUE
_SORT_ELIMINATION_COST_RATIO = 0
_OR_EXPAND_NVL_PREDICATE = TRUE
_NEW_INITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
_OPTIMIZER_MODE_FORCE = TRUE
_OPTIMIZER_UNDO_CHANGES = FALSE
_UNNEST_SUBQUERY = TRUE
_PUSH_JOIN_UNION_VIEW = TRUE
_FAST_FULL_SCAN_ENABLED = TRUE
_OPTIM_ENHANCE_NNULL_DETECTION = TRUE
_ORDERED_NESTED_LOOP = TRUE
_NESTED_LOOP_FUDGE = 100
_NO_OR_EXPANSION = FALSE
_QUERY_COST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
_IMPROVED_ROW_LENGTH_ENABLED = TRUE
_USE_NOSEGMENT_INDEXES = FALSE
_ENABLE_TYPE_DEP_SELECTIVITY = TRUE
_IMPROVED_OUTERJOIN_CARD = TRUE
_OPTIMIZER_ADJUST_FOR_NULLS = TRUE
_OPTIMIZER_CHOOSE_PERMUTATION = 0
_USE_COLUMN_STATS_FOR_FUNCTION = TRUE
_SUBQUERY_PRUNING_ENABLED = TRUE
_SUBQUERY_PRUNING_REDUCTION_FACTOR = 50
_SUBQUERY_PRUNING_COST_FACTOR = 20
_LIKE_WITH_BIND_AS_EQUALITY = FALSE
_TABLE_SCAN_COST_PLUS_ONE = TRUE
_SORTMERGE_INEQUALITY_JOIN_OFF = FALSE
_DEFAULT_NON_EQUALITY_SEL_CHECK = TRUE
_ONESIDE_COLSTAT_FOR_EQUIJOINS = TRUE
_OPTIMIZER_COST_MODEL = CHOOSE
_GSETS_ALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 128
_NEW_SORT_COST_ESTIMATE = TRUE
_GS_ANTI_SEMI_JOIN_ALLOWED = TRUE
_CPU_TO_IO = 0
_PRED_MOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: SOC_LIST Alias: SOC
TOTAL :: CDN: 17584 NBLKS: 653 AVG_ROW_LEN: 260
-- Index stats
INDEX NAME: I_SNAP$_SOC_LIST COL#: 1
TOTAL :: LVLS: 1 #LB: 64 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 699
INDEX NAME: SOC_LIST_1IX COL#: 3
TOTAL :: LVLS: 1 #LB: 47 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 14065
_OPTIMIZER_PERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
TABLE: SOC_LIST ORIG CDN: 17584 ROUNDED CDN: 17584 CMPTD CDN: 17584
Access path: tsc Resc: 18 Resp: 18
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
BEST_CST: 18.00 PATH: 2 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: SOC_LIST[SOC]#0
Best so far: TABLE#: 0 CST: 18 CDN: 17584 BYTES: 0
Final - All Rows Plan:
JOIN ORDER: 1
CST: 18 CDN: 17584 RSC: 18 RSP: 18 BYTES: 0
IO-RSC: 18 IO-RSP: 18 CPU-RSC: 0 CPU-RSP: 0
BINDS #1:
bind 0: dty=96 mxl=32(01) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=32 offset=0
bfp=800003ffefea9490 bln=32 avl=01 flg=05
value="N"
EXEC #1:c=0,e=152,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017698469481
WAIT #1: nam='SQL*Net message to client' ela= 4 p1=1413697536 p2=1 p3=0
FETCH #1:c=10000,e=1506,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=3017698471536
WAIT #1: nam='SQL*Net message from client' ela= 2607 p1=1413697536 p2=1 p3=0
FETCH #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=3017698474268
WAIT #1: nam='SQL*Net message to client' ela= 1 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:35:07.656
WAIT #1: nam='SQL*Net message from client' ela= 22922584 p1=1413697536 p2=1 p3=0
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=0 r=0 w=0 time=93 us)'
STAT #1 id=2 cnt=0 pid=1 pos=1 obj=0 op='FILTER (cr=0 r=0 w=0 time=29 us)'
STAT #1 id=3 cnt=0 pid=2 pos=1 obj=5769120 op='TABLE ACCESS FULL SOC_LIST '
=====================
PARSE ERROR #1:len=369 dep=0 uid=33 oct=0 lid=33 tim=3017721397730 err=900
exec := 'N'
SELEC ...
WAIT #1: nam='SQL*Net break/reset to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net break/reset to client' ela= 2403 p1=1413697536 p2=0 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:35:24.017
WAIT #1: nam='SQL*Net message from client' ela= 15973854 p1=1413697536 p2=1 p3=0
QUERY
SELECT count(*)
FROM SOC_LIST SOC
WHERE
( EXISTS( SELECT 1
FROM ELIGIBILITY_RELATION
WHERE SRC_CODE = 'SHDMM4215'
AND DEST_CODE = SOC.SOC
AND SRC_TYPE = 'P'
AND DEST_TYPE = 'S'))
UNION ALL
SELECT count(*)
FROM SOC_LIST SOC
WHERE ( = 'Y')
=====================
PARSING IN CURSOR #1 len=353 dep=0 uid=33 oct=3 lid=33 tim=3017737377655 hv=4202798596 ad='45639568'
SELECT count(*)
FROM SOC_LIST SOC
WHERE
( EXISTS( SELECT 1
FROM ELIGIBILITY_RELATION
WHERE SRC_CODE = 'SHDMM4215'
AND DEST_CODE = SOC.SOC
AND SRC_TYPE = 'P'
AND DEST_TYPE = 'S'))
UNION ALL
SELECT count(*)
FROM SOC_LIST SOC
WHERE ( = 'Y')
END OF STMT
PARSE #1:c=0,e=2624,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=3017737377644
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
_OPTIMIZER_PERCENT_PARALLEL = 101
HASH_AREA_SIZE = 131072
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 65536
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
_ALWAYS_STAR_TRANSFORMATION = FALSE
_B_TREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
_COMPLEX_VIEW_MERGING = TRUE
_PUSH_JOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
_SYSTEM_INDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 1
OPTIMIZER_DYNAMIC_SAMPLING = 1
_OPTIMIZER_DYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = ENFORCED
_INDEX_JOIN_ENABLED = TRUE
_SORT_ELIMINATION_COST_RATIO = 0
_OR_EXPAND_NVL_PREDICATE = TRUE
_NEW_INITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
_OPTIMIZER_MODE_FORCE = TRUE
_OPTIMIZER_UNDO_CHANGES = FALSE
_UNNEST_SUBQUERY = TRUE
_PUSH_JOIN_UNION_VIEW = TRUE
_FAST_FULL_SCAN_ENABLED = TRUE
_OPTIM_ENHANCE_NNULL_DETECTION = TRUE
_ORDERED_NESTED_LOOP = TRUE
_NESTED_LOOP_FUDGE = 100
_NO_OR_EXPANSION = FALSE
_QUERY_COST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
_IMPROVED_ROW_LENGTH_ENABLED = TRUE
_USE_NOSEGMENT_INDEXES = FALSE
_ENABLE_TYPE_DEP_SELECTIVITY = TRUE
_IMPROVED_OUTERJOIN_CARD = TRUE
_OPTIMIZER_ADJUST_FOR_NULLS = TRUE
_OPTIMIZER_CHOOSE_PERMUTATION = 0
_USE_COLUMN_STATS_FOR_FUNCTION = TRUE
_SUBQUERY_PRUNING_ENABLED = TRUE
_SUBQUERY_PRUNING_REDUCTION_FACTOR = 50
_SUBQUERY_PRUNING_COST_FACTOR = 20
_LIKE_WITH_BIND_AS_EQUALITY = FALSE
_TABLE_SCAN_COST_PLUS_ONE = TRUE
_SORTMERGE_INEQUALITY_JOIN_OFF = FALSE
_DEFAULT_NON_EQUALITY_SEL_CHECK = TRUE
_ONESIDE_COLSTAT_FOR_EQUIJOINS = TRUE
_OPTIMIZER_COST_MODEL = CHOOSE
_GSETS_ALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 128
_NEW_SORT_COST_ESTIMATE = TRUE
_GS_ANTI_SEMI_JOIN_ALLOWED = TRUE
_CPU_TO_IO = 0
_PRED_MOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
(Using composite stats)
(adjusted for partition skews)
ORIG STATS:: CDN: 11982220 NBLKS: 125493 AVG_ROW_LEN: 71
PARTCNT::
PRUNED: 4 ANALYZED: 4 UNANALYZED: 0
TOTAL :: CDN: 11982220 NBLKS: 125493 AVG_ROW_LEN: 71
-- Index stats
INDEX NAME: ELIGIBILITY_RELATION_1IX COL#: 3 4 5
USING COMPOSITE STATS
TOTAL :: LVLS: 2 #LB: 38360 #DK: 4164 LB/K: 9 DB/K: 740 CLUF: 3081860
INDEX NAME: ELIGIBILITY_RELATION_PK COL#: 2 3 4 5
USING COMPOSITE STATS
TOTAL :: LVLS: 2 #LB: 50740 #DK: 11873160 LB/K: 1 DB/K: 1 CLUF: 9158280
INDEX NAME: I_SNAP$_ELIGIBILITY_RELATI COL#: 1
TOTAL :: LVLS: 2 #LB: 49600 #DK: 11953600 LB/K: 1 DB/K: 1 CLUF: 8833300
_OPTIMIZER_PERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
Column: SRC_CODE Col#: 2 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 22087 NULLS: 0 DENS: 4.5276e-05
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: DEST_CODE Col#: 4 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 11970 NULLS: 0 DENS: 8.3542e-05
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: SRC_TYPE Col#: 3 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 2 NULLS: 0 DENS: 5.0000e-01
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: DEST_TYPE Col#: 5 Table: ELIGIBILITY_RELATION Alias: ELIGIBILITY_RELATION
NDV: 2 NULLS: 0 DENS: 5.0000e-01
NO HISTOGRAM: #BKT: 1 #VAL: 2
TABLE: ELIGIBILITY_RELATION ORIG CDN: 11982220 ROUNDED CDN: 1 CMPTD CDN: 0
Access path: tsc Resc: 3072 Resp: 3072
Access path: index (iff)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 1243
IX_SEL: 0.0000e+00 TB_SEL: 1.0000e+00
Access path: iff Resc: 1243 Resp: 1243
Access path: index (unique)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 2
IX_SEL: 8.3457e-08 TB_SEL: 8.3457e-08
Access path: index (equal)
Index: ELIGIBILITY_RELATION_1IX
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 68
IX_SEL: 0.0000e+00 TB_SEL: 2.0886e-05
Access path: index (eq-unique)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 2
IX_SEL: 0.0000e+00 TB_SEL: 0.0000e+00
****** trying bitmap/domain indexes ******
Access path: index (equal)
Index: ELIGIBILITY_RELATION_1IX
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 3
IX_SEL: 2.0886e-05 TB_SEL: 2.0886e-05
Access path: index (index-only)
Index: ELIGIBILITY_RELATION_PK
TABLE: ELIGIBILITY_RELATION
RSC_CPU: 0 RSC_IO: 5
IX_SEL: 4.5276e-05 TB_SEL: 4.5276e-05
SORT resource Sort statistics
Sort width: 11 Area size: 628736 Max Area size: 31457280 Degree: 1
Blocks to Sort: 2 Row size: 21 Rows: 543
Initial runs: 1 Merge passes: 1 IO Cost / pass: 3
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
****** finished trying bitmap/domain indexes ******
One row CDN: 1
BEST_CST: 1.00 PATH: 3 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: ELIGIBILITY_RELATION[ELIGIBILITY_RELATION]#0
Best so far: TABLE#: 0 CST: 1 CDN: 1 BYTES: 24
Final - First Rows Plan:
JOIN ORDER: 1
CST: 1 CDN: 1 RSC: 1 RSP: 1 BYTES: 24
IO-RSC: 1 IO-RSP: 1 CPU-RSC: 0 CPU-RSP: 0
First Rows Plan
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
_OPTIMIZER_PERCENT_PARALLEL = 101
HASH_AREA_SIZE = 131072
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 65536
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
_ALWAYS_STAR_TRANSFORMATION = FALSE
_B_TREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
_COMPLEX_VIEW_MERGING = TRUE
_PUSH_JOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
_SYSTEM_INDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 1
OPTIMIZER_DYNAMIC_SAMPLING = 1
_OPTIMIZER_DYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = ENFORCED
_INDEX_JOIN_ENABLED = TRUE
_SORT_ELIMINATION_COST_RATIO = 0
_OR_EXPAND_NVL_PREDICATE = TRUE
_NEW_INITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
_OPTIMIZER_MODE_FORCE = TRUE
_OPTIMIZER_UNDO_CHANGES = FALSE
_UNNEST_SUBQUERY = TRUE
_PUSH_JOIN_UNION_VIEW = TRUE
_FAST_FULL_SCAN_ENABLED = TRUE
_OPTIM_ENHANCE_NNULL_DETECTION = TRUE
_ORDERED_NESTED_LOOP = TRUE
_NESTED_LOOP_FUDGE = 100
_NO_OR_EXPANSION = FALSE
_QUERY_COST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
_IMPROVED_ROW_LENGTH_ENABLED = TRUE
_USE_NOSEGMENT_INDEXES = FALSE
_ENABLE_TYPE_DEP_SELECTIVITY = TRUE
_IMPROVED_OUTERJOIN_CARD = TRUE
_OPTIMIZER_ADJUST_FOR_NULLS = TRUE
_OPTIMIZER_CHOOSE_PERMUTATION = 0
_USE_COLUMN_STATS_FOR_FUNCTION = TRUE
_SUBQUERY_PRUNING_ENABLED = TRUE
_SUBQUERY_PRUNING_REDUCTION_FACTOR = 50
_SUBQUERY_PRUNING_COST_FACTOR = 20
_LIKE_WITH_BIND_AS_EQUALITY = FALSE
_TABLE_SCAN_COST_PLUS_ONE = TRUE
_SORTMERGE_INEQUALITY_JOIN_OFF = FALSE
_DEFAULT_NON_EQUALITY_SEL_CHECK = TRUE
_ONESIDE_COLSTAT_FOR_EQUIJOINS = TRUE
_OPTIMIZER_COST_MODEL = CHOOSE
_GSETS_ALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 128
_NEW_SORT_COST_ESTIMATE = TRUE
_GS_ANTI_SEMI_JOIN_ALLOWED = TRUE
_CPU_TO_IO = 0
_PRED_MOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: SOC_LIST Alias: SYS_ALIAS_1
TOTAL :: CDN: 17584 NBLKS: 653 AVG_ROW_LEN: 260
-- Index stats
INDEX NAME: I_SNAP$_SOC_LIST COL#: 1
TOTAL :: LVLS: 1 #LB: 64 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 699
INDEX NAME: SOC_LIST_1IX COL#: 3
TOTAL :: LVLS: 1 #LB: 47 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 14065
_OPTIMIZER_PERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
TABLE: SOC_LIST ORIG CDN: 17584 ROUNDED CDN: 879 CMPTD CDN: 879
Access path: tsc Resc: 18 Resp: 18
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
BEST_CST: 18.00 PATH: 2 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: SOC_LIST[SYS_ALIAS_1]#0
Best so far: TABLE#: 0 CST: 18 CDN: 879 BYTES: 8790
Final - All Rows Plan:
JOIN ORDER: 1
CST: 18 CDN: 879 RSC: 18 RSP: 18 BYTES: 8790
IO-RSC: 18 IO-RSP: 18 CPU-RSC: 0 CPU-RSP: 0
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
_OPTIMIZER_PERCENT_PARALLEL = 101
HASH_AREA_SIZE = 131072
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 65536
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
_ALWAYS_STAR_TRANSFORMATION = FALSE
_B_TREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
_COMPLEX_VIEW_MERGING = TRUE
_PUSH_JOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
_SYSTEM_INDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 1
OPTIMIZER_DYNAMIC_SAMPLING = 1
_OPTIMIZER_DYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = ENFORCED
_INDEX_JOIN_ENABLED = TRUE
_SORT_ELIMINATION_COST_RATIO = 0
_OR_EXPAND_NVL_PREDICATE = TRUE
_NEW_INITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
_OPTIMIZER_MODE_FORCE = TRUE
_OPTIMIZER_UNDO_CHANGES = FALSE
_UNNEST_SUBQUERY = TRUE
_PUSH_JOIN_UNION_VIEW = TRUE
_FAST_FULL_SCAN_ENABLED = TRUE
_OPTIM_ENHANCE_NNULL_DETECTION = TRUE
_ORDERED_NESTED_LOOP = TRUE
_NESTED_LOOP_FUDGE = 100
_NO_OR_EXPANSION = FALSE
_QUERY_COST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
_IMPROVED_ROW_LENGTH_ENABLED = TRUE
_USE_NOSEGMENT_INDEXES = FALSE
_ENABLE_TYPE_DEP_SELECTIVITY = TRUE
_IMPROVED_OUTERJOIN_CARD = TRUE
_OPTIMIZER_ADJUST_FOR_NULLS = TRUE
_OPTIMIZER_CHOOSE_PERMUTATION = 0
_USE_COLUMN_STATS_FOR_FUNCTION = TRUE
_SUBQUERY_PRUNING_ENABLED = TRUE
_SUBQUERY_PRUNING_REDUCTION_FACTOR = 50
_SUBQUERY_PRUNING_COST_FACTOR = 20
_LIKE_WITH_BIND_AS_EQUALITY = FALSE
_TABLE_SCAN_COST_PLUS_ONE = TRUE
_SORTMERGE_INEQUALITY_JOIN_OFF = FALSE
_DEFAULT_NON_EQUALITY_SEL_CHECK = TRUE
_ONESIDE_COLSTAT_FOR_EQUIJOINS = TRUE
_OPTIMIZER_COST_MODEL = CHOOSE
_GSETS_ALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 128
_NEW_SORT_COST_ESTIMATE = TRUE
_GS_ANTI_SEMI_JOIN_ALLOWED = TRUE
_CPU_TO_IO = 0
_PRED_MOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: SOC_LIST Alias: SOC
TOTAL :: CDN: 17584 NBLKS: 653 AVG_ROW_LEN: 260
-- Index stats
INDEX NAME: I_SNAP$_SOC_LIST COL#: 1
TOTAL :: LVLS: 1 #LB: 64 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 699
INDEX NAME: SOC_LIST_1IX COL#: 3
TOTAL :: LVLS: 1 #LB: 47 #DK: 17487 LB/K: 1 DB/K: 1 CLUF: 14065
_OPTIMIZER_PERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
TABLE: SOC_LIST ORIG CDN: 17584 ROUNDED CDN: 17584 CMPTD CDN: 17584
Access path: tsc Resc: 18 Resp: 18
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
BEST_CST: 18.00 PATH: 2 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: SOC_LIST[SOC]#0
Best so far: TABLE#: 0 CST: 18 CDN: 17584 BYTES: 0
Final - All Rows Plan:
JOIN ORDER: 1
CST: 18 CDN: 17584 RSC: 18 RSP: 18 BYTES: 0
IO-RSC: 18 IO-RSP: 18 CPU-RSC: 0 CPU-RSP: 0
BINDS #1:
bind 0: dty=96 mxl=32(01) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=32 offset=0
bfp=800003ffefea9490 bln=32 avl=01 flg=05
value="N"
EXEC #1:c=0,e=159,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017737385286
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='db file sequential read' ela= 9958 p1=586 p2=128001 p3=1
WAIT #1: nam='db file scattered read' ela= 619 p1=586 p2=128002 p3=4
WAIT #1: nam='db file sequential read' ela= 12880 p1=2535 p2=39498 p3=1
WAIT #1: nam='db file sequential read' ela= 39878 p1=2536 p2=68185 p3=1
WAIT #1: nam='db file sequential read' ela= 10240 p1=2536 p2=68520 p3=1
WAIT #1: nam='db file sequential read' ela= 15805 p1=2535 p2=45162 p3=1
WAIT #1: nam='db file sequential read' ela= 11733 p1=2535 p2=178335 p3=1
WAIT #1: nam='db file sequential read' ela= 11863 p1=2535 p2=178798 p3=1
WAIT #1: nam='db file sequential read' ela= 4886 p1=2535 p2=33834 p3=1
WAIT #1: nam='db file sequential read' ela= 12067 p1=2536 p2=60958 p3=1
WAIT #1: nam='db file sequential read' ela= 16496 p1=2535 p2=61232 p3=1
WAIT #1: nam='db file sequential read' ela= 8970 p1=2535 p2=50826 p3=1
WAIT #1: nam='db file sequential read' ela= 10940 p1=2536 p2=260451 p3=1
WAIT #1: nam='db file sequential read' ela= 8508 p1=2536 p2=261538 p3=1
WAIT #1: nam='db file scattered read' ela= 32000 p1=1613 p2=4622 p3=35
WAIT #1: nam='db file sequential read' ela= 1762 p1=2535 p2=178799 p3=1
WAIT #1: nam='db file sequential read' ela= 341 p1=2535 p2=61233 p3=1
WAIT #1: nam='db file scattered read' ela= 50494 p1=957 p2=230324 p3=35
WAIT #1: nam='db file scattered read' ela= 36716 p1=5 p2=588169 p3=35
WAIT #1: nam='db file scattered read' ela= 45241 p1=2326 p2=227427 p3=35
WAIT #1: nam='db file sequential read' ela= 11783 p1=2535 p2=68809 p3=1
WAIT #1: nam='db file scattered read' ela= 26720 p1=471 p2=102809 p3=35
WAIT #1: nam='db file scattered read' ela= 31074 p1=1496 p2=97015 p3=35
WAIT #1: nam='db file scattered read' ela= 39750 p1=586 p2=69452 p3=35
WAIT #1: nam='db file scattered read' ela= 30923 p1=1613 p2=8636 p3=35
WAIT #1: nam='db file scattered read' ela= 46328 p1=957 p2=67050 p3=35
WAIT #1: nam='db file scattered read' ela= 34570 p1=5 p2=362823 p3=35
WAIT #1: nam='db file scattered read' ela= 43343 p1=2326 p2=240311 p3=35
WAIT #1: nam='db file scattered read' ela= 30818 p1=471 p2=76417 p3=35
WAIT #1: nam='db file scattered read' ela= 19167 p1=1496 p2=480612 p3=35
WAIT #1: nam='db file scattered read' ela= 26405 p1=586 p2=193036 p3=35
WAIT #1: nam='db file scattered read' ela= 35374 p1=1613 p2=201565 p3=35
WAIT #1: nam='db file scattered read' ela= 14275 p1=957 p2=15804 p3=7
FETCH #1:c=190000,e=926019,p=552,cr=43429,cu=0,mis=0,r=1,dep=0,og=4,tim=3017738311433
WAIT #1: nam='SQL*Net message from client' ela= 2749 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
FETCH #1:c=0,e=79,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=3017738314443
*** 2013-06-10 13:35:44.078
WAIT #1: nam='SQL*Net message from client' ela= 18650883 p1=1413697536 p2=1 p3=0
STAT #1 id=1 cnt=2 pid=0 pos=1 obj=0 op='UNION-ALL (cr=43429 r=552 w=0 time=926047 us)'
STAT #1 id=2 cnt=1 pid=1 pos=1 obj=0 op='SORT AGGREGATE (cr=43429 r=552 w=0 time=925989 us)'
STAT #1 id=3 cnt=157 pid=2 pos=1 obj=0 op='FILTER (cr=43429 r=552 w=0 time=925909 us)'
STAT #1 id=4 cnt=14296 pid=3 pos=1 obj=5769120 op='TABLE ACCESS FULL SOC_LIST (cr=541 r=537 w=0 time=579577 us)'
STAT #1 id=5 cnt=157 pid=3 pos=2 obj=0 op='PARTITION HASH SINGLE PARTITION: KEY KEY (cr=42888 r=15 w=0 time=285564 us)'
STAT #1 id=6 cnt=157 pid=5 pos=1 obj=5401812 op='INDEX UNIQUE SCAN ELIGIBILITY_RELATION_PK PARTITION: KEY KEY (cr=42888 r=15 w=0 time=265355 us)'
STAT #1 id=7 cnt=1 pid=1 pos=2 obj=0 op='SORT AGGREGATE (cr=0 r=0 w=0 time=4 us)'
STAT #1 id=8 cnt=0 pid=7 pos=1 obj=0 op='FILTER (cr=0 r=0 w=0 time=1 us)'
STAT #1 id=9 cnt=0 pid=8 pos=1 obj=5769120 op='TABLE ACCESS FULL SOC_LIST '
QUERY
select 'close cursor' from dual
=====================
PARSING IN CURSOR #1 len=31 dep=0 uid=33 oct=3 lid=33 tim=3017756967074 hv=3487944275 ad='48de6a60'
select 'close cursor' from dual
END OF STMT
PARSE #1:c=0,e=986,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3017756967063
BINDS #1:
EXEC #1:c=0,e=47,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017756967278
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
FETCH #1:c=0,e=134,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=3017756967515
WAIT #1: nam='SQL*Net message from client' ela= 2682 p1=1413697536 p2=1 p3=0
FETCH #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=3017756970325
WAIT #1: nam='SQL*Net message to client' ela= 1 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:35:57.804
WAIT #1: nam='SQL*Net message from client' ela= 13399621 p1=1413697536 p2=1 p3=0
=====================
PARSING IN CURSOR #3 len=116 dep=1 uid=0 oct=3 lid=0 tim=3017770371839 hv=431456802 ad='39fbad80'
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,o.dataobj#,o.flags from obj$ o where o.obj#=:1
END OF STMT
PARSE #3:c=0,e=1249,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=3017770371828
BINDS #3:
bind 0: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=08 oacfl2=1 size=24 offset=0
bfp=800003ffefea7a90 bln=22 avl=03 flg=05
value=172
EXEC #3:c=0,e=666,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=3017770372725
WAIT #3: nam='db file sequential read' ela= 10318 p1=1 p2=978 p3=1
WAIT #3: nam='db file sequential read' ela= 10292 p1=1 p2=318 p3=1
FETCH #3:c=10000,e=21071,p=2,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=3017770393830
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=172 op='TABLE ACCESS FULL DUAL (cr=3 r=0 w=0 time=121 us)'
QUERY
ALTER SESSION SET EVENTS '10053 trace name context off'
=====================
PARSING IN CURSOR #1 len=55 dep=0 uid=33 oct=42 lid=33 tim=3017770394351 hv=3500836485 ad='3bed84c8'
ALTER SESSION SET EVENTS '10053 trace name context off'
END OF STMT
PARSE #1:c=0,e=227,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3017770394344
BINDS #1:
EXEC #1:c=0,e=177,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017770394624
WAIT #1: nam='SQL*Net message to client' ela= 4 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:36:13.139
WAIT #1: nam='SQL*Net message from client' ela= 14951473 p1=1413697536 p2=1 p3=0
=====================
PARSE ERROR #1:len=55 dep=0 uid=33 oct=42 lid=33 tim=3017785346905 err=911
ALTER SESSION SET EVENT=¿10046 trace name context off¿
WAIT #1: nam='SQL*Net break/reset to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net break/reset to client' ela= 2358 p1=1413697536 p2=0 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:36:53.497
WAIT #1: nam='SQL*Net message from client' ela= 39408861 p1=1413697536 p2=1 p3=0
=====================
PARSE ERROR #1:len=56 dep=0 uid=33 oct=42 lid=33 tim=3017824759339 err=911
ALTER SESSION SET EVENTS ¿10046 trace name context off¿
WAIT #1: nam='SQL*Net break/reset to client' ela= 4 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net break/reset to client' ela= 2342 p1=1413697536 p2=0 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 4 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:37:17.528
WAIT #1: nam='SQL*Net message from client' ela= 23463963 p1=1413697536 p2=1 p3=0
=====================
PARSE ERROR #1:len=57 dep=0 uid=33 oct=42 lid=33 tim=3017848226738 err=911
ALTER SESSION SET EVENTS '10043 trace name context off';
WAIT #1: nam='SQL*Net break/reset to client' ela= 1 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net break/reset to client' ela= 2305 p1=1413697536 p2=0 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 9416071 p1=1413697536 p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=55 dep=0 uid=33 oct=42 lid=33 tim=3017857646552 hv=2635134026 ad='4b92b7e8'
ALTER SESSION SET EVENTS '10043 trace name context off'
END OF STMT
PARSE #1:c=0,e=616,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3017857646541
BINDS #1:
EXEC #1:c=0,e=285,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=3017857647009
WAIT #1: nam='SQL*Net message to client' ela= 4 p1=1413697536 p2=1 p3=0
*** 2013-06-10 13:58:46.112
WAIT #1: nam='SQL*Net message from client' ela= 1248974802 p1=1413697536 p2=1 p3=0
XCTEND rlbk=0, rd_only=1 -
Hello,
Some days back, I came across a blog entry in which author concluded that when a = b and b = c, oracle does not conclude as a = c. He also provided a test case to prove his point. The URL is [http://sandeepredkar.blogspot.com/2009/09/query-performance-join-conditions.html]
Now, I thought that that can not be true. So I executed his test case (on 10.2.04) and the outcome indeed proved his point. Initially, I thought it might be due to absense of PK-FK relationship. But even after adding the PK-FK relationship, there was no change in the outcome. Although, when I modified the subquery with list of values, both the queries performed equally. I tried asking the author on his blog but it seems he has not yet seen my comment.
I am pasting his test case below. Can somebody please help me understand why CBO does not/can not use optimal plan here?
SQL> create table cu_all (custid number, addr varchar2(200), ph number, cano number, acctype varchar2(10));
Table created.
SQL> create table ca_receipt (custid number, caamt number, cadt date, totbal number);
Table created.
SQL>
SQL> insert into cu_all
2 select lvl,
3 dbms_random.string('A',30),
4 round(dbms_random.value(1,100000)),
5 round(dbms_random.value(1,10000)),
6 dbms_random.string('A',10)
7 from (select level "LVL" from dual connect by level <=200000);
200000 rows created.
SQL> insert into ca_receipt
2 select round(dbms_random.value(1,10000)),
3 round(dbms_random.value(1,100000)),
4 sysdate - round(dbms_random.value(1,100000)),
5 round(dbms_random.value(1,100000))
6 from (select level "LVL" from dual connect by level <=500000);
500000 rows created.
SQL> create unique index pk_cu_all_ind on cu_all(custid);
Index created.
SQL> create index ind2_cu_all on cu_all(CANO);
Index created.
SQL> create index ind_ca_receipt_custid on ca_receipt(custid);
Index created.
SQL> exec dbms_stats.gather_table_stats(user,'CU_ALL', cascade=>true);
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats(user,'CA_RECEIPT', cascade=>true);
PL/SQL procedure successfully completed.
Now let us execute the query with trace on. This is the similar query which was provided to me.
SQL> set autot trace
SQL> SELECT ca.*, cu.*
2 FROM ca_receipt CA,
3 cu_all CU
4 WHERE CA.CUSTID = CU.CUSTID
5 AND CA.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
6 CONNECT BY PRIOR CUSTID = CANO)
7 ORDER BY ACCTYPE DESC;
289 rows selected.
Execution Plan
Plan hash value: 3186098611
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1000 | 81000 | 504 (2)| 00:00:07 |
| 1 | SORT ORDER BY | | 1000 | 81000 | 504 (2)| 00:00:07 |
|* 2 | HASH JOIN | | 1000 | 81000 | 503 (2)| 00:00:07 |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1000 | 26000 | 112 (1)| 00:00:02 |
| 5 | VIEW | VW_NSO_1 | 20 | 100 | 21 (0)| 00:00:01 |
| 6 | HASH UNIQUE | | 20 | 180 | | |
|* 7 | CONNECT BY WITH FILTERING | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 9 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | | | | |
| 11 | CONNECT BY PUMP | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 21 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
| 16 | TABLE ACCESS FULL | CU_ALL | 200K| 10M| 389 (1)| 00:00:05 |
Predicate Information (identified by operation id):
2 - access("CA"."CUSTID"="CU"."CUSTID")
7 - access("CANO"=PRIOR "CUSTID")
9 - access("CUSTID"=2353)
13 - access("CANO"=PRIOR "CUSTID")
14 - access("CA"."CUSTID"="CUSTID")
Statistics
1 recursive calls
0 db block gets
2249 consistent gets
25 physical reads
0 redo size
11748 bytes sent via SQL*Net to client
729 bytes received via SQL*Net from client
21 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
289 rows processed
If you look at the query, it seems to be normal one.
But the problem is here-
Query is having two tables CA and CU. From the inner CU table query, it fetches records and joins with CA table an CA table Joins with CU table using the same column.
Here the inner query joins with CA table and cardinality of the query gets changed. So it is opting FTS when joining to CU table again.
This is causing the performance bottleneck. So to resolve the issue, I have change the joining condition.
Now if we check, following is the proper execution plan. Also the consistents gets have been reduced to 797 against 2249 in original query.
SQL> SELECT ca.*, cu.*
2 FROM ca_receipt CA,
3 cu_all CU
4 WHERE CA.CUSTID = CU.CUSTID
5 AND CU.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
6 CONNECT BY PRIOR CUSTID = CANO)
7 ORDER BY ACCTYPE DESC;
289 rows selected.
Execution Plan
Plan hash value: 3713271440
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1000 | 81000 | 133 (2)| 00:00:02 |
| 1 | SORT ORDER BY | | 1000 | 81000 | 133 (2)| 00:00:02 |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1000 | 81000 | 132 (1)| 00:00:02 |
| 4 | NESTED LOOPS | | 20 | 1200 | 42 (3)| 00:00:01 |
| 5 | VIEW | VW_NSO_1 | 20 | 100 | 21 (0)| 00:00:01 |
| 6 | HASH UNIQUE | | 20 | 180 | | |
|* 7 | CONNECT BY WITH FILTERING | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 9 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | | | | |
| 11 | CONNECT BY PUMP | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 21 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 55 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 0 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
Predicate Information (identified by operation id):
7 - access("CANO"=PRIOR "CUSTID")
9 - access("CUSTID"=2353)
13 - access("CANO"=PRIOR "CUSTID")
15 - access("CU"."CUSTID"="CUSTID")
16 - access("CA"."CUSTID"="CU"."CUSTID")
Statistics
1 recursive calls
0 db block gets
797 consistent gets
1 physical reads
0 redo size
11748 bytes sent via SQL*Net to client
729 bytes received via SQL*Net from client
21 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
289 rows processeduser503699 wrote:
Hello,
Some days back, I came across a blog entry in which author concluded that when a = b and b = c, oracle does not conclude as a = c. He also provided a test case to prove his point. The URL is [http://sandeepredkar.blogspot.com/2009/09/query-performance-join-conditions.html]
Now, I thought that that can not be true. So I executed his test case (on 10.2.04) and the outcome indeed proved his point. Initially, I thought it might be due to absense of PK-FK relationship. But even after adding the PK-FK relationship, there was no change in the outcome. Although, when I modified the subquery with list of values, both the queries performed equally. I tried asking the author on his blog but it seems he has not yet seen my comment.I see that Jonathan provided a helpful reply to you while I was in the process of setting up a test case.
Is it possible that the optimizer is correct? What if... the optimizer transformed the SQL statement? What if... the original SQL statement actually executes faster than the modified SQL statement? What if... the autotrace plans do not match the plans shown on that web page?
The first execution with the original SQL statement:
ALTER SESSION SET EVENTS '10053 trace name context forever, level 1';
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_case';
SET AUTOTRACE TRACE
SELECT ca.*, cu.*
FROM ca_receipt CA,
cu_all CU
WHERE CA.CUSTID = CU.CUSTID
AND CA.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
CONNECT BY PRIOR CUSTID = CANO)
ORDER BY ACCTYPE DESC;
Execution Plan
Plan hash value: 2794552689
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 81081 | 1125 (2)| 00:00:01 |
| 1 | SORT ORDER BY | | 1001 | 81081 | 1125 (2)| 00:00:01 |
| 2 | NESTED LOOPS | | 1001 | 81081 | 1123 (1)| 00:00:01 |
| 3 | NESTED LOOPS | | 1001 | 26026 | 114 (2)| 00:00:01 |
| 4 | VIEW | VW_NSO_1 | 20 | 100 | 22 (0)| 00:00:01 |
| 5 | HASH UNIQUE | | 20 | 180 | | |
|* 6 | CONNECT BY WITH FILTERING | | | | | |
| 7 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 19 | 2 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | | | | |
| 10 | CONNECT BY PUMP | | | | | |
| 11 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 22 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 55 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
6 - access("CANO"=PRIOR "CUSTID")
8 - access("CUSTID"=2353)
12 - access("CANO"=PRIOR "CUSTID")
14 - access("CA"."CUSTID"="$nso_col_1")
16 - access("CA"."CUSTID"="CU"."CUSTID")
Statistics
1 recursive calls
0 db block gets
232 consistent gets
7 physical reads
0 redo size
2302 bytes sent via SQL*Net to client
379 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processedThe second SQL statement which was modified:
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_case2';
SELECT ca.*, cu.*
FROM ca_receipt CA,
cu_all CU
WHERE CA.CUSTID = CU.CUSTID
AND CU.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
CONNECT BY PRIOR CUSTID = CANO)
ORDER BY ACCTYPE DESC;
Execution Plan
Plan hash value: 497148844
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 81081 | 136 (3)| 00:00:01 |
| 1 | SORT ORDER BY | | 1001 | 81081 | 136 (3)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 1001 | 81081 | 134 (2)| 00:00:01 |
| 4 | NESTED LOOPS | | 20 | 1200 | 43 (3)| 00:00:01 |
| 5 | VIEW | VW_NSO_1 | 20 | 100 | 22 (0)| 00:00:01 |
| 6 | HASH UNIQUE | | 20 | 180 | | |
|* 7 | CONNECT BY WITH FILTERING | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 19 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | | | | |
| 11 | CONNECT BY PUMP | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 22 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 55 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 0 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
7 - access("CANO"=PRIOR "CUSTID")
9 - access("CUSTID"=2353)
13 - access("CANO"=PRIOR "CUSTID")
15 - access("CU"."CUSTID"="$nso_col_1")
16 - access("CA"."CUSTID"="CU"."CUSTID")
Statistics
1 recursive calls
0 db block gets
162 consistent gets
0 physical reads
0 redo size
2302 bytes sent via SQL*Net to client
379 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processed
ALTER SESSION SET EVENTS '10053 trace name context off';The question might be asked, does the final SQL statement actually executed look the same as the original? Slightly reformatted:
The first SQL statement:
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CA.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;
Final Transformation:
SELECT
"CA"."CUSTID" "CUSTID",
"CA"."CAAMT" "CAAMT",
"CA"."CADT" "CADT",
"CA"."TOTBAL" "TOTBAL",
"CU"."CUSTID" "CUSTID",
"CU"."ADDR" "ADDR",
"CU"."PH" "PH",
"CU"."CANO" "CANO",
"CU"."ACCTYPE" "ACCTYPE"
FROM
(SELECT DISTINCT
"CU_ALL"."CUSTID" "$nso_col_1"
FROM
"TESTUSER"."CU_ALL" "CU_ALL"
WHERE
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID"
CONNECT BY
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID") "VW_NSO_1",
"TESTUSER"."CA_RECEIPT" "CA",
"TESTUSER"."CU_ALL" "CU"
WHERE
"CA"."CUSTID"="VW_NSO_1"."$nso_col_1"
AND "CA"."CUSTID"="CU"."CUSTID"
ORDER BY
"CU"."ACCTYPE" DESC;The second SQL statement:
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CU.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;
Final Transformation:
SELECT
"CA"."CUSTID" "CUSTID",
"CA"."CAAMT" "CAAMT",
"CA"."CADT" "CADT",
"CA"."TOTBAL" "TOTBAL",
"CU"."CUSTID" "CUSTID",
"CU"."ADDR" "ADDR",
"CU"."PH" "PH",
"CU"."CANO" "CANO",
"CU"."ACCTYPE" "ACCTYPE"
FROM
(SELECT DISTINCT
"CU_ALL"."CUSTID" "$nso_col_1"
FROM
"TESTUSER"."CU_ALL" "CU_ALL"
WHERE
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID"
CONNECT BY
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID") "VW_NSO_1",
"TESTUSER"."CA_RECEIPT" "CA",
"TESTUSER"."CU_ALL" "CU"
WHERE
"CA"."CUSTID"="CU"."CUSTID"
AND "CU"."CUSTID"="VW_NSO_1"."$nso_col_1"
ORDER BY
"CU"."ACCTYPE" DESC;Now, let's take a look at performance, flushing the buffer cache to force physical reads:
SET AUTOTRACE OFF
SET TIMING ON
SET AUTOTRACE TRACEONLY STATISTICS
SET ARRAYSIZE 100
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CA.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CU.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;The output:
/* (with AND CA.CUSTID IN...) */
52 rows selected.
Elapsed: 00:00:00.64
Statistics
0 recursive calls
0 db block gets
232 consistent gets
592 physical reads
0 redo size
2044 bytes sent via SQL*Net to client
346 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processed
/* (with AND CU.CUSTID IN...) */
52 rows selected.
Elapsed: 00:00:00.70
Statistics
0 recursive calls
0 db block gets
162 consistent gets
712 physical reads
0 redo size
2044 bytes sent via SQL*Net to client
346 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processedThe original SQL statement completed in 0.64 seconds, and the second completed in 0.70 seconds.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Hi all,
10.2.0.1
I have a query of the kind
SELECT DISTINCT a.trea_code,
a.class1,
a.class2,
a.class3,
a.class4,
a.other,
a.gross_pay,
b.trea_name
FROM (SELECT trea_code,
Count(CASE
WHEN empl_code = '1'
THEN emp_code
END) class1,
Count(CASE
WHEN empl_code = '2'
THEN emp_code
END) class2,
Count(CASE
WHEN empl_code = '3'
THEN emp_code
END) class3,
Count(CASE
WHEN empl_code = '4'
THEN emp_code
END) class4,
Count(CASE
WHEN empl_code = '5'
THEN emp_code
END) other,
Sum(CASE
WHEN empl_code BETWEEN '1' AND '5'
THEN gross_pay
END) gross_pay
FROM mon_act
WHERE v_no IS NOT NULL
--and upto_date between to_date('01-JAN-10') and to_date('31-JAN-10')
AND To_char(upto_date,'MONYYYY') = 'JAN2010'
GROUP BY trea_code
ORDER BY 1) a,
treasury.trea_mast b
WHERE a.trea_code = b.trea_code
ORDER BY 1 The trea_code,emp_code,upto_date column of mon_Act are primary key indexed[pk_monact].
Upon creating a function based index on to_char(upto_date,'MONYYYY'), oracle uses the function based index.
But If query as
SELECT DISTINCT a.trea_code,
a.class1,
a.class2,
a.class3,
a.class4,
a.other,
a.gross_pay,
b.trea_name
FROM (SELECT trea_code,
Count(CASE
WHEN empl_code = '1'
THEN emp_code
END) class1,
Count(CASE
WHEN empl_code = '2'
THEN emp_code
END) class2,
Count(CASE
WHEN empl_code = '3'
THEN emp_code
END) class3,
Count(CASE
WHEN empl_code = '4'
THEN emp_code
END) class4,
Count(CASE
WHEN empl_code = '5'
THEN emp_code
END) other,
Sum(CASE
WHEN empl_code BETWEEN '1' AND '5'
THEN gross_pay
END) gross_pay
FROM mon_act
WHERE v_no IS NOT NULL
and upto_date between to_date('01-JAN-10') and to_date('31-JAN-10')
--AND To_char(upto_date,'MONYYYY') = 'JAN2010'
GROUP BY trea_code
ORDER BY 1) a,
treasury.trea_mast b
WHERE a.trea_code = b.trea_code
ORDER BY 1 Oracle does not use the index pk_monact and does a n expansive full scan of mon_act.
The statistics are upto date.
Even if i use a hint as /*+ mon_act pk_monact */ in the outer query,it does not use an index.
Why it is ignoring the index based on primary key?Hi !
Which execution plan to use , CBO decides based on its own calculations which depends on ... many things . You can
analize CBO decision with activating event 10053 and analyzing output ( trace file )
ALTER SESSION SET EVENTS='10053 trace name context forever, level 1'; --- activate tracing
-- run your query
ALTER SESSION SET EVENTS '10053 trace name context off'; --- deactivate tracing
analize recent trace file using TKPROF T -
Why does query do a full table scan?
I have a simple select query that filters on the last 10 or 11 days of data from a table. In the first case it executes in 1 second. In the second case it is taking 15+ minutes and still not done.
I can tell that the second query (11 days) is doing a full table scan.
- Why is this happening? ... I guess some sort of threshold calculation???
- Is there a way to prevent this? ... or encourage Oracle to play nice.
I find it confusing from a front end/query perspective to get vastly different performance.
Jason
Oracle 10g
Quest Toad 10.6
CREATE TABLE delme10 AS
SELECT *
FROM ed_visits
WHERE first_contact_dt >= TRUNC(SYSDATE-10,'D');
Plan hash value: 915912709
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | CREATE TABLE STATEMENT | | 4799 | 5534K| 4951 (1)| 00:01:00 |
| 1 | LOAD AS SELECT | DELME10 | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ED_VISITS | 4799 | 5534K| 4796 (1)| 00:00:58 |
|* 3 | INDEX RANGE SCAN | NDX_ED_VISITS_020 | 4799 | | 15 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("FIRST_CONTACT_DT">=TRUNC(SYSDATE@!-10,'fmd'))
CREATE TABLE delme11 AS
SELECT *
FROM ed_visits
WHERE first_contact_dt >= TRUNC(SYSDATE-11,'D');
Plan hash value: 1113251513
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | CREATE TABLE STATEMENT | | 25157 | 28M| 14580 (1)| 00:02:55 | | | |
| 1 | LOAD AS SELECT | DELME11 | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 25157 | 28M| 14530 (1)| 00:02:55 | Q1,00 | P->S | QC (RAND) |
| 4 | PX BLOCK ITERATOR | | 25157 | 28M| 14530 (1)| 00:02:55 | Q1,00 | PCWC | |
|* 5 | TABLE ACCESS FULL | ED_VISITS | 25157 | 28M| 14530 (1)| 00:02:55 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
5 - filter("FIRST_CONTACT_DT">=TRUNC(SYSDATE@!-11,'fmd'))Hi Jason,
I think you're right with kind of "threshold". You can verify CBO costing with event 10053 enabled. There are many possible ways to change this behaviour. Most straightforward would be probably INDEX hint, but you can also change some index-cost related parameters, check histograms, decrease degree of paralellism on table, create stored outline, etc.
Lukasz -
Hibernate with oracle 9 and 10
Hi,
We're are developing application using hibernate and oracle database. Our application currently using hibernate 3.1.2 and oracle jdbc 9. Because we are using 10.2 version of database, we decided to migrate to jdbc 10.2.0.4 driver version. And there the problem appears: one of queries, which joins 2 tables (one about 550K rows, and second about 130K rows), using hibernate and jdbc 9 runs in seconds, but using hibernate and jdbc 10 runs in 10 minutes. But the same query executed with pure jdbc 10 (without hibernate) executes normally (as on jdbc 9). During execution cpu usage is 100%, it doesn't happen on jdbc 9. I traced sql session and the execution plans for both jdbc version are the same. Fetch_size in jdbc is the same in both cases. In tkprof out files i discovered, that fetch time for this query is extremely long on jdbc 10, no other differences could be found. Has anyone experienced such behavior of hibernate and jdbc drivers with different versions? Is there any chance to migrate from jdbc 9 to jdbc 10?
Regards
OlekHello
I can't explain the longer fetch time
I find it strange that the oracle shadow processes is busy, that would indicate an issue on the database side
That is why I asked to do more investigation into the trace
If you set those events, you will get more info in your trace file, you will get the oracle wait events that occurred
This will give more information about why the oracle shadow process was at 100%
Here is what I am looking for, I set the events and then ran a select on our database , here is the output from tkprof
See at the bottom where it has the 'Elapsed times include waiting on following events:', that is what I'd like to see
If you already have this detailed info, could you post it for both the 9 and 10 test?
select count(*)
from
mytab where mycol like '%xx%'
call count cpu elapsed disk query current rows
Parse 1 0.02 0.02 0 0 1 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 9.45 56.14 237740 237762 0 1
total 4 9.47 56.17 237740 237762 1 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 299
Rows Row Source Operation
1 SORT AGGREGATE (cr=237762 pr=237740 pw=0 time=56147059 us)
3 TABLE ACCESS FULL mytab (cr=237762 pr=237740 pw=0 time=53139375 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file scattered read 14914 0.19 51.74
SQL*Net message from client 2 4.94 5.10
If you can't create a logon trigger, could you change your java to run these alter sessions before running the sql?
alter session set sql_trace=true;
alter session set events '10046 trace name context forever, level 12';
alter session set events '10053 trace name context forever, level 1';
Thanks -
PreparedStatement.setTimestamp does not allo use of DATE index..
(...although they' re not suposed be related)
Hi;
I use Oracle 10g with Java JDBC driver ojdbc14.jar and I have a PreparedStatement on which among other "bind" JDBC parameters I have a java.util.Date. The ORM that we use (Hibernate 2.0.3) passes this Date instance as a java.sql.Timestamp binding it with setTimestamp on the PreparedStatement.
Interestingly enaugh, this way of binding the value does not make the database use the date column index, although the explain available from TOAD / Session browse, for instance, tells me the planner first demands an index scan there (it is possible i think that explain only operates on prepared SQL alone, disregarding value initial types and values). Doing a preparedStatement.setDate(value) instead, passing a java.sql.Date, uses the index and probably fully respects the Explain Plan that I have seen.
I assure you I have done many tests, with exact same query, parameter types and values, session origination and environment and changing one thing at a time. The only thing that being changed enables the query to make use of the DATE column index and return under a second, compared to tens of seconds of full table scan with expensive function calls, is to replace the preparedStatement.setTimestamp with setDate.
This can only be a JDBC bug, as far as I can tell. Do you know of this problem? What may be the cause?
As a note, since I need to continue to use that version of Hibernate on that spot, I momentarily worked around this apparent bug by modifying the SQL WHERE clause in order to provide the DATE value as to_date function output from a String bind, so doing date_col = to_date('YYYY-MM-DD', :value) instead of date_col = :value. Works fain, but just a work around.
Looking forward for your answer and suggestions,
Nicu MarasoiuA few remarks:
- Toad explain plans can be frought by implicit data type conversions.
Generally speaking everything is treated as a varchar2.
- You would need to show the plan from v$sql_plan.
- It would be a JDBC bug if you can show 'correct' behavior from sql*plus, making sure you actually do use bind variables of the correct type (so VARIABLE foo date prior to running the SQL, the SELECT referencing :foo)
- In the past I have observed strange CBO behavior because the date wasn't a complete date (ie time was missing). This can be rectified by function based indexes.
- You probably can enable event 10053 in your JDBC session, or event 10046 level 12
Sybrand Bakker
Senior Oracle DBA -
How to force the optimaizer to stop using an index ?
Hello,
I have an index on a very large table and I want to see how the applications running on this DB handles a situation in which this index does not exists.
Therfore I have 2 options:
1. drop the index - but this is too risky as if i will need to recreate it , it will last forever and will result in long application downtime which I can not afford.
The test and Dev environments does not contain ammounts of data like the prodicution so its hard to predict from these environments.
2. the second option is Modify the index columns statistics (which I have done) giving it low NDV (number of diftinct values) -- but sadly this did not work.
when cheking event 10053 I see a the line "Using prorated density: [ 1/(2*num_rows) ] of col #n as selectivity of out-of-range value pred" which I guess meens the High value of the column is lower then the value given it the query ( I do not run statistics every day , the current statistics for all columns (execpt this one ) suits best and I do not want to handle plan changes . also it will take a lot of time to gather table stats on daily basis.
So - to make a long story short - how do I force Oracle to avoid using an index but continue builing it and without dropping it?
I can not use the 'NO_INDEX' hint as it will requre change in many Applications.
I don need something like NO_INDEX hint on system level.
I am using Oracle 10g Enterprise edition.
the optimaized_mode is set to COST BASED.
Thanks in advance for any help resolving this complicated issue.
Regards,
Amit Zor.
ADBA.user3698066 wrote:
Hello,
I have an index on a very large table and I want to see how the applications running on this DB handles a situation in which this index does not exists.
2. the second option is Modify the index columns statistics (which I have done)
I'm still wondering if there is a way of modifying the statistics of the index in such a way so that it is not used by the optimizer.
Since the main contributors of the formula for an simple b-tree index access path are the height of index, the number of leaf blocks and for the table access the clustering factor, may be you could come up with all those values bumped up to very large values for that particular index.
Unfortunately the only component of the formula that is not multiplied by a factor is the height of the index, which is sanity checked (at least in 10.2) when set manually and is limited to a (already quite unreasonable) 255, so you can't set it greater than 255, but the remaining attributes can be set more or less to whatever you want.
So you could come up with an manual modification of the index statistics like this. Note that I don't modify the NUM_ROWS and DISTINCT_KEYS values in an attempt to limit the risk of unwanted side effects of this modification.
begin dbms_stats.set_index_stats(
ownname=>'<index_owner>,
indname=>'<index_name>',
indlevel=>255,
numlblks=>1000000000,
clstfct=>1000000000,
avglblk=>1000000000/<num_distinct>,
avgdblk=>1000000000);
end;
/In a quick test I was successfully able to prevent a very selective index access path using these settings, but depending on your remaining statistics and the access paths chosen by the optimizer this might not work for you, at least not in all possible cases, e.g. an index unique scan won't cost more than 256 even using these settings because only a single leaf block by definition has to be visited in this case.
Of course I haven't checked thoroughly what other side effects this statistics fudging does have, so use at your own risk resp. test it in your non-production environment before even thinking about applying it to an production system.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
Many different user authorisation while query runtime
Hello experts,
I've got a request for a query authorization where about 100 people needs to have a different view of a query result and I'm not sure what way I have to go.
There is Bex Query (SAP BW3.5) which contains the IO 0bp_respper and a key figure which gives you the number of activities back.
The requirement is that about 100 users can have access but they are not allowed to see all 0bp_respper.
One user can see the details of 0bp_respper (1,2,3), the next user is allowed see the details of 0bp_respper (30,76,55,60) and so on. And some are allowed to see all 0bp_respper.
You see that I actually would need in worst case 100 roles. Within the query I would use the authorisation variable to read the athorisation at runtime from each user profile.
It seems, and pls correct me if I'm wrong, that the authorisation variable is only feasible as long as the different combinations behind the authorisation check is manageable. (less than 10)
There is also the option to use exit variable at runtime. Should I rather use that one and do some coding. But in this case I would need a seperate table to define each users rights for 0bp_respper, or not?!
Or do u have another idea to implement the requirement?
thanks for ur help
MichaelA good way to check this out would be to do a 10053 trace.
Try this:
connect user1/pwd@whateverdb
alter session set events '10053 trace name context forever, level 1';
<run query here>
connect user1/pwd@whateverdb
alter session set events '10053 trace name context forever, level 1';
<run query here>
exit;
Now compare the trace files to see what the CBO is doing differently. Pay particular attention to the optimizer parameters at the beginning of the trace file. Are all the values the same?
-Mark
Maybe you are looking for
-
i have a mac mini early 2009 and i want to install 8 gb ram but it doesn,t work. it says on the OWC site that i have to install the EFI firmware 2.1 update but it won,t let me,it says(the mac mini)that i don,t need this update. my kernel is 32bit but
-
Open Directory Configuration Question
I've got a Mac-Mini based server running Mountain Lion (10.8.3) and Server.app (2.2.1). The server was migrated from Lion some weeks ago, the Server works OK, but seeing odd CPU usage and fairly frequent non-specific error reports which suggests tha
-
Need help with passing a variable in a function
Hello. I am working on a Flash app that needs to play videos. I have code using netstream that works great for one movie. The problem is I have 3 movies I want to play and I need to figure out how to replace the string variable with the correct path
-
How to determine an object is in an OU based on its DistinguishedName attribute
Hello, Im trying to ensure all group objects are in a particular OU and if they are, then I will remove them. All I have is a CSV input file of group names by SamAccountName, so I then do a Get-ADGroup to get the DistinguishedName attribute, but wan
-
Problem running Illustrator CS6 for the first time
Hi! I just installed Illustrator CS6 from the Creative Cloud and the following message appears as I try to start the program "Unable to set maximum number of files to be opened" and then it closes again. Can somebody help me? Many thanks!