Explain plan looks ok but query still slow

hi,
i have a query that from the explain plan it looks ok( at least to me) but the query is taking very long time to return results
how can i further improve its performance ?
SELECT STATEMENT, GOAL = CHOOSE     Cardinality=45     Cost=7529     Optimizer=CHOOSE
SORT UNIQUE     Cardinality=45     Cost=7426
FILTER
   FILTER
    HASH JOIN     Cardinality=45     Cost=7421
     INDEX RANGE SCAN     Cardinality=277     Cost=5     Optimizer=ANALYZED     Object name=FDC_EQP_IDX
     TABLE ACCESS BY INDEX ROWID     Cardinality=417     Cost=7415     Optimizer=ANALYZED     Object name=FDC_SSALARMACTIVE
      INDEX RANGE SCAN     Cardinality=15015     Cost=42     Optimizer=ANALYZED     Object name=FDC_SSALARM_IDX
   BITMAP CONVERSION TO ROWIDS
    BITMAP AND
     BITMAP INDEX SINGLE VALUE                    Object name=FDC_ALARM_IDX1
     BITMAP CONVERSION FROM ROWIDS
      INDEX RANGE SCAN     Cardinality=11     Cost=1     Optimizer=ANALYZED     Object name=FDC_ALARM_IDX2tks & rdgs

Hi,
I agreed with Nicolas. But I have few suggestion for.
First you check the indexes used is fine or not.
-FDC_SSALARMACTIVE
-FDC_SSALARM_IDX
Because I am confuse here
""TABLE ACCESS BY INDEX ROWID Cardinality=417 Cost=7415 Optimizer=ANALYZED Object name=FDC_SSALARMACTIVE"
IF the table is accessed by index rowid then why both the Cost & Cardinality is that much high.
Thanx.. Ratan

Similar Messages

Explain plan - lower cost but higher response time in 11g compared to 10g

Hello,
I have a strange scenario where 'm migrating a db from standalone Sun FS running 10g RDBMS to a 2-Node Sun/ASM 11g RAC env. The issue is with response time of queries -
In 11g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANALYZED NUM_ROWS
11-08-2012 18:21:12 3413956
Elapsed: 00:00:00.30
In 10g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANAL NUM_ROWS
07-NOV-12 3502160
Elapsed: 00:00:00.04If you look @ the response times, even a simple query on the dba_tables takes ~8 times. Any ideas what might be causing this? I have compared the XPlans and they are exactly the same, moreover, the cost is less in the 11g env compared to the 10g env, but still the response time is higher.
BTW - 'm running the queries directly on the server, so no network latency in play here.
Thanks in advance
aBBy.

*11g Env:*
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1104 | 376K| 394 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1104 | 376K| 394 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1104 | 376K| 393 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1136 | | 15 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
*10g Env:*
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1137 | 373K| 389 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1137 | 373K| 389 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1137 | 373K| 388 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1137 | | 15 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
The query used is:
explain plan for
select
NCP_DETAIL_ID ,
NCP_ID ,
STATUS_ID ,
FIBER_NODE ,
NODE_DESC ,
GL ,
FTA_ID ,
OLD_BUS_ID ,
VIRTUAL_NODE_IND ,
SERVICE_DELIVERY_TYPE ,
HHP_AUDIT_QTY ,
COMMUNITY_SERVED ,
CMTS_CARD_ID ,
OPTICAL_TRANSMITTER ,
OPTICAL_RECEIVER ,
LASER_GROUP_ID ,
UNIT_ID ,
DS_SLOT ,
DOWNSTREAM_PORT_ID ,
DS_PORT_OR_MOD_RF_CHAN ,
DOWNSTREAM_FREQ ,
DOWNSTREAM_MODULATION ,
UPSTREAM_PORT_ID ,
UPSTREAM_PORT ,
UPSTREAM_FREQ ,
UPSTREAM_MODULATION ,
UPSTREAM_WIDTH ,
UPSTREAM_LOGICAL_PORT ,
UPSTREAM_PHYSICAL_PORT ,
NCP_DETAIL_COMMENTS ,
ROW_CHANGE_IND ,
STATUS_DATE ,
STATUS_USER ,
MODEM_COUNT ,
NODE_ID ,
NODE_FIELD_ID ,
CREATE_USER ,
CREATE_DT ,
LAST_CHANGE_USER ,
LAST_CHANGE_DT ,
UNIT_ID_IP ,
US_SLOT ,
MOD_RF_CHAN_ID ,
DOWNSTREAM_LOGICAL_PORT ,
STATE
from markethealth.NCP_DETAIL_TAB
WHERE UNIT_ID = :B1
ORDER BY UNIT_ID, DS_SLOT, DS_PORT_OR_MOD_RF_CHAN, FIBER_NODE
This is the query used for Query 1.
Stats differences are:
1. Rownum differes by apprx - 90K more rows in 10g env
2. RAC env has 4 additional columns (excluded in the select statement for analysis purposes).
3. Gather Stats was performed with estimate_percent = 20 in 10g and estimate_percent = 50 in 11g.

