Tables in subquery resulting in full table scans

Hi,
This is related to a p1 bug 13009447. Customer recently upgraded to 10G. Customer reported this type of problem for the second time.
Problem Description:
All the tables in sub-query are resulting in full table scans and hence are executing for hours.
Here is the query
SELECT /*+ PARALLEL*/
act.assignment_action_id
, act.assignment_id
, act.tax_unit_id
, as1.person_id
, as1.effective_start_date
, as1.primary_flag
FROM pay_payroll_actions pa1
, pay_population_ranges pop
, per_periods_of_service pos
, per_all_assignments_f as1
, pay_assignment_actions act
, pay_payroll_actions pa2
, pay_action_classifications pcl
, per_all_assignments_f as2
WHERE pa1.payroll_action_id = :b2
AND pa2.payroll_id = pa1.payroll_id
AND pa2.effective_date
BETWEEN pa1.start_date
AND pa1.effective_date
AND act.payroll_action_id = pa2.payroll_action_id
AND act.action_status IN ('C', 'S')
AND pcl.classification_name = :b3
AND pa2.consolidation_set_id = pa1.consolidation_set_id
AND pa2.action_type = pcl.action_type
AND nvl (pa2.future_process_mode, 'Y') = 'Y'
AND as1.assignment_id = act.assignment_id
AND pa1.effective_date
BETWEEN as1.effective_start_date
AND as1.effective_end_date
AND as2.assignment_id = act.assignment_id
AND pa2.effective_date
BETWEEN as2.effective_start_date
AND as2.effective_end_date
AND as2.payroll_id = as1.payroll_id
AND pos.period_of_service_id = as1.period_of_service_id
AND pop.payroll_action_id = :b2
AND pop.chunk_number = :b1
AND pos.person_id = pop.person_id
AND (
as1.payroll_id = pa1.payroll_id
OR pa1.payroll_id IS NULL
AND NOT EXISTS
SELECT /*+ PARALLEL*/ NULL
FROM pay_assignment_actions ac2
, pay_payroll_actions pa3
, pay_action_interlocks int
WHERE int.locked_action_id = act.assignment_action_id
AND ac2.assignment_action_id = int.locking_action_id
AND pa3.payroll_action_id = ac2.payroll_action_id
AND pa3.action_type IN ('P', 'U')
AND NOT EXISTS
SELECT /*+ PARALLEL*/
NULL
FROM per_all_assignments_f as3
, pay_assignment_actions ac3
WHERE :b4 = 'N'
AND ac3.payroll_action_id = pa2.payroll_action_id
AND ac3.action_status NOT IN ('C', 'S')
AND as3.assignment_id = ac3.assignment_id
AND pa2.effective_date
BETWEEN as3.effective_start_date
AND as3.effective_end_date
AND as3.person_id = as2.person_id
ORDER BY as1.person_id
, as1.primary_flag DESC
, as1.effective_start_date
, act.assignment_id
FOR UPDATE OF as1.assignment_id
, pos.period_of_service_id
Here is the execution plan for this query. We tried adding hints in sub-query to force indexes to pick-up but it is still doing Full table scans.
Suspecting some db parameter which is causing this issue.
In the
- Full table scans on tables in the first sub-query
PAY_PAYROLL_ACTIONS, PAY_ASSIGNMENT_ACTIONS, PAY_ACTION_INTERLOCKS
- Full table scans on tables in Second sub-query
PER_ALL_ASSIGNMENTS_F PAY_ASSIGNMENT_ACTIONS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 29 398.80 2192.99 238706 4991924 2383 0
Fetch 1136 378.38 1921.39 0 4820511 0 1108
total 1166 777.19 4114.38 238706 9812435 2383 1108
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 41 (APPS) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 FOR UPDATE
0 PX COORDINATOR
0 PX SEND (QC (ORDER)) OF ':TQ10009' [:Q1009]
0 SORT (ORDER BY) [:Q1009]
0 PX RECEIVE [:Q1009]
0 PX SEND (RANGE) OF ':TQ10008' [:Q1008]
0 HASH JOIN (ANTI BUFFERED) [:Q1008]
0 PX RECEIVE [:Q1008]
0 PX SEND (HASH) OF ':TQ10006' [:Q1006]
0 BUFFER (SORT) [:Q1006]
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PER_ALL_ASSIGNMENTS_F' (TABLE) [:Q1006]
0 NESTED LOOPS [:Q1006]
0 NESTED LOOPS [:Q1006]
0 NESTED LOOPS [:Q1006]
0 HASH JOIN (ANTI) [:Q1006]
0 BUFFER (SORT) [:Q1006]
0 PX RECEIVE [:Q1006]
0 PX SEND (HASH) OF ':TQ10002'
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PAY_ASSIGNMENT_ACTIONS' (TABLE)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PAY_PAYROLL_ACTIONS' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PAY_PAYROLL_ACTIONS_PK' (INDEX (UNIQUE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PAY_POPULATION_RANGES_N4' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PER_PERIODS_OF_SERVICE' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PER_PERIODS_OF_SERVICE_N3' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PER_ALL_ASSIGNMENTS_F' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PER_ASSIGNMENTS_N4' (INDEX)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PAY_ASSIGNMENT_ACTIONS_N51' (INDEX)
0 PX RECEIVE [:Q1006]
0 PX SEND (HASH) OF ':TQ10005' [:Q1005]
0 VIEW OF 'VW_SQ_1' (VIEW) [:Q1005]
0 HASH JOIN [:Q1005]
0 BUFFER (SORT) [:Q1005]
0 PX RECEIVE [:Q1005]
0 PX SEND (BROADCAST) OF ':TQ10000'
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_PAYROLL_ACTIONS' (TABLE)
0 HASH JOIN [:Q1005]
0 PX RECEIVE [:Q1005]
0 PX SEND (HASH) OF ':TQ10004' [:Q1004]
0 PX BLOCK (ITERATOR) [:Q1004]
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_ASSIGNMENT_ACTIONS' (TABLE) [:Q1004]
0 BUFFER (SORT) [:Q1005]
0 PX RECEIVE [:Q1005]
0 PX SEND (HASH) OF ':TQ10001'
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_ACTION_INTERLOCKS' (TABLE)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PAY_PAYROLL_ACTIONS' (TABLE) [:Q1006]
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PAY_PAYROLL_ACTIONS_PK' (INDEX (UNIQUE)) [:Q1006]
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PAY_ACTION_CLASSIFICATIONS_PK' (INDEX (UNIQUE))[:Q1006]
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PER_ASSIGNMENTS_F_PK' (INDEX (UNIQUE)) [:Q1006]
0 PX RECEIVE [:Q1008]
0 PX SEND (HASH) OF ':TQ10007' [:Q1007]
0 VIEW OF 'VW_SQ_2' (VIEW) [:Q1007]
0 FILTER [:Q1007]
0 HASH JOIN [:Q1007]
0 BUFFER (SORT) [:Q1007]
0 PX RECEIVE [:Q1007]
0 PX SEND (BROADCAST) OF ':TQ10003'
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PER_ALL_ASSIGNMENTS_F' (TABLE)
0 PX BLOCK (ITERATOR) [:Q1007]
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_ASSIGNMENT_ACTIONS' (TABLE) [:Q1007]
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
enq: KO - fast object checkpoint 32 0.02 0.12
os thread startup 8 0.02 0.19
PX Deq: Join ACK 198 0.00 0.04
PX Deq Credit: send blkd 167116 1.95 1103.72
PX Deq Credit: need buffer 327389 1.95 266.30
PX Deq: Parse Reply 148 0.01 0.03
PX Deq: Execute Reply 11531 1.95 1901.50
PX qref latch 23060 0.00 0.60
db file sequential read 108199 0.17 22.11
db file scattered read 9272 0.19 51.74
PX Deq: Table Q qref 78 0.00 0.03
PX Deq: Signal ACK 1165 0.10 10.84
enq: PS - contention 73 0.00 0.00
reliable message 27 0.00 0.00
latch free 218 0.00 0.01
latch: session allocation 11 0.00 0.00
Thanks in advance
Suresh PV

Hi,
welcome,
how is the query performing if you delete all the hints for PARALLEL, because most of the waits are related to waits on Parallel.
Herald ten Dam
http://htendam.wordpress.com
PS. Use "{code}" for showing your code and explain plans, it looks nicer

Similar Messages

Order by column has index which results in full table scan

I have a query on table A which has index for column B.In the query i am using order by column B .In explain plan it shows that the full table scan is performed for table A without picking up the index for B .How can i ensure that index is picked up in the explain plan.Please help its urgent.
Pandu

Please help its urgent.Contact Oracle Support in that case.
By making that remark you have just made Blushadow go out to lunch (again) now.... ;)
Depending on your query a full scan could be 100% appropriate here.
But since you didn't post your DB_version, optimizer settings, execution plan etc. there's not much more to say, really, besides:
"Full scans aren't always evil".
See:
[When your query takes too long...|http://forums.oracle.com/forums/thread.jspa?messageID=3299435]
[How to post a SQLstatement Tuning Request|http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0]

URGENT HELP Required: Solution to avoid Full table scan for a PL/SQL query

Hi Everyone,
When I checked the EXPLAIN PLAN for the below SQL query, I saw that Full table scans is going on both the tables TABLE_A and TABLE_B
UPDATE TABLE_A a
SET a.current_commit_date =
(SELECT MAX (b.loading_date)
FROM TABLE_B b
WHERE a.sales_order_id = b.sales_order_id
AND a.sales_order_line_id = b.sales_order_line_id
AND b.confirmed_qty > 0
AND b.data_flag IS NULL
OR b.schedule_line_delivery_date >= '23 NOV 2008')
Though the TABLE_A is a small table having nearly 1 lakh records, the TABLE_B is a huge table, having nearly 2 and a half crore records.
I created an Index on the TABLE_B having all its fields used in the WHERE clause. But, still the explain plan is showing FULL TABLE SCAN only.
When I run the query, it is taking long long time to execute (more than 1 day) and each time I have to kill the session.
Please please help me in optimizing this.
Thanks,
Sudhindra

Check the instruction again, you're leaving out information we need in order to help you, like optimizer information.
- Post your exact database version, that is: the result of select * from v$version;
- Don't use TOAD's execution plan, but use
SQL> explain plan for <your_query>;
SQL> select * from table(dbms_xplan.display);(You can execute that in TOAD as well).
Don't forget you need to use the {noformat}{noformat} tag in order to post formatted code/output/execution plans etc.
It's also explained in the instruction.
When was the last time statistics were gathered for table_a and table_b?
You can find out by issuing the following query:select table_name
, last_analyzed
, num_rows
from user_tables
where table_name in ('TABLE_A', 'TABLE_B');
Can you also post the results of these counts;select count(*)
from table_b
where confirmed_qty > 0;
select count(*)
from table_b
where data_flag is null;
select count(*)
from table_b
where schedule_line_delivery_date >= /* assuming you're using a date, and not a string*/ to_date('23 NOV 2008', 'dd mon yyyy');

How to avoid full Table scan when using Rule based optimizer (Oracle817)

1. We have a Oracle 8.1.7 DB, and the optimizer_mode is set to "RULE"
2. There are three indexes on table cm_contract_supply, which is a large table having 28732830 Rows, and average row length 149 Bytes
COLUMN_NAME INDEX_NAME
PROGRESS_RECID XAK11CM_CONTRACT_SUPPLY
COMPANY_CODE XIE1CM_CONTRACT_SUPPLY
CONTRACT_NUMBER XIE1CM_CONTRACT_SUPPLY
COUNTRY_CODE XIE1CM_CONTRACT_SUPPLY
SUPPLY_TYPE_CODE XIE1CM_CONTRACT_SUPPLY
VERSION_NUMBER XIE1CM_CONTRACT_SUPPLY
CAMPAIGN_CODE XIF1290CM_CONTRACT_SUPPLY
COMPANY_CODE XIF1290CM_CONTRACT_SUPPLY
COUNTRY_CODE XIF1290CM_CONTRACT_SUPPLY
SUPPLIER_BP_ID XIF801CONTRACT_SUPPLY
COMMISSION_LETTER_CODE XIF803CONTRACT_SUPPLY
COMPANY_CODE XIF803CONTRACT_SUPPLY
COUNTRY_CODE XIF803CONTRACT_SUPPLY
COMPANY_CODE XPKCM_CONTRACT_SUPPLY
CONTRACT_NUMBER XPKCM_CONTRACT_SUPPLY
COUNTRY_CODE XPKCM_CONTRACT_SUPPLY
SUPPLY_SEQUENCE_NUMBER XPKCM_CONTRACT_SUPPLY
VERSION_NUMBER XPKCM_CONTRACT_SUPPLY
3. We are querying the table for a particular contract_number and version_number. We want to avoid full table scan.
SELECT /*+ INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
However despite of giving hint, query results are fetched after full table scan.
Execution Plan
0 SELECT STATEMENT Optimizer=RULE (Cost=1182 Card=1 Bytes=742)
1 0 TABLE ACCESS (FULL) OF 'CM_CONTRACT_SUPPLY' (Cost=1182 Card=1 Bytes=742)
4. I have tried giving
SELECT /*+ FIRST_ROWS + INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
and
SELECT /*+ CHOOSE + INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
But it does not work.
Is there some way without changing optimizer mode and without creating an additional index, we can use the index instead of full table scan?

David,
Here is my test on a Oracle 10g database.
SQL> create table mytable as select * from all_tables;
Table created.
SQL> set autot traceonly
SQL> alter session set optimizer_mode = choose;
Session altered.
SQL> select count(*) from mytable;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE)
Statistics
          1 recursive calls
          0 db block gets
         29 consistent gets
          0 physical reads
          0 redo size
        223 bytes sent via SQL*Net to client
        276 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> analyze table mytable compute statistics;
Table analyzed.
SQL> select count(*) from mytable
2 ;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE) (Cost=11 Card=1
          788)
Statistics
          1 recursive calls
          0 db block gets
         29 consistent gets
          0 physical reads
          0 redo size
        222 bytes sent via SQL*Net to client
        276 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options

Slow queries and full table scans in spite of context index

I have defined a USER_DATASTORE, which uses a PL/SQL procedure to compile data from several tables. The master table has 1.3 million rows, and one of the fields being joined is a CLOB field.
The resulting token table has 65,000 rows, which seems about right.
If I query the token table for a word, such as "ORACLE" in the token_text field, I see that the token_count is 139. This query returns instantly.
The query against the master table is very slow, taking about 15 minutes to return the 139 rows.
Example query:
select hnd from master_table where contains(myindex,'ORACLE',1) > 0;
I've run a sql_trace on this query, and it shows full table scans on both the master table and the DR$MYINDEX$I table. Why is it doing this, and how can I fix it?

After looking at the tuning FAQ, I can see that this is doing a functional lookup instead of an indexed lookup. But why, when the rows are not constrained by any structural query, and how can I get it to instead to an indexed lookup?
Thanks in advance,
Annie

Trunc causing Full Table Scans

I have a situtaion here where my query is as follows.
SQL> select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and trunc(FIRST_ACTVN_DATE) = trunc(sysdate);
COUNT(1)
6
PLAN_TABLE_OUTPUT
Plan hash value: 3951750498
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 10 | 13904 (1)| 00:02:47 | | |
| 1 | SORT AGGREGATE | | 1 | 10 | | | | |
| 2 | PARTITION LIST SINGLE| | 1 | 10 | 13904 (1)| 00:02:47 | 12 | 12 |
|* 3 | TABLE ACCESS FULL | HBSM_SM_ACCOUNT_INFO | 1 | 10 | 13904 (1)| 00:02:47 | 12 | 12 |
Predicate Information (identified by operation id):
3 - filter(("CUST_STATUS"='UP' OR "CUST_STATUS"='UUP') AND
TO_DATE(INTERNAL_FUNCTION("FIRST_ACTVN_DATE"))=TO_DATE(TO_CHAR(SYSDATE@!)))
16 rows selected.
If I remove the trunc clause from the query the performance definitely improves the the results are wrong.
SQL> select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and FIRST_ACTVN_DATE = trunc(sysdate);
COUNT(1)
0
PLAN_TABLE_OUTPUT
Plan hash value: 454529511
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 40 | 47 (0)| 00:00:01 | | |
|* 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| HBSM_SM_ACCOUNT_INFO | 1 | 40 | 47 (0)| 00:00:01 | 12 | 12 |
|* 2 | INDEX RANGE SCAN | IND_FIRST_ACTVN_DATE | 51 | | 4 (0)| 00:00:01 | | |
Can someone please help me whereby I can get the right data and I can also prevent these full table scans.

Unless you are using a functional index, applying any function to an indexed column prevents the use of the index.
The way round it in your case is to realise that
select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and trunc(FIRST_ACTVN_DATE) = trunc(sysdate)Is really asking that FIRST_ACTVN_DATE should be sometime today. You could therefore rewrite it as
select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP')
and FIRST_ACTVN_DATE >= trunc(sysdate)
and FIRST_ACTVN_DATE < trunc(sysdate) + 1Note, this still might not use the index depending on how many rows are within today's date versus how many are outside today's date.
Also, when posting, remember to put your code between tags and to post create table scripts and sample data inserts.

Why does not a query go by index but FULL TABLE SCAN

I have two tables;
table 1 has 1400 rwos and more than 30 columns , one of them is named as 'site_code' , a index was created on this column;
table 2 has more 150 rows than 20 column , this primary key is 'site_code' also.
the two tables were analysed by dbms_stats.gather_table()...
when I run the explain for the 2 sqls below:
select * from table1 where site_code='XXXXXXXXXX';
select * from table1 where site_code='XXXXXXXXXX';
certainly the oracle explain report show that 'Index scan'
but the problem raised that
I try to explain the sql
select *
from table1,table2
where 1.'site_code'=2.'site_code'
the explain report that :
select .....
FULL Table1 Scan
FULL Table2 Scan
why......

Nikolay Ivankin wrote:
BluShadow wrote:
Nikolay Ivankin wrote:
Try to use hint, but I really doubt it will be faster.No, using hints should only be advised when investigating an issue, not recommended for production code, as it assumes that, as a developer, you know better than the Oracle Optimizer how the data is distributed in the data files, and how the data is going to grow and change over time, and how best to access that data for performance etc.Yes, you are absolutly right. But aren't we performing such an investigation, are we? ;-)The way you wrote it, made it sound that a hint would be the solution, not just something for investigation.
select * from .. always performs full scan, so limit your query.No, select * will not always perform a full scan, that's just selecting all the columns.
A select without a where clause or that has a where clause that has low selectivity will result in full table scans.But this is what I have ment.But not what you said.

VARRAY bind parameter in IN clause causes Full Table Scan

Hi
My problem is that Oracle elects to perform a full table scan when I want it to use an index.
The situation is this: I have a single table SQL query with an IN clause such as:
SELECT EMPNO, ENAME, JOB FROM EMP WHERE ENAME IN (...)
Since this is running in an application, I want to allow the user to provide a list of ENAMES to search. Because IN clauses don't accept bind parameters I've been using the Tom Kyte workaround which relies on setting a bind variable to an array-valued scalar, and then casting this array to be a table of records that the database can handle in an IN clause:
SELECT *
FROM EMP
WHERE ENAME IN (
SELECT *
FROM TABLE(CAST( ? AS TABLE_OF_VARCHAR)))
This resulted in very slow performance due to a full table scan. To test, I ran the SQL in SQL*Plus and provided the IN clause values in the query itself. The explain plan showed it using my index...ok good. But once I changed the IN clause to the 'select * from table...' syntax Oracle went into Full Scan mode. I added an index hint but it didn't change the plan. Has anyone had success using this technique without a full scan?
Thanks
John
p.s.
Please let me know if you think this should be posted on a different forum. Even though my context is a Java app developed with JDev this seemed like a SQL question.

Justin and 3360 - that was great advice and certainly nothing I would have come up with. However, as posted, the performance still wasn't good...but it gave me a term to Google on. I found this Ask Tom page http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:3779680732446#15740265481549, where he included a seemingly magical 'where rownum >=0' which, when applied with your suggestions, turned my query from minutes into seconds.
My plans are as follows:
1 - Query with standard IN clause
SQL> explain plan for
2 select accession_number, protein_name, sequence_id from protein_dim
3 where accession_number in ('33460', '33458', '33451');
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 7 | 336 | 4 |
| 1 | INLIST ITERATOR | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| PROTEIN_DIM | 7 | 336 | 4 |
| 3 | INDEX RANGE SCAN | IDX_PROTEIN_ACCNUM | 7 | | 3 |
Note: cpu costing is off, 'PLAN_TABLE' is old version
11 rows selected.
2 - Standard IN Clause with Index hint
SQL> explain plan for
2 select /*+ INDEX(protein_dim IDX_PROTEIN_ACCNUM) */
3 accession_number, protein_name, sequence_id, taxon_id, organism_name, data_source
4 from pdssuser.protein_dim
5 where accession_number in
6 ('33460', '33458', '33451');
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 7 | 588 | 4 |
| 1 | INLIST ITERATOR | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| PROTEIN_DIM | 7 | 588 | 4 |
| 3 | INDEX RANGE SCAN | IDX_PROTEIN_ACCNUM | 7 | | 3 |
Note: cpu costing is off, 'PLAN_TABLE' is old version
11 rows selected.
3 - Using custom TABLE_OF_VARCHAR type
CREATE TYPE TABLE_OF_VARCHAR AS
TABLE OF VARCHAR2(50);
SQL> explain plan for
2 select
3 accession_number, protein_name, sequence_id, taxon_id, organism_name, data_source
4 from pdssuser.protein_dim
5 where accession_number in
6 (select * from table(cast(TABLE_OF_VARCHAR('33460', '33458', '33451') as TABLE_OF_VARCHAR)) t);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 168 | 57M|
| 1 | NESTED LOOPS SEMI | | 2 | 168 | 57M|
| 2 | TABLE ACCESS FULL | PROTEIN_DIM | 5235K| 419M| 13729 |
| 3 | COLLECTION ITERATOR CONSTRUCTOR FETCH| | | | |
Note: cpu costing is off, 'PLAN_TABLE' is old version
11 rows selected.
4 - Using custom TABLE_OF_VARCHAR type w/ Index hint
SQL> explain plan for
2 select /*+ INDEX(protein_dim IDX_PROTEIN_ACCNUM) */
3 accession_number, protein_name, sequence_id, taxon_id, organism_name, data_source
4 from pdssuser.protein_dim
5 where accession_number in
6 (select * from table(cast(TABLE_OF_VARCHAR('33460', '33458', '33451') as TABLE_OF_VARCHAR)) t);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 168 | 57M|
| 1 | NESTED LOOPS SEMI | | 2 | 168 | 57M|
| 2 | TABLE ACCESS BY INDEX ROWID | PROTEIN_DIM | 5235K| 419M| 252K|
| 3 | INDEX FULL SCAN | IDX_PROTEIN_ACCNUM | 5235K| | 17255 |
| 4 | COLLECTION ITERATOR CONSTRUCTOR FETCH| | | | |
PLAN_TABLE_OUTPUT
Note: cpu costing is off, 'PLAN_TABLE' is old version
12 rows selected.
5 - Using custom TABLE_OF_VARCHAR type w/ cardinality hint
SQL> explain plan for
2 select
3 accession_number, protein_name, sequence_id, taxon_id, organism_name, data_source from protein_dim
4 where accession_number in (select /*+ cardinality( t 10 ) */
5 * from TABLE(CAST (TABLE_OF_VARCHAR('33460', '33458', '33451') AS TABLE_OF_VARCHAR)) t);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 168 | 57M|
| 1 | NESTED LOOPS SEMI | | 2 | 168 | 57M|
| 2 | TABLE ACCESS FULL | PROTEIN_DIM | 5235K| 419M| 13729 |
| 3 | COLLECTION ITERATOR CONSTRUCTOR FETCH| | | | |
Note: cpu costing is off, 'PLAN_TABLE' is old version
11 rows selected.
6 - Using custom TABLE_OF_VARCHAR type w/ cardinality hint
and rownum >= 0 constraint
SQL> explain plan for
2 select
3 accession_number, protein_name, sequence_id, taxon_id, organism_name, data_source from protein_dim
4 where accession_number in (select /*+ cardinality( t 10 ) */
5 * from TABLE(CAST (TABLE_OF_VARCHAR('33460', '33458', '33451') AS TABLE_OF_VARCHAR)) t
6 where rownum >= 0);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 25 | 2775 | 43 |
| 1 | TABLE ACCESS BY INDEX ROWID | PROTEIN_DIM | 2 | 168 | 3 |
| 2 | NESTED LOOPS | | 25 | 2775 | 43 |
| 3 | VIEW | VW_NSO_1 | 10 | 270 | 11 |
| 4 | SORT UNIQUE | | 10 | | |
| 5 | COUNT | | | | |
| 6 | FILTER | | | | |
PLAN_TABLE_OUTPUT
| 7 | COLLECTION ITERATOR CONSTRUCTOR FETCH| | | | |
| 8 | INDEX RANGE SCAN | IDX_PROTEIN_ACCNUM | 2 | | 2 |
Note: cpu costing is off, 'PLAN_TABLE' is old version
16 rows selected.
I don't understand why performance improved so dramatically but happy that it did.
Thanks a ton!
John

Query is doing full table scan

Hi All,
The below query is doing full table scan. So many threads from application trigger this query and doing full table scan. Can you please tell me how to improve the performance of this query?
Env is 11.2.0.3 RAC (4 node). Unique index on VZ_ID, LOGGED_IN. The table row count is 2,501,103.
Query is :-
select ccagentsta0_.LOGGED_IN as LOGGED1_404_, ccagentsta0_.VZ_ID as VZ2_404_, ccagentsta0_.ACTIVE as ACTIVE404_, ccagentsta0_.AGENT_STATE as AGENT4_404_,
ccagentsta0_.APPLICATION_CODE as APPLICAT5_404_, ccagentsta0_.CREATED_ON as CREATED6_404_, ccagentsta0_.CURRENT_ORDER as CURRENT7_404_,
ccagentsta0_.CURRENT_TASK as CURRENT8_404_, ccagentsta0_.HELM_ID as HELM9_404_, ccagentsta0_.LAST_UPDATED as LAST10_404_, ccagentsta0_.LOCATION as LOCATION404_,
ccagentsta0_.LOGGED_OUT as LOGGED12_404_, ccagentsta0_.SUPERVISOR_VZID as SUPERVISOR13_404_, ccagentsta0_.VENDOR_NAME as VENDOR14_404_
from AGENT_STATE ccagentsta0_ where ccagentsta0_.VZ_ID='v790531' and ccagentsta0_.ACTIVE='Y';
Table Scan                                                       AGENT_STATE                                                2.366666667
Table Scan                                                       AGENT_STATE                                                0.3666666667
Table Scan                                                       AGENT_STATE                                                1.633333333
Table Scan                                                       AGENT_STATE                                                       0.75
Table Scan                                                       AGENT_STATE                                                1.866666667
Table Scan                                                       AGENT_STATE                                                2.533333333
Table Scan                                                       AGENT_STATE                                                0.5333333333
Table Scan                                                       AGENT_STATE                                                       1.95
Table Scan                                                       AGENT_STATE                                                        0.8
Table Scan                                                       AGENT_STATE                                                0.2833333333
Table Scan                                                       AGENT_STATE                                                1.983333333
Table Scan                                                       AGENT_STATE                                                        2.5
Table Scan                                                       AGENT_STATE                                                1.866666667
Table Scan                                                       AGENT_STATE                                                1.883333333
Table Scan                                                       AGENT_STATE                                                        0.9
Table Scan                                                       AGENT_STATE                                                2.366666667
But the explain plan shows the query is taking the index
Explain plan output:-
PLAN_TABLE_OUTPUT
Plan hash value: 1946142815
| Id | Operation                   | Name            | Rows | Bytes | Cost (%C
PU)| Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT            |                 |     1 |   106 |   244
(0)| 00:00:03 |
|* 1 | TABLE ACCESS BY INDEX ROWID| AGENT_STATE     |     1 |   106 |   244
(0)| 00:00:03 |
|* 2 |   INDEX RANGE SCAN          | AGENT_STATE_IDX |   229 |       |     4
(0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - filter("CCAGENTSTA0_"."ACTIVE"='Y')
   2 - access("CCAGENTSTA0_"."VZ_ID"='v790531')
The values (VZ_ID) i have given are dummy values picked from the table. I dont get the actual values since the query is coming with bind variables. Please let me know your suggestion on this.
Thanks,
Mani

Hi,
But I am not getting what is the issue..its a simple select query and index is there on one of the leading columns (VZ_ID --- PK). Explain plan says its using its using Index and it only select fraction of rows from the table. Then why it is doing FTS. For Optimizer, why its like a query doing FTS.
The rule-based optimizer would have picked the plan with the index. The cost-based optimizer, however, is picking the plan with the lowest cost. Apparently, the lowest cost plan is the one with the full table scan. And the optimizer isn't necessarily wrong about this.
Reading data from a table via index probes is only efficient when selecting a relatively small percentage of rows. For larger percentages, a full table scan is generally better.
Consider a simple example: a query that selects from a table with biographies for all people on the planet. Suppose you are interested in all people from a certain country.
select * from all_people where country='Vatican'
would only return only 800 rows (as Vatican is an extremely small country with population of just 800 people). For this case, obviously, using an index would be very efficient.
Now if we run this query:
select * from all_people where contry = 'India',
we'd be getting over a billion of rows. For this case, a full table scan would be several thousand times faster.
Now consider the third case:
select * from all_people where country = :b1
What plan should the optimizer choose? The value of :b1 bind variable is generally not known during the parse time, it will be passed by the user when the query is already parsed, during run-time.
In this case, one of two scenarios takes place: either the optimizer relies on some built-in default selectivities (basically, it takes a wild guess), or the optimizer postpones taking the final decision until the
first time the query is run, 'peeks' the value of the bind, and optimizes the query for this case.
In means, that if the first time the query is parsed, it was called with :b1 = 'India', a plan with a full table scan will be generated and cached for subsequent usage. And until the cursor is aged out of library cache
or invalidated for some reason, this will be the plan for this query.
If the first time it was called with :b1='Vatican', then an index-based plan will be picked.
Either way, bind peeking only gives good results if the subsequent usage of the query is the same kind as the first usage. I.e. in the first case it will be efficient, if the query would always be run for countries with big popultions.
And in the second case, if it's always run for countries with small populations.
This mechanism is called 'bind peeking' and it's one of the most common causes of performance problems. In 11g, there are more sophisticated mechanisms, such a cardinality feedback, but they don't always work as expected.
This mechanism is the most likely explanation for your issue. However, without proper diagnostic information we cannot be 100% sure.
Best regards,
Nikolay

Problem of full table scan on a partitioned table

hi all
There is a table called "si_sync_operation" that have 171040 number of rows.
I partitioned that table into a new table called "si_sync_operation_par" with 7 partitoins.
I issued the following statements
SELECT * FROM si_sync_operation_par.
SELECT * FROM si_sync_operation.
The explain plan show that the cost of the first statement is 1626 and that of the second statments is 1810.
The "cost" of full table scan on partitioned table is lower than the that of non-partitioned table.That's fine.
But the "Bytes" of full table scan on partitioned table is 5761288680 and that of the non-partitioned table is 263743680.
Why full table scan on partitioned table access more bytes than non-partitioned table?
And how could a statment that access more bytes results a lower cost?
Thank u very much

As Hemant metioned bytes reported are approximate number of bytes. As far as Cost is concerned, according to Tom its just a number and we should not compare queries by their cost. (search asktom.oracle.com for more information)
SQL> drop table non_part purge;
Table dropped.
SQL> drop table part purge;
Table dropped.
SQL>
SQL> CREATE TABLE non_part
2        (id NUMBER(5),
3         dt    DATE);
Table created.
SQL>
SQL> CREATE TABLE part
2        (id NUMBER(5),
3         dt    DATE)
4         PARTITION BY RANGE(dt)
5         (
6         PARTITION part1_jan2008 VALUES LESS THAN(TO_DATE('01/02/2008','DD/MM/YYYY')),
7         PARTITION part2_feb2008 VALUES LESS THAN(TO_DATE('01/03/2008','DD/MM/YYYY')),
8         PARTITION part3_mar2008 VALUES LESS THAN(TO_DATE('01/04/2008','DD/MM/YYYY')),
9         PARTITION part4_apr2008 VALUES LESS THAN(TO_DATE('01/05/2008','DD/MM/YYYY')),
10         PARTITION part5_may2008 VALUES LESS THAN(TO_DATE('01/06/2008','DD/MM/YYYY'))
11       );
Table created.
SQL>
SQL>
SQL> insert into non_part select rownum, trunc(sysdate) - rownum from dual connect by level <= 140;
140 rows created.
Execution Plan
Plan hash value: 1731520519
| Id | Operation                     | Name | Rows | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
|   1 | COUNT                        |      |       |            |          |
|* 2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
|   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(LEVEL<=140)
SQL>
SQL> insert into part select * from non_part;
140 rows created.
Execution Plan
Plan hash value: 1654070669
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT |          |   140 | 3080 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| NON_PART |   140 | 3080 |     3   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
SQL>
SQL> commit;
Commit complete.
SQL>
SQL> set line 10000
SQL> set autotrace traceonly exp
SQL> select * from non_part;
Execution Plan
Plan hash value: 1654070669
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |          |   140 | 3080 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| NON_PART |   140 | 3080 |     3   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
SQL> select * from part;
Execution Plan
Plan hash value: 3392317243
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |      |   140 | 3080 |     9   (0)| 00:00:01 |       |       |
|   1 | PARTITION RANGE ALL|      |   140 | 3080 |     9   (0)| 00:00:01 |     1 |     5 |
|   2 |   TABLE ACCESS FULL | PART |   140 | 3080 |     9   (0)| 00:00:01 |     1 |     5 |
Note
   - dynamic sampling used for this statement
SQL>
SQL> exec dbms_stats.gather_table_stats(user, 'non_part');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats(user, 'part');
PL/SQL procedure successfully completed.
SQL>
SQL>
SQL> select * from non_part;
Execution Plan
Plan hash value: 1654070669
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |          |   140 | 1540 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| NON_PART |   140 | 1540 |     3   (0)| 00:00:01 |
SQL> select * from part;
Execution Plan
Plan hash value: 3392317243
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |      |   140 | 1540 |     9   (0)| 00:00:01 |       |       |
|   1 | PARTITION RANGE ALL|      |   140 | 1540 |     9   (0)| 00:00:01 |     1 |     5 |
|   2 |   TABLE ACCESS FULL | PART |   140 | 1540 |     9   (0)| 00:00:01 |     1 |     5 |
SQL>After analyzing the tables, notice that the Bytes column has changed value

Full table scan

Hello,
I am working on Oracle 9i and IBM AIX O/S .I am working on two database ..one is production and other one is development.
we are having one select statement which we are running on both database .. On development database this sql stetement is using indexes and give result fast but in production enviornment it is using full table scan for all table and taking time to execute.
The number of rows returning in both envoronment are also al most same ..
I checked that almost all parameters in both databases are same and we use to collect stats on both databses .So stats are also current ..
What all parameters is need to check and what easle i can do to make query using indexes ...?
Any idea...

oradba11 wrote:
Is this true that if we are fetching more then 15% of rows of a table ...oracle will prefer full table scan instead of index read..? Depend index,table stats,selectivity of predicate(so type of query,effective table ,index selectivity and clustering factor)
is this can be a reason for this ..?
any idea ..?Are both databases running in same host?
In both databases did you collected system stats?
In both databases optimizer related parameters are same?
You said,you collected statistics both table ok,but collection methods are same?(mean have you collected histograms both table or for one only).
Also investigate index structure and columns.(post here both table and index structure)
If CBO choose FULL TABLE SCAN(FTS) over INDEX RANGE SCAN(IS) it mean CBO can not use this index or cost of index scan actually expensive than FTS,in this case CBO choose FTS.In additionally depend your query predicate and literal values oracle can choose FTS or IS(depend predicate literals/condition and if here histograms are available).
And finally here is main matter is properties of index,you have to check clustering factor and leaf blocks of your index,due to cost of IS directly related of them.

Why the full table scans in this query on a complex view?

Does someone have an idea of why the FTSs are in here? As I mentioned before, it seems to be using the indexes where I figured it would. I just don't see why it needs to FTS ALL tables involved in the view to put the combined result sets together.
Thanks
Here's the plan
PLAN_TABLE_OUTPUT
Plan hash value: 4040654044
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3060 | 116K| 1404 (2)| 00:00:17 |
|* 1 | FILTER | | | | | |
| 2 | VIEW | V_MOD2_V3 | 305K| 11M| 1259 (2)| 00:00:16 |
| 3 | UNION-ALL | | | | | |
| 4 | TABLE ACCESS FULL | MOD_TAB1 | 101K| 4880K| 420 (2)| 00:00:06 |
| 5 | TABLE ACCESS FULL | MOD_TAB2 | 101K| 4880K| 420 (2)| 00:00:06 |
| 6 | TABLE ACCESS FULL | MOD_TAB3 | 101K| 4880K| 420 (2)| 00:00:06 |
|* 7 | VIEW | V_MOD2_V3 | 3 | 156 | 6 (0)| 00:00:01 |
| 8 | UNION-ALL | | | | | |
|* 9 | TABLE ACCESS BY INDEX ROWID| MOD_TAB1 | 1 | 53 | 2 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | MOD_TAB1_PK | 1 | | 1 (0)| 00:00:01 |
|* 11 | TABLE ACCESS BY INDEX ROWID| MOD_TAB2 | 1 | 53 | 2 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | MOD_TAB2_PK | 1 | | 1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID| MOD_TAB3 | 1 | 53 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | MOD_TAB3_PK | 1 | | 1 (0)| 00:00:01 |
| 15 | SORT AGGREGATE | | 1 | 13 | | |
| 16 | VIEW | V_MOD2_V3 | 219K| 2792K| 139 (6)| 00:00:02 |
| 17 | UNION-ALL | | | | | |
|* 18 | INDEX FAST FULL SCAN | MOD_TAB1_ST_IDX | 101K| 398K| 51 (6)| 00:00:01 |
|* 19 | INDEX FAST FULL SCAN | MOD_TAB2_ST_IDX | 101K| 398K| 52 (6)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | MOD_TAB3_ST_IDX | 16000 | 64000 | 35 (0)| 00:00:01 |
Message was edited by:
Gaff

Alas, ALL of that was in the original post I put up a few weeks ago. I meant to reply to it in the message you saw but instead I "edited" it and the original post is now gone!
Suffice it to say that the 3 tables that make up the view are identical, have the proper columns indexed and have statistics generated. The view you see the explain plan for is a view that just does a "UNION ALL" of each of the 3 mod_tab tables.
As I figured it would, a query on the view uses the indexes to figure out which rows of each underlying table have data for the result set based on the "where" clause , and that is where you see the index range scan, etc. What I don't understand is the part in bold. Assuming all rows in all tables that make up the view have been indentified by these index range scans, what requires the 3 full table scans at the end? The explain plan in SQL Developer (Raptor) will show why each of the other things is there, but not the full table scans.
I am getting a few hundred result set rows out of 100,000-200,000 rows altogether so I can't imagine a full table scan on any of these underlying tables being the right way to go (and look at the cost in the plan).
Thanks

Update Query is Performing Full table Scan of 1 Millions Records

Hello Everyboby I have one update query ,
UPDATE tablea SET
          task_status = 12
          WHERE tablea.link_id >0
          AND tablea.task_status <> 0
          AND tablea.event_class='eventexception'
          AND Exists(SELECT 1 from tablea ltask where ltask.task_id=tablea.link_id
          AND ltask.task_status = 0)
When I do explain plan it shows following result...
Execution Plan
0 UPDATE STATEMENT Optimizer=CHOOSE
1 0 UPDATE OF 'tablea'
2 1 FILTER
3 2 TABLE ACCESS (FULL) OF 'tablea'
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'tablea'
5 4 INDEX (UNIQUE SCAN) OF 'PK_tablea' (UNIQUE)
NOW tablea may have more than 10 MILLION Records....This would take hell of time even if it has to
update 2 records....please suggest me some optimal solutions.....
Regards
Mahesh

I see your point but my question or logic say i have index on all columns used in where clauses so i find no reason for oracle to do full table scan,,,,
UPDATE tablea SET
task_status = 12
WHERE tablea.link_id >0
AND tablea.task_status <> 0
AND tablea.event_class='eventexception'
AND Exists(SELECT 1 from tablea ltask where ltask.task_id=tablea.link_id
AND ltask.task_status = 0)
I am clearly statis where task_status <> 0 and event_class= something and tablea.link_id >0
so ideal case FOR optimizer should be
Step 1)Select all the rowid having this condition...
Step 2)
For each row in rowid get all the row where task_status=0
and where taskid=linkid of rowid selected above...
Step 3)While looping for each rowid if it find any condition try for rowid obtained from ltask in task 2 update that record....
I want to have this kind of plan,,,,,does anyone know how to make oracle obtained this kind of plan......
It is try FULL TABLE SCAN is harmfull alteast not better than index scan.....

