Optimizer=ALL_ROWS, PARTITION HASH, INDEX (RANGE SCAN) POOR PERFORMANCE?
Our os is;
SunOS 5.9
and database is;
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit
Our autotrace outputs are below also we have 10046 trace outputs;
08:41:04 tcell_dev@SCME > set timing on
08:41:19 tcell_dev@SCME > set autot on
08:41:21 tcell_dev@SCME > SELECT lnpessv.PROFILE_ID FROM SCME.LNK_PROFILEENTITY_SUBSSERVVAR lnpessv
08:41:25 2 WHERE lnpessv.SUBSCRIPTION_SERVICEVARIANT_ID = 1695083 ;
PROFILE_ID
1.400E+14
1.600E+14
Elapsed: 00:00:03.07
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=3 Bytes=51)
1 0 PARTITION HASH (ALL) (Cost=3 Card=3 Bytes=51)
2 1 INDEX (RANGE SCAN) OF 'PK_PROFILEENTITY_SUBSSERVVAR' (INDEX (UNIQUE)) (Cost=
3 Card=3 Bytes=51)
Statistics
1 recursive calls
0 db block gets
1539 consistent gets
514 physical reads
0 redo size
258 bytes sent via SQL*Net to client
273 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
08:41:32 tcell_dev@SCME > SELECT lnpessv.PROFILE_ID FROM SCME.LNK_PROFILEENTITY_SUBSSERVVAR lnpessv
08:41:43 2 WHERE lnpessv.SUBSCRIPTION_SERVICEVARIANT_ID = 169508 ;
PROFILE_ID
1.400E+14
1.600E+14
Elapsed: 00:00:04.01
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=3 Bytes=51)
1 0 PARTITION HASH (ALL) (Cost=3 Card=3 Bytes=51)
2 1 INDEX (RANGE SCAN) OF 'PK_PROFILEENTITY_SUBSSERVVAR' (INDEX (UNIQUE)) (Cost=
3 Card=3 Bytes=51)
Statistics
1 recursive calls
0 db block gets
1537 consistent gets
512 physical reads
0 redo size
258 bytes sent via SQL*Net to client
273 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
Here we see 97% wait time, and responce time is unexceptable; These are the waits from 10046 trace file;
WAIT #1: nam='gc cr grant 2-way' ela= 783 p1=341 p2=67065 p3=1 obj#=169530 tim=571610438395
WAIT #1: nam='db file sequential read' ela= 6924 file#=341 block#=67065 blocks=1 obj#=169530 tim=571610445466
WAIT #1: nam='gc cr grant 2-way' ela= 564 p1=294 p2=86263 p3=1 obj#=169531 tim=571610446493
WAIT #1: nam='db file sequential read' ela= 6629 file#=294 block#=86263 blocks=1 obj#=169531 tim=571610453158
INDEX RANGE SCAN PK_PROFILEENTITY_SUBSSERVVAR PARTITION: 1 512 (cr=1537 pr=512 pw=0 time=4272017 us)
This is the related tables properties;
OWNER SCME
TABLE_NAME LNK_PROFILEENTITY_SUBSSERVVAR
TABLESPACE_NAME DATA01
STATUS VALID
PCT_FREE 10
INI_TRANS 10
MAX_TRANS 255
INITIAL_EXTENT 65536
MIN_EXTENTS 1
MAX_EXTENTS 2147483645
LOGGING NO
BACKED_UP N
NUM_ROWS 239587420
BLOCKS 1587288
EMPTY_BLOCKS 0
AVG_SPACE 0
CHAIN_CNT 0
AVG_ROW_LEN 41
AVG_SPACE_FREELIST_BLOCKS 0
NUM_FREELIST_BLOCKS 0
DEGREE 1
INSTANCES 1
CACHE N
TABLE_LOCK ENABLED
SAMPLE_SIZE 71876226
LAST_ANALYZED 29.05.2006 23:21:24
PARTITIONED NO
TEMPORARY N
SECONDARY N
NESTED NO
BUFFER_POOL DEFAULT
ROW_MOVEMENT DISABLED
GLOBAL_STATS YES
USER_STATS NO
SKIP_CORRUPT DISABLED
MONITORING YES
DEPENDENCIES DISABLED
COMPRESSION DISABLED
DROPPED NO
We are suspecting rac configuration and hash partition and index usage with rac.
Any comments will be welcomed,
Thank you.
Tonguç
this is the output of dbms_metadata.get_ddl for the table;
CREATE TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR"
( "SUBSCRIPTION_SERVICEVARIANT_ID" NUMBER NOT NULL ENABLE NOVALIDATE,
"PROFILE_ID" NUMBER NOT NULL ENABLE NOVALIDATE,
"CREATED_BY_ID" NUMBER,
"CREATED_DATE" DATE DEFAULT SYSDATE,
"UPDATED_BY_ID" NUMBER,
"UPDATED_DATE" DATE,
CONSTRAINT "PK_PROFILEENTITY_SUBSSERVVAR" PRIMARY KEY ("SUBSCRIPTION_SERVICEVARIANT_ID", "PROFILE_ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 4194304
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID","PROFILE_ID")
(PARTITION "SYS_P52989"
TABLESPACE "INDX02",
PARTITION "SYS_P52990"
TABLESPACE "INDX02",
PARTITION "SYS_P54010"
TABLESPACE "INDX02",
PARTITION "SYS_P54011"
TABLESPACE "INDX02",
PARTITION "SYS_P54012"
TABLESPACE "INDX02") ;
CREATE UNIQUE INDEX "SCME"."PK_PROFILEENTITY_SUBSSERVVAR" ON "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ("SUBSCRIPTION_SERVICEVARIANT_ID", "PROFILE_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 4194304
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID","PROFILE_ID")
(PARTITION "SYS_P52989"
TABLESPACE "INDX02",
PARTITION "SYS_P52990"
TABLESPACE "INDX02",
PARTITION "SYS_P53499"
TABLESPACE "INDX02",
PARTITION "SYS_P53500"
TABLESPACE "INDX02") ENABLE NOVALIDATE,
CONSTRAINT "FK_LNK_PROF_REFERENCE_SDP_SUBS" FOREIGN KEY ("SUBSCRIPTION_SERVICEVARIANT_ID")
REFERENCES "SCME"."SDP_SUBSCRIPTIONSERVICEVARIANT" ("SUBSCRIPTION_SERVICEVARIANT_ID") DEFERRABLE INITIALLY DEFERRED ENABLE NOVALIDATE
) PCTFREE 10 PCTUSED 40 INITRANS 10 MAXTRANS 255 NOCOMPRESS NOLOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "DATA01" ;
CREATE INDEX "SCME"."LNK_PROFILEENTITY_SUB_HNDX3" ON "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ("SUBSCRIPTION_SERVICEVARIANT_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 2097152
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID")
(PARTITION "SYS_P53501"
TABLESPACE "INDX02",
PARTITION "SYS_P53502"
TABLESPACE "INDX02",
PARTITION "SYS_P53499"
TABLESPACE "INDX02",
PARTITION "SYS_P53500"
TABLESPACE "INDX02") ;
CREATE INDEX "SCME"."PROFILE_ID_NDX43" ON "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ("PROFILE_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "INDX03" ;
ALTER TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ADD CONSTRAINT "PK_PROFILEENTITY_SUBSSERVVAR" PRIMARY KEY ("SUBSCRIPTION_SERVICEVARIANT_ID", "PROFILE_ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 4194304
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID","PROFILE_ID")
(PARTITION "SYS_P52989"
TABLESPACE "INDX02",
PARTITION "SYS_P52990"
PARTITION "SYS_P53498"
TABLESPACE "INDX02",
PARTITION "SYS_P53499"
TABLESPACE "INDX02",
PARTITION "SYS_P53500"
TABLESPACE "INDX02") ENABLE NOVALIDATE;
ALTER TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" MODIFY ("SUBSCRIPTION_SERVICEVARIANT_ID" NOT NULL ENABLE NOVALIDATE);
ALTER TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" MODIFY ("PROFILE_ID" NOT NULL ENABLE NOVALIDATE);
Similar Messages
-
Index range scan cost change in 10.2.0.1
SQL> create table t1 as
2 select
3 rpad('x',40) ind_pad,
4 trunc(dbms_random.value(0,25)) n1,
5 trunc(dbms_random.value(0,25)) n2,
6 lpad(rownum,10,'0') small_vc,
7 rpad('x',200) padding
8 from
9 all_objects
10 where
11 rownum <= 10000
12 ;
Table created.
SQL> create index t1_i1 on t1(ind_pad,n1,n2)
2 pctfree 91
3 ;
Index created.
SQL> set autot trace exp
SQL> alter session set optimizer_features_enable='10.2.0.1';
Session altered.
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> select
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 16 928 20 (0)00:00
:01
1 TABLE ACCESS BY INDEX ROWIDT1 16 928 20 (0)00:00
:01
* 2 INDEX RANGE SCAN T1_I1 16 4 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
SQL> update t1 set n2=n1; //now t1 and t2 are correlated
10000 rows updated.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> select
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 3617692013
Id Operation Name Rows Bytes Cost (%CPU)Time
0 SELECT STATEMENT 16 928 84 (2)00:00:02 * 1 TABLE ACCESS FULLT1 16 928 84 (2)00:00:02
Predicate Information (identified by operation id):
1 - filter("T1"."N1"=0 AND "T1"."N2"=4 AND "T1"."IND_PAD"='x
SQL> exec dbms_stats.delete_table_stats(user,'T1');
//delete table stats test dynamic sampling
PL/SQL procedure successfully completed.
SQL> select
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 1 60 1 (0)00:00
:01
1 TABLE ACCESS BY INDEX ROWIDT1 1 60 1 (0)00:00
:01
* 2 INDEX RANGE SCAN T1_I1 1 1 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
Note
- dynamic sampling used for this statement
//under dynamic sampling ,oracle choose true explain plan
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> select /*+ index(t1) */
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 16 928 256 (0)00:00
:04
1 TABLE ACCESS BY INDEX ROWIDT1 16 928 256 (0)00:00
:04
* 2 INDEX RANGE SCAN T1_I1 400 7 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
SQL> set autot off
SQL> select blevel,leaf_blocks,clustering_factor from user_indexes where table_name='T1';
BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
2 119 6201
//index selectity and table selectity are 0.4
index cost=2+119/25=7
table cost=7+6201/25=256
SQL> alter session set optimizer_features_enable='10.1.0.4';
Session altered.
SQL> set autot trace exp
SQL> select /*+ index(t1) */
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 16 928 13 (0)00:00
:01
1 TABLE ACCESS BY INDEX ROWIDT1 16 928 13 (0)00:00
:01
* 2 INDEX RANGE SCAN T1_I1 16 3 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
//change optimizer to 10.1,then cbo caculate index selectity and table selectity 1/625>
Very interesting again. I can reproduce your test case in 10.2.0.4, and it looks like you're right. I don't know whether it's intended behaviour or not, but in this particular case, when a index-only access is possible (and the table is not required) then the old selectivity formula is used (in this case 1/10000 * 1/10000), and it ignores the DISTINCT_KEYS of the index.
The trace file shows that the index selectivity is actually determined as 1/10000 but it's obviously not used for the calculation.
Interestingly, repeating the same test case in 11.1.0.7 shows that it uses the DISTINCT_KEYS again in the case you're using the entire index:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Session altered.
SQL>
SQL> drop table m purge;
Table dropped.
SQL>
SQL> create table m(id int,id1 int);
Table created.
SQL>
SQL> insert into m select rownum,rownum+1 from dba_objects where rownum<10001;
10000 rows created.
SQL>
SQL> insert into m select * from m;
10000 rows created.
SQL>
SQL> insert into m select * from m;
20000 rows created.
SQL>
SQL> insert into m select * from m;
40000 rows created.
SQL>
SQL> insert into m select * from m;
80000 rows created.
SQL>
SQL> commit;
Commit complete.
SQL>
SQL> select count(*) from m;
COUNT(*)
160000
SQL>
SQL> create index i_m_1 on m(id,id1);
Index created.
SQL>
SQL> exec dbms_stats.gather_table_stats(user,'M',method_opt=>'for all columns si
ze 1', estimate_percent => null);
PL/SQL procedure successfully completed.
SQL>
SQL> set autotrace traceonly
SQL>
SQL> select * from m where id=1;
16 rows selected.
Execution Plan
Plan hash value: 3644412196
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 16 | 112 | 2 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_M_1 | 16 | 112 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("ID"=1)
Statistics
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
670 bytes sent via SQL*Net to client
427 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
16 rows processed
SQL>
SQL> select * from m where id=1 and id1=2;
16 rows selected.
Execution Plan
Plan hash value: 3644412196
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 16 | 112 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_M_1 | 16 | 112 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("ID"=1 AND "ID1"=2)
Statistics
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
670 bytes sent via SQL*Net to client
427 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
16 rows processed
SQL>
SQL>So in 11.1.0.7 it seems to be consistent behaviour to take the DISTINCT_KEYS for an access using the entire index, but not in 10.2.
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/ -
Taking more time in INDEX RANGE SCAN compare to the full table scan
Hi all ,
Below are the version og my database.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I have gather the table statistics and plan change for sql statment.
SELECT P1.COMPANY, P1.PAYGROUP, P1.PAY_END_DT, P1.PAYCHECK_OPTION,
P1.OFF_CYCLE, P1.PAGE_NUM, P1.LINE_NUM, P1.SEPCHK FROM PS_PAY_CHECK P1
WHERE P1.FORM_ID = :1 AND P1.PAYCHECK_NBR = :2 AND
P1.CHECK_DT = :3 AND P1.PAYCHECK_OPTION <> 'R'
Plan before the gather stats.
Plan hash value: 3872726522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | *14306* (100)| |
| 1 | *TABLE ACCESS FULL| PS_PAY_CHECK* | 1 | 51 | 14306 (4)| 00:02:52 |
Plan after the gather stats:
Operation Object Name Rows Bytes Cost
SELECT STATEMENT Optimizer Mode=CHOOSE
1 4
*TABLE ACCESS BY INDEX ROWID SYSADM.PS_PAY_CHECK* 1 51 *4*
*INDEX RANGE SCAN SYSADM.PS0PAY_CHECK* 1 3After gather stats paln look good . but when i am exeuting the query it take 5 hours. before the gather stats it finishing the within 2 hours. i do not want to restore my old statistics. below are the data for the tables.and when i am obserrving it lot of db files scatter rea
NAME TYPE VALUE
_optimizer_cost_based_transformation string OFF
filesystemio_options string asynch
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string choose
optimizer_secure_view_merging boolean TRUE
plsql_optimize_level integer 2
SQL> select count(*) from sysadm.ps_pay_check;
select num_rows,blocks from dba_tables where table_name ='PS_PAY_CHECK';
COUNT(*)
1270052
SQL> SQL> SQL>
NUM_ROWS BLOCKS
1270047 63166
Event Waits Time (s) (ms) Time Wait Class
db file sequential read 1,584,677 6,375 4 36.6 User I/O
db file scattered read 2,366,398 5,689 2 32.7 User I/Oplease let me know why it taking more time in INDEX RANGE SCAN compare to the full table scan?suresh.ratnaji wrote:
NAME TYPE VALUE
_optimizer_cost_based_transformation string OFF
filesystemio_options string asynch
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string choose
optimizer_secure_view_merging boolean TRUE
plsql_optimize_level integer 2
please let me know why it taking more time in INDEX RANGE SCAN compare to the full table scan?Suresh,
Any particular reason why you have a non-default value for a hidden parameter, optimizercost_based_transformation ?
On my 10.2.0.1 database, its default value is "linear". What happens when you reset the value of the hidden parameter to default? -
What is mean by index range scan and fast full scan
What is mean by the following execution plans
1)Table access by index rowid
2) Index range scan
3) Index fast full scan
4) global index by rowid
..etc
where i can get this information.In what situation CBO take these paths.Can you pls give me a link where i can find all these.I read these long time ago but not able to recollect
Thanks
AnandOracle® Database Performance Tuning Guide
10g Release 2 (10.2)
Part Number B14211-01
13.5 Understanding Access Paths for the Query Optimizer
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#sthref1281 -
Dblink + local function: INDEX RANGE SCAN not used
Hi All,
I have an sql query to remote database:
SELECT N FROM [email protected] WHERE cd_n = 60
It works with INDEX RANGE SCAN for "N" field of table "tab", it's ok.
Now I'm replacing the constant value with the local database function:
SELECT N FROM [email protected] WHERE cd_n = dannis.foo()
Then 'INDEX RANGE SCAN' is removed out from query execution plan :-(
I've tried some tricks as
/*+ rule index(user.tab TAB$PK) */,
driving_site(tab),
to_number(dannis.foo()),
(select dannis.foo from [email protected])
and so on...
but INDEX RANGE SCAN wasn't appear while using the local function.
Is it true when dblink is used in combination with local function then INDEX RANGE SCAN will never used?
/Oracle 9.0.1.2/
Thanx,
dannis.See Optimizer not taking the hint
-
Is index range scan the reason for query running long time
I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
Operation Object COST CARDINALITY BYTES
SELECT STATEMENT () 413 1000 265000
COUNT (STOPKEY)
FILTER ()
TABLE ACCESS (BY INDEX ROWID) ORDERS 413 58720 15560800
INDEX (RANGE SCAN) IDX_SERV_PROV_ID 13 411709
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
John Seaman
http://www.asktheoracle.net -
Index Range Scan / Deleted Leaf Blocks
Hello guys,
i have such a scenario on a big index / table which i can not reproduce on my test database, so i need to know how oracle handles the index range scan.
For example:
TABLE TAB with the following columns NR (number), I_DATE (date), TEXT (VARCHAR2(50))
INDEX I_TAB on the column I_DATE.
Now the index has blevel 2 and many leaf blocks. And now my question.
Query: SQL> SELECT * from TAB WHERE I_DATE < 10.10.2004
The index had stored some values which are a less than 2003 but these ones are already deleted (so the leaf blocks are gone to the freelist), but it was not reorganized.
The execution plan is a INDEX RANGE SCAN on the INDEX I_TAB. Does the branch block still have pointers to the deleted leaf blocks which contained only 2003 values before (and so the INDEX RANGE SCAN scans all these blocks too) or are the pointers to these leaf blocks deleted in the branch block?
Thanks and Regards
StefanYou can verify it by yourself. See following:
SELECT count(*) FROM index_test;
==> 1569408
SELECT count(*) FROM index_test WHERE id <= 2;
==> 12
-- Delete all except first 12 rows
DELETE FROM index_test WHERE id > 2;
-- Query and SQL Trace
BEGIN
FOR C IN (SELECT /*+index(index_test index_test_idx) deleted */ * FROM INDEX_TEST WHERE ID < 1000000) LOOP
NULL;
END LOOP;
END;
SELECT /*+index(index_test index_test_idx) deleted */ *
FROM
INDEX_TEST WHERE ID < 1000000
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3490 0 12
total 3 0.00 0.01 0 3490 0 12
==> 3490 logical reads only for 12 rows and range scan??
-- Index tree dump
ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME TREEDUMP LEVEL 67513'
----- begin tree dump
branch: 0x1000124 16777508 (0: nrow: 6, level: 2)
branch: 0x100b1ca 16822730 (-1: nrow: 557, level: 1)
leaf: 0x1000125 16777509 (-1: nrow: 512 rrow: 12)
leaf: 0x1000126 16777510 (0: nrow: 484 rrow: 0)
leaf: 0x1000127 16777511 (1: nrow: 479 rrow: 0)
leaf: 0x1000128 16777512 (2: nrow: 479 rrow: 0)
leaf: 0x1000139 16777529 (3: nrow: 479 rrow: 0)
leaf: 0x100013a 16777530 (4: nrow: 478 rrow: 0)
branch: 0x100b401 16823297 (0: nrow: 558, level: 1)
leaf: 0x100b1c9 16822729 (-1: nrow: 449 rrow: 0)
leaf: 0x100b1cb 16822731 (0: nrow: 449 rrow: 0)
leaf: 0x100b1cc 16822732 (1: nrow: 449 rrow: 0)
==> leaf:3488, branch: 7
This means that almost all the branch and leaf nodes are read only for 12 keys.
You can cross check this with the result of "10200" event which traces cr reads. You would find out that the blocks that are read by the query are exactly same as all the index blocks.
This is what you mean? that the deleted leaf blocks(which contain no actual data) are read by range scan? Through the simple test, the anwer is "yes". -
Direct Path Reads instead of Sequential Reads for index range scan
Database is 11.2. I have two development schemas, with the same table loaded in each schema - a 5 million row table. The execution path for the sql statement is the same against both tables; it's doing an index range scan.
But it would appear Oracle performs a direct path read against one schema, and performs sequential reads against the other schema. I don't understand why I'm seeing different behavior when the execution plan is the same. Any ideas? These are two different schemas in the same database.There is not enough information.So you even these tables located same database and you gathered statistics it is not mean both run time wait event statistics must be same.Really they are different tables.If both query use INDEX RANGE SCAN the it is not mean these plans are same.What about table and their index statistics? are they same? for example num_row or num_blocks of both tables are same? also about indexes.In additionally if you want to get exact reason you can enable sql trace(using dbms_monitor or setting sql_trace parameter to true according session) and need analyze result trace file using tkprof utility.In additionally in 11g here when query execution time oracle automatically choose direct read path(serial) based on size of tables and size of buffer cache(also here is available some hidden parameter to controlling this behavior).
-
10.5.6 Results in "forever" indexing Spotlight and poor performance
Hi all,
I recently updated to 10.5.6 and have been struggling with a constantly indexing spotlight ever since. I have tried the following:
-- repairing the disk
-- repairing the disk permissions
-- deleting the spotlight index and re-indexing
-- use Onyx to clean up spotlight indexes
-- added various directories to "privacy" in spotlight preferences
Essentially, the computer becomes very laggy with TONS of I/O activity (180GB in data read overnight, 100GB of data on the disk). Even after it appears that Spotlight is done indexing, it does not provide any search results and will eventually start re-indexing all over again.
Here is the repeated lines I keep seeing in the system logs:
Dec 19 09:11:21 marzuki com.apple.metadata.mds[1970]: mds(1970,0xb071b000) malloc: * mmap(size=45056) failed (error code=12)
Dec 19 09:11:21 marzuki mds[1970]: mds(1970,0xb071b000) malloc: * mmap(size=45056) failed (error code=12)\n* error: can't allocate region\n* set a breakpoint in mallocerrorbreak to debug
Dec 19 09:11:21 marzuki com.apple.metadata.mds[1970]: * error: can't allocate region
Dec 19 09:11:21 marzuki com.apple.metadata.mds[1970]: * set a breakpoint in mallocerrorbreak to debug
Dec 19 09:11:27 marzuki com.apple.metadata.mds[1970]: terminate called after throwing an instance of 'std::bad_alloc'
Dec 19 09:11:27 marzuki com.apple.metadata.mds[1970]: what(): St9bad_alloc
Dec 19 09:11:28 marzuki /usr/sbin/spindump[2103]: process 1971 is being monitored
Dec 19 09:11:42 marzuki ReportCrash[2104]: Formulating crash report for process mds[1970]
Dec 19 09:11:42 marzuki com.apple.launchd[1] (0x10dfd0.mdworker[2097]): Exited: Terminated
Dec 19 09:11:42 marzuki com.apple.launchd[1] (0x10e6e0.mdworker[2093]): Exited: Terminated
Dec 19 09:11:43 marzuki com.apple.launchd[1] (com.apple.metadata.mds[1970]): Exited abnormally: Abort trap
Dec 19 09:11:44 marzuki /usr/sbin/spindump[2103]: process 1971 is being no longer being monitored
Dec 19 09:11:48 marzuki ReportCrash[2104]: Saved crashreport to /Library/Logs/CrashReporter/mds2008-12-19-091128marzuki.crash using uid: 0 gid: 0, euid: 0 egid: 0
Dec 19 09:11:55 marzuki mds[2105]: (Error) Server: Client checkin failed: (ipc/send) invalid destination port
Dec 19 09:11:55 marzuki mds[2105]: (Warning) Server: No stores registered for metascope "kMDQueryScopeComputer"
Dec 19 09:11:56 marzuki /usr/sbin/spindump[2103]: process 1971 is being monitored
Dec 19 09:12:22 marzuki /usr/sbin/spindump[2103]: process 1971 is being no longer being monitored
The only solution I have found is to disable Spotlight completely.
Any help would be appreciated.
Thanks.Thanks for all the replies. Unfortunately, none of them solved my problem. I tried:
1) restarting in safe-mode
2) repairing permissions
3) restarting in safe-mode
4) installing the combo update
5) restarting normally
My machine has been indexing for about 9 hours now and Spotlight status still says, "Estimating Indexing Time".
I am seeing this over and over again in my system log:
Jan 5 08:37:13 marzuki mds[2984]: mds(2984,0xb081f000) malloc: * mmap(size=45056) failed (error code=12)\n* error: can't allocate region\n* set a breakpoint in mallocerrorbreak to debug
Jan 5 08:37:13 marzuki com.apple.metadata.mds[2984]: mds(2984,0xb081f000) malloc: * mmap(size=45056) failed (error code=12)
Jan 5 08:37:13 marzuki com.apple.metadata.mds[2984]: * error: can't allocate region
Jan 5 08:37:13 marzuki com.apple.metadata.mds[2984]: * set a breakpoint in mallocerrorbreak to debug
Jan 5 08:37:13 marzuki com.apple.metadata.mds[2984]: terminate called after throwing an instance of 'std::bad_alloc'
Jan 5 08:37:13 marzuki com.apple.metadata.mds[2984]: what(): St9bad_alloc
Jan 5 08:37:14 marzuki ReportCrash[2988]: Formulating crash report for process mds[2984]
Jan 5 08:37:14 marzuki com.apple.launchd[1] (0x10d370.mdworker[2987]): Exited: Terminated
Jan 5 08:37:15 marzuki ReportCrash[2988]: Saved crashreport to /Library/Logs/CrashReporter/mds2009-01-05-083713marzuki.crash using uid: 0 gid: 0, euid: 0 egid: 0
Jan 5 08:37:15 marzuki com.apple.launchd[1] (0x10d160.mdworker[2986]): Exited: Terminated
Jan 5 08:37:15 marzuki com.apple.launchd[1] (com.apple.metadata.mds[2984]): Exited abnormally: Abort trap
Jan 5 08:38:14 marzuki mds[2989]: mds(2989,0xb081f000) malloc: * mmap(size=45056) failed (error code=12)\n* error: can't allocate region\n* set a breakpoint in mallocerrorbreak to debug
Jan 5 08:38:14 marzuki com.apple.metadata.mds[2989]: mds(2989,0xb081f000) malloc: * mmap(size=45056) failed (error code=12)
Jan 5 08:38:14 marzuki com.apple.metadata.mds[2989]: * error: can't allocate region
Jan 5 08:38:14 marzuki com.apple.metadata.mds[2989]: * set a breakpoint in mallocerrorbreak to debug
Jan 5 08:38:14 marzuki com.apple.metadata.mds[2989]: terminate called after throwing an instance of 'std::bad_alloc'
Jan 5 08:38:14 marzuki com.apple.metadata.mds[2989]: what(): St9bad_alloc
Jan 5 08:38:15 marzuki ReportCrash[2995]: Formulating crash report for process mds[2989]
Jan 5 08:38:15 marzuki mdworker[2992]: (Fatal) Import: Importer mach message failure on request work: (-308) (ipc/mig) server died
Jan 5 08:38:15 marzuki mdworker[2991]: (Fatal) Import: Importer mach message failure on request work: (-308) (ipc/mig) server died
Jan 5 08:38:15 marzuki ReportCrash[2995]: Saved crashreport to /Library/Logs/CrashReporter/mds2009-01-05-083814marzuki.crash using uid: 0 gid: 0, euid: 0 egid: 0
Jan 5 08:38:16 marzuki com.apple.launchd[1] (com.apple.metadata.mds[2989]): Exited abnormally: Abort trap
Any other ideas?
Thanks. -
Issues with reverse key indexes and range scan
I have a question. Why is it that reverse key indexes do not work in a range scan?
ThanksChris, well said in simple terms.
Extract from metalink:
Oracle8 provides the ability to create reverse key indexes. Reverse key indexes
reverse the bytes of each indexed column with the exception of ROWID and still
maintains the column order. Reverse key indexes are useful for Oracle Parallel
Server environments.
In an OPS environment, modifications to indexes are focused on a small
set of leaf blocks. Reversing the keys of the index allows insertions to be
distributed across all the leaf keys in the index. Reverse key indexes prevent
queries from performing an index range scan since lexically adjacent keys
are not stored next to each other. Reverse key indexes can also be used in
situations where users insert ascending values and delete lower values from the
table, thus helping to prevent skewed indexes.
===
Good discussion at
http://asktom.oracle.com/pls/ask/f?p=4950:8:2737861489787945222::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:627823669999
http://asktom.oracle.com/pls/ask/f?p=4950:8:2737861489787945222::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:6163160472530
Jaffar
Message was edited by:
The Human Fly -
Wrong cardinality estimate for range scan
select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - ProductionSQL : select * from GC_FULFILLMENT_ITEMS where MARKETPLACE_ID=:b1 and GC_FULFILLMENT_STATUS_ID=:b2;
Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 474K| 99M| 102 (85)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| GC_FULFILLMENT_ITEMS | 474K| 99M| 102 (85)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_GCFI_GCFS_ID_SDOC_MKTPLID | 474K| | 91 (95)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("GC_FULFILLMENT_STATUS_ID"=TO_NUMBER(:B2) AND "MARKETPLACE_ID"=TO_NUMBER(:B1))
filter("MARKETPLACE_ID"=TO_NUMBER(:B1))If i use literals than CBO uses cardinality =1 (I believe this is due it fix control :5483301 which i set to off In my environment)
select * from GC_FULFILLMENT_ITEMS where MARKETPLACE_ID=5 and GC_FULFILLMENT_STATUS_ID=2;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 220 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| GC_FULFILLMENT_ITEMS | 1 | 220 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_GCFI_GCFS_ID_SDOC_MKTPLID | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("GC_FULFILLMENT_STATUS_ID"=2 AND "MARKETPLACE_ID"=5)
filter("MARKETPLACE_ID"=5)Here is column distribution and histogram information
Enter value for column_name: MARKETPLACE_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
MARKETPLACE_ID 1 1 1
MARKETPLACE_ID 3 8548 8547
MARKETPLACE_ID 4 15608 7060
MARKETPLACE_ID 5 16385 777 --->
MARKETPLACE_ID 35691 16398 13
MARKETPLACE_ID 44551 16407 9
6 rows selected.
Enter value for column_name: GC_FULFILLMENT_STATUS_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
GC_FULFILLMENT_STATUS_ID 5 19602 19602
GC_FULFILLMENT_STATUS_ID 6 19612 10
GC_FULFILLMENT_STATUS_ID 8 19802 190
3 rows selected.
Actual distribution
select MARKETPLACE_ID,count(*) from GC_FULFILLMENT_ITEMS group by MARKETPLACE_ID order by 1;
MARKETPLACE_ID COUNT(*)
1 2099
3 16339936
4 13358682
5 1471839 --->
35691 33623
44551 19881
78931 40273
101611 1
6309408
9 rows selected.
BHAVIK_DBA: GC1EU> select GC_FULFILLMENT_STATUS_ID,count(*) from GC_FULFILLMENT_ITEMS group by GC_FULFILLMENT_STATUS_ID order by 1;
GC_FULFILLMENT_STATUS_ID COUNT(*)
1 880
2 63 --->
3 24
5 37226908
6 22099
7 18
8 325409
9 343
8 rows selected.10053 trace
SINGLE TABLE ACCESS PATH
Table: GC_FULFILLMENT_ITEMS Alias: GC_FULFILLMENT_ITEMS
Card: Original: 36703588.000000 Rounded: 474909 Computed: 474909.06 Non Adjusted: 474909.06
Best:: AccessPath: IndexRange
Index: I_GCFI_GCFS_ID_SDOC_MKTPLID
Cost: 102.05 Degree: 1 Resp: 102.05 Card: 474909.06 Bytes: 0
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('_b_tree_bitmap_plans' 'false')
OPT_PARAM('_optim_peek_user_binds' 'false')
OPT_PARAM('_fix_control' '5483301:0')
ALL_ROWS
OUTLINE_LEAF(@"SEL$F5BB74E1")
MERGE(@"SEL$2")
OUTLINE(@"SEL$1")
OUTLINE(@"SEL$2")
INDEX_RS_ASC(@"SEL$F5BB74E1" "GC_FULFILLMENT_ITEMS"@"SEL$2" ("GC_FULFILLMENT_ITEMS"."GC_FULFILLMENT_STATUS_ID" "GC_FULFILLMENT_ITEMS"."SHIP_DELIVERY_OPTION_CODE" "GC_FULFILLMENT_ITEMS"."MARKETPLACE_ID"))
END_OUTLINE_DATA
*/Is there any reason why CBO is using card=474909.06 ? Having fix control () in place, it should have set card=1 if it is considering GC_FULFILLMENT_STATUS_ID= 2 as "rare" value..isn't it ?OraDBA02 wrote:
You are right Charles.
I was reading one of your blog and saw that.
As you said, it is an issue with SQLPLUS.
However, plan for the sql which is comming from application still shows the same (wrong cardinality) plan. It does not have TO_NUMBER function because of the reason that it does not experience data-type conversion that SQLPLUS has.
But YES...Plan is exactly the same with/without NO_NUMBER.OraDBA02,
I believe that some of the other people responding to this thread might have already described why the execution plan in the library cache is the same plan that you are seeing. One of the goals of using bind variables in SQL statements is to reduce the number of time consuming (and resource intensive) hard parses. That also means that a second goal is to share the same execution plan for future executions of the same SQL statement, even through bind variable values have changed. The catch here is that bind variable peeking, introduced with Oracle Database 9.0.1 (may be disabled by modifying a hidden parameter), helps the optimizer select the "best" (lowest calculated cost) execution plan for those specific bind variable values - the same plan may not be the "best" execution plan for other sets of bind variable values on future executions.
Histograms on one or more of the columns in the WHERE clause could either help or hinder the situation further. It might further help the first execution, but might further hinder future executions with different bind variable values. Oracle Database 11.1 introduced something called adaptive cursor sharing (and 11.2 introduced cardinality feedback) that in theory addresses issues where the execution plan should change for later executions with different bind variable values (but the SQL statement must execute poorly at least once).
There might be multiple child cursors in the library cache for the same SQL statement, each potentially with a different execution plan. I suggest finding the SQL_ID of the SQL statement that the application is submitting (you can do this by checking V$SQL or V$SQLAREA). Once you have the SQL_ID, go back to the SQL statement that I suggested for displaying the execution plan:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL'));The first NULL in the above SQL statement is where you would specify the SQL_ID. If you leave the second NULL in place, the above SQL statement will retrieve the execution plan for all child cursors with that SQL_ID.
For instance, if the SQL_ID was 75chksrfa5fbt, you would execute the following:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL'));Usually, you can take it a step further to see the bind variables that were used during the optimization phase. To do that, you would add the +PEEKED_BINDS format parameter:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL +PEEKED_BINDS'));Note that there are various optimizer parameters that affect the optimizer's decisions, for instance, maybe the optimizer mode is set to FIRST_ROWS. Also possibly helpful is the +OUTLINE format parameter that might provide a clue regarding the value of some of the parameters affecting the optimizer. The SQL statement that you would then enter is similar to the following:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL +PEEKED_BINDS +OUTLINE'));Additional information might be helpful. Please see the following two forum threads to see what kind of information you should gather:
When your query takes too long… : When your query takes too long ...
How to post a SQL statement tuning request: HOW TO: Post a SQL statement tuning request - template posting
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Performance issue, same range scan different execution times
Oracle 11gR1, queries run within seconds of each other.
I have 2 queries that are logically the same. Even the explain plans are very similar, except the second one reports an index range scan doing much more work than the first. The table is an IOT with deal_bucket_id and datetime as PK (in that order).
TKPROF output below:
select count(*) from deal_bucket_detail where deal_bucket_id
in
(815
, 816
, 817
, 818
, 997)
and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.79 2.24 2936 3551 0 1
total 4 0.79 2.24 2936 3551 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 43
Rows Row Source Operation
1 SORT AGGREGATE (cr=3551 pr=2936 pw=2936 time=0 us)
1430928 FILTER (cr=3551 pr=2936 pw=2936 time=380920 us)
1430928 INLIST ITERATOR (cr=3551 pr=2936 pw=2936 time=372057 us)
1430928 INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=3551 pr=2936 pw=2936 time=8782 us cost=1203 size=4069596 card=339133)(object id 14199)
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 sequential read 2936 0.02 1.49
SQL*Net message from client 2 0.00 0.00
select count(*) from deal_bucket_detail where deal_bucket_id
between 815 and 997
and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 3.70 8.86 29199 26986 0 1
total 4 3.70 8.86 29199 26986 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 43
Rows Row Source Operation
1 SORT AGGREGATE (cr=26986 pr=29199 pw=29199 time=0 us)
1430928 FILTER (cr=26986 pr=29199 pw=29199 time=6986078 us)
1430928 INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=26986 pr=29199 pw=29199 time=6977063 us cost=45208 size=5195748 card=432979)(object id 14199)
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 sequential read 219 0.04 0.08
db file parallel read 35 0.04 0.32
db file scattered read 211 0.10 5.02
SQL*Net message from client 2 0.00 0.00
********************************************************************************How can I work out why the second query is doing much more work than the first?
Edited by: SamB on Aug 5, 2009 6:09 PMBoth are doing an index range scan, however a different index range scan.
query 1: inlist iterator with <n> index range scan for 1 value, due to hard-coded values.
query 2: index range scan for all values, starting at the lowest, due to between.
Sybrand Bakker
Senior Oracle DBA -
Oracle 11.2 slow with range scan
L.S.,
I have an issue with performance with select.
The select only selects 40 objects via index. The table is generated by SAP, but in customer namespace.
With ST05 the explain shows:
SELECT
FROM
"ZCSNN_CAS"
WHERE
"MANDT" = :A0 AND "BUSOBJ_TYPE" = :A1 AND "BUSOBJ_ID" IN ( :A2 , :A3 , :A4 , :A5 , :A6 , :A7 ,
:A8 , :A9 , :A10 , :A11 , :A12 , :A13 , :A14 , :A15 , :A16 , :A17 , :A18 , :A19 , :A20 , :A21 ,
:A22 , :A23 , :A24 , :A25 , :A26 , :A27 , :A28 , :A29 , :A30 , :A31 , :A32 , :A33 ) AND
"BUSOBJ_VERSDATE" >= :A34 AND "STATUS_VERSION" = :A35 AND "STATUS_WORK" = :A36 AND
"FLG_CANCEL_VERS" = :A37 AND "FLG_CANCEL_OBJ" <> :A38
The execution plan is:
SELECT STATEMENT ( Estimated Costs = 68 , Estimated #Rows = 4 )
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID ZCSNN_CAS
( Estim. Costs = 67 , Estim. #Rows = 4 )
Estim. CPU-Costs = 735.327 Estim. IO-Costs = 67
Filter Predicates
1 INDEX RANGE SCAN ZCSNN_CAS~Z02
( Estim. Costs = 7 , Estim. #Rows = 316 )
Search Columns: 3
Estim. CPU-Costs = 213.909 Estim. IO-Costs = 7
Access Predicates Filter Predicates
Then then following fetches show long runtimes:
Runtime Object Operation Returncode
329 ZCSNN_CAS PREPARE 0
2 ZCSNN_CAS OPEN 0
150.678 ZCSNN_CAS FETCH 46 0
194.637 ZCSNN_CAS FETCH 46 0
157.639 ZCSNN_CAS FETCH 46 0
12.707 ZCSNN_CAS FETCH 46 0
90.340 ZCSNN_CAS FETCH 46 0
138.845 ZCSNN_CAS FETCH 46 0
49.715 ZCSNN_CAS FETCH 46 0
137.186 ZCSNN_CAS FETCH 46 0
204.770 ZCSNN_CAS FETCH 46 0
339.622 ZCSNN_CAS FETCH 46 0
173.157 ZCSNN_CAS FETCH 14 1403
To me it looks like an Oracle issue? Changes in the ABAP-code did not help.
Can Oracle be tweaked?
Regards,
WalterFirst of all, thanks for all the responses!
Below the requested data for starters!
Table ZCSNN_ACT
Last statistics date 05.12.2011
Analyze Method Sample 344.222 Rows
Number of rows 34.422.200
Number of blocks allocated 416.900
Number of empty blocks 0
Average space 0
Chain count 0
Average row length 82
Partitioned NO
UNIQUE Index ZCSNN_ACT~0
Column Name
#Distinct
MANDT
1
IMPORT_YEAR
9
CASE_ID
2.459.014
CASE_VERS
3
ACT_POS
30
Last statistics date 05.12.2011
Analyze Method Sample 362.683 Rows
Levels of B-Tree 3
Number of leaf blocks 294.140
Number of distinct keys 36.268.300
Average leaf blocks per key 1
Average data blocks per key 1
Clustering factor 8.322.500 -
Poor performance and high number of gets on seemingly simple insert/select
Versions & config:
Database : 10.2.0.4.0
Application : Oracle E-Business Suite 11.5.10.2
2 node RAC, IBM AIX 5.3Here's the insert / select which I'm struggling to explain why it's taking 6 seconds, and why it needs to get > 24,000 blocks:
INSERT INTO WF_ITEM_ATTRIBUTE_VALUES ( ITEM_TYPE, ITEM_KEY, NAME, TEXT_VALUE,
NUMBER_VALUE, DATE_VALUE ) SELECT :B1 , :B2 , WIA.NAME, WIA.TEXT_DEFAULT,
WIA.NUMBER_DEFAULT, WIA.DATE_DEFAULT FROM WF_ITEM_ATTRIBUTES WIA WHERE
WIA.ITEM_TYPE = :B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 4 0
Execute 2 3.44 6.36 2 24297 198 36
Fetch 0 0.00 0.00 0 0 0 0
total 3 3.44 6.36 2 24297 202 36
Misses in library cache during parse: 1
Misses in library cache during execute: 2Also from the tkprof output, the explain plan and waits - virtually zero waits:
Rows Execution Plan
0 INSERT STATEMENT MODE: ALL_ROWS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'WF_ITEM_ATTRIBUTES' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'WF_ITEM_ATTRIBUTES_PK' (INDEX (UNIQUE))
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 12 0.00 0.00
gc current block 2-way 14 0.00 0.00
db file sequential read 2 0.01 0.01
row cache lock 24 0.00 0.01
library cache pin 2 0.00 0.00
rdbms ipc reply 1 0.00 0.00
gc cr block 2-way 4 0.00 0.00
gc current grant busy 1 0.00 0.00
********************************************************************************The statement was executed 2 times. I know from slicing up the trc file that :
exe #1 : elapsed = 0.02s, query = 25, current = 47, rows = 11
exe #2 : elapsed = 6.34s, query = 24272, current = 151, rows = 25
If I run just the select portion of the statement, using bind values from exe #2, I get small number of gets (< 10), and < 0.1 secs elapsed.
If I make the insert into an empty, non-partitioned table, I get :
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.08 0 137 53 25
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.01 0.08 0 137 53 25and same explain plan - using index range scan on WF_Item_Attributes_PK.
This problem is part of testing of a database upgrade and country go-live. On a 10.2.0.3 test system (non-RAC), the same insert/select - using the real WF_Item_Attributes_Value table takes :
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.10 10 27 136 25
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.10 10 27 136 25So I'm struggling to understand why the performance on the 10.2.0.4 RAC system is so much worse for this query, and why it's doing so many gets. Suggestions, thoughts, ideas welcomed.
I've verified system level things - CPUs weren't/aren't max'd out, no significant paging/swapping activity, run queue not long. AWR report for the time period shows nothing unusual.
further info on the objects concerned:
query source table :
WF_Item_Attributes_PK : unique index on Item_Type, Name. Index has 144 blocks, non-partitioned
WF_Item_Attributes tbl : non-partitioned, 160 blocks
insert destination table:
WF_Item_Attribute_Values:
range partitioned on Item_Type, and hash sub-partitioned on Item_Key
both executions of the insert hit the partition with the most data : 127,691 blocks total ; 8 sub-partitions with 15,896 to 16,055 blocks per sub-partition.
WF_Item_Attribute_Values_PK : unique index on columns Item_Type, Item_Key, Name. Range/hash partitioned as per table.
Bind values:
exe #1 : Item_Type (:B1) = OEOH, Item_Key (:B2) = 1048671
exe #2 : Item_Type (:B1) = OEOL, Item_Key (:B2) = 4253168
number of rows in WF_Item_Attribute_Values for Item_Type = OEOH : 1132587
number of rows in WF_Item_Attribute_Values for Item_Type = OEOL : 18763670
The non-RAC 10.2.0.3 test system (clone of Production from last night) has higher row counts for these 2.
thanks and regards
Ivanhi Sven,
Thanks for your input.
1) I guess so, but I haven't lifted the lid to delve inside the form as to which one. I don't think it's the cause though, as I got poor performance running the insert statement with my own value (same statement, using my own bind value).
2) In every execution plan I've seen, checked, re-checked, it uses a range scan on the primary key. It is the most efficient I think, but the source table is small in any case - table 160 blocks, PK index 144 blocks. So I think it's the partitioned destination table that's the problem - but we only see this issue on the 10.2.0.4 pre-production (RAC) system. The 10.2.0.3 (RAC) Production system doesn't have it. This is why it's so puzzling to me - the source table read is fast, and does few gets.
3) table storage details below - the Item_Types being used were 'OEOH' (fast execution) and 'OEOL' (slow execution). Both hit partition WF_ITEM49, hence I've only expanded the subpartition info for that one (there are over 600 sub-partitions).
============= From DBA_Part_Tables : Partition Type / Count =============
PARTITI SUBPART PARTITION_COUNT DEF_TABLESPACE_NAME
RANGE HASH 77 APPS_TS_TX_DATA
1 row selected.
============= From DBA_Tab_Partitions : Partition Names / Tablespaces =============
Partition Name TS Name High Value High Val Len
WF_ITEM1 APPS_TS_TX_DATA 'A1' 4
WF_ITEM2 APPS_TS_TX_DATA 'AM' 4
WF_ITEM3 APPS_TS_TX_DATA 'AP' 4
WF_ITEM47 APPS_TS_TX_DATA 'OB' 4
WF_ITEM48 APPS_TS_TX_DATA 'OE' 4
WF_ITEM49 APPS_TS_TX_DATA 'OF' 4
WF_ITEM50 APPS_TS_TX_DATA 'OK' 4
WF_ITEM75 APPS_TS_TX_DATA 'WI' 4
WF_ITEM76 APPS_TS_TX_DATA 'WS' 4
WF_ITEM77 APPS_TS_TX_DATA MAXVALUE 8
77 rows selected.
============= From dba_part_key_columns : Partition Columns =============
NAME OBJEC Column Name COLUMN_POSITION
WF_ITEM_ATTRIBUTE_VALUES TABLE ITEM_TYPE 1
1 row selected.
PPR1 sql> @q_tabsubpart wf_item_attribute_values WF_ITEM49
============= From DBA_Tab_SubPartitions : SubPartition Names / Tablespaces =============
Partition Name SUBPARTITION_NAME TS Name High Value High Val Len
WF_ITEM49 SYS_SUBP3326 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3328 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3332 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3331 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3330 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3329 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3327 APPS_TS_TX_DATA 0
WF_ITEM49 SYS_SUBP3325 APPS_TS_TX_DATA 0
8 rows selected.
============= From dba_part_key_columns : Partition Columns =============
NAME OBJEC Column Name COLUMN_POSITION
WF_ITEM_ATTRIBUTE_VALUES TABLE ITEM_KEY 1
1 row selected.
from DBA_Segments - just for partition WF_ITEM49 :
Segment Name TSname Partition Name Segment Type BLOCKS Mbytes EXTENTS Next Ext(Mb)
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3332 TblSubPart 16096 125.75 1006 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3331 TblSubPart 16160 126.25 1010 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3330 TblSubPart 16160 126.25 1010 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3329 TblSubPart 16112 125.875 1007 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3328 TblSubPart 16096 125.75 1006 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3327 TblSubPart 16224 126.75 1014 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3326 TblSubPart 16208 126.625 1013 .125
WF_ITEM_ATTRIBUTE_VALUES @TX_DATA SYS_SUBP3325 TblSubPart 16128 126 1008 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3332 IdxSubPart 59424 464.25 3714 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3331 IdxSubPart 59296 463.25 3706 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3330 IdxSubPart 59520 465 3720 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3329 IdxSubPart 59104 461.75 3694 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3328 IdxSubPart 59456 464.5 3716 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3327 IdxSubPart 60016 468.875 3751 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3326 IdxSubPart 59616 465.75 3726 .125
WF_ITEM_ATTRIBUTE_VALUES_PK @TX_IDX SYS_SUBP3325 IdxSubPart 59376 463.875 3711 .125
sum 4726.5
[the @ in the TS Name is my shortcode, as Apps stupidly prefixes every ts with "APPS_TS_"]
The Tablespaces used for all subpartitions are UNIFORM extent mgmt, AUTO segment_space_management ; LOCAL extent mgmt.regards
Ivan -
Poor performance while join of 2 comprehensive large views and small table
Hi,
The following SQL statement has been identified to perform poorly. It currently takes up to 6 seconds to execute, but it's supposed to take ~30-40ms at most.
This is the statement(all bind variables change to numbers):
SELECT v__96.connector_objectid, v__96.connector_classid, v__96.from_objectid,
v__96.to_objectid, v__96.from_classid, v__96.to_classid,
v__96.from_firstunit, v__96.to_firstunit, v__96.number_of_units,
tmp_trace.first_unit, tmp_trace.last_unit, v__96.inv_status_number,
tmp_trace.first_unit, tmp_trace.last_unit, v__96.answers,
v__96.priority, v__97.first_unit, v__97.n_units,
v__97.mid_span_distance
FROM ne.tmp_trace,
(SELECT b.objectid, b.answers, b.connector_classid,
b.connector_objectid, b.from_classid, b.from_objectid,
b.to_classid, b.to_objectid, b.from_firstunit, b.to_firstunit,
b.number_of_units, b.inv_status_number, b.splice_closure_name,
b.work_order_name, b.work_order_item_number,
b.inventory_status_code, b.priority
FROM ne.connection b
WHERE b.objectid NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id
FROM ne.d96
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id = 0)
UNION ALL
SELECT a.objectid, a.answers, a.connector_classid,
a.connector_objectid, a.from_classid, a.from_objectid,
a.to_classid, a.to_objectid, a.from_firstunit, a.to_firstunit,
a.number_of_units, a.inv_status_number, a.splice_closure_name,
a.work_order_name, a.work_order_item_number,
a.inventory_status_code, a.priority
FROM ne.a96 a, sde.state_lineages sl
WHERE (a.objectid, a.sde_state_id) NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id, sde_state_id
FROM ne.d96
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id > 0)
AND a.sde_state_id = sl.lineage_id
AND sl.lineage_name = 2
AND sl.lineage_id <= 115) v__96,
(SELECT b.objectid, b.tray_number, b.db_loss, b.first_unit, b.n_units,
b.connection_objectid, b.connector_type_name,
b.dedicated_status, b.mid_span_distance
FROM ne.connection_attributes b
WHERE b.objectid NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id
FROM ne.d97
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id = 0)
UNION ALL
SELECT a.objectid, a.tray_number, a.db_loss, a.first_unit, a.n_units,
a.connection_objectid, a.connector_type_name,
a.dedicated_status, a.mid_span_distance
FROM ne.a97 a, sde.state_lineages sl
WHERE (a.objectid, a.sde_state_id) NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id, sde_state_id
FROM ne.d97
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id > 0)
AND a.sde_state_id = sl.lineage_id
AND sl.lineage_name = 2
AND sl.lineage_id <= 115) v__97
WHERE ( ( ( ( ( ( ne.tmp_trace.equipment_object_id =
v__96.to_objectid
AND v__96.to_classid = 9
OR ( ne.tmp_trace.transmedia_object_id =
v__96.to_objectid
AND v__96.to_classid = 5
AND ( (v__96.to_firstunit
BETWEEN ne.tmp_trace.first_unit
AND ne.tmp_trace.last_unit
OR (ne.tmp_trace.first_unit
BETWEEN v__96.to_firstunit
AND v__96.to_firstunit
+ v__96.number_of_units
- 1
AND v__96.answers = 0
AND v__96.objectid = v__97.connection_objectid
AND (ne.tmp_trace.session_id = -1234)
);It should return many values from 2 comprehensive views (v__96, v__97) and business table (tmp_trace). 2 comprehensive views ~1,000,000 recs each, business table ~ 10 recs.
The version of the database is 11.1.0.6.
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.6
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string FORCE
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL> select sname, pname, pval1, pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-15-2009 10:27
SYSSTATS_INFO DSTOP 07-15-2009 10:27
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1812.32129
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SNAME PNAME PVAL1 PVAL2
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.Here is the output of EXPLAIN PLAN:
explain plan for -- statement above
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1005186751
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 282 | 268 (2)| 00:00:04 |
| 1 | NESTED LOOPS | | 1 | 282 | 268 (2)| 00:00:04 |
| 2 | MERGE JOIN CARTESIAN | | 1 | 119 | 260 (1)| 00:00:04 |
|* 3 | TABLE ACCESS FULL | TMP_TRACE | 1 | 65 | 2 (0)| 00:00:01 |
| 4 | BUFFER SORT | | 103K| 5467K| 258 (1)| 00:00:04 |
| 5 | VIEW | | 103K| 5467K| 258 (1)| 00:00:04 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 14 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID| A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 23 | VIEW | | 1 | 163 | 8 (13)| 00:00:01 |
| 24 | UNION ALL PUSHED PREDICATE | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 185 | 1 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID | CONNECTION | 1 | 181 | 0 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | R96_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
| 28 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 32 | HASH JOIN ANTI | | 1 | 97 | 7 (15)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 71 | 4 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | A96 | 1 | 64 | 4 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | A96_PK | 1 | | 3 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 37 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 38 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 39 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
23 - filter(("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=9
OR "TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=5) AND
("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
"V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
26 - filter("B"."ANSWERS"=0)
27 - access("B"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
30 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
31 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
32 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("A"."ANSWERS"=0)
35 - access("A"."OBJECTID"="V__97"."CONNECTION_OBJECTID" AND "A"."SDE_STATE_ID"<=115)
36 - access("SL"."LINEAGE_NAME"=2 AND "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("SL"."LINEAGE_ID"<=115)
39 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND
"SDE_DELETES_ROW_ID"="V__97"."CONNECTION_OBJECTID" AND "SDE_STATE_ID">0)
40 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
Note
- dynamic sampling used for this statement
87 rows selected.Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> set autotrace traceonly arraysize 100
Elapsed: 00:00:01.64
Execution Plan
Plan hash value: 1198408274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 876K| 238M| 1301 (2)| 00:00:16 |
| 1 | CONCATENATION | | | | | |
|* 2 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 3 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 4 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 5 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 8 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 14 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 22 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 23 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 24 | UNION-ALL | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 26 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 27 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 31 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 32 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 34 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | | | | |
| 37 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 38 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 41 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 42 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 43 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 44 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 45 | UNION-ALL | | | | | |
| 46 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 47 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 48 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 50 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 52 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 53 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 54 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 55 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 57 | NESTED LOOPS | | | | | |
| 58 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 59 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 62 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 63 | UNION-ALL | | | | | |
| 64 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 65 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 66 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 70 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 71 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 72 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 73 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 75 | NESTED LOOPS | | | | | |
| 76 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 77 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 79 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
3 - access("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID")
filter("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
"V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1)
4 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
5 - filter("V__96"."TO_CLASSID"=5)
8 - filter("B"."ANSWERS"=0)
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
22 - filter("A"."ANSWERS"=0)
29 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
30 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
31 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
35 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
38 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
39 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
41 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
42 - access("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID")
filter((LNNVL("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID") OR
LNNVL("V__96"."TO_CLASSID"=5)) AND ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
"V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
43 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
44 - filter("V__96"."TO_CLASSID"=9)
47 - filter("B"."ANSWERS"=0)
50 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
51 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
52 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
55 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
56 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
59 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
60 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
61 - filter("A"."ANSWERS"=0)
68 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
69 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
70 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
73 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
74 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
77 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
78 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
Note
- dynamic sampling used for this statementThe TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: pro &The TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: problem.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT V__96.CONNECTOR_OBJECTID, V__96.CONNECTOR_CLASSID, V__96.FROM_OBJECTID, V__96.TO_OBJECTID, V__96.FROM_CLASSID, V__96.TO_CLASSID,
V__96.FROM_FIRSTUNIT, V__96.TO_FIRSTUNIT, V__96.NUMBER_OF_UNITS, TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.INV_STATUS_NUMBER,
TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.ANSWERS, V__96.PRIORITY, V__97.FIRST_UNIT, V__97.N_UNITS, V__97.MID_SPAN_DISTANCE FROM
NE.TMP_TRACE,(SELECT
b.OBJECTID,b.ANSWERS,b.CONNECTOR_CLASSID,b.CONNECTOR_OBJECTID,b.FROM_CLASSID,b.FROM_OBJECTID,b.TO_CLASSID,b.TO_OBJECTID,b.FROM_FIRSTUNIT,b.TO_FIRSTUNIT,b.NUM
BER_OF_UNITS,b.INV_STATUS_NUMBER,b.SPLICE_CLOSURE_NAME,b.WORK_ORDER_NAME,b.WORK_ORDER_ITEM_NUMBER,b.INVENTORY_STATUS_CODE,b.PRIORITY FROM NE.connection b
WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D96 WHERE DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
l.lineage_name = :"SYS_B_00" AND l.lineage_id <= :"SYS_B_01") AND SDE_STATE_ID = :"SYS_B_02") UNION ALL SELECT
a.OBJECTID,a.ANSWERS,a.CONNECTOR_CLASSID,a.CONNECTOR_OBJECTID,a.FROM_CLASSID,a.FROM_OBJECTID,a.TO_CLASSID,a.TO_OBJECTID,a.FROM_FIRSTUNIT,a.TO_FIRSTUNIT,a.NUM
BER_OF_UNITS,a.INV_STATUS_NUMBER,a.SPLICE_CLOSURE_NAME,a.WORK_ORDER_NAME,a.WORK_ORDER_ITEM_NUMBER,a.INVENTORY_STATUS_CODE,a.PRIORITY FROM NE.A96
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D96 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_03" AND l.lineage_id <= :"SYS_B_04") AND SDE_STATE_ID > :"SYS_B_05") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_06" AND SL.lineage_id <= :"SYS_B_07") V__96,(SELECT
b.OBJECTID,b.TRAY_NUMBER,b.DB_LOSS,b.FIRST_UNIT,b.N_UNITS,b.CONNECTION_OBJECTID,b.CONNECTOR_TYPE_NAME,b.DEDICATED_STATUS,b.MID_SPAN_DISTANCE FROM
NE.connection_attributes b WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D97 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_08" AND l.lineage_id <= :"SYS_B_09") AND SDE_STATE_ID = :"SYS_B_10") UNION ALL SELECT
a.OBJECTID,a.TRAY_NUMBER,a.DB_LOSS,a.FIRST_UNIT,a.N_UNITS,a.CONNECTION_OBJECTID,a.CONNECTOR_TYPE_NAME,a.DEDICATED_STATUS,a.MID_SPAN_DISTANCE FROM NE.A97
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D97 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_11" AND l.lineage_id <= :"SYS_B_12") AND SDE_STATE_ID > :"SYS_B_13") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_14" AND SL.lineage_id <= :"SYS_B_15") V__97 WHERE ((((( (
NE.tmp_trace.equipment_object_id = V__96.to_objectid
AND
V__96.to_classid = :"SYS_B_16"
OR
NE.tmp_trace.transmedia_object_id = V__96.to_objectid
AND
V__96.to_classid = :"SYS_B_17"
)) AND (
(V__96.to_firstunit
BETWEEN NE.tmp_trace.first_unit AND NE.tmp_trace.last_unit)
OR
(NE.tmp_trace.first_unit BETWEEN V__96.to_firstunit
AND V__96.to_firstunit + V__96.number_of_units - :"SYS_B_18")
)) AND V__96.answers = :"SYS_B_19") AND V__96.objectid = V__97.connection_objectid) AND (NE.tmp_trace.session_id =
:"SYS_B_20"))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 5.98 5.99 0 22652 0 10
total 3 5.98 5.99 0 22652 0 10
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 45
Rows Row Source Operation
10 NESTED LOOPS (cr=22652 pr=0 pw=0 time=654515 us cost=67 size=282 card=1)
10 NESTED LOOPS (cr=22436 pr=0 pw=0 time=653673 us cost=61 size=235 card=1)
10 TABLE ACCESS FULL TMP_TRACE (cr=5 pr=0 pw=0 time=7 us cost=2 size=65 card=1)
10 VIEW (cr=22431 pr=0 pw=0 time=0 us cost=59 size=170 card=1)
1773000 UNION-ALL (cr=22431 pr=0 pw=0 time=93649 us)
0 NESTED LOOPS ANTI (cr=30 pr=0 pw=0 time=0 us cost=3 size=185 card=1)
0 TABLE ACCESS FULL CONNECTION (cr=30 pr=0 pw=0 time=0 us cost=2 size=181 card=1)
0 VIEW PUSHED PREDICATE VW_NSO_3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
0 INDEX UNIQUE SCAN D96_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35121)
1773000 HASH JOIN RIGHT ANTI (cr=22401 pr=0 pw=0 time=75084 us cost=56 size=46948 card=484)
0 VIEW VW_NSO_4 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
0 FILTER (cr=180 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
0 INDEX FAST FULL SCAN D96_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35121)
0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
1773000 NESTED LOOPS (cr=22221 pr=0 pw=0 time=56155 us)
1773000 NESTED LOOPS (cr=3231 pr=0 pw=0 time=15078 us cost=53 size=34364 card=484)
50 INDEX RANGE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=7 us cost=1 size=7 card=1)(object id 34021)
1773000 INDEX RANGE SCAN A96_STATEID_IX1 (cr=3221 pr=0 pw=0 time=6810 us cost=32 size=0 card=1774)(object id 35116)
1773000 TABLE ACCESS BY INDEX ROWID A96 (cr=18990 pr=0 pw=0 time=0 us cost=52 size=82560 card=1290)
10 VIEW (cr=216 pr=0 pw=0 time=0 us cost=7 size=47 card=1)
10 UNION ALL PUSHED PREDICATE (cr=216 pr=0 pw=0 time=0 us)
0 NESTED LOOPS ANTI (cr=1 pr=0 pw=0 time=0 us cost=2 size=82 card=1)
0 TABLE ACCESS BY INDEX ROWID CONNECTION_ATTRIBUTES (cr=1 pr=0 pw=0 time=0 us cost=1 size=78 card=1)
0 INDEX RANGE SCAN GDB_59_CONNECTIO (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 34346)
0 VIEW PUSHED PREDICATE VW_NSO_1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
0 INDEX UNIQUE SCAN D97_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35127)
10 HASH JOIN ANTI (cr=215 pr=0 pw=0 time=0 us cost=5 size=55 card=1)
10 NESTED LOOPS (cr=35 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
10 TABLE ACCESS BY INDEX ROWID A97 (cr=25 pr=0 pw=0 time=0 us cost=2 size=22 card=1)
10 INDEX RANGE SCAN GDB_59_CONNECTIO_A (cr=15 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 35122)
10 INDEX UNIQUE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
0 VIEW VW_NSO_2 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
0 FILTER (cr=180 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
0 INDEX FAST FULL SCAN D97_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35127)
0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
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
SQL*Net message from client 2 0.00 0.00After manually rewrite query in TOAD it produces nested loops on business table and than access v__96, v__97 produce desired quick performance.
I can use stored outlines but this is the last chance. I am playing with hints right now to produce desired plan with no result yet.
Does anybody know how to insist Oracle to merge internal views to bigger query block, so Oracle can choose better plan?
Or any guide what hints to use from ol$hints to get desired result via hints addition to original sql query (thanks God application don't cut hints just pass-through to Oracle)?
Thanks,
Sergiy
Maybe you are looking for
-
[SOLVED] Netbens Error with java openjdk7
hi! i have a error with netbeans: [pablo@arch ~]$ netbeans # A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0x802067a9, pid=11781, tid=2165295936 # JRE version: 7.0_21-b02 # Java VM: OpenJDK Client VM (23.7-b01
-
Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported.
SharePoint 2007 custom (VS 2008) solution is upgraded to SharePoint 2013 using (VS 2012). I followed this approach. I had created new empty project (solution) in SharePoint 2013 using (VS 2012) compiled and deployed successfully. All safe controls ar
-
I have just required a second hand mac and when I try to download a song or import a cd to iTunes an error notice says that I am not priveledged to make changes? The preference settings and apple I'd seem to be ok. How do I fix this?
-
Hi experts pardon me if I am wrong, it says OWB in 11g Rel 2 come as part of database does it incur additional license costs as i believe OWB is used for data migration from legacy systems thanks
-
Transferring data with system 10.4.
My daughter wants to transfer the contents of a much older laptop (I'd guess a G4) to a slightly less-older iBook, both, of course using a 10.4. system. Since Migration Assistant is a 10.5. feature, I believe, how best to do this under that older sys