Table Access

What is the difference between USER_TAB_PRIVS and DBA_TAB_PRIVS?

So USER_TAB_PRIVS is a view of DBA_TAB_PRIVS, showing the objects that I own, have granted to someone, or have been granted by someone. Check.
Is there any way to do this:
GRANT SELECT ON PS_PAYGROUP_TBL TO (SELECT OPRID FROM PSOPRDEFN WHERE OPRCLASS = '0')
In other words, I want to grant table access to a specific group of operators....without keying them manually.

Similar Messages

INDEX UNIQUE SCAN instead of   INDEX FULL SCAN or TABLE ACCESS FULL

I have calculated statistics in all tables and indexes
I have a table and a view and when I put it
SELECT *
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
Itâs OK. I NEED IT (INDEX UNIQUE SCAN)
But If I put
SELECT A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
In table A make a TABLE ACCESS FULL.
Then If I put:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
Itâs OK. I NEED IT (INDEX UNIQUE SCAN)
Finally, If I put other tables and views in the query (I NEED IT)
For example:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
INNER JOIN TABLE_Câ¦.
LEFT JOIN VIEW_Dâ¦.
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX FULL SCAN (FIELD_A_TABLE_A_PK)
I need INDEX UNIQUE SCAN instead of INDEX FULL SCAN or TABLE ACCESS FULL.
How can obtain it?
What happens???
Thanks!