Prompt on DATE forces FULL TABLE SCAN

When using a prompt on a datetime field OBIEE sends a SQL to the Database with the TIMESTAMP COMMAND.
Due to Timestamp the Oracle database does a Full Table Scan. The field ATIST is a date with time on the physical database.
By Default ATIST was configured as TIMESTAMP in the rpd physical layer. The SQL request is sent to a Oracle 10 Database.
That is the query sent to the database:
-------------------- Sending query to database named PlantControl1 (id: <<10167>>):
select distinct T1471.ATIST as c1,
T1471.GUTMENGEMELD2 as c2
from
AGRUECK T1471 /* Fact_ARBEITSGANGMELDUNGEN */
where ( T1471.ATIST = TIMESTAMP '2005-04-01 13:48:05' )
order by c1, c2
The result takes more than half a minute to appear.
Because BIEE is using "TIMESTAMP" , the database performs a full table scan instead of using the index.
By using TO_DATE instead of timestamp the result appears after a second.
select distinct T1471.ATIST, T1471.GUTMENGEMELD2 as c2
from
AGRUECK T1471 /* Fact_ARBEITSGANGMELDUNGEN */
where ( T1471.ATIST = to_date('2005.04.01 13:48:05', 'yyyy.mm.dd hh24:mi:ss') );
Is there any way resolving the issue?
PS:When the field ATIST is configured as date at the physical layer the SQL performs well is it uses the command "to_date" instead of "timestamp". But this cuts the time of the date, When it is configured as DATETIME, OBIEE uses TIMESTAMP again.
What I need is a working date + time field.
Anybody has encountered a similiar problem?

