Full table scan full scan vs. Index
Hi allFollowing is explain plan sql
SELECT 1 FROM hz_code_assignments ca, hz_relationship_types rt,
hz_hierarchy_nodes hn
WHERE ca.class_category = 'RELATIONSHIP_TYPE_GROUP' AND ca.owner_table_name = 'HZ_RELATIONSHIP_TYPES. '
AND ca.class_code = 'PARTY_REL_GRP_AR_PAY_ANY' AND ca.status = 'A' AND
CA.owner_table_id = rt.relationship_type_id AND rt.subject_type = 'ORGANIZATION '.
And hn.hierarchy_type = rt.relationship_type
=====================================================================
Operation object name lines cost TQ/exit PStart PStop bytes
SELECT Hint = ALL_ROWS 519 508
519 K 53 508 HASH JOIN
NESTED LOOPS 1-97-5
ACCESS BY INDEX ROWID 1 68 4 TABLES HZ_CODE_ASSIGNMENTS
INDEX RANGE SCAN 15 1 HZ_CODE_ASSIGNMENTS_N1
TABLE ACCESS BY INDEX ROWID 1-29-1 HZ_RELATIONSHIP_TYPES
INDEX UNIQUE SCAN HZ_RELATIONSHIP_TYPES_U1 1-0
TABLE ACCESS FULL HZ_HIERARCHY_NODES 91 K 802 502 K
===================================================================
I added more tip
SELECT / * + INDEX (HP HZ_HIERARCHY_NODES_N2) * / 1 OF hz_code_assignments ca, hz_relationship_types rt,.
hz_hierarchy_nodes hn
WHERE ca.class_category = 'RELATIONSHIP_TYPE_GROUP' AND ca.owner_table_name = 'HZ_RELATIONSHIP_TYPES. '
AND ca.class_code = 'PARTY_REL_GRP_AR_PAY_ANY' AND ca.status = 'A' AND
CA.owner_table_id = rt.relationship_type_id AND rt.subject_type = 'ORGANIZATION '.
And hn.hierarchy_type = rt.relationship_type
=========================================================================
Operation object name lines cost TQ/exit PStart PStop bytes
SELECT Hint = ALL_ROWS 519 605
519 K 53 605 NESTED LOOPS
NESTED LOOPS 1-97-5
ACCESS BY INDEX ROWID 1 68 4 TABLES HZ_CODE_ASSIGNMENTS
INDEX RANGE SCAN 15 1 HZ_CODE_ASSIGNMENTS_N1
TABLE ACCESS BY INDEX ROWID 1-29-1 HZ_RELATIONSHIP_TYPES
INDEX UNIQUE SCAN HZ_RELATIONSHIP_TYPES_U1 1-0
INDEX SCAN FULL HZ_HIERARCHY_NODES_N2 6 K 53 K 600
================================================================
Complete systematic index scan is always expensive
Same query in another instance works fine
==================================================================
Operation object name lines cost TQ/exit PStart PStop bytes
SELECT Hint = 472 19 ALL_ROWS
472 K 48 19 NESTED LOOPS
NESTED LOOPS 1-97-2
TABLE ACCESS BY INDEX ROWID 1 68 1 HZ_CODE_ASSIGNMENTS
INDEX RANGE SCAN 15 1 HZ_CODE_ASSIGNMENTS_N1
TABLE ACCESS BY INDEX ROWID 1-29-1 HZ_RELATIONSHIP_TYPES
INDEX UNIQUE SCAN 1 1 HZ_RELATIONSHIP_TYPES_U1
INDEX FULL SCAN HZ_HIERARCHY_NODES_N2 5 K 48 17 K
===============================================================
Can anyone help find why INDEX FULL SCAN is also expensive in the second case
Thank you
in the application code, add the alter session statement after opening session, either before the execution of the sql statement, how exaclty this works will depend on the design of the application and if you use connection pool etc.
Tags: Database
Similar Questions
-
Path to XML index table is full table scan
Hi all
I have a version of oracle 11.2.0.4.6 database
Try to implement partitioning on XML indexes.
Creates a table and index partitioned by time stamp as below.
Whenever I'm trying to find the path table makes a full table scan.
I have applied the fix as indicated ( Doc ID 13522189.8 ).
So the recovery is quite slow and partition pruning does not not on XML indexes.
Wondering if anyone has experienced the same problem?
CREATE TABLE INCIDENT
(
INCIDENT_PK NUMBER (14.5).
INCIDENTGROUPING_PK NUMBER (14.5).
INCIDENTTYPE_PK NUMBER (14.5).
SECURITYCLASS_PK NUMBER (14.5).
STAMP OF INCIDENT_DATE,
SYS INCIDENT_DETAIL. XMLTYPE
)
TABLESPACE DATA_TBS_INCIDENT
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE)
64K INITIALS
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
DEFAULT USER_TABLES
)
LOGGING
NOCOMPRESS
PARTITION BY RANGE (INCIDENT_DATE)
(PARTITION SEP2013_WEEK1 VALUES LESS THAN (to_timestamp (' 00:00:00.00 2013-09-08 ',' YYYY-MM-DD HH24:MI:SS.))) FF2')),
PARTITION SEP2013_WEEK2 VALUES LESS THAN (to_timestamp ('2013-09-15 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),
PARTITION SEP2013_WEEK3 VALUES LESS THAN (to_timestamp ('2013-09-22 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),
..........);
CREATE the INDEX INCIDENTxdb_idx
ON corpaudlive. INCIDENT (INCIDENT_detail) INDEXTYPE IS XDB. LOCAL XMLINDEX 10 PARALLEL
PARAMETERS (' PATH TABLE INCIDENT_PATHTABLE (TABLESPACE DATA_TBS_INCIDENT))
PIKEY INDEX INCIDENT_PATHTABLE_PIKEY_IX (TABLESPACE IDX_TBS_INCIDENT)
PATH ID INDEX INCIDENT_PATHTABLE_ID_IX (TABLESPACE IDX_TBS_INCIDENT)
INCIDENT_PATHTABLE_VALUE_IX VALUE INDEX (TABLESPACE IDX_TBS_INCIDENT)
ORDER KEY INDEX INCIDENT_PATHTABLE_KEY_IX (TABLESPACE IDX_TBS_INCIDENT)
Paths (INCLUDE (//forename //surname //postcode //dateofbirth //street //town))');
SQL > explain the plan for
2 Select INCIDENT_pk in INCIDENT where XMLEXISTS ('/ / name [text () = 'john']' by the way of INCIDENT_detail)
3 and XMLEXISTS ("/ / name [text () 'clark' =]' by the way of INCIDENT_detail")
4 and a.INCIDENT_date between TO_TIMESTAMP (January 10, 2014 ',' DD/MM/YYYY "")
5 and TO_TIMESTAMP (September 10, 2014 ',' DD/MM/YYYY ');
He explained.
Elapsed time: 00:00:02.77
SQL > select * from table (dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 123057549
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop | TQ | IN-OUT | PQ Distrib.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 70. 1803 (5) | 00:00:22 | | | | | |
| 1. COORDINATOR OF PX | | | | | | | | | | |
| 2. PX SEND QC (RANDOM). : TQ10003 | 1. 70. 1803 (5) | 00:00:22 | | | Q1, 03 | P > S | QC (RAND) |
| 3. SEMI NESTED LOOPS. | 1. 70. 1803 (5) | 00:00:22 | | | Q1, 03 | SVCP | |
| 4. NESTED LOOPS | | 1. 57. 1800 (5) | 00:00:22 | | | Q1, 03 | SVCP | |
| 5. VIEW | VW_SQ_1 | 239. 5975 | 1773 (5) | 00:00:22 | | | Q1, 03 | SVCP | |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 6. UNIQUE HASH | | 239. 25334 | | | | | Q1, 03 | SVCP | |
| 7. RECEIVE PX | | 239. 25334 | | | | | Q1, 03 | SVCP | |
| 8. PX SEND HASH | : TQ10002 | 239. 25334 | | | | | Q1, 02 | P > P | HASH |
| 9. UNIQUE HASH | | 239. 25334 | | | | | Q1, 02 | SVCP | |
| * 10 | HASH JOIN | | 239. 25334 | 1773 (5) | 00:00:22 | | | Q1, 02 | SVCP | |
| 11. KIND OF BUFFER. | | | | | | | Q1, 02 | ISSUE | |
| 12. RECEIVE PX | | 1. 22. 3 (0) | 00:00:01 | | | Q1, 02 | SVCP | |
| 13. PX SEND BROADCAST | : TQ10000 | 1. 22. 3 (0) | 00:00:01 | | | | S > P | BROADCAST |
| 14. TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 | 1. 22. 3 (0) | 00:00:01 | | | | | |
| * 15 | INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 | 1. | 2 (0) | 00:00:01 | | | | | |
| * 16. HASH JOIN | | 12077 | 990K | 1770 (5) | 00:00:22 | | | Q1, 02 | SVCP | |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 17. RECEIVE PX | | 250K | 10 M | 39 (0) | 00:00:01 | | | Q1, 02 | SVCP | |
| 18. PX SEND BROADCAST | : TQ10001 | 250K | 10 M | 39 (0) | 00:00:01 | | | Q1, 01 | P > P | BROADCAST |
| 19. SYSTEM PARTITION ALL | | 250K | 10 M | 39 (0) | 00:00:01 | 1. 112. Q1, 01 | ISSUE | |
| * 20. TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE | 250K | 10 M | 39 (0) | 00:00:01 | 1. 112. Q1, 01 | SVCP | |
| * 21. INDEX RANGE SCAN | INCIDENT_PATHTABLE_VALUE_IX | 161. | 25 (0) | 00:00:01 | 1. 112. Q1, 01 | SVCP | |
| 22. ITERATOR BLOCK PX | | 221 M | 8865M | 1671 (1) | 00:00:21 | 53. 54. Q1, 02 | ISSUE | |
| * 23. TABLE ACCESS FULL | INCIDENT_PATHTABLE | 221 M | 8865M | 1671 (1) | 00:00:21 | 53. 54. Q1, 02 | SVCP | |
| * 24. TABLE ACCESS BY ROWID USER | INCIDENT | 1. 32. 1 (0) | 00:00:01 | ROWID | ROWID | Q1, 03 | SVCP | |
| * 25. SEE PUSHED PREDICATE. VW_SQ_2 | 1. 13. 20 (0) | 00:00:01 | | | Q1, 03 | SVCP | |
| 26. NESTED LOOPS | | 1. 106. 20 (0) | 00:00:01 | | | Q1, 03 | SVCP | |
| 27. NESTED LOOPS | | 4. 106. 20 (0) | 00:00:01 | | | Q1, 03 | SVCP | |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 28. NESTED LOOPS | | 4. 256. 8 (0) | 00:00:01 | | | Q1, 03 | SVCP | |
| 29. TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 | 1. 22. 3 (0) | 00:00:01 | | | Q1, 03 | SVCP | |
| * 30 | INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 | 1. | 2 (0) | 00:00:01 | | | Q1, 03 | SVCP | |
| 31. ITERATOR SYSTEM PARTITION. | 4. 168. 5 (0) | 00:00:01 | 53. 54. Q1, 03 | SVCP | |
| * 32 | TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE | 4. 168. 5 (0) | 00:00:01 | 53. 54. Q1, 03 | SVCP | |
| * 33 | INDEX RANGE SCAN | INCIDENT_PATHTABLE_PIKEY_IX | 4. | 4 (0) | 00:00:01 | 53. 54. Q1, 03 | SVCP | |
| 34. ITERATOR SYSTEM PARTITION. | 1. | 2 (0) | 00:00:01 | KEY | KEY | Q1, 03 | SVCP | |
| * 35 | INDEX RANGE SCAN | INCIDENT_PATHTABLE_KEY_IX | 1. | 2 (0) | 00:00:01 | KEY | KEY | Q1, 03 | SVCP | |
| * 36 | TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE | 1. 42. 3 (0) | 00:00:01 | 1. 1. Q1, 03 | SVCP | |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
10 - access("SYS_P9".") PATHID '=' ID')
Access (SYS_PATH_REVERSE ("PATH") 15 - > = HEXTORAW ('02582E') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('02582EFF'))
16 - access("SYS_P11".") RID "IS 'SYS_P9'." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "THE INCIDENT", 0,7,65535, "SYS_P9" "." " "RID") = TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "INCIDENT_PATHTAB
THE', 0,7,65535, ROWID))
filter ("SYS_P9". "ORDER_KEY" < = 'SYS_P11' "." " ORDER_KEY' AND 'SYS_P11 '. "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P9". "ORDER_KEY")) "
20 filter (SYS_XMLI_LOC_ISTEXT ("SYS_P11". "LOCATOR", "SYS_P11" "." " PATHID') = 1)
21 - access("SYS_P11".") The VALUE "= 'John')
23 filter (SYS_XMLI_LOC_ISNODE ("SYS_P9". "LOCATOR") = 1 AND SYS_OP_BLOOM_FILTER (: BF0000, "SYS_P9".) " PATHID'))
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
24 - filter("A".") INCIDENT_DATE' > = TIMESTAMP' 2014 - 10 - 01 00:00:00.000000000 "AND"A"". "" INCIDENT_DATE"< = TIMESTAMP' 2014 - 10 - 09 00:00:00.000000000' AND
"ITEM_2" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A". ROWID))
25 filter ("ITEM_4" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A".) ROWID))
30 - access (SYS_PATH_REVERSE ("PATH") > = HEXTORAW('027FF9') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('027FF9FF'))
32 filter (SYS_XMLI_LOC_ISNODE ("SYS_P2". "LOCATOR") = 1) "
33 - access("SYS_P2".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. ("' PATHID '=' ID ')
35 - access("SYS_P4".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. "" ORDER_KEY "< ="SYS_P4. " "" ORDER_KEY "AND"SYS_P4 ". "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P2". "ORDER_KEY")) "
filter ("SYS_P4". "RID"IS "SYS_P2"." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM("INCIDENT",0,7,65535,"SYS_P2".") "RID") = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT_PATHTABL
E «(, 0,7,65535, ROWID)).
36 - filter("SYS_P4".") The VALUE '= 'clark' AND SYS_XMLI_LOC_ISTEXT ("SYS_P4".' LOCATOR', 'SYS_P4 '. (("" PATHID ') = 1).
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note
-----
-dynamic sample used for this survey (level = 6)
69 selected lines.
Elapsed time: 00:00:00.47
SQL > spool off
Thank you
CenterB
You must create a XMLIndex with two groups:
create table actionnew)
number of action_pk
action_date timestamp
action_detail xmltype
)
partition by (range (action_date)
partition values before_2015 less (timestamp ' 2015-01-01 00:00:00 ')
, partition values jan_2015 less (timestamp ' 2015-02-01 00:00:00 ')
, partition values feb_2015 less (timestamp ' 2015-03-01 00:00:00 ')
);
create index actionnew_sxi on actionnew (action_detail)
indexType is xdb.xmlindex
local
parameters (q'~)
Group my_group_1
XMLTable actionnew_xt1
"/ audit/action_details/screen_data/tables/table/row.
path of varchar2 (100) the columns "name".
, path of surname varchar2 (100) "first name".
Group my_group_2
XMLTable actionnew_xt2
"/ audit/action_details/fields.
path of varchar2 (100) the columns "name".
, path of surname varchar2 (100) "first name".
~'
);
Select x.*
to actionnew t
xmltable)
"/ audit/action_details/screen_data/tables/table/row.
in passing t.action_detail
path of varchar2 (100) the columns "name".
, path of surname varchar2 (100) "first name".
) x
where t.action_date between timestamp ' 2015-02-01 00:00:00 '
and timestamp ' 2015-03-01 00:00:00 '
and x.forename = 'anwardo. '
and x.surname = 'gram '.
;
-
Index on non unique values in order to avoid the full table scan
I have a table with > 100 k records. The table is updated only during the race every night. All columns except one have non - unique values and I am querying the table with this request.
COL3 - non - unique values - only 40 distinct values
unique values - no - COL4 - 1000 distinct values
last_column - 100 k unique values
Select last_column in the table_name where in (...) col3 or col4 (...)
I tried to create a Bitmap index individually on col3 and col4 and also combined. However, in both cases, it performs a full table scan.
Please, help me optimize this query as it is used in the term altogether the system and the cost of the query is very high around 650.
I don't have much experience with popular indexes then all tracks.
Thank you
Sensey
Published by: user13312817 on November 7, 2011 11:32An alternative might be to use a union instead and the 2 index:
create index my_index1 on my_table (col3, last_column) compress 1;
create index my_index2 on my_table (col4, last_column) compress 1;Select last_column from my_table
where col3 in (...)
Union
Select last_column from my_table
where col4 (...)In other words, if the UNION would apply here whereas in double values for last_column will be deleted.
-
FULL TABLE SCAN even with the index, but why?
Could someone please explain why I'd get FULL TABLE SCAN explain plan results when joining 2 tables on columns that already have clues about them? For example,.
consider this fictional scenario:
employee table with columns:
employee # (primary key column)
name
address table with columns:
employee # (foreign key to employee.employee #)
subscription_type
address
Select Employee.Name since it is, address.address_type, address.address
where employee.employee # = address.employee #.
This query shows a full table scan in terms of the explain command.Full scan of the table is not necessarily slow and index access is not necessarily fast.
You will recover, no doubt, most if not all the ranks on both sides. The fastest way to retrieve each row in a table is to do a table scan. Using an index, and a single block of reading for each row in a table is much less effective than to do a table scan.
Justin
-
CBO: full instead of bitmap index use, why table scan?
I have a query in which it is clearly benefitial to use the bitmap index, rather oracle goes for the full table scan. Could you please shed some light on this? Because even a hint does not help, I guess that something prevents oracle (11.1.0.7.0) to use it in a sort of range index scan pass.
installation program:
several select statements:create table test_distance ( x_display number, y_display number, x_rough number(5,2) as (trunc(x_display,2)), y_rough number(5,2) as (trunc(y_display,2))); insert into test_distance (x_display,y_display) (select dbms_random.value(-180,180), dbms_random.value(-90,90) from dual connect by level < 200000); create bitmap index test_bm_xrough on test_distance(x_rough); create bitmap index test_bm_yrough on test_distance(y_rough); create or replace function western_bbox_longitude(x binary_double, y binary_double, radius binary_double) return number is begin --simplified return x - 0.0001*radius; end; / exec dbms_stats.gather_table_stats(user,'TEST_DISTANCE',cascade=>true,estimate_percent=>100);--remember x and y values and use them in the subsequent queries. select * from test_distance where rownum = 1; alter session set statistics_level = all; --no bind variable, no function call -> proper plan select * from test_distance where x_rough = 16.14 and y_rough = -35.53; select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); --with bind variable, no function call -> still proper plan select * from test_distance where x_rough = :xin and y_rough = :yin; select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); --using between, bind variable, no function call -> proper plan select * from test_distance where x_rough between :xin-0.01 and :xin and y_rough between :yin-0.01 and :yin; select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); --full table scan, why? select td.*, trunc(western_bbox_longitude(:xin,:yin,:radius),2) from test_distance td where x_rough = trunc( western_bbox_longitude(:xin,:yin,:radius),2); select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); --forcing oracle to use the index results in bitmap index full instead of range scan, why? select /*+ index( td test_bm_xrough) */ td.*, trunc(western_bbox_longitude(:xin,:yin,:radius),2) from test_distance td where x_rough = trunc( western_bbox_longitude(:xin,:yin,:radius),2); select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); --guessing it might be related to the selectivity of the function doesn't change the plan either associate statistics with functions western_bbox_longitude default selectivity 0.001;Ah sorry, I somehow read the wrong line in your initial statement where it between the function has been used.
Yes it is possible that the selectivity of the function plays a role here. More likely may be the order of execution for the undeterministic functions is then different for literals. However, you can try to work around this problem by using a few different approaches.
encapsulate the function inside a double subseelct
select /*+ index( td test_bm_xrough) */ td.*, (select trunc(western_bbox_longitude(:xin,:yin,:radius),2)) from test_distance td where x_rough = (select trunc(western_bbox_longitude(:xin,:yin,:radius),2) from dual);This should allow to cache the result of the function to a certain extent. Otherwise, the result of the function may be recalculated for each row in the test_distance table.
The same can be achieved with a WITH clause
not testedwith wboxlong as (select trunc(western_bbox_longitude(:xin,:yin,:radius),2) xrough from dual) select /*+ index( td test_bm_xrough) */ td.*, x.xrough from test_distance td join wboxlong x on td.x_rough = x.xroughAlso note that your tip worked. Oracle uses the bitmap indexes to access the data. Index indicator indicates to the CBO to use this index if possible, but is not on the path. If you want a different plan, you can try to apply also the path combined with a suspicion as NO_INDEX_FFS (http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements006.htm#SQLRF50413).
Published by: Sven w. on January 3, 2011 18:57
-
Why full when I index the table scan
Can someone quickly tell me why this statement will generate a full table scan if RECEIPT_NO for both tables have a unique index.
Select * from agency_ledger where a.RECEIPT_NO in (select receipt_no from temp)
concerningHello
Two reason I can think
(1) statistics are not collected or are at a standstill.
(2) oracle considers the hash join full table scan more appropriate than the nested loop + scan small index.Post your explain plain and let us know stats is collected or not.
In addition, let us know what is the percentage of rows are expected in output compared to the total number of lines.Concerning
Anurag Tibrewal. -
Hi all
I have a table which is accesed by application every 5 seconds. Now, this table has several delete insert updates current. The table size is aprox 200 MB (high tide) and there is say 5 ranks, which will be a sentence of 20 to 30 KB. My CMS is say 2 GB. So now the stats are not met and there is no index in this table. Now I see full table scan as his wait event. Now, I want to know.
How a scan full of tabel happens Oracle load the entire 200MB of data in the SGA and then do a table scan or should just the actual size used by the table IE 20 to 30 KB.
Thank you
A
Hello
high waters is precisely the limit up to which Oracle must read to be sure that all the data has been seen, so if you have only about 30 KB of data in the table, even if the data is in the first a few blocks from the table, a complete analysis must read the 200 MB (which is not so good but takes more time to read a few blocks). (the reason is that it was once the data written in this block and it triggered the HWM),
You can reorganize the table (alter table mytable move or use DBMS_REDEFINITION so that you can do this, the application uses the table) to reset the HWM. ("If the current small" size used"is transient and if you expect the table to increase again to use 200 MB or more, don't need to reorg; do it if you are confident that the table will remain very weak)
Best regards
Brno Vroman.
-
3 clues on 3 different columns, but explain plan shows full table scan for select queries
I have a table - used and have index - functional ind1 (upper (f_name)), index - (emp_id) ind2 ind3 (upper (l_name) functional on 3 columns diffferent - what, emp_id, l_name respectively.) Now when I check explain plans for sub queries, they all have two shows complete table for the employee of the table scan. FYI - employee table is non-parittioned.
Can someone tell me why 3 indices are not used here?
(1) select emp_id, upper (f_name), upper (l_name) of the employee
(2) select upper (f_name), mp_id, upper (l_name) of the employee
where upper (f_name) = upper (f_name)
and emp_id = emp_id
and upper (l_name) = upper (l_name)
If I can push oracle (version 11) to use these indexes somewho - maybe using tips? Any help is appreciated.
Observations: SQL> desc emp1; Name Null? Type ----------------------------------------- -------- ----------------- EMPID NOT NULL NUMBER F_NAME NOT NULL VARCHAR2(3) L_NAME NOT NULL VARCHAR2(3) SALARY NUMBER JOB_ROLE VARCHAR2(5) DEPTID NUMBER create index idx2 on emp1(empid); create index idx1 on emp1(upper(f_name) ); create index idx3 on emp1(f_name,empid, l_name); exec dbms_stats.gather_table_stats(user,'EMP1', cascade=>true); 8 rows selected. SQL> explain plan for 2 select /*+ index_join(e idx1 idx2 idx3)*/ upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select upper(f_name),empid,upper(l_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select /*+ index_ffs(e idx3)*/ upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 2496145112 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FAST FULL SCAN| IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ----------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select /*+ index(e idx3)*/ upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select upper(f_name),empid,upper(l_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> drop index idx3; Index dropped. SQL> explain plan for 2 select upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3330885630 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 18 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| EMP1 | 20000 | 175K| 18 (0)| 00:00:01 | -------------------------------------------------------------------------- 8 rows selected. SQL> create index idx3 on emp1(f_name,empid, l_name ); Index created. SQL> explain plan for 2 select upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 |
-
Is it reasonable to require a Full table Scan (Direct path read) on a large Table
Hello
I have an Oracle 11.2.0.3 on a Sun Solaris 10 sparc with SGA 25 GB machine
One of my made SQL an analysis of indexes on the table to 45 GB where the size of the index is 14FR and the thourghput for the sequential read is 2MBPS.
so now (Index) 14 000 Mo, 14 GB / 2 MB = dry 7000 = 2 hours to scan the index.
Flow of the direct path read is 500 Mbps for an another SQL and reads assimilate them all live.
and because of this flow, a read (FTS) of direct path on the table of 7 GB out in 12-13 seconds. So in my case, it probably takes 100 seconds to scan the entire table. It is a monthly report and does not often.
Should I try to use a trick to force sql to do a full scan and exploit the possibilities of direct reading and is done in a few minutes? Assuming it to do a FTS (direct play)
Of course, it will be tested and verified, but the question is, is this a sensible apprioach? is - anyone has experience by forcing it?
Any suggestions would be helpful... I'll test this on a different machine tomorrow.
Best regards
Maran
82million lines and a grouping of 18million factor? And really 17million from lines to recover? However, your result set after the hash join is 3500 lines, although the optimizer expects 16 lines.
I would say that the statistics are not representative or not in use for this SQL. Certainly, the index does not match query predicates.
The fact that the index is also using the virtual columns only adds to confusion.
Hemant K Collette
-
How to avoid the full table scan?
Hello
I'm new to sql tuning. When I run the following query. Full table scan that happens and it does not use the index.
SELECT / * + FIRST_ROWS (2) * / a0.t$ ttyp, a0.t$ amnt FROM forest112 WHERE a0.t$ amnt <>: 1 AND a0.t$ dapr =: 2 AND a0.t$ tapr =: 3;
When I searched on the net, I found by changing the operator '<>' with 'NOT IN' we can make the query to use the index, but that will change the result. Is this true? What are the other changes that can be made to this query?
I think that create under index may solve your problem, because in this case, it will not hit the table and get all desired data to index itself
create index ind_1 on forest112 (tapr$ t, t$ WTSA, dapr$ t, t$ ttyp) compute statistics;
Thank you
Harman
-
Tuning sql insert that inserts 1 million lines makes a full table scan
Hi Experts,
I'm on Oracle 11.2.0.3 on Linux. I have a sql that inserts data into a table of History/Archives of a table main application based on the date. The application table has 3 million lines. and all the lines that are more then 6 months old must go in a table of History/Archives. This was decided recently, and we have 1 million rows that meet this criterion. This insertion in table archive takes about 3 minutes. Plan of the explain command shows a full table scan on the main Board - which is the right thing, because we are pulling 1 million rows in the main table in the history table.
My question is that, is it possible that I can do this sql go faster?
Here's the query plan (I changed the names of table etc.)
INSERT INTO EMP_ARCH SELECT * FROM EMP M where HIRE_date < (sysdate - :v_num_days); call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 2 0.00 0.00 0 0 0 0 Execute 2 96.22 165.59 92266 147180 8529323 1441230 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 96.22 165.59 92266 147180 8529323 1441230 Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: FIRST_ROWS Parsing user id: 166 Rows Row Source Operation ------- --------------------------------------------------- 1441401 TABLE ACCESS FULL EMP (cr=52900 pr=52885 pw=0 time=21189581 us)
I heard that there is a way to use opt_param tip to increase the multiblock read County but did not work for me... I will be grateful for suggestions on this. can collections and this changing in pl/sql also make it faster?
Thank you
OrauserN
(1) create an index on hire_date
(2) tip 'additional' use in the 'select' query '
(3) run ' alter session parallel DML'; before you run the entire statement
-
Hi Experts/gurus,
I read Oracle http://docs.oracle.com/cd/B19306_01/server.102/b14211/optimops.htm#i52044 docs, i.e. the difference between the range index scans, full scan and full scan index restricts index. Here is the description of 'Fast Full Index Scans'
Full index scans are an alternative to a full table scan when the index contains all the columns needed for the query, and at least one column in the index key has the NOT NULL constraint. A full scan accesses the data in the index itself, without access to the table. It can be used to eliminate a sort operation, because the data are not classified by the index key. It reads the entire index using multiblock bed, unlike a full index scan and can be parallelized.
Therefore, the document says, the optimizer to choose index FFS, 'at least in the index key column a NOT NULL constraint', but I see less test cases is in complete contrast to what I've read.
I created a table without constraints "NOT NULL".
As expected under its weight "Full Table Scan", now if I have an index on columns (a, b), if my interpretation is correct, according to the docs, the optimizer should not do a "full Index scan", but Interestingly, it obeys the indication of index_ffs and did a full scan indexSQL> create table r_dummy(a number,b varchar2(10)); Table created. SQL> insert into r_dummy select level,'hi' from dual connect by level<=20; 20 rows created. SQL> commit; Commit complete. SQL> exec dbms_stats.gather_table_stats('HLODS','R_DUMMY'); PL/SQL procedure successfully completed. SQL> select * from r_dummy where a <= 10; A B ---------- ---------- 1 hi 2 hi 3 hi 4 hi 5 hi 6 hi 7 hi 8 hi 9 hi 10 hi 10 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 2533004807 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 60 | 3 (0)| 00:00:01 | |* 1 | TABLE ACCESS FULL| R_DUMMY | 10 | 60 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("A"<=10) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 329 bytes sent via SQL*Net to client 238 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 10 rows processed
This clearly shows the optimizer chooses 'INDEX FAST FULL SCAN' even though none of the indexed columns have 'NOT NULL' constraint.SQL> create index r_dummy_idx on r_dummy(a,b); Index created. SQL> exec dbms_stats.gather_index_stats('HLODS','R_DUMMY_IDX'); PL/SQL procedure successfully completed. SQL> select /*+index_ffs(r)*/ * from r_dummy r where a <= 10; A B ---------- ---------- 1 hi 2 hi 3 hi 4 hi 5 hi 6 hi 7 hi 8 hi 9 hi 10 hi 10 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 3219236618 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 60 | 2 (0)| 00:00:01 | |* 1 | INDEX FAST FULL SCAN| R_DUMMY_IDX | 10 | 60 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("A"<=10) Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 330 bytes sent via SQL*Net to client 238 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 10 rows processed
And there is another statement that talks about the results of the COMMAND.
+ "May not be used to eliminate a sort operation, because data are not classified by the index key ' +.
He eliminated the sort operation, I see my results in ascending order.
Below you can see the results in ascending order.SQL> drop table r_dummy; Table dropped. SQL> create table r_Dummy(a number); Table created. SQL> insert into r_dummy values(10); 1 row created. SQL> insert into r_dummy values(3); 1 row created. SQL> insert into r_dummy values(1); 1 row created. SQL> insert into r_dummy values(9); 1 row created. SQL> insert into r_dummy values(5); 1 row created. SQL> insert into r_dummy values(4); 1 row created. SQL> insert into r_dummy values(2); 1 row created. SQL> insert into r_dummy values(6); 1 row created. SQL> insert into r_dummy values(7); 1 row created. SQL> commit; Commit complete. SQL> select * from r_dummy; A ---------- 10 3 1 9 5 4 2 6 7 9 rows selected. SQL> create index r_dummy_idx on r_dummy(a); Index created. SQL> set autotrace on; SQL> exec dbms_stats.gather_table_stats('HLODS','R_DUMMY'); PL/SQL procedure successfully completed. SQL> exec dbms_stats.gather_index_stats('HLODS','R_DUMMY_IDX'); PL/SQL procedure successfully completed.
I am not sure if the docs are wrong or I'm reading wrong. Please help / correct me if my interpretation is poor.SQL> select /*+index_ffs(r)*/ * from r_dummy r where a<=10; A ---------- 1 2 3 4 5 6 7 9 10 9 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 3219236618 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 9 | 27 | 2 (0)| 00:00:01 | |* 1 | INDEX FAST FULL SCAN| R_DUMMY_IDX | 9 | 27 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("A"<=10) Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 291 bytes sent via SQL*Net to client 238 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 9 rows processed SQL>RUSSO says:
Nicosa salvation,
First of all, thank you for your elaborate explanation.Nicosa wrote:
Will rely on data to order no order by clause and your app will be one day or the other have a bug. + (which, in fact, will not one, as the app has been designed in this way!) +I don't really do this, I know that even in parallel the same query may return also rows without a prescription. But was surprised to see my results neatly on INDEX NORMAL (non-partitioned). However, I make sure that I have use 'order by' when I want my results to order.
But still I'm not sure, how the absence of constraint column 'NOT NULL' in the index would stop optimizer to do a full scan limited index
Oracle does not index lines where all coluumns in the index are null. So, in your first example it could be possible that there is a line wiith the two a and b null. Oracle could not return this line using an index full assessment because it would not be in the index. However, by adding a predicate on a indexed columns say you actually column is not null.
In the table, that I used in my example above, all three columns are nullable. Take into account:
SQL> select acctno, count(*) from pttrans 2 group by acctno; Execution Plan ---------------------------------------------------------- Plan hash value: 3294770776 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 532K| 6239K| | 48143 (2)| 00:09:38 | | 1 | HASH GROUP BY | | 532K| 6239K| 107M| 48143 (2)| 00:09:38 | | 2 | TABLE ACCESS FULL| PTTRANS | 5081K| 58M| | 37895 (1)| 00:07:35 | -------------------------------------------------------------------------------------- SQL> select acctno, count(*) from pttrans 2 where acctno is not null 3 group by acctno; Execution Plan ---------------------------------------------------------- Plan hash value: 3737827862 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 532K| 6239K| | 20641 (4)| 00:04:08 | | 1 | HASH GROUP BY | | 532K| 6239K| 107M| 20641 (4)| 00:04:08 | |* 2 | INDEX FAST FULL SCAN| PTTRANS1 | 5081K| 58M| | 10393 (2)| 00:02:05 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("ACCTNO" IS NOT NULL)The first query must examine acctno null to get the correct number, but the second, because I asked explicitly not null can use the index.
John
-
The query makes a full table scan?
I have a simple select query that filters on the last 10 or 11 days of data in a table. In the first case, it runs in 1 second. In the second case it takes 15 minutes and still not done.
I can say that the second query (11 days) makes a full table scan.
-Why is this happening? ... I guess some kind of threshold?
-Are there a way to avoid this? ... or encourage Oracle to play nice.
I find confusing from the point of view before end/query to get very different performances.
Jason
Oracle 10g
Toad quest 10.6
CREATE TABLE delme10 AS SELECT * FROM ed_visits WHERE first_contact_dt >= TRUNC(SYSDATE-10,'D'); Plan hash value: 915912709 -------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------- | 0 | CREATE TABLE STATEMENT | | 4799 | 5534K| 4951 (1)| 00:01:00 | | 1 | LOAD AS SELECT | DELME10 | | | | | | 2 | TABLE ACCESS BY INDEX ROWID| ED_VISITS | 4799 | 5534K| 4796 (1)| 00:00:58 | |* 3 | INDEX RANGE SCAN | NDX_ED_VISITS_020 | 4799 | | 15 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("FIRST_CONTACT_DT">=TRUNC(SYSDATE@!-10,'fmd')) CREATE TABLE delme11 AS SELECT * FROM ed_visits WHERE first_contact_dt >= TRUNC(SYSDATE-11,'D'); Plan hash value: 1113251513 ----------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ----------------------------------------------------------------------------------------------------------------- | 0 | CREATE TABLE STATEMENT | | 25157 | 28M| 14580 (1)| 00:02:55 | | | | | 1 | LOAD AS SELECT | DELME11 | | | | | | | | | 2 | PX COORDINATOR | | | | | | | | | | 3 | PX SEND QC (RANDOM) | :TQ10000 | 25157 | 28M| 14530 (1)| 00:02:55 | Q1,00 | P->S | QC (RAND) | | 4 | PX BLOCK ITERATOR | | 25157 | 28M| 14530 (1)| 00:02:55 | Q1,00 | PCWC | | |* 5 | TABLE ACCESS FULL | ED_VISITS | 25157 | 28M| 14530 (1)| 00:02:55 | Q1,00 | PCWP | | ----------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 5 - filter("FIRST_CONTACT_DT">=TRUNC(SYSDATE@!-11,'fmd'))This seems to change the plan to explain it...
alter session set optimizer_index_cost_adj=10; -
causing trunc of the full Table Scans
I have a situtaion here where my query is this.
SQL > select count (1) in the HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5 = 'HD' and CUST_STATUS in ('UP', "UUP") and trunc (FIRST_ACTVN_DATE) = trunc (sysdate);
COUNT (1)
----------
6
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3951750498
---------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 10. 13904 (1) | 00:02:47 |
| 1. GLOBAL TRI | 1. 10 | | | | |
| 2. SIMPLE LIST OF PARTITION. 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.
---------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 filter (("CUST_STATUS" = "UP" OU "CUST_STATUS" = 'UUP') AND)
TO_DATE (INTERNAL_FUNCTION ("FIRST_ACTVN_DATE")) = TO_DATE (TO_CHAR(SYSDATE@!)))
16 selected lines.
If I remove the trunc clause in the query performance improves significantly the results are false.
SQL > select count (1) in the HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5 = 'HD' and CUST_STATUS in ('UP', "UUP") and FIRST_ACTVN_DATE = trunc (sysdate);
COUNT (1)
----------
0
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 454529511
---------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 40. 47 (0) | 00:00:01 |
|* 1 | TABLE ACCESS BY 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 anyone please help me by which I can get the right data, and I can also prevent such full table scans.Unless you use a functional index, apply any function to an indexed column prevents the use of the index.
The way around it in your case is to realize 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)Really asking that the FIRST_ACTVN_DATE are sometimes today. You can rewrite so 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 that this may not always use the index according to the number of lines are the date of the day compared to how many are outside today's date.
Also, when you post, don't forget to put your code between
tags and to post create table scripts and sample data inserts. -
Hello
Please help me understand why full scan limited index that happens in the following query:
Even if chargeid is not where clause of the query performs index FFS on NBFC_xyz_PK. Also, what is "index$ _join$ _001?SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi PL/SQL Release 10.2.0.2.0 - Production CORE 10.2.0.2.0 Production TNS for Solaris: Version 10.2.0.2.0 - Production NLSRTL Version 10.2.0.2.0 - Production explain plan for SELECT CHARGEID FROM xyz WHERE CHARGECODEID in(2,29); Explained. ---------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 18 | 2 (50)| 00:00:01 | |* 1 | VIEW | index$_join$_001 | 2 | 18 | 2 (50)| 00:00:01 | |* 2 | HASH JOIN | | | | | | | 3 | INLIST ITERATOR | | | | | | |* 4 | INDEX RANGE SCAN | xyz_IDX1 | 2 | 18 | 2 (0)| 00:00:01 | | 5 | INDEX FAST FULL SCAN| NBFC_xyz_PK | 2 | 18 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("CHARGECODEID"=2 OR "CHARGECODEID"=29) 2 - access(ROWID=ROWID) 4 - access("CHARGECODEID"=2 OR "CHARGECODEID"=29) COLUMN_NAME DATA_TYPE NUM_DISTINCT NUM_NULLS DENSITY HISTOGRAM ------------------------------ ------------------------------ ------------ ---------- ---------- --------------- CHARGECODEID NUMBER 241 0 .004149378 NONE CHARGEID NUMBER 296 0 .003378378 NONE INDEX_NAME COLUMN_NAME COLUMN_POSITION ------------------------------ ------------------------------ --------------- NBFC_xyz_PK CHARGEID 1 xyz_IDX1 CHARGECODEID 1 xyz_IDX1 TXNTYPE 2 xyz_IDX1 MODULEID 3 xyz_IDX1 VALIDTILLDATE 4 SQL> show parameter optimizer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ optimizer_dynamic_sampling integer 2 optimizer_features_enable string 10.2.0.2 optimizer_index_caching integer 0 optimizer_index_cost_adj integer 100 optimizer_mode string ALL_ROWS optimizer_secure_view_merging boolean TRUE
Kind regards
Published by: santi January 5, 2012 04:04Hi Santi
Rather than read the index and the ROWID can visit the table, the CBO has decided it's cheaper to do:
Get all the ROWID of the index xyz_IDX1 on the CHARGECODEID column via a scan interval for two values of interest (2.29)
Get all the ROWID for all entries using the Index Index fast Full Scan on the NBFC_xyz_PK index on the CHARGEID column (as this is the only column to select)
Do a hash join to determine what ROWID exists between these two indices.
The index view $ _join$ _001 is the result of this hash join, which allows to extract only CHARGEID values that are of interest.
All necessary information can be obtained from these 2 indices and so avoided visits to the table. A column should not be in the WHERE clause of an index to consider.
See you soon
Richard Foote
http://richardfoote.WordPress.com/ -
Hello experts,
I am on 11g R2 RHEL5, I have a general question here, oracle said complete random for table scan reads are slower sequential reading, as far as my knowledge a sequential read is a monobloc read into the buffer cache, and read a straggling is a multiblock read that can occur for a full restricted index scan or a full table scan. My question is what is a shuffle? and how it is different from the sequential reading? on the technical side... Please put some light on these technical terms, so that I can work on the setting. There is also a warrant RANDOM i/o.In a very brief way, the scan would be something like, you ask for the first time for employees starting with the name 'Aman' (wasn't there a lot with this name) to access using an index be a better choice (perhaps not a good example of a column containing names in real time. Example is just for the sake of discussion) then asking with the name of 'John '.
Aman...
Maybe you are looking for
-
Satellite C665 - noise adaptor
Hello I bought this Toshiba Satellite C665 JB HiFi Australia about 2-3 weeks ago. Today, I suddenly heard some strange noise from the adapter. I don't really know how to describe the sound, but I did registered using my cell phone. The noise lasted a
-
HP a6110n bios update not showing do not update review date.
HP a6110n, mo M2N68 - LA, vista home prem (32 bit), Bios v 5.13/10/29/2007. looked on the support of the HP driver if the bios update is availabe & found bios update v5.13 / 11/9/2007. so I downloaded from the revision date is later. It seems that th
-
I need a replacement 14 "motherboard for my R52 with ATI graphics card. #39T 5684 is compatible? Model of Thinkpad R52-1847-2FU is.
-
Problems Math Expression using Labview
Hi all I am trying to solve a mathematical expression with Labview. The expression, I am trying to solve is 4 ^ x + 7 x ^ 3 = 200. Let's say 200 = y. The task is someone inserts a number of 'y' and Labview calculates 'x '. The way I'm trying to achie
-
1935 error message when you try to install the device driver for the wireless broadband
need help addressing an error message when you install a device wide band. Error 1935