Notice the difference in cardinality between your two select statements:
SELECT STATEMENT, GOAL = ALL_ROWS Cost=5 Cardinality=1
SELECT STATEMENT, GOAL = ALL_ROWS Cost=10450 Cardinality=472161Apparently since the optimizer believed the first statement was going to return one row, it used an index. But in the second statement it believed it was going to return nearly the whole table (didn't you say it had around 500k rows?). Hence full table scan.

Using index in a query return few records than full table access

Today we have an issue with a query, when it use the ok index the returned are not all records that apply to where clause condition.
See bellow
explain plan for
select * from movdb.zan_m03 where
M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
M00za = 10 AND
m00AC = 50 AND
M00AD between 136906 and 136999
SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1882720105
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS BY INDEX ROWID| ZAN_M03 |
|* 2 | INDEX RANGE SCAN | PK_ZAN_M03 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("M00AF"=TO_DATE('11/01/28','YY/MM/DD') AND "M00ZA"=10 AND
"M00AC"=50 AND "M00AD">=136906 AND "M00AD"<=137141)
filter("M00AD"<=137141 AND "M00AD">=136906)
Note
- rule based optimizer used (consider using cbo)
20 rows selected.
The query above return only one row insted 1579 record that apply to this conditions.
When forcing a full table acess with a hint, the query return all records that apply, the 1579 record.
select /*+ FULL(zan_m03) */ M00AF, M00za, m00AC , M00AD from movdb.zan_m03 where
M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
M00za = 10 AND
m00AC = 50 AND
M00AD between 136906 and 137141
Can you help me to identify what's happening?
I am with Oracle 10g R2 10.2.0.4 standard edition
the statistics are up to date
the opitimizer_mode are rule, but altering in session level to all_rows happens the same issue.
Nothing about corruption in the alert log.
Thanks in advance
Regards
Cristiano

Yes the query are the same and correct restriction for where clause are M00AD between 136906 and 137141.
I've pasted, by mistake, another test query
The corrects are:
select M00AF, M00za, m00AC , M00AD from movdb.zan_m03 where
M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
M00za = 10 AND
m00AC = 50 AND
M00AD between 136906 and 137141
This use pk index and return one row
select /*+ FULL(zan_m03) */ M00AF, M00za, m00AC , M00AD from movdb.zan_m03 where
M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
M00za = 10 AND
m00AC = 50 AND
M00AD between 136906 and 137141
This does a full table access and return 1579 records
I´ve been searching for wrong results bugs on my oracle support, but not found one that mentions something like our issue.
I checked the dba_tables and dba indexes and the number of rows are different, and I think this would be the same because it's is a pk.
Look this
SQL> select NUM_ROWS from dba_tables where table_name = 'ZAN_M03'
2 /
NUM_ROWS
228527878
select NUM_ROWS from dba_indexes where index_name = 'PK_ZAN_M03';
SQL> select NUM_ROWS from dba_indexes where index_name = 'PK_ZAN_M03';
NUM_ROWS
217510185
Is normal a index for pk having much fewer rows than table? I think not, but not sure.
Again
Thanks in advance
Regards
Cristiano

Table access by index rowid taking more time

Hi All
I've a query like
update tab1
set col1 = ( select col2 from
tab2
where tab1.id = tab2.id) table 1 has arnd 10,000 rows
table 2 has arnd 1,700,000 rows and has a primay key on column id.
This query is taking around 20 secs to execute. I checked the xplan and most of time taken for table access by index rowid.
Could you please suggest what can be the reason for this. (Can it be the clustering factor or something else)
I checked the stats for the tab2, its just three days old.
Regards
Ashwani

>
table 1 has arnd 10,000 rows
table 2 has arnd 1,700,000 rows and has a primay key on column id.
This query is taking around 20 secs to execute. I checked the xplan and most of time taken for table access by index rowid.
Could you please suggest what can be the reason for this. (Can it be the clustering factor or something else)
I checked the stats for the tab2, its just three days old.
>
If you checked the xplan why haven't you posted it so we can look at it? Then we could see what table is being accessed by index rowid. Presumably it is table 2 but we the plan would eliminate the need to make assumptions.
The clustering factor could be a factor. You haven't told us how table1 is being accessed. All rows are being updated so a full table scann is most likely but again the plan would actually show the access.
Did you query the dictionary to see what the clustering factor is? Post the results of that
SQL> select index_name, leaf_blocks, avg_leaf_blocks_per_key, avg_data_blocks_per_key, clustering_factor, distinct_keys
2 from dba_indexes
3 where owner = 'schema'
4 and index_name in ('index_b','index_a');

Oracle 9.2 prefers Table Access Full over Local Index by rowid access

There's this table that has phone call records (30 million per day) that is partitioned by month (using the date column) and stores the last 6 months.
The primary key is date (varchar2 in yymmdd format) + call_id (a varchar2(18) with a format like this yyyymmdd+<3letters>+<sequentialnumber>)
The partition is by range like this:
PARTITION BY RANGE (FECHA)
PARTITION P200804 VALUES LESS THAN ('080501')
LOGGING
NOCOMPRESS,
If I run this query I get this plan
SELECT FECHA, SENTIDOTRAFICO,GEOGRAFIAID,SWITCHID,TIPOTRAFICOID,COUNT(*)
FROM GES_CDRS_RCNG_NEW
WHERE FECHA BETWEEN '080801' AND '080825'
     AND TASACION IS NULL
     AND BORRADO IS NULL
GROUP BY FECHA, SENTIDOTRAFICO,GEOGRAFIAID,SWITCHID,TIPOTRAFICOID
Plan
SELECT STATEMENT CHOOSECost: 78 K Bytes: 24 K Cardinality: 1 K
     2 SORT GROUP BY Cost: 78 K Bytes: 24 K Cardinality: 1 K
          1 TABLE ACCESS FULL GESTION.GES_CDRS_RCNG_NEW Cost: 43 K Bytes: 625 M Cardinality: 31 M Partition #: 2 Partitions accessed #5
If I hint the primary key index using /*+INDEX(GES_CDRS_RCNG_NEW PK_CDRS_RCNG_NEW)*/
I get a different plan
Plan
SELECT STATEMENT CHOOSECost: 954 K Bytes: 24 K Cardinality: 1 K
     3 SORT GROUP BY Cost: 954 K Bytes: 24 K Cardinality: 1 K
          2 TABLE ACCESS BY LOCAL INDEX ROWID GESTION.GES_CDRS_RCNG_NEW Cost: 918 K Bytes: 625 M Cardinality: 31 M Partition #: 2 Partitions accessed #5
               1 INDEX RANGE SCAN UNIQUE GESTION.PK_CDRS_RCNG_NEW Cost: 137 K Cardinality: 31 M Partition #: 3 Partitions accessed #5
Looking at the cost, the full scan is way better, but this is obviously not the case. Why does this happen?
This problem forces many querys on this table to use hints or force the index use by adding conditions to the where clause like this
where fecha = '080801'
and clave like '20080801%'
when just by stating the date would be enough to choose the correct partition. It also messes up joins with other tables.
The table is analized every month, it has statistics that claim: 237,981,000 rows, 3,222,677 blocks, GLOBAL STATS: YES, LAST ANALYZED: 15/10/2008 21:05:26, Average row length: 213.
The partition envolved in this query has this stats: 32,520,520 rows, 442,715 blocks, analized on 27/08/2008 20:43:40
The index has this stats: analized on 15/10/2008 21:35:32, Blevel: 3, leaf blocks: 1,056,410, distinct keys: 238,484,510.
It is a local index and each partition has its own statistics.

If I don't understand incorrectly the plan and the Predicater information, it seems the full scan version that costs less is actually doing a full scan from the biggining of the table (6 months) up to the 080825 date and the one using an index (hinted) does a better scan.
without hint
| Id | Operation            | Name              | Rows | Bytes | Cost | Pstart| Pstop |
|   0 | SELECT STATEMENT     |                    | 1170 | 24570 | 78443 |       |       |
|   1 | SORT GROUP BY       |                    | 1170 | 24570 | 78443 |       |       |
|* 2 |   TABLE ACCESS FULL | GES_CDRS_RCNG_NEW |    31M|   625M| 42579 |     5 |     5 |
Predicate Information (identified by operation id):
   2 - filter("GES_CDRS_RCNG_NEW"."FECHA"<='080825')
Note: cpu costing is offWith the hint:
| Id | Operation                          | Name              | Rows | Bytes | Cost | Pstart| Pstop |
|   0 | SELECT STATEMENT                   |                    | 1170 | 24570 |   953K|       |       |
|   1 | SORT GROUP BY                     |                    | 1170 | 24570 |   953K|       |       |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| GES_CDRS_RCNG_NEW |    31M|   625M|   918K|     5 |     5 |
|* 3 |    INDEX RANGE SCAN                | PK_CDRS_RCNG_NEW   |    31M|       |   136K|     5 |     5 |
Predicate Information (identified by operation id):
   3 - access("GES_CDRS_RCNG_NEW"."FECHA">='080801' AND "GES_CDRS_RCNG_NEW"."FECHA"<='080825')
Note: cpu costing is off

Export table access to oracle with Database ODBC()

Hi,
I export a table, access 2003, ent_tab whit 'DataBase ODBC()' to oracle.
I open Oracle SQL Developer and i can show table ent_tab, but i go worksheet and execute:
select * from ent_tab
and display error: ORA-00942...
Why??!!
Regards
Jomar

Because ODBC created the table with "" which allowed lower case table name, but Oracle uses upper case table name by default. Suggest you recreate the table with upper-case name to avoid having to use "" in select statements.
Edited by: rgeier on Oct 27, 2009 5:34 PM

Excluding slow table access in a UNION ALL view

Hi,
I have a view which unions three tables together.
One component of the view requires a table scan, as 90% of the records are required.
This view is then used in another outer select where these records are actually not required.
So I tagged each component with a code and excluded that in the outer select. However it still appears to access the table.
Is there any way I can exclude a component of the UNION ALL or do I need to explicitly split them?
example:
SELECT * FROM (
SELECT 'A' Q, JANUARY F FROM ENORMOUS.TABLE WHERE KEY = 'Non Selective Key' UNION ALL
SELECT 'B' Q, 1 F FROM DUAL UNION ALL
SELECT 'C' Q, 1 F FROM DUAL
) A
WHERE Q = 'B'
When I run the query plan without the WHERE it performs the table scan
When I include the WHERE it still performs the table scan but with a FILTER NULL IS NOT NULL afterwards.
So it appears that it is doing the table scan regardless and then throwing the records away - is that correct?
Any thoughts appreciated. I would prefer not the split this view out if possible as it is used everywhere.

In summary my question is: is The Oracle query planner smart enough to exclude a component from a load of stacked UNION ALL queries?
given this query:
CREATE VIEW TEST AS
SELECT Q, F
FROM
SELECT 'A' Q, JANUARY F FROM ENORMOUS.TABLE WHERE KEY = 'Non Selective Key' UNION ALL
SELECT 'B' Q, 1 F FROM DUAL UNION ALL
SELECT 'C' Q, 1 F FROM DUAL
) A;
-- 1. This one selects from all tables, including a table scan on the enormous table
SELECT * FROM TEST;
-- 2. This one selects from all tables, including a table scan on the enormous table
-- However the query plan has a FILTER after the table scan. Does it exclude this work?
SELECT * FROM TEST WHERE Q = 'B';When I run the query plan without the WHERE it performs the table scan
When I include the WHERE the query plan indicates it's doing the table scan but with a FILTER NULL IS NOT NULL afterwards.
So it appears that it is doing the table scan regardless and then throwing the records away - is that correct?
Any thoughts appreciated. I would prefer not the split this view out if possible as it is used everywhere.
Oracle version:
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 64-bit Windows: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Plan output for 1:
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=7166 Card=2 M Bytes=41 M)
1 VIEW (Cost=7166 Card=2 M Bytes=41 M)
2 1 UNION-ALL
3 2 TABLE ACCESS FULL PLANNING.BF_GEN_STATS_TRAN (Cost=7162 Card=2 M Bytes=72 M)
4 2 FAST DUAL (Cost=2 Card=1)
5 2 FAST DUAL (Cost=2 Card=1)
Plan output for 2:
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=2 Card=3 Bytes=48)
1 VIEW (Cost=2 Card=3 Bytes=48)
2 1 UNION-ALL
3 2 FILTER
4 3 TABLE ACCESS FULL PLANNING.BF_GEN_STATS_TRAN (Cost=7162 Card=2 M Bytes=72 M)
5 2 FAST DUAL (Cost=2 Card=1)
6 2 FILTER
7 6 FAST DUAL (Cost=2 Card=1)