To be honest I haven't come across many scenarios where the Time has been important. Most of our reporting stops at Day level.
What is the real world business question being asked here that requires DayTime?
Incidentally if you change your datatype on the base table you will see it works fine.
CREATE TABLE daytime( daytime TIMESTAMP );
CREATE UNIQUE INDEX dt ON daytime (daytime)
SQL> set autotrace traceonly
SQL> SELECT * FROM daytime
2 WHERE daytime = TIMESTAMP '2007-04-01 13:00:45';
no rows selected
Execution Plan
Plan hash value: 3985400340
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |    13 |     1   (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| DT   |     1 |    13 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("DAYTIME"=TIMESTAMP' 2007-04-01 13:00:45.000000000')
Statistics
          1 recursive calls
          0 db block gets
          1 consistent gets
          0 physical reads
          0 redo size
        242 bytes sent via SQL*Net to client
        362 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processed
SQL>However if its a date it would appear to do some internal function call which I guess is the source of the problem ...
| Id | Operation         | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |         |     1 |     9 |     2   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAYTIME |     1 |     9 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(INTERNAL_FUNCTION("DAYTIME")=TIMESTAMP' 2007-04-01
              13:00:45.000000000')

Entity Framework Generated SQL for paging or using Linq skip take causes full table scans.

The slq genreated creates queries that cause a full table scan for pagination. Is there any way to fix this?
I am using
ODP.NET ODTwithODAC1120320_32bit
ASP.NET 4.5
EF 5
Oracle 11gR2
This table has 2 million records. The further into the records you page the longer it takes.
LINQ
var cnt = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                    select errorLog).Count();
                var query = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                             orderby errorLog.ERR_LOG_ID
                             select errorLog).Skip(cnt-10).Take(10).ToList();