Explain plan different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme

How to change the explain plan for currently running query?

Hi All,
I am using Oracle enterprise 9i edition. I have a query which frames dynamically and running in the database. I noticed a table with 31147758 rows
in the query which has no indexes and taking more time to process. I tried to create an INdex on that table. I know the query is already running with a FULL table scan. Is it possible to change the explain plan for the current running query to consider the INDEX?
[code]
SELECT /*+ USE_HASH (c,e,b,a) */
d.att_fcc extrt_prod_dim_id,
d.att_fcc compr_prod_dim_id,
a.glbl_uniq_id glbl_uniq_id,
to_date(c.dit_code,'RRRRMMDD')STRT_DT,
(to_date(c.dit_code,'RRRRMMDD')+150)END_DT,
a.pat_nbr pat_id,
a.rxer_id       rxer_id,
e.rxer_geog_id rxer_geog_id,
a.pharmy_id pharmy_id,
a.pscr_pack_id pscr_pack_id,
a.dspnsd_pack_id dspnsd_pack_id,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr ORDER BY c.dit_code) daterank,
COUNT( DISTINCT d.att_fcc ) OVER (PARTITION BY a.pat_nbr, c.dit_code) event_cnt
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code) prodrank,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code DESC) stoprank
FROM
pd_dimitems c,
   pd_pack_attribs   d ,
    lrx_tmp_rxer_geog e,
    lrx_tmp_pat_daterank p,
    lrx_tmp_valid_fact_link     a
    WHERE c.dit_id = a.tm_id
    AND   e.rxer_id = a.rxer_id
    AND   a.glbl_uniq_id = p.glbl_uniq_id
    AND   p.daterank > 1
AND   a.pscr_pack_id = d.att_dit_id
[/code]
The table lrx_tmp_pat_daterank is having that 31147758 rows. So I am wondering how to make the query to use the newly created index on the table?

Why do you think using Indexes will improve the performance of the query? How many rows this query is returning? Optimizer might chose a Full table scan when it finds out that Index plan might not be useful. Why are you using /*+ USE_HASH (c,e,b,a) */ hint? This Hint will force oracle to use Full table scan instead of using the index. Try removing it and see if the plan changes.
Regards,

How i can obtain explain plan without run the query

Hello,
i need to know the result of explain of a query without run the query, it's this possible?
Thanks and best regards.

explain plan for <your query>;
select * from table(dbms_xplan.display);Regards,
Rob.

Cisco Router RV180W - Switch to faster speed modem but router still slow

We upgraded our DSL speed from 50 x 5 to 100 x 10 and can only achieve 40 x 10 on our LAN. Does
anyone have a solution ??

You Can Make use of the Wrt54g as a wireless switch but it cannot talk wirelessly to the 2wire router, you have to connect the wrt54g to the 2wire router with a Ethernet cable.
If you want the wrt54g to act as a switch and get internet from 2wire router do the following
Login to setup of linksys setup page
Configure the wireless settings
on the setup Tab Disable the DHCP server and save the settings
Now connect a Ethernet cable from the Lan port of the 2wire router to LAN port of the Linksys Wrt54g Router
Disabling the Wrt54g DHCP the router will act as a switch as it will be getting IP address from the DHCP server of the 2Wire router
Now you can connect wired devices by plugging it to the linksys router and wireless devices by connecting to the wireless network Name you configured in the router.

Explain plan for query with variables

Trying to Explain plan for some sql in sql*plus. The query has a variable in it. How do I do this ?
I did look into explain plan and dbms_xplan but could not find anything with variables

use sqlplus bind variables:
SQL> --define variable
SQL> var x varchar2
SQL> -- notice the colon prefixing the variable
SQL> explain plan for select * from customer where cid = :x;
Explained.
SQL> select * from table( dbms_xplan.display );
PLAN_TABLE_OUTPUT
Plan hash value: 1709312366
| Id | Operation                   | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |          |     1 |    67 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| CUSTOMER |     1 |    67 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | CID      |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("CID"=:X)
14 rows selected.the variable does not need to be set to explain the query, since explain does not actually execute.
Edited by: shoblock on Nov 6, 2008 4:51 PM

Query regarding Partition table Explain plan

Hello,
We are amidst a tuning activity, wherein a large table has been partitioned for better administration. During testing, I was analyzing the explain plans for long running sql's and found a piece that I was unable to understand. The PSTART and PSTOP columns show ROWID as its value, which in normal partition pruning scenario be the Partition number or the KEY. I tried to look around for this issue but did not get enough information. Can anybody help me of what it means? Also, if there is a good explanation of the same, it will be extremely helpful.
The snippet from explain plan looks like:
| Id | Operation                                | Name                          | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
7 |        TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXXXXXXXX             | 43874 | 9083K|       | 1386   (1)| 00:00:17 | ROWID | ROWID |
On another similar query it looks like:
| Id | Operation                             | Name                         | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXX               | 22455 | 4648K|       |   456   (1)| 00:00:06 |     9 |     9 |
I have another query with regards to the Partition tables. Does it, require/benefit if, the Indexes to be in partitioned mode? I tried to read about it but did not get a conclusive evidence. I am trying to test it and post here the outcome, but if anybody has experience of working with it, it would be great to have some advice.
Oracle Version:- 10.2.0.4
Regards,
Purvesh.

Hi Purvesh.
Great explanation and example on this this topic...
Ask Tom &quot;explain plan on range-partitioned table&quot;
Hope this help.

Query returns different Explain Plan

Hi,
I have two databases that are identical to each other. But I have a query that runs on both and returns different explain plans in both. It runs slower in one than other. How can I troubleshoot this further to get faster times in the slower database?
THanks,
Prachi

Query:
=====
SELECT sum(total_contacts), sum(email_partner_news), sum(email_tech_news),
sum(email_enduser_news), sum(email), sum(email_gmo), sum(gmo_nophone),
sum(email_gmo_noaddress), sum(email_gmo_address), sum(
email_gmo_nocertaddr), sum(email_gmo_certaddress), sum(
email_gmo_nophone_noaddr), sum(phone_number), sum(gmo_with_phone),
sum(phone_number_email_gmo_noaddr), sum(phone_number_email_gmo_nocert),
sum(phone_number_address), sum(phone_number_address_noemail), sum(
phone_address_email_nogmo), sum(phone_number_address_email), sum(
phone_number_certaddr), sum(phone_number_certaddr_noemail), sum(
phone_certaddr_email_nogmo), sum(phone_number_address_gmo), sum(
phone_certaddr_email_gmo), sum(address), sum(
address_nophone_number_nogmo), sum(address_certified), sum(
certaddr_nophone_nogmo), sum(address_email_nophone_gmo), sum(
certaddr_email_nophone_gmo), sum(phone_gmo), sum(smail_gmo), sum(fax_gmo
), sum(email_wcast), sum(email_inews), sum(email_salrt), sum(
phone_gmo_phone), sum(smail_gmo_address), sum(fax_gmo_fax)
FROM contact_values_vw_tc_2 cv, ((SELECT gcd_contact_id
FROM contact_values)
INTERSECT
((SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 1)
INTERSECT
(SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.sub_region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 2)) ) sl
WHERE cv.gcd_contact_id = sl.gcd_contact_id
AND cv.country_id IN (SELECT cm.country_id
FROM segmentation_user_country_map cm
WHERE cm.user_name = 'E30590')
========================================
Execution Plan - FAST
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=32931 Card=1 Bytes=73)
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=32931 Card=386388 Bytes=28206324)
3 2 VIEW (Cost=29617 Card=1142043 Bytes=14846559)
4 3 INTERSECTION
5 4 SORT (UNIQUE)
6 5 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1907737 Bytes=11446422)
7 4 INTERSECTION
8 7 SORT (UNIQUE)
9 8 HASH JOIN (Cost=655 Card=1998575 Bytes=57958675)
10 9 HASH JOIN (Cost=6 Card=110 Bytes=2200)
11 10 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
12 11 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_ PK' (UNIQUE) (Cost=2 Card=15)
13 10 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
14 9 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
15 7 SORT (UNIQUE)
16 15 HASH JOIN (Cost=655 Card=1142043 Bytes=33119247)
17 16 HASH JOIN (Cost=6 Card=63 Bytes=1260)
18 17 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
19 18 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=15)
20 17 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
21 16 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
22 2 HASH JOIN (Cost=2174 Card=645445 Bytes=38726700)
23 22 SORT (UNIQUE)
24 23 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP' (Cost=5 Card=43 Bytes=473)
25 22 TABLE ACCESS (FULL) OF 'CONTACT_VALUES1' (Cost=2151 Card=1907737 Bytes=93479113)
=====================================================
Execution Plan -SLOW
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8751 Card=1 Bytes=73 )
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (SEMI) (Cost=8751 Card=14477 Bytes=1056821)
3 2 MERGE JOIN (Cost=8583 Card=89527 Bytes=5550674)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'CONTACT_VALUES1' ( Cost=826 Card=1852109 Bytes=90753341)
5 4 INDEX (FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=26 Card=1852109)
6 3 SORT (JOIN) (Cost=7757 Card=89527 Bytes=1163851)
7 6 VIEW (Cost=7454 Card=89527 Bytes=1163851)
8 7 INTERSECTION
9 8 SORT (UNIQUE)
10 9 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1852109 Bytes=11112654)
11 8 INTERSECTION
12 11 SORT (UNIQUE)
13 12 HASH JOIN (Cost=640 Card=250676 Bytes=7269604)
14 13 HASH JOIN (Cost=6 Card=28 Bytes=560)
15 14 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
16 15 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
17 14 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
18 13 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
19 11 SORT (UNIQUE)
20 19 HASH JOIN (Cost=640 Card=89527 Bytes=25962 83)
21 20 HASH JOIN (Cost=6 Card=10 Bytes=200)
22 21 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
23 22 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
24 21 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
25 20 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
26 2 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP'
(Cost=5 Card=45 Bytes=495)

Explain plan for running query

Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
Shareef

912856 wrote:
Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
ShareefYOu can also use dbms_xplain to generate plan used in v$sql. like for example
SQL>SELECT SQL_ID, CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select * from em%';
SQL_ID CHILD_NUMBER
6kd5fkqdjb8fu 0
SQL>SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('6kd5fkqdjb8fu',0,'ALLSTATS'));If you need the actual tuntime statistics used by sql statement then you need to put hint /*+ gather_plan_statistics */ in sql ststement, something like
select /*+ gather_plan_statistics */ * from emp;
and then generate the explain plan for this
Have a look
http://hoopercharles.wordpress.com/2010/03/01/dbms_xplan-format-parameters/
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

Analyze Explain Plan --Query Stuck

Hello,
I am a newbie to Oracle.Urgently need help on a query running on Production Oracle 11g database.
This query is getting stuck for a very long time while fetching data.Here is the explain Plan for it.Could anyone please point out what is the problem and what needs to be corrected.Thanks in advance.
Rollback complete.
Explain complete.
Commit complete.
PLAN_TABLE_OUTPUT
Plan hash value: 3980578161
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 155 | 33325 | 716 (1)| 00:00:11 | | |
| 1 | SORT ORDER BY | | 155 | 33325 | 716 (1)| 00:00:11 | | |
|* 2 | VIEW | | 155 | 33325 | 715 (1)| 00:00:11 | | |
|* 3 | WINDOW SORT PUSHED RANK | | 155 | 61535 | 715 (1)| 00:00:11 | | |
|* 4 | VIEW | | 155 | 61535 | 714 (1)| 00:00:10 | | |
| 5 | WINDOW BUFFER | | 155 | 34565 | 714 (1)| 00:00:10 | | |
| 6 | SORT GROUP BY | | 155 | 34565 | 714 (1)| 00:00:10 | | |
| 7 | TABLE ACCESS BY INDEX ROWID | BTM_EIN | 1 | 19 | 2 (0)| 00:00:01 | | |
| 8 | NESTED LOOPS | | 155 | 34565 | 712 (1)| 00:00:10 | | |
|* 9 | HASH JOIN | | 155 | 31620 | 669 (1)| 00:00:10 | | |
|* 10 | HASH JOIN | | 222 | 28194 | 662 (1)| 00:00:10 | | |
| 11 | TABLE ACCESS BY LOCAL INDEX ROWID| PR_EMPRESS_PAYROLL_FACT | 194 | 7178 | 658 (1)| 00:00:10 | | |
| 12 | NESTED LOOPS | | 1001 | 89089 | 658 (1)| 00:00:10 | | |
| 13 | NESTED LOOPS | | 5 | 260 | 17 (6)| 00:00:01 | | |
|* 14 | HASH JOIN | | 5 | 200 | 7 (15)| 00:00:01 | | |
| 15 | NESTED LOOPS | | 6 | 144 | 4 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
|* 16 | INDEX UNIQUE SCAN | REPORT_OU_IDX1 | 1 | 14 | 1 (0)| 00:00:01 | | |
|* 17 | MAT_VIEW ACCESS FULL | PARENT_LEVEL_LOOKUP_MV | 6 | 60 | 3 (0)| 00:00:01 | | |
| 18 | TABLE ACCESS BY INDEX ROWID | TP_OUC_HIER_CDIM | 5 | 80 | 2 (0)| 00:00:01 | | |
| 19 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 20 | BITMAP INDEX SINGLE VALUE | TP_OUC_HI_IDX2 | | | | | | |
| 21 | TABLE ACCESS BY INDEX ROWID | LEDGER_OUC | 1 | 12 | 2 (0)| 00:00:01 | | |
|* 22 | INDEX RANGE SCAN | LEDGER_OUC_I1 | 1 | | 1 (0)| 00:00:01 | | |
| 23 | PARTITION RANGE ALL | | | | | | 1 | 82 |
| 24 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 25 | BITMAP INDEX SINGLE VALUE | PR_EMPRES_IDX7 | | | | | 1 | 82 |
|* 26 | MAT_VIEW ACCESS FULL | TP_TIME_CDIM_MV | 12 | 456 | 3 (0)| 00:00:01 | | |
|* 27 | TABLE ACCESS FULL | EMPRESS_CODE_DIM | 289 | 22253 | 7 (0)| 00:00:01 | | |
|* 28 | INDEX RANGE SCAN | BTM_EIN_I1 | 1 | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - filter("D1"."C16"=1)
3 - filter(ROW_NUMBER() OVER ( PARTITION BY "SAWITH1"."C5","SAWITH1"."C6","SAWITH1"."C20","SAWITH1"."C21","SAWITH1"."C26","S
AWITH1"."C27","SAWITH1"."C28","SAWITH1"."C29","SAWITH1"."C30" ORDER BY
PLAN_TABLE_OUTPUT
"SAWITH1"."C5","SAWITH1"."C6","SAWITH1"."C20","SAWITH1"."C21","SAWITH1"."C26","SAWITH1"."C27","SAWITH1"."C28","SAWITH1"."C29","
SAWITH1"."C30")<=1)
4 - filter(CASE WHEN '@{PR_Allowance}'='London Weighting' THEN "SAWITH1"."C9" WHEN '@{PR_Allowance}'='Pensionable' THEN
"SAWITH1"."C10" WHEN '@{PR_Allowance}'='Non Pensionable' THEN "SAWITH1"."C11" ELSE "SAWITH1"."C8" END <>0.0)
9 - access("T808692"."EMPRESS_CODE_KEY"="T808833"."PR_EMPRESS_CODE_KEY")
10 - access("T808833"."PERIOD_KEY"="T809005"."PERIOD_KEY")
14 - access("T808816"."LEVEL_FROM_PARENT"="T808999"."LEVEL_FROM_PARENT")
16 - access("T809014"."TP_REPORT_OUC_KEY"='B')
17 - filter("T808816"."OUC_TYPE"='Summed')
20 - access("T808999"."TP_REPORT_OUC_KEY"='B')
22 - access("T808999"."TP_CHILD_REPORT_OUC_KEY"="REPORT_OUC")
25 - access("T808833"."TP_LEDGER_OUC_KEY"="LEDGER_OUC")
26 - filter("T809005"."YEAR_DESC"='2010/11' AND TO_NUMBER("T809005"."PERIOD_KEY")<=201112)
27 - filter("T808692"."EMPRESS_HIER_3_CODE"=3 OR "T808692"."EMPRESS_HIER_3_CODE"=5 OR "T808692"."EMPRESS_HIER_3_CODE"=13 OR
"T808692"."EMPRESS_HIER_3_CODE"=17 OR "T808692"."EMPRESS_HIER_3_CODE"=19 OR "T808692"."EMPRESS_HIER_3_CODE"=27 OR
"T808692"."EMPRESS_HIER_3_CODE"=29 OR "T808692"."EMPRESS_HIER_3_CODE"=31)
28 - access("A"."EIN"="T808833"."TP_EIN_KEY")
Note
- dynamic sampling used for this statement
63 rows selected.
Regards
AD

Here is the explain plan for the same query run on CT environment.
Rollback complete.
Explain complete.
Commit complete.
PLAN_TABLE_OUTPUT
Plan hash value: 3514862671
| Id | Operation                                          | Name                    | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |    TQ |I
N-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                                   |                         | 58565 |    14M|       | 5558   (1)| 00:01:18 |       |       |        |
     |            |
|   1 | PX COORDINATOR                                    |                         |       |       |       |            |          |       |       |        |
     |            |
|   2 |   PX SEND QC (ORDER)                               | :TQ10011                | 58565 |    14M|       | 5558   (1)| 00:01:18 |       |       | Q1,11 |
P->S | QC (ORDER) |
|   3 |    SORT ORDER BY                                   |                         | 58565 |    14M|    33M| 5558   (1)| 00:01:18 |       |       | Q1,11 |
PLAN_TABLE_OUTPUT
PCWP |            |
|   4 |     PX RECEIVE                                     |                         | 58565 |    14M|       | 5556   (1)| 00:01:18 |       |       | Q1,11 |
PCWP |            |
|   5 |      PX SEND RANGE                                 | :TQ10010                | 58565 |    14M|       | 5556   (1)| 00:01:18 |       |       | Q1,10 |
P->P | RANGE      |
|* 6 |       VIEW                                         |                         | 58565 |    14M|       | 5556   (1)| 00:01:18 |       |       | Q1,10 |
PCWP |            |
|* 7 |        WINDOW SORT PUSHED RANK                     |                         | 58565 |    24M|    57M| 5556   (1)| 00:01:18 |       |       | Q1,10 |
PCWP |            |
|* 8 |         VIEW                                       |                         | 58565 |    24M|       | 5555   (1)| 00:01:18 |       |       | Q1,10 |
PCWP |            |
|   9 |          WINDOW BUFFER                             |                         | 58565 |    13M|       | 5555   (1)| 00:01:18 |       |       | Q1,10 |
PCWP |            |
| 10 |           SORT GROUP BY                            |                         | 58565 |    13M|    28M| 5555   (1)| 00:01:18 |       |       | Q1,10 |
PLAN_TABLE_OUTPUT
PCWP |            |
| 11 |            PX RECEIVE                              |                         | 58565 |    13M|       | 5554   (1)| 00:01:18 |       |       | Q1,10 |
PCWP |            |
| 12 |             PX SEND HASH                           | :TQ10009                | 58565 |    13M|       | 5554   (1)| 00:01:18 |       |       | Q1,09 |
P->P | HASH       |
|* 13 |              HASH JOIN                             |                         | 58565 |    13M|       | 5554   (1)| 00:01:18 |       |       | Q1,09 |
PCWP |            |
| 14 |               PX RECEIVE                           |                         | 58565 |    12M|       | 1731   (1)| 00:00:25 |       |       | Q1,09 |
PCWP |            |
| 15 |                PX SEND HASH                        | :TQ10008                | 58565 |    12M|       | 1731   (1)| 00:00:25 |       |       | Q1,08 |
P->P | HASH       |
|* 16 |                 HASH JOIN BUFFERED                 |                         | 58565 |    12M|       | 1731   (1)| 00:00:25 |       |       | Q1,08 |
PCWP |            |
| 17 |                  BUFFER SORT                       |                         |       |       |       |            |          |       |       | Q1,08 |
PLAN_TABLE_OUTPUT
PCWC |            |
| 18 |                   PX RECEIVE                       |                         |     1 |    14 |       |     1   (0)| 00:00:01 |       |       | Q1,08 |
PCWP |            |
| 19 |                    PX SEND BROADCAST               | :TQ10001                |     1 |    14 |       |     1   (0)| 00:00:01 |       |       |        |
S->P | BROADCAST |
|* 20 |                     INDEX RANGE SCAN               | REPORT_OU_IDX1          |     1 |    14 |       |     1   (0)| 00:00:01 |       |       |        |
     |            |
|* 21 |                  HASH JOIN                         |                         | 58565 |    11M|       | 1730   (1)| 00:00:25 |       |       | Q1,08 |
PCWP |            |
| 22 |                   BUFFER SORT                      |                         |       |       |       |            |          |       |       | Q1,08 |
PCWC |            |
| 23 |                    PX RECEIVE                      |                         |   383 | 31023 |       |     7   (0)| 00:00:01 |       |       | Q1,08 |
PCWP |            |
| 24 |                     PX SEND BROADCAST              | :TQ10002                |   383 | 31023 |       |     7   (0)| 00:00:01 |       |       |        |
PLAN_TABLE_OUTPUT
S->P | BROADCAST |
|* 25 |                      TABLE ACCESS FULL             | EMPRESS_CODE_DIM        |   383 | 31023 |       |     7   (0)| 00:00:01 |       |       |        |
     |            |
|* 26 |                   HASH JOIN                        |                         | 82520 | 9912K|       | 1722   (1)| 00:00:25 |       |       | Q1,08 |
PCWP |            |
| 27 |                    BUFFER SORT                     |                         |       |       |       |            |          |       |       | Q1,08 |
PCWC |            |
| 28 |                     PX RECEIVE                     |                         |     6 |    60 |       |     3   (0)| 00:00:01 |       |       | Q1,08 |
PCWP |            |
| 29 |                      PX SEND BROADCAST             | :TQ10003                |     6 |    60 |       |     3   (0)| 00:00:01 |       |       |        |
S->P | BROADCAST |
|* 30 |                       MAT_VIEW ACCESS FULL         | PARENT_LEVEL_LOOKUP_MV |     6 |    60 |       |     3   (0)| 00:00:01 |       |       |        |
     |            |
|* 31 |                    HASH JOIN                       |                         |   136K|    14M|       | 1718   (1)| 00:00:25 |       |       | Q1,08 |
PLAN_TABLE_OUTPUT
PCWP |            |
| 32 |                     BUFFER SORT                    |                         |       |       |       |            |          |       |       | Q1,08 |
PCWC |            |
| 33 |                      PX RECEIVE                    |                         | 43293 |   845K|       | 1137   (1)| 00:00:16 |       |       | Q1,08 |
PCWP |            |
| 34 |                       PX SEND BROADCAST            | :TQ10004                | 43293 |   845K|       | 1137   (1)| 00:00:16 |       |       |        |
S->P | BROADCAST |
| 35 |                        TABLE ACCESS BY INDEX ROWID | TP_OUC_HIER_CDIM        | 43293 |   845K|       | 1137   (1)| 00:00:16 |       |       |        |
     |            |
| 36 |                         BITMAP CONVERSION TO ROWIDS|                         |       |       |       |            |          |       |       |        |
     |            |
|* 37 |                          BITMAP INDEX SINGLE VALUE | TP_OUC_HI_IDX2          |       |       |       |            |          |       |       |        |
     |            |
|* 38 |                     HASH JOIN                      |                         |   627K|    55M|       |   581   (2)| 00:00:09 |       |       | Q1,08 |
{code}
Edited by: user1128836 on Apr 26, 2012 3:39 AM

Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
         0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE         OWNER
SYNONYM             APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
PO_LINES                       PO                             PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
         C
      8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
|* 1 | FILTER            |              |       |       |            |
|   2 |   TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K|   106   (4)|
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE         OWNER
TABLE               POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneesh

Next time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

Explain plans comparison

Guys,
I've a query with explain plan as below:
| Id | Operation                              | Name                 | Rows | Bytes | Cost | Pstart| Pstop |
|   0 | SELECT STATEMENT                       |                       |    12 |   792 | 1172 |       |       |
|   1 | SORT GROUP BY                         |                       |    12 |   792 | 1172 |       |       |
|   2 |   HASH JOIN                            |                       |    12 |   792 | 1159 |       |       |
|   3 |    MERGE JOIN CARTESIAN                |                       |   206 | 2884 |    34 |       |       |
|   4 |     VIEW                               | VW_NSO_1              |     1 |    10 |    20 |       |       |
|   5 |      SORT UNIQUE                       |                       |     1 |    35 |    20 |       |       |
|   6 |       TABLE ACCESS BY LOCAL INDEX ROWID| PROD                 |     1 |    35 |     7 |    65 |    65 |
PLAN_TABLE_OUTPUT
|   7 |        INDEX RANGE SCAN                | PROD_PK               |     7 |       |     3 |    65 |    65 |
|   8 |     BUFFER SORT                        |                       |   206 |   824 |    34 |       |       |
|   9 |      VIEW                              | VW_NSO_2              |   206 |   824 |    15 |       |       |
| 10 |       SORT UNIQUE                      |                       |   206 | 3914 |    15 |       |       |
| 11 |        INDEX FAST FULL SCAN            | GEO                   |   295 | 5605 |     1 |    22 |    22 |
| 12 |    PARTITION RANGE INLIST              |                       |       |       |       |KEY(I) |KEY(I) |
| 13 |     TABLE ACCESS BY LOCAL INDEX ROWID | FP_FSRVOL_FB          | 36641 | 1860K| 1124 |KEY(I) |KEY(I) |
| 14 |      INDEX RANGE SCAN                  | FP_FSRVOL_FB_IDX1     | 6595 |       | 1009 |KEY(I) |KEY(I) |
And with little modifications to the query, the explain plan looks below:
| Id | Operation                              | Name                  | Rows | Bytes | Cost | Pstart| Pstop |
|   0 | SELECT STATEMENT                       |                        |    63 | 3528 | 1140 |       |       |
|   1 | SORT GROUP BY                         |                        |    63 | 3528 | 1140 |       |       |
|   2 |   HASH JOIN                            |                        |    63 | 3528 | 1127 |       |       |
|   3 |    MERGE JOIN CARTESIAN                |                        |   206 | 2884 |    34 |       |       |
|   4 |     VIEW                               | VW_NSO_1               |     1 |    10 |    20 |       |       |
|   5 |      SORT UNIQUE                       |                        |     1 |    35 |    20 |       |       |
|   6 |       TABLE ACCESS BY LOCAL INDEX ROWID| PROD                   |     1 |    35 |     7 |    65 |    65 |
PLAN_TABLE_OUTPUT
|   7 |        INDEX RANGE SCAN                | PROD_PK                |     7 |       |     3 |    65 |    65 |
|   8 |     BUFFER SORT                        |                        |   206 |   824 |    34 |       |       |
|   9 |      VIEW                              | VW_NSO_2               |   206 |   824 |    15 |       |       |
| 10 |       SORT UNIQUE                      |                        |   206 | 3914 |    15 |       |       |
| 11 |        INDEX FAST FULL SCAN            | GEO                    |   295 | 5605 |     1 |    22 |    22 |
| 12 |    PARTITION RANGE ALL                 |                        |       |       |       |     1 |   506 |
| 13 |     TABLE ACCESS BY LOCAL INDEX ROWID | FP_FSRVOL_FB           |   183K| 7539K| 1092 |     1 |   506 |
| 14 |      INDEX RANGE SCAN                  | FP_FSRVOL_FB_DUE_PERD | 33086 |       |   594 |     1 |   506 |I've seen PSTOP=PSTART = KEY,but KEY(I) looks strange to me.
Could someone explain the same?
And I need your advice regarding which of the above plans is acceptable..
Regards,
Bhagat

This is from the Oracle documentation:
Index Column
If the IN list column EMPNO is an index column but not a partition column, then the plan is as follows (the IN list operator appears above the table operation but below the partition operation):
OPERATION         OPTIONS        OBJECT_NAME   PARTITION_START   PARTITION_STOP
SELECT STATEMENT
PARTITION         CONCATENATED                 KEY(INLIST)       KEY(INLIST)
INLIST ITERATOR   CONCATENATED
TABLE ACCESS      BY ROWID       EMP           KEY(INLIST)       KEY(INLIST)
INDEX             RANGE SCAN     EMP_EMPNO     KEY(INLIST)       KEY(INLIST)
The KEY(INLIST) designation for the partition start and stop keys specifies that an IN list predicate appears on the index start/stop keys.
/[pre]
I'll assume the changes involve either removing an IN list or changing the query so that it decides that a full scan is better than using a INLIST ITERATOR to scan through the list. It's difficult to say which is better without knowing how many values are in the IN list and how big the table is that the values are taken from. The IN LIST iterator seems to result in less rows being processed so in theory could be quicker... The best way is to try it.

Problem wid explain plans

hi all,
i am facing problem with the explain plan of the following query , firslty my database version is 9.2.0.5 , EBS is 11.5.10 and OS is HP UX 11.11
select
a.vendor_site_code,
'GAIN/LOSS' invoice_type_lookup_code,
api.invoice_num,
d. ACCOUNTING_DATE INVOICE_DATE ,
null description,
a.accts_pay_code_combination_id ccid,
c.currency_code invoice_currency_code,
c.currency_conversion_rate rate ,
DECODE(c.ae_line_type_code,'GAIN',accounted_cr/NVL(c.currency_conversion_rate,1),0) dr_val,
DECODE(c.ae_line_type_code,'LOSS',accounted_dr/NVL(c.currency_conversion_rate,1),0) cr_val,
null payment_num,
d.accounting_date pay_accounting_date,
null check_number,
b.segment1 ,
null ATTRIBUTE5,
b.vendor_name,
b.vendor_type_lookup_code,
apd.po_distribution_id po_distribution_id,
api.exchange_rate_type,
api.org_id,
api.batch_id,
sysdate exchange_date,
api.invoice_id,
d.accounting_date
from po_vendor_sites_all a,
po_vendors b,
ap_ae_lines_all c,
ap_ae_headers_all d,
ap_invoices_all api,
ap_invoice_distributions_all apd
where a.vendor_id = b.vendor_id AND
a.vendor_id = api.vendor_id AND
a.vendor_site_id = api.vendor_site_id AND
b.vendor_id = api.vendor_id AND
c.ae_header_id = d.ae_header_id AND
c.ae_line_type_code in ( 'GAIN','LOSS') AND
c.source_table = 'AP_INVOICE_DISTRIBUTIONS' AND
c.source_id = apd.invoice_distribution_id AND
D.ACCOUNTING_DATE < :p_to_date AND
b.vendor_id = NVL(:p_vendor_id,b.vendor_id) AND
(api.org_id = :p_org_id OR api.org_id IS NULL) AND
b.segment1 = NVL(:p_vendor_no, b.segment1) AND
api.vendor_id = NVL(:p_vendor_id, api.vendor_id)
this query was taking around 7-8 hrs to complete , so i ran gather schema statistics , this solved my problem , but few days back some one accidenlty cancelled
gather schema statistics , so i started facing the same problem.
but this time ,even after running stats i am unable to solve the problem , the same query runs fine on test server, please view the outputs of both plans and the query, there seems to be a difference of table selection in both plans, can any one plz help me on this one, iam runnig out of ideas here
the plans are uploaded to
http://rapidshare.com/files/226264001/9iprod_plan.zip.html

sir,
the query is same ob both instances i have double checked it
the prob on production server started only after gather schema statistics was cancelled by mistake on PROD, earlier it was working fine
another difference in explain plans is that in TEST instance it uses ap_ae_lines_all table
and Prod uses ap_ae_headers_all which is slow
Edited by: user7864753 on Apr 27, 2009 5:11 PM

SDO_ANYINTERACT query runs slower with numerous iterations

hi all,
I have some PL/SQL code within a loop that take longer and longer to run as it iterates through the loop.
I have identified the problem function below. It seems that the SDO_ANYINTERACT takes longer and longer to execute the more it is called.
I have found a bug on metalink 7003151 with indicates a potential memory leak issue. Could this be a cause? I know that this function runs as expected using Oracle Express. The issue is on a development server which has been patched to 10.2.0.4.
FUNCTION SEARCHFORFEATURE(sTABLE VARCHAR2,gGEOM MDSYS.SDO_GEOMETRY, nSEARCH NUMBER) RETURN VARCHAR2 IS
TYPE typNIMSREF IS TABLE OF VARCHAR2(10);
vNIMSREF TYPNIMSREF;
sSQL VARCHAR2(500);
BEGIN
     sSQL := 'SELECT NIMSREF FROM ' || sTABLE || ' S WHERE SDO_ANYINTERACT(S.GEOLOC, :gGEOM) = 'TRUE';
     EXECUTE IMMEDIATE sSQL BULK COLLECT INTO vNIMSref USING gGEOM;
     IF vNIMSREF.COUNT = 1 THEN
          RETURN vNIMSREF(1);
     ELSIF vNIMSREF.COUNT > 1 THEN
          RETURN '-1';
     ELSE
          RETURN '-2';
     END IF;
EXCEPTION -- exception-handling part starts here
     WHEN OTHERS THEN
     dbms_output.put_line(SQLERRM);
     dbms_output.put_line(sSQL);
END SEARCHFORFEATURE;
Thanks in advance
Daniel

I have run the query in SQLPLUS. As a single call performance is as expected. I ahve included the XPLAN. I have also tried using SDO_RELATE and SDO_INSIDE but it still slows down after a number if interations. I have looked at bug 7003151 but there are not available patches for a window 32bit OS.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3399 | 331K| 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| WATER_NODES | 3399 | 331K| 3 (0)| 00:00:01 |
|* 2 | DOMAIN INDEX | WATER_NODES_SDX | | | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("MDSYS"."SDO_ANYINTERACT"("S"."GEOLOC","MDSYS"."SDO_GEOMETRY"(2003,82086,
NULL,"SDO_ELEM_INFO_ARRAY"(1,1003,4),"SDO_ORDINATE_ARRAY"(123455.9,123456,123456.1,1234
56,123456,123456.1)))='TRUE')

Explain plan looks ok but query still slow

Similar Messages

Maybe you are looking for