Need to reduce table accesses

oracle 9.2.0.8 (if there's a 10G way that would work)
This is a simplified view of a much biiger table I am having to deal with.
create table stg
(ddate date,
num number);
insert into stg
select sysdate, 26 from dual
union all
select sysdate - 1, 38 from dual
union all
select sysdate - 2, 10 from dual
union all
select sysdate - 3, 40 from dual
union all
select sysdate - 4, 50 from dual
union all
select sysdate - 5, 1 from dual
union all
select sysdate - 6, 11 from dual
union all
select sysdate - 7, 50 from dual
union all
select sysdate - 9, 38 from dual
union all
select sysdate - 10, 20 from dual
union all
select sysdate - 11, 11 from dual
union all
select sysdate - 12, 99 from dual
union all
select sysdate - 13, 18 from dual
union all
select sysdate - 14, 27 from dual
union all
select sysdate - 15, 28 from dual
union all
select sysdate - 16, 2 from dual
union all
select sysdate - 17, 99 from dual
union all
select sysdate - 18, 12 from dual
union all
select sysdate - 19, 27 from dual
union all
select sysdate - 20, 28 from dual
select
sum(case when ddate > d.the_date then 1
else 0
end)
,sum(case when ddate < d.the_date then 1
else 0
end)
,the_date
,max(ddate)
from stg, (select min(ddate) as the_date from stg
where num in (10,11,12,13,14,25))d
group by the_date
the query does give me the result set I'm looking for but the explain plan
shows it takes 2 table accesses. My question is how to re-write this so it
takes one access.
I have tried the analytic functions but there does not seem to be a way to
use the where clause in just the analytic function. Also I have tried:
select min(ddate), max(ddate) from stg
where num in (10,11,12,13,14,25)
but the problem with this is the max is the max where num is (10,11,12,13,14,25)not the max of the whole table.
any ideas to get rid of the nested loop would be helpful
thanks

What do you want is not clear for me, but you can try to replace your query :
SCOTT@demo102> select greater,lesser,min_date,max_date
2 from
3 (SELECT
4   SUM(decode(SIGN(ddate -stg_sub."min_date"), 1, 1, 0)) over() AS greater
5 ,SUM(decode(SIGN(ddate -stg_sub."min_date"), -1, 1, 0)) over() AS lesser
6 ,stg_sub."min_date" AS min_date
7 ,stg_sub."max_date" AS max_date
8 ,rownum AS rnum
9 FROM
10 (SELECT
11      ddate
12     ,(SELECT MIN(ddate) FROM stg WHERE num IN(10,11,12,13,14,25)) AS "min_date"
13     ,max(ddate) over() AS "max_date"
14   FROM stg)stg_sub)
15 where rnum = 1
16 ;
   GREATER     LESSER MIN_DATE MAX_DATE
        17          2 26/09/06 14/10/06by
SCOTT@demo102> select sum(greater) greater, sum(lesser) lesser, max(min_date) min_date, max(max_date) max_date
2 from
3 (SELECT
4     case when ddate - MIN(case when num IN(10,11,12,13,14,25) then ddate end) over () > 0 then 1 end AS greater,
5     case when ddate - MIN(case when num IN(10,11,12,13,14,25) then ddate end) over () < 0 then 1 end AS lesser,
6     MIN(case when num IN(10,11,12,13,14,25) then ddate end) over () as min_date,
7     max(ddate) over() AS max_date
8   FROM stg)
9 ;
   GREATER     LESSER MIN_DATE MAX_DATE
        17          2 26/09/06 14/10/06
SCOTT@demo102>
It is a lower cost What did you mean by cost ? Is it cost from explain plan ? Take care, a low cost here doesn't say that your query will run fatser...
Nicolas.

Problem with Table Access Full

Hi,
Please help me how to resolve the problem of table access full, when i am executing query i facing a problem with these. all though i have create index on these is queru but execution time taking too late.
Also please help if there any syntax to run faster execution.
Thanks in Advance
Sreenivas

Hi,
Please try to analyze your tables once with DBA's help.
If the above does not work, try to use hints which will force use the index created on the column.
Do not use any conversion functions on that column, in the where clause while checking any condition.
If you are storing numbers in a character column, try to have the conditional value as character value in where clause instead of number type.
Thanks and Regards,
Sridhar.

Authorize table access aligned with e.g. MOLGA

Hi everybody,
Is there any possibility to create some R/3 standard authorization to:
- Give access only to specific tables (e.g. T510)
- Does this only work via authorization groups?
- If yes, it is possible to assign more than one authorization group to SAP standard tables?
- To let an user only maintain entires belonging to e.g. his/own MOLGA code
Example:
User can only maintain entries for T510 for MOLGA 04.
Thanks a lot in advance,
Jennifer

Hi Jennifer,
Please find below answers on your questions:
- Give access only to specific tables (e.g. T510)
Yes, via authorization group. Object S_TABU_DIS, configuration of groups in table TDDAT.
- Does this only work via authorization groups?
Normally, yes. But you can restrict access to tables via general transactions, like SM31, SM30, SE16, etc. and allow to maintain/view tables via custom transactions. Then you shift table access to transaction level. In this case you will have to create all those transactions and assign them in S_TCODE object.
- If yes, it is possible to assign more than one authorization group to SAP standard tables?
No, in table TDDAT table name is key field, so only one entry per table is allowed.
- To let an user only maintain entires belonging to e.g. his/own MOLGA code
Yes, this is possible. You can use standard SAP authorization abject S_TABU_LIN. Before using it you have to activate it. Please check following SAP help link for more details/
http://help.sap.com/erp2005_ehp_02/helpdata/en/6d/56cdd3edabc14ebd1bc84dae20dec8/content.htm
I hope it will help you.
Cheers

Tables access information

Hi,
we are in a cleaning process. Althoug nobody gets hurt by unnused customer tables, the customer wants to know about tables that are nort used.
One approach is a where-used-list. OK, done.
Another approach is to analyze table access statistics. AFAIK the database collects statistics from database accesses. From those statistics the system gains information to optimize table access.
Now my question: Where can I find (programatrically or via transaction/report) information about table access?
TIA,
regards,
Clemens

Hello Clements
In packages SEST you will find very interesting objects for program analysis.
Function group SEA1 contains function module <b>RS_PROGRAM_TABLES</b> which will show you all tables accessed by a program object.
For example, enter OBJECT_TYPE = 'TRAN' and OBJECT_NAME = 'VA01' and the function module will show you all tables accessed by the transaction. The list shows you if the tables are read, updated or deleted.
In your case you could write a report that analyzes all customer transactions (since SAP standard transactions should not access customer tables) using function module RS_PROGRAM_TABLES. Customer tables that will not be listed here are not accessed by any program.
Regards
Uwe

Monitor table access

Hi,
we are in a cleaning process. Althoug nobody gets hurt by unnused customer tables, the customer wants to know about tables that are nort used.
One approach is a where-used-list. OK, done.
Another approach is to analyze table access statistics. AFAIK the database collects statistics from database accesses. From those statistics the system gains information to optimize table access.
Now my question: Where can I find (programatrically or via transaction/report) information about table access?
TIA,
regards,
Clemens

U have the list of custom related tables. Goto SE11 & using the custom table check where-used-list. It displays where all the table has been used. If the table has not been used anywhere or else not related at all to a program which is not needed, these all tables can be eliminated from the system.

High cost of TABLE ACCESS BY LOCAL INDEX ROWID

Hi,
We are having a query which is running very slow, while checking the execution plan we found high cost on "TABLE ACCESS BY LOCAL INDEX ROWID"
Db version : 11.2.0.1
EBS version: 12.1.2
Os version : Aix 6.1
SID        : 567
ADDRESS    : 07000004EB12A7A8
HASH_VALUE : 556917643
MODULE     : ora_rw20_run@erpprodapp (TNS V1-V3)
PROGRAM    : ora_rw20_run@erpprodapp (TNS V1-V3)
MACHINE    : erpprodapp
CHILD CNT : 2
[ Current SQL ]
SELECT API.INVOICE_TYPE_LOOKUP_CODE
,   DECODE(API.INVOICE_TYPE_LOOKUP_CODE, 'CREDIT', 0, Z.AMT_VAL ) CREDIT_VAL, 0 ACCT_CR
,   API.EXCHANGE_RATE EXCHANGE_RATE
,   API.EXCHANGE_RATE_TYPE EXCHANGE_RATE_TYPE, API.INVOICE_CURRENCY_CODE INVOICE_CURRENCY_CODE
,   API.EXCHANGE_DATE EXCHANGE_DATE
FROM AP_INVOICES_ALL API, AP_INVOICE_DISTRIBUTIONS_ALL APD, (SELECT NVL(SUM(APD.AMOUNT),0) AMT_VAL
,   API.INVOICE_ID
FROM AP_INVOICES_ALL API, AP_INVOICE_DISTRIBUTIONS_ALL APD
WHERE API.INVOICE_ID = APD.INVOICE_ID
AND API.INVOICE_TYPE_LOOKUP_CODE <> :B6
AND APD.MATCH_STATUS_FLAG = 'A'
AND API.VENDOR_ID = :B5
AND API.VENDOR_SITE_ID = :B4
AND APD.ACCOUNTING_DATE < :B3
AND (API.ORG_ID = :B2
OR API.ORG_ID IS NULL)
AND APD.LINE_TYPE_LOOKUP_CODE <> :B1
GROUP BY API.INVOICE_ID) Z
WHERE Z.INVOICE_ID = API.INVOICE_ID
AND API.INVOICE_ID = APD.INVOICE_ID
AND APD.ROWID = (SELECT ROWID
FROM AP_INVOICE_DISTRIBUTIONS_ALL WHERE ROWNUM=1
AND INVOICE_ID=APD.INVOICE_ID
AND MATCH_STATUS_FLAG = 'A'
AND ACCOUNTING_DATE < :B3 )
AND API.INVOICE_TYPE_LOOKUP_CODE <> :B6
AND APD.MATCH_STATUS_FLAG = 'A'
AND API.VENDOR_ID = :B5 AND API.VENDOR_SITE_ID = :B4
AND APD.ACCOUNTING_DATE < :B3
AND (API.ORG_ID = :B2
OR API.ORG_ID IS NULL)
AND ((API.INVOICE_TYPE_LOOKUP_CODE <> :B9 )
OR ( (API.INVOICE_TYPE_LOOKUP_CODE = :B9 ) AND ( NOT EXISTS (SELECT '1'
FROM AP_INVOICE_PAYMENTS_ALL APP, AP_CHECKS_ALL APC
WHERE APP.CHECK_ID = APC.CHECK_ID
AND APP.INVOICE_ID = API.INVOICE_ID
AND APC.PAYMENT_TYPE_FLAG = 'R' ) ) ) ) AND API.INVOICE_CURRENCY_CODE =NVL( :B8
, API.INVOICE_CURRENCY_CODE)
AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7 ,API.ACCTS_PAY_CODE_COMBINATION_ID) UNION ALL
SELECT API.INVOICE_TYPE_LOOKUP_CODE, DECODE(API.INVOICE_TYPE_LOOKUP_CODE,'CREDIT'
,   DECODE(STATUS_LOOKUP_CODE,'VOIDED', APP.AMOUNT+ NVL(DISCOUNT_AMOUNT_TAKEN
,   0) , ABS(APP.AMOUNT)+ ABS(NVL(DISCOUNT_AMOUNT_TAKEN, 0)) )
,   0) CREDIT_VAL, 0 ACCT_CR, APC.EXCHANGE_RATE EXCHANGE_RATE
,   APC.EXCHANGE_RATE_TYPE EXCHANGE_RATE_TYPE
,   API.PAYMENT_CURRENCY_CODE INVOICE_CURRENCY_CODE, APC.EXCHANGE_DATE EXCHANGE_DATE
FROM AP_INVOICES_ALL API, AP_INVOICE_PAYMENTS_ALL APP, AP_CHECKS_ALL APC
WHERE APP.INVOICE_ID = API.INVOICE_ID
AND APP.CHECK_ID = APC.CHECK_ID AND APC.STATUS_LOOKUP_CODE IN (:B15 ,:B14 ,:B13 ,:B12 ,:B11
, :B10 )
AND API.VENDOR_ID = :B5
AND API.VENDOR_SITE_ID = :B4
AND APP.ACCOUNTING_DATE < TRUNC(:B3 )
AND ( API.ORG_ID = :B2
OR API.ORG_ID IS NULL )
AND EXISTS (
SELECT '1'
FROM AP_INVOICE_DISTRIBUTIONS_ALL APD , AP_INVOICE_LINES_ALL APIL
WHERE APD.INVOICE_ID = API.INVOICE_ID
AND APIL.INVOICE_ID = APD.INVOICE_ID
AND APD.MATCH_STATUS_FLAG ='A'
AND APIL.LINE_NUMBER = APD.INVOICE_LINE_NUMBER)
AND API.INVOICE_CURRENCY_CODE =NVL( :B8 ,API.INVOICE_CURRENCY_CODE)
AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7 ,API.ACCTS_PAY_CODE_COMBINATION_ID) UNION ALL
SELECT 'LOSS' INVOICE_TYPE_LOOKUP_CODE, 0 CREDIT_VAL, DECODE(XAL.ACCOUNTING_CLASS_CODE
, 'LOSS', ACCOUNTED_DR,0) ACCT_CR
,   XAL.CURRENCY_CONVERSION_RATE EXCHANGE_RATE , XAL.CURRENCY_CONVERSION_TYPE EXCHANGE_RATE_TYPE
,   XAL.CURRENCY_CODE INVOICE_CURRENCY_CODE
,   XAL.CURRENCY_CONVERSION_DATE EXCHANGE_DATE
FROM XLA_AE_LINES XAL, XLA_AE_HEADERS XAH, XLA_TRANSACTION_ENTITIES XTE, AP_INVOICES_ALL API
WHERE XAL.APPLICATION_ID = 200
AND XAL.AE_HEADER_ID = XAH.AE_HEADER_ID
AND XAL.ACCOUNTING_CLASS_CODE IN ( :B18 ,:B17 )
AND XAH.APPLICATION_ID = 200 AND XAH.ENTITY_ID = XTE.ENTITY_ID
AND XTE.APPLICATION_ID = 200 AND XTE.ENTITY_CODE =:B16
AND XTE.SOURCE_ID_INT_1 = API.INVOICE_ID
AND API.VENDOR_ID = :B5
AND API.VENDOR_SITE_ID = :B4
AND XAH.ACCOUNTING_DATE < :B3
AND (API.ORG_ID = :B2
OR API.ORG_ID IS NULL )
AND API.INVOICE_CURRENCY_CODE =NVL( :B8 ,API.INVOICE_CURRENCY_CODE)
AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7 ,API.ACCTS_PAY_CODE_COMBINATION_ID) UNION ALL
SELECT 'LOSS' INVOICE_TYPE_LOOKUP_CODE, 0 CREDIT_VAL, DECODE(XAL.ACCOUNTING_CLASS_CODE
, 'LOSS', ACCOUNTED_DR,0) ACCT_CR
,   XAL.CURRENCY_CONVERSION_RATE EXCHANGE_RATE , XAL.CURRENCY_CONVERSION_TYPE EXCHANGE_RATE_TYPE
,   XAL.CURRENCY_CODE INVOICE_CURRENCY_CODE
,   XAL.CURRENCY_CONVERSION_DATE EXCHANGE_DATE
FROM XLA_AE_LINES XAL, XLA_AE_HEADERS XAH, XLA_TRANSACTION_ENTITIES XTE, AP_INVOICES_ALL API, AP_CHECKS_ALL AC
,   AP_INVOICE_PAYMENTS_ALL APP
WHERE XAL.APPLICATION_ID = 200
AND XAL.AE_HEADER_ID = XAH.AE_HEADER_ID
AND XAL.ACCOUNTING_CLASS_CODE IN ( :B18 ,:B17 )
AND XAH.APPLICATION_ID = 200
AND XAH.ENTITY_ID = XTE.ENTITY_ID
AND XTE.APPLICATION_ID = 200
AND XTE.ENTITY_CODE = :B19
AND XTE.SOURCE_ID_INT_1 = AC.CHECK_ID
AND XAH.EVENT_ID = APP.ACCOUNTING_EVENT_ID
AND API.INVOICE_ID = APP.INVOICE_ID AND APP.CHECK_ID = AC.CHECK_ID
AND AC.STATUS_LOOKUP_CODE IN (:B15 ,:B14 ,:B13 , :B12 ,:B11 ,:B10 )
AND API.VENDOR_ID = :B5
AND API.VENDOR_SITE_ID = :B4
AND XAH.ACCOUNTING_DATE < :B3
AND (API.ORG_ID = :B2
OR API.ORG_ID IS NULL )
AND API.INVOICE_CURRENCY_CODE =NVL( :B8 ,API.INVOICE_CURRENCY_CODE)
AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7
, API.ACCTS_PAY_CODE_COMBINATION_ID)
Plan hash value: 1352234085
| Id | Operation                                | Name                         | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Ps
|   0 | SELECT STATEMENT                         |                              |       |       | 1904 (100)|          |       |
|   1 | UNION-ALL                               |                              |       |       |            |          |       |
|   2 |   FILTER                                 |                              |       |       |            |          |       |
|   3 |    NESTED LOOPS                          |                              |       |       |            |          |       |
|   4 |     NESTED LOOPS                         |                              |     1 |    87 |    20   (5)| 00:06:09 |       |
|   5 |      NESTED LOOPS                        |                              |     1 |    60 |    17   (6)| 00:05:14 |       |
|   6 |       VIEW                               |                              |     1 |    18 |    15   (7)| 00:04:37 |       |
|   7 |        HASH GROUP BY                     |                              |     1 |    54 |    15   (7)| 00:04:37 |       |
|   8 |         NESTED LOOPS                     |                              |       |       |            |          |       |
|   9 |          NESTED LOOPS                    |                              |     1 |    54 |    14   (0)| 00:04:19 |       |
| 10 |           TABLE ACCESS BY INDEX ROWID    | AP_INVOICES_ALL              |     1 |    27 |    11   (0)| 00:03:23 |       |
| 11 |            INDEX RANGE SCAN              | AP_INVOICES_N2               |    11 |       |     3   (0)| 00:00:56 |       |
| 12 |           INDEX RANGE SCAN               | AP_INVOICE_DISTRIBUTIONS_N33 |     2 |       |     2   (0)| 00:00:37 |       |
| 13 |          TABLE ACCESS BY INDEX ROWID     | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    27 |     3   (0)| 00:00:56 |       |
| 14 |       TABLE ACCESS BY INDEX ROWID        | AP_INVOICES_ALL              |     1 |    42 |     2   (0)| 00:00:37 |       |
| 15 |        INDEX UNIQUE SCAN                 | AP_INVOICES_U1               |     1 |       |     1   (0)| 00:00:19 |       |
| 16 |      INDEX RANGE SCAN                    | AP_INVOICE_DISTRIBUTIONS_N33 |     1 |       |     2   (0)| 00:00:37 |       |
| 17 |       COUNT STOPKEY                      |                              |       |       |            |          |       |
| 18 |        TABLE ACCESS BY INDEX ROWID       | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    27 |     4   (0)| 00:01:14 |       |
| 19 |         INDEX RANGE SCAN                 | AP_INVOICE_DISTRIBUTIONS_N33 |     2 |       |     3   (0)| 00:00:56 |       |
| 20 |     TABLE ACCESS BY INDEX ROWID          | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    27 |     3   (0)| 00:00:56 |       |
| 21 |    NESTED LOOPS                          |                              |       |       |            |          |       |
| 22 |     NESTED LOOPS                         |                              |     1 |    17 |     6   (0)| 00:01:51 |       |
| 23 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICE_PAYMENTS_ALL      |     1 |    10 |     4   (0)| 00:01:14 |       |
| 24 |       INDEX RANGE SCAN                   | AP_INVOICE_PAYMENTS_N1       |     1 |       |     3   (0)| 00:00:56 |       |
| 25 |      INDEX UNIQUE SCAN                   | AP_CHECKS_U1                 |     1 |       |     1   (0)| 00:00:19 |       |
| 26 |     TABLE ACCESS BY INDEX ROWID          | AP_CHECKS_ALL                |     1 |     7 |     2   (0)| 00:00:37 |       |
| 27 |   NESTED LOOPS SEMI                      |                              |     1 |   102 |    25   (0)| 00:07:41 |       |
| 28 |    NESTED LOOPS                          |                              |     1 |   100 |    20   (0)| 00:06:09 |       |
| 29 |     NESTED LOOPS                         |                              |     1 |    67 |    18   (0)| 00:05:32 |       |
| 30 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICES_ALL              |     1 |    42 |    15   (0)| 00:04:37 |       |
| 31 |       INDEX RANGE SCAN                   | AP_INVOICES_N7               |    15 |       |     3   (0)| 00:00:56 |       |
| 32 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICE_PAYMENTS_ALL      |     1 |    25 |     3   (0)| 00:00:56 |       |
| 33 |       INDEX RANGE SCAN                   | AP_INVOICE_PAYMENTS_N1       |     1 |       |     2   (0)| 00:00:37 |       |
| 34 |     TABLE ACCESS BY INDEX ROWID          | AP_CHECKS_ALL                |     1 |    33 |     2   (0)| 00:00:37 |       |
| 35 |      INDEX UNIQUE SCAN                   | AP_CHECKS_U1                 |     1 |       |     1   (0)| 00:00:19 |       |
| 36 |    VIEW PUSHED PREDICATE                 | VW_SQ_1                      |     1 |     2 |     5   (0)| 00:01:33 |       |
| 37 |     NESTED LOOPS                         |                              |     1 |    20 |     5   (0)| 00:01:33 |       |
| 38 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    11 |     4   (0)| 00:01:14 |       |
| 39 |       INDEX RANGE SCAN                   | AP_INVOICE_DISTRIBUTIONS_N33 |     2 |       |     3   (0)| 00:00:56 |       |
| 40 |      INDEX UNIQUE SCAN                   | AP_INVOICE_LINES_U1          |     1 |     9 |     1   (0)| 00:00:19 |       |
| 41 |   NESTED LOOPS                           |                              |       |       |            |          |       |
| 42 |    NESTED LOOPS                          |                              |     1 |   113 | 1825   (0)| 09:20:33 |       |
| 43 |     NESTED LOOPS                         |                              |     1 |    79 | 1822   (0)| 09:19:38 |       |
| 44 |      MERGE JOIN CARTESIAN                |                              |     1 |    50 | 1820   (0)| 09:19:01 |       |
| 45 |       TABLE ACCESS BY INDEX ROWID        | AP_INVOICES_ALL              |     1 |    27 |    15   (0)| 00:04:37 |       |
| 46 |        INDEX RANGE SCAN                  | AP_INVOICES_N7               |    15 |       |     3   (0)| 00:00:56 |       |
| 47 |       BUFFER SORT                        |                              | 17282 |   388K| 1805   (0)| 09:14:24 |       |
| 48 |        PARTITION LIST SINGLE             |                              | 17282 |   388K| 1805   (0)| 09:14:24 |   KEY |
| 49 |         TABLE ACCESS BY LOCAL INDEX ROWID| XLA_AE_HEADERS               | 17282 |   388K| 1805   (0)| 09:14:24 |     1 |
| 50 |          INDEX RANGE SCAN                | XLA_AE_HEADERS_N5            | 5445 |       |   100   (0)| 00:30:43 |     1 |
| 51 |      PARTITION LIST SINGLE               |                              |     1 |    29 |     2   (0)| 00:00:37 |   KEY |
| 52 |       TABLE ACCESS BY LOCAL INDEX ROWID | XLA_TRANSACTION_ENTITIES     |     1 |    29 |     2   (0)| 00:00:37 |     1 |
| 53 |        INDEX UNIQUE SCAN                 | XLA_TRANSACTION_ENTITIES_U1 |     1 |       |     1   (0)| 00:00:19 |     1 |
| 54 |     PARTITION LIST SINGLE                |                              |     1 |       |     2   (0)| 00:00:37 |   KEY |
| 55 |      INDEX RANGE SCAN                    | XLA_AE_LINES_U1              |     1 |       |     2   (0)| 00:00:37 |     1 |
| 56 |    TABLE ACCESS BY LOCAL INDEX ROWID     | XLA_AE_LINES                 |     1 |    34 |     3   (0)| 00:00:56 |     1 |
| 57 |   NESTED LOOPS                           |                              |       |       |            |          |       |
| 58 |    NESTED LOOPS                          |                              |     1 |   151 |    30   (0)| 00:09:13 |       |
| 59 |     NESTED LOOPS                         |                              |     1 |   135 |    28   (0)| 00:08:37 |       |
| 60 |      NESTED LOOPS                        |                              |     1 |   101 |    25   (0)| 00:07:41 |       |
| 61 |       NESTED LOOPS                       |                              |     1 |    72 |    23   (0)| 00:07:04 |       |
| 62 |        NESTED LOOPS                      |                              |     1 |    43 |    18   (0)| 00:05:32 |       |
| 63 |         TABLE ACCESS BY INDEX ROWID      | AP_INVOICES_ALL              |     1 |    27 |    15   (0)| 00:04:37 |       |
| 64 |          INDEX RANGE SCAN                | AP_INVOICES_N7               |    15 |       |     3   (0)| 00:00:56 |       |
| 65 |         TABLE ACCESS BY INDEX ROWID      | AP_INVOICE_PAYMENTS_ALL      |     1 |    16 |     3   (0)| 00:00:56 |       |
| 66 |          INDEX RANGE SCAN                | AP_INVOICE_PAYMENTS_N1       |     1 |       |     2   (0)| 00:00:37 |       |
| 67 |        PARTITION LIST SINGLE             |                              |     1 |    29 |     5   (0)| 00:01:33 |   KEY |
| 68 |         TABLE ACCESS BY LOCAL INDEX ROWID| XLA_AE_HEADERS               |     1 |    29 |     5   (0)| 00:01:33 |     1 |
| 69 |          INDEX RANGE SCAN                | XLA_AE_HEADERS_N2            |     1 |       |     2   (0)| 00:00:37 |     1 |
| 70 |       PARTITION LIST SINGLE              |                              |     1 |    29 |     2   (0)| 00:00:37 |   KEY |
| 71 |        TABLE ACCESS BY LOCAL INDEX ROWID | XLA_TRANSACTION_ENTITIES     |     1 |    29 |     2   (0)| 00:00:37 |     1 |
| 72 |         INDEX UNIQUE SCAN                | XLA_TRANSACTION_ENTITIES_U1 |     1 |       |     1   (0)| 00:00:19 |     1 |
| 73 |      PARTITION LIST SINGLE               |                              |     1 |    34 |     3   (0)| 00:00:56 |   KEY |
| 74 |       TABLE ACCESS BY LOCAL INDEX ROWID | XLA_AE_LINES                 |     1 |    34 |     3   (0)| 00:00:56 |     1 |
| 75 |        INDEX RANGE SCAN                  | XLA_AE_LINES_U1              |     1 |       |     2   (0)| 00:00:37 |     1 |
| 76 |     INDEX UNIQUE SCAN                    | AP_CHECKS_U1                 |     1 |       |     1   (0)| 00:00:19 |       |
| 77 |    TABLE ACCESS BY INDEX ROWID           | AP_CHECKS_ALL                |     1 |    16 |     2   (0)| 00:00:37 |       |
XLA_AE_HEADERS is a table partition
Regards,
Gaurav