Here is the query & execution plans.
SELECT *
FROM   (SELECT "Extent1"."ERR_LOG_ID" AS "ERR_LOG_ID",
               "Extent1"."SRV_LOG_ID" AS "SRV_LOG_ID",
               "Extent1"."TS"          AS "TS",
               "Extent1"."MSG"         AS "MSG",
               "Extent1"."STACK_TRACE" AS "STACK_TRACE",
               "Extent1"."MTD_NM"      AS "MTD_NM",
               "Extent1"."PRM"         AS "PRM",
               "Extent1"."INSN_ID"     AS "INSN_ID",
               "Extent1"."TS_1"        AS "TS_1",
               "Extent1"."LOG_ETRY"    AS "LOG_ETRY"
        FROM   (SELECT "Extent1"."ERR_LOG_ID"                                  AS "ERR_LOG_ID",
                       "Extent1"."SRV_LOG_ID"                                  AS "SRV_LOG_ID",
                       "Extent1"."TS"                                          AS "TS",
                       "Extent1"."MSG"                                         AS "MSG",
                       "Extent1"."STACK_TRACE"                                 AS "STACK_TRACE",
                       "Extent1"."MTD_NM"                                      AS "MTD_NM",
                       "Extent1"."PRM"                                         AS "PRM",
                       "Extent1"."INSN_ID"                                     AS "INSN_ID",
                       "Extent1"."TS_1"                                        AS "TS_1",
                       "Extent1"."LOG_ETRY"                                    AS "LOG_ETRY",
                       row_number() OVER (ORDER BY "Extent1"."ERR_LOG_ID" ASC) AS "row_number"
                FROM   (SELECT "ERRORLOGANDSERVICELOG_VIEW"."ERR_LOG_ID" AS "ERR_LOG_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."SRV_LOG_ID" AS "SRV_LOG_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."TS"          AS "TS",
                               "ERRORLOGANDSERVICELOG_VIEW"."MSG"         AS "MSG",
                               "ERRORLOGANDSERVICELOG_VIEW"."STACK_TRACE" AS "STACK_TRACE",
                               "ERRORLOGANDSERVICELOG_VIEW"."MTD_NM"      AS "MTD_NM",
                               "ERRORLOGANDSERVICELOG_VIEW"."PRM"         AS "PRM",
                               "ERRORLOGANDSERVICELOG_VIEW"."INSN_ID"     AS "INSN_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."TS_1"        AS "TS_1",
                               "ERRORLOGANDSERVICELOG_VIEW"."LOG_ETRY"    AS "LOG_ETRY"
                        FROM   "IDS_CORE"."ERRORLOGANDSERVICELOG_VIEW" "ERRORLOGANDSERVICELOG_VIEW") "Extent1") "Extent1"
        WHERE ("Extent1"."row_number" > 1933849)
        ORDER BY "Extent1"."ERR_LOG_ID" ASC)
WHERE (ROWNUM <= (10))
| Id | Operation              | Name                   | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |                        |    10 | 31750 |       |   821K (1)| 02:44:15 |
|* 1 | COUNT STOPKEY         |                        |       |       |       |            |          |
|   2 |   VIEW                 |                        | 1561K| 4728M|       |   821K (1)| 02:44:15 |
|* 3 |    VIEW                |                        | 1561K| 4748M|       |   821K (1)| 02:44:15 |
|   4 |     WINDOW SORT        |                        | 1561K| 3154M| 4066M|   821K (1)| 02:44:15 |
|* 5 |      HASH JOIN OUTER   |                        | 1561K| 3154M|       |   130K (1)| 00:26:09 |
|   6 |       TABLE ACCESS FULL| IDS_SERVICES_LOG       | 1047 | 52350 |       |     5   (0)| 00:00:01 |
|   7 |       TABLE ACCESS FULL| IDS_SERVICES_ERROR_LOG | 1561K| 3080M|       |   130K (1)| 00:26:08 |
Predicate Information (identified by operation id):
   1 - filter(ROWNUM<=10)
   3 - filter("Extent1"."row_number">1933849)
   5 - access("T1"."SRV_LOG_ID"(+)="T2"."SRV_LOG_ID")

I did try a sample from stack overflow that would apply it to all string types, but I didn't see any query results differences. Please note, I am having the problem without any order with or where statements. Of course the skip take generates them. Please advise how I would implement the EntityFunctions.AsNonUnicode method with this Linq query.
LINQ
var cnt = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                    select errorLog).Count();
                var query = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                             orderby errorLog.ERR_LOG_ID
                             select errorLog).Skip(cnt-10).Take(10).ToList();
This is what I inserted into my model to hopefully fix it. FROM:c# - EF Code First - Globally set varchar mapping over nvarchar - Stack Overflow
/// <summary>
/// Change the "default" of all string properties for a given entity to varchar instead of nvarchar.
/// </summary>
/// <param name="modelBuilder"></param>
/// <param name="entityType"></param>
protected void SetAllStringPropertiesAsNonUnicode(
   DbModelBuilder modelBuilder,
   Type entityType)
   var stringProperties = entityType.GetProperties().Where(
c => c.PropertyType == typeof(string)
   && c.PropertyType.IsPublic
   && c.

Tables in subquery resulting in full table scans

Similar Messages

Maybe you are looking for