Thanks for the prompt reply.
XLA_AE_HEADERS is a table partition and showing high cost on TABLE ACCESS BY LOCAL INDEX ROWID similarly XLA_TRANSACTION_ENTITIES is also a table partion
OWNER    SEGMENT_NAME                   SEGMENT_T BYTES/1024/1024
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR        2014.375
XLA      XLA_AE_HEADERS                 TABLE PAR          4424.5
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125
XLA      XLA_AE_HEADERS                 TABLE PAR          10.125
XLA      XLA_AE_HEADERS                 TABLE PAR            .125

How to make optimizer fetch and join values from Indexes, no table access.

Hi All,
i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
Execution Plan
Plan hash value: 1209914516
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | | 6 (17)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | | | | | |
|* 2 | FILTER | | | | | | | |
| 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |
| 4 | NESTED LOOPS | | 1 | 24 | 4 (25)| 00:00:01 | | |
| 5 | SORT UNIQUE | | 1 | 10 | 2 (0)| 00:00:01 | | |
| 6 | TABLE ACCESS BY INDEX ROWID | INVOICELINEDISB | 1 | 10 | 2 (0)| 00:00:01 | | |
|* 7 | INDEX RANGE SCAN | IDX_INVLINEDISB_UOMCD | 1 | | 1 (0)| 00:00:01 | | |
| 8 | PARTITION HASH ITERATOR | | 1 | 14 | 1 (0)| 00:00:01 | KEY | KEY |
|* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB | 1 | 14 | 1 (0)| 00:00:01 | ROWID | ROWID |
|* 10 | INDEX UNIQUE SCAN | P_INVOICEHEADERDISB_PART | 1 | | 0 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
"INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
"INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
Statistics
0 recursive calls
0 db block gets
14 consistent gets
0 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client

Jonathan Lewis wrote:
930254 wrote:
Hi All,
i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
Execution Plan
Plan hash value: 1209914516
| Id | Operation                              | Name                     | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                       |                          |     1 |       |     6 (17)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE                        |                          |     1 |       |            |          |       |       |
|* 2 |   FILTER                               |                          |       |       |            |          |       |       |
|   3 |    FAST DUAL                           |                          |     1 |       |     2   (0)| 00:00:01 |       |       |
|   4 |    NESTED LOOPS                        |                          |     1 |    24 |     4 (25)| 00:00:01 |       |       |
|   5 |     SORT UNIQUE                        |                          |     1 |    10 |     2   (0)| 00:00:01 |       |       |
|   6 |      TABLE ACCESS BY INDEX ROWID       | INVOICELINEDISB          |     1 |    10 |     2   (0)| 00:00:01 |       |       |
|* 7 |       INDEX RANGE SCAN                 | IDX_INVLINEDISB_UOMCD    |     1 |       |     1   (0)| 00:00:01 |       |       |
|   8 |     PARTITION HASH ITERATOR            |                          |     1 |    14 |     1   (0)| 00:00:01 |   KEY |   KEY |
|* 9 |      TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB        |     1 |    14 |     1   (0)| 00:00:01 | ROWID | ROWID |
|* 10 |       INDEX UNIQUE SCAN                | P_INVOICEHEADERDISB_PART |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
"INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
"INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
The sort unique at line 5 is surprising, I can't think of an obvious reason why it should appear unless the optimizer is trying to do something very clever to work around a problem we can't see (such as a statistics error with the hash partitioned indexe).
Assuming that the test would do better starting with invoiceheaderdisn.paypkl I have to ask if you have an index on INVOICELINEDISB(INVOICEPK).The optimizer's choice of driving table indeed looks odd. Could it be due to misleading statistics or plain bug or just a case of CBO preferring a non-partitioned table over partitioned table when deciding the driving table? I must admit this design does look odd as it appears INVOICEHEADERDISB is a parent table and INVOICELINEDISB is a child table but somehow the parent table has been partitioned (using hash partitioning, I assume) but the child table is not.
However, once CBO has decided the driving table, the SORT UNIQUE is not quite surprising. Assuming optimizer knows that there is a parent-child relationship between INVOICEHEADERDISB and INVOICELINEDISB table (based on INVOICEPK column), CBO needs to access only INVOICEPK and UNITOFMEASURECD columns fron the INVOICELINEDISB table in order to process the join. It uses index range scan on UNITOFMEASURECD table in order to get (part of) the necessary data and then accesses INVOICELINEDISB table to get the values of INVOICEPK column. Being a child table, it is possible that the driving row source will contain duplicate values for INVOICEPK column but not necessarily sorted. As CBO knows that outer table (i.e. INVOICEHEADERDISB) has a PK on INVOICEPK column, each row in driving row source will have either 1 or 0 rows matching from outer table. It appears that CBO "decides" that by eliminating the duplicate values of the INVOICEPK from driving row source, it can reduce the number of times the INVOICEHEADERDISB table is accessed.
Now I am not sure if CBO does all this (eliminating duplicates from driving row source) only because the outer table is partitioned.
Coming back to OP's original question, I believe OP will have to change the index definitions in order to avoid table access for this query. But there has to be a strong and logical argument to make this kind of change for just one query.
Hope this helps.

With query and table access

I am using WITH query to reduce the scanning the teacher table thrice for the below query
xe > with q as
2 (select teacher_id,subject_1,subject_2,subject_3 from teacher
3 )
4 select teacher_id,subject_1 from q
5 union all
6 select teacher_id,subject_2 from q
7 union all
8 select teacher_id,subject_3 from q
9 /
However, the execution plan shows that the table was scanned for twice.
Execution Plan
Plan hash value: 91048842
| Id | Operation          | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |         |     6 |   180 |     6 (67)| 00:00:01 |
|   1 | UNION-ALL         |         |       |       |            |          |
| 2 |   TABLE ACCESS FULL| TEACHER |     2 |    60 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| TEACHER |     2 |    60 |     2   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL| TEACHER |     2 |    60 |     2   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
         10 recursive calls
          0 db block gets
         22 consistent gets
          0 physical reads
          0 redo size
        594 bytes sent via SQL*Net to client
        420 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          6 rows processed
Why the table was scanned thrice?
Thanks for your time..

Hi,
A SQL query describes the result set you want; it does not show how the system gets those results. Don't expect how the query code looks to have much to do with what the system will do. For example, the fact that the code only says "teacher" 1 time doesn't mean that the teacher table will only be scanned 1 time.
Try
SELECT    teacher_id, subject
FROM      teacher
UNPIVOT   ( subject
          FOR subject_num IN ( subject_1 AS 1
                              , subject_2 AS 2
                              , subject_3 AS 3

Program to get list of tables accessed by query

Hi Guru's,
Is there any program or function module to get the list of tables accessed by the query(as we get in query execution plan by using SQL debug option)?

Shanthi,
The SQL trace is giving only object list..
when i used combined table accesses option its giving the standard SAP tables.. not tables related to master data or TD....
And my requirement is to get directly the program output or program intermediate output as
tables (like MD TD tables etc)

Table Access

Similar Messages

Maybe you are looking for