How to avoid this full table scan (and index FFS) ?

Hi All,
Oracle 11.2 on Linux.
See this query and its plan below
SQL> DELETE
2 FROM TABLEA APE
3 WHERE NOT EXISTS
4 (SELECT 1
5 FROM TABLEB AP
6 WHERE AP.col1 = APE.col1
7 AND AP.col2 = APE.col2
8 AND AP.col3 = APE.col3)
9 AND ROWNUM < 51 ;
50 rows deleted.
Elapsed: 00:12:01.07
Execution Plan
Plan hash value: 1740911877
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | DELETE STATEMENT | | 50 | 2650 | | 573K (1)| 01:54:40 |
| 1 | DELETE | TABLEA | | | | | |
|* 2 | COUNT STOPKEY | | | | | | |
|* 3 | HASH JOIN RIGHT ANTI | | 80M| 4059M| 1775M| 573K (1)| 01:54:40 |
| 4 | INDEX FAST FULL SCAN| TABLEB_UK | 47M| 1228M| | 96480 (1)| 00:19:18 |
| 5 | TABLE ACCESS FULL | TABLEA | 80M| 1991M| | 243K (1)| 00:48:42 |
---------------------------------------------------------------------------------------------------------In both tables, TABLEA and TABLEB, there is index on columns col1-col2-col3 as leading columns (TABLEB has few more columns in the index, but after these 3 columns).
Requirement is, I want to delete first 50 records in TABLEA, which does not exist in TABLEB.
I tried with various hints, but Oracle is always doing a full scan on one of the tables and index FFS on other. In some cases, Oracle did full scan on both tables and then deleted 50 records. Stats is up-to-date. Doing a full scan on tables with 80 million and 47 million rows is a bit too much for deleting 50 rows.
How I can make Oracle do
1) Read TABLEA row-by-row
2) for each row, check if it exists in TABLEB
3) If not exists, then delete row from TABLEA, else continue
4) Stop reading TABLEA after we have deleted 50 records
Thanks in advance

>
>
Oracle 11.2 on Linux.
SQL> DELETE
2 FROM TABLEA APE
3 WHERE NOT EXISTS
4 (SELECT 1
5 FROM TABLEB AP
6 WHERE AP.col1 = APE.col1
7 AND AP.col2 = APE.col2
8 AND AP.col3 = APE.col3)
9 AND ROWNUM < 51 ;
50 rows deleted.
Elapsed: 00:12:01.07
Execution Plan
Plan hash value: 1740911877
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | DELETE STATEMENT | | 50 | 2650 | | 573K (1)| 01:54:40 |
| 1 | DELETE | TABLEA | | | | | |
|* 2 | COUNT STOPKEY | | | | | | |
|* 3 | HASH JOIN RIGHT ANTI | | 80M| 4059M| 1775M| 573K (1)| 01:54:40 |
| 4 | INDEX FAST FULL SCAN| TABLEB_UK | 47M| 1228M| | 96480 (1)| 00:19:18 |
| 5 | TABLE ACCESS FULL | TABLEA | 80M| 1991M| | 243K (1)| 00:48:42 |
---------------------------------------------------------------------------------------------------------Requirement is, I want to delete first 50 records in TABLEA, which does not exist in TABLEB.
Such requirements usually make me curious - what's special about a randomly selected 50 rows ?
Is this trying to delete the data in batches of 50 rows at a time.
How I can make Oracle do
1) Read TABLEA row-by-row
2) for each row, check if it exists in TABLEB
3) If not exists, then delete row from TABLEA, else continue
4) Stop reading TABLEA after we have deleted 50 records
It look's as if a 'no_unnest' hint in the subquery should do what you want. It should make Oracle run the quey with a FILTER subquery. You could then choose to drive the delete through a tablescan of tableA or an index range scan of the index on tableA. Have you considered the effect of (and requirements relating to) nulls in the three columns of either table ?
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: Oracle Core

Similar Messages

Why it is taking full table scan when index is available

Hi all,
I am facing a strange problem with index.
I created index on a column like
1. CREATE INDEX ASSETS_ARTIST_IDX2 ON ASSETS(artist).
SELECT asset.artist AS NAME FROM ASSETS asset WHERE asset.artist LIKE 'J%'
Explain Plan : INDEX RANGE SCAN
2. CREATE INDEX ASSETS_ARTIST_IDX2 ON ASSETS(UPPER (TRANSLATE (artist, ',;:"', ' ')));
SELECT asset.artist AS NAME FROM ASSETS asset WHERE UPPER (TRANSLATE (artist, ',;:"', ' ')) LIKE 'J%'
          Explain Plan : TABLE ACCESS FULL
first time it is taking index range scan,but in second situation scaning full table.Please let me know how to avoid the full table scan.
Regards,
Rajasekhar

Actually, I misseunderstood damorgan' s statement about NULL and OP did not provide table definition. So based on FTS I would say it is more likely column is NULLable, otherwise I would expect INDEX FAST SCAN:
SQL> create table emp1 as select * from emp
2 /
Table created.
SQL> create index emp1_idx1 on emp1(empno)
2 /
Index created.
SQL> exec dbms_stats.gather_table_stats('SCOTT','EMP1');
PL/SQL procedure successfully completed.
SQL> desc emp1
Name                                                                     Null?    Type
EMPNO                                                                             NUMBER(4)
ENAME                                                                             VARCHAR2(10)
JOB                                                                               VARCHAR2(9)
MGR                                                                               NUMBER(4)
HIREDATE                                                                          DATE
SAL                                                                               NUMBER(7,2)
COMM                                                                              NUMBER(7,2)
DEPTNO                                                                            NUMBER(2)
SQL> explain plan for
2 select empno
3 from emp1 where UPPER(TRANSLATE(empno, ',;:"', ' ')) LIKE '7%'
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2226897347
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     4 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP1 |     1 |     4 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER(TRANSLATE(TO_CHAR("EMPNO"),',;:"',' ')) LIKE '7%')
13 rows selected.
SQL> alter table emp1 modify empno not null
2 /
Table altered.
SQL> explain plan for
2 select empno
3 from emp1 where UPPER(TRANSLATE(empno, ',;:"', ' ')) LIKE '7%'
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2850860361
| Id | Operation        | Name      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |           |     1 |     4 |     1   (0)| 00:00:01 |
|* 1 | INDEX FULL SCAN | EMP1_IDX1 |     1 |     4 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER(TRANSLATE(TO_CHAR("EMPNO"),',;:"',' ')) LIKE '7%')
13 rows selected.
SQL> SY.

How can i make the optimiser to skip this full table scan ??

Hi,
I am trying to tune the below query, I have checked up all the possibilities to skip the full table scan on vhd_calldesh_archive, But am unable to find the predicate in the where clause, which is letting the optimiser to choose the full table scan on vhd_calldesk_archive table, which is very large one. how can i make the optimiser to skip this full table scan.
Please check the below sql script and explain plan ,
SELECT a.call_id, a.entry_date,
NVL (INITCAP (b.full_name), caller_name) AS caller_name,
c.description AS org_desc, a.env_id, i.env_desc, a.appl_id,
d.appl_desc, a.module_id, e.module_desc, a.call_type_id,
f.call_type_desc, a.priority, a.upduserid,
INITCAP (g.full_name) AS lastupdated_username, a.call_desc, h.mode_desc,
a.received_time,a.assignment_team, a.status,
ROUND (lcc.pkg_com.fn_datediff ('MI',
a.entry_date,
a.status_date
) AS elapsed_time,
ROUND (lcc.pkg_com.fn_datediff ('MI',
a.entry_date,
a.status_date
) AS resolved_min,
CASE
WHEN a.orgid in (1,100,200) THEN a.orgid
ELSE j.regionorgid
END AS region
,(SELECT coalesce(MAX(upddate),a.upddate) FROM lcc.vhd_callstatus stat WHERE stat.call_id = a.call_id
) as stat_upddate
,(SELECT team_desc from lcc.vhd_teams t where t.team_id = a.assignment_team) as team_desc
,a.eta_date
,coalesce(a.caller_contact, b.telephone) AS caller_contact
,coalesce(a.caller_email, b.email) as email
,a.affected_users
,a.outage_time
,a.QA_DONE
,a.LAST_ACTION_TEAM
,a.LAST_ACTION_USER
,INITCAP (k.full_name) AS last_action_username
,a.last_action_date
,l.team_desc as last_action_teamdesc
,a.refid
,INITCAP (lu.full_name) AS logged_name
,a.pmreview
,a.status as main_status
FROM lcc.vhd_calldesk_archive a
LEFT OUTER JOIN lcc.lcc_userinfo_details b ON b.user_name = a.caller_id
INNER JOIN lcc.com_organization c ON c.code = a.orgid
INNER JOIN lcc.vhd_applications d ON d.appl_id = a.appl_id
INNER JOIN lcc.vhd_modules e ON e.appl_id = a.appl_id AND e.module_id = a.module_id
INNER JOIN lcc.vhd_calltypes f ON f.call_type_id = a.call_type_id
INNER JOIN lcc.com_rptorganization j ON j.orgid = a.orgid AND j.tree = 'HLPDK'
LEFT OUTER JOIN lcc.lcc_userinfo_details g ON g.user_name = a.upduserid
LEFT OUTER JOIN lcc.vhd_callmode h ON h.mode_id = a.mode_id
LEFT OUTER JOIN lcc.vhd_environment i ON i.appl_id = a.appl_id AND i.env_id = a.env_id
LEFT OUTER JOIN lcc.lcc_userinfo_details k ON k.user_name = a.last_action_user
LEFT OUTER JOIN lcc.vhd_teams l ON l.team_id = a.last_action_user
LEFT OUTER JOIN (select CALL_ID,upduserid FROM lcc.VHD_CALLDESK_HISTORY P where upddate
in ( select min(upddate) from lcc.VHD_CALLDESK_HISTORY Q WHERE Q.CALL_ID = P.CALL_ID
group by call_id)) ku
ON ku.call_id = a.call_id
LEFT OUTER JOIN lcc.lcc_userinfo_details lu ON NVL(ku.upduserid,A.upduserid) = lu.user_name;
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2104 | 3667K| 37696 |
| 1 | UNION-ALL | | | | |
| 2 | NESTED LOOPS OUTER | | 2103 | 3665K| 37683 |
| 3 | VIEW | | 2103 | 3616K| 35580 |
| 4 | NESTED LOOPS OUTER | | 2103 | 823K| 35580 |
| 5 | NESTED LOOPS OUTER | | 2103 | 774K| 33477 |
| 6 | NESTED LOOPS OUTER | | 2103 | 685K| 31374 |
| 7 | NESTED LOOPS | | 2103 | 636K| 29271 |
| 8 | NESTED LOOPS | | 2103 | 603K| 27168 |
| 9 | NESTED LOOPS OUTER | | 2103 | 558K| 25065 |
| 10 | NESTED LOOPS OUTER | | 2103 | 515K| 22962 |
| 11 | NESTED LOOPS | | 2103 | 472K| 20859 |
| 12 | NESTED LOOPS | | 2103 | 429K| 18756 |
| 13 | NESTED LOOPS OUTER | | 4826 | 890K| 13930 |
| 14 | NESTED LOOPS OUTER | | 4826 | 848K| 9104 |
| 15 | NESTED LOOPS | | 4826 | 754K| 4278 |
|* 16 | TABLE ACCESS FULL | COM_RPTORGANIZATION | 75 | 1050 | 3 |
| 17 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK | 64 | 9344 | 57 |
|* 18 | INDEX RANGE SCAN | VHD_CALLDSK_ORGID | 2476 | | 7 |
| 19 | VIEW PUSHED PREDICATE | | 1 | 20 | 1 |
|* 20 | FILTER | | | | |
| 21 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 20 | 2 |
|* 22 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
|* 23 | FILTER | | | | |
| 24 | SORT GROUP BY NOSORT | | 1 | 12 | 2 |
| 25 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 12 | 2 |
|* 26 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
| 27 | TABLE ACCESS BY INDEX ROWID | VHD_CALLMODE | 1 | 9 | 1 |
|* 28 | INDEX UNIQUE SCAN | VHD_CALLMOD_MODID_PK | 1 | | |
| 29 | TABLE ACCESS BY INDEX ROWID | VHD_APPLICATIONS | 1 | 20 | 1 |
|* 30 | INDEX UNIQUE SCAN | VHD_APPL_APPLID_PK | 1 | | |
| 31 | TABLE ACCESS BY INDEX ROWID | VHD_CALLTYPES | 1 | 21 | 1 |
|* 32 | INDEX UNIQUE SCAN | VHD_CALLTYP_ID_PK | 1 | | |
| 33 | TABLE ACCESS BY INDEX ROWID | VHD_TEAMS | 1 | 21 | 1 |
|* 34 | INDEX UNIQUE SCAN | VHD_TEAMID_PK | 1 | | |
| 35 | TABLE ACCESS BY INDEX ROWID | VHD_ENVIRONMENT | 1 | 21 | 1 |
|* 36 | INDEX UNIQUE SCAN | VHD_ENV_APLENVID_PK | 1 | | |
| 37 | TABLE ACCESS BY INDEX ROWID | VHD_MODULES | 1 | 22 | 1 |
|* 38 | INDEX UNIQUE SCAN | VHD_MOD_APLMOD_ID_PK | 1 | | |
| 39 | TABLE ACCESS BY INDEX ROWID | COM_ORGANIZATION | 1 | 16 | 1 |
|* 40 | INDEX UNIQUE SCAN | COM_ORG_PK | 1 | | |
| 41 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 |
|* 42 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 43 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 43 |
|* 44 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 45 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 46 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 47 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 48 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 49 | NESTED LOOPS OUTER | | 1 | 1785 | 13 |
| 50 | VIEW | | 1 | 1761 | 12 |
| 51 | NESTED LOOPS OUTER | | 1 | 1656 | 12 |
| 52 | NESTED LOOPS OUTER | | 1 | 1632 | 11 |
| 53 | NESTED LOOPS OUTER | | 1 | 1608 | 10 |
| 54 | NESTED LOOPS | | 1 | 1565 | 9 |
| 55 | NESTED LOOPS | | 1 | 1549 | 9 |
| 56 | NESTED LOOPS | | 1 | 1535 | 9 |
| 57 | NESTED LOOPS OUTER | | 1 | 1513 | 8 |
| 58 | NESTED LOOPS OUTER | | 1 | 1492 | 7 |
| 59 | NESTED LOOPS | | 1 | 1471 | 6 |
| 60 | NESTED LOOPS | | 1 | 1450 | 5 |
| 61 | NESTED LOOPS OUTER | | 1 | 1430 | 4 |
| 62 | NESTED LOOPS OUTER | | 1 | 1421 | 3 |
| 63 | TABLE ACCESS FULL | VHD_CALLDESK_ARCHIVE | 1 | 1401 | 2 |
| 64 | VIEW PUSHED PREDICATE | | 1 | 20 | 1 |
|* 65 | FILTER | | | | |
| 66 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 20 | 2 |
|* 67 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
|* 68 | FILTER | | | | |
| 69 | SORT GROUP BY NOSORT | | 1 | 12 | 2 |
| 70 | TABLE ACCESS BY INDEX ROWID| VHD_CALLDESK_HISTORY | 1 | 12 | 2 |
|* 71 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
| 72 | TABLE ACCESS BY INDEX ROWID | VHD_CALLMODE | 1 | 9 | 1 |
|* 73 | INDEX UNIQUE SCAN | VHD_CALLMOD_MODID_PK | 1 | | |
| 74 | TABLE ACCESS BY INDEX ROWID | VHD_APPLICATIONS | 1 | 20 | 1 |
|* 75 | INDEX UNIQUE SCAN | VHD_APPL_APPLID_PK | 1 | | |
| 76 | TABLE ACCESS BY INDEX ROWID | VHD_CALLTYPES | 1 | 21 | 1 |
|* 77 | INDEX UNIQUE SCAN | VHD_CALLTYP_ID_PK | 1 | | |
| 78 | TABLE ACCESS BY INDEX ROWID | VHD_TEAMS | 1 | 21 | 1 |
|* 79 | INDEX UNIQUE SCAN | VHD_TEAMID_PK | 1 | | |
| 80 | TABLE ACCESS BY INDEX ROWID | VHD_ENVIRONMENT | 1 | 21 | 1 |
|* 81 | INDEX UNIQUE SCAN | VHD_ENV_APLENVID_PK | 1 | | |
| 82 | TABLE ACCESS BY INDEX ROWID | VHD_MODULES | 1 | 22 | 1 |
|* 83 | INDEX UNIQUE SCAN | VHD_MOD_APLMOD_ID_PK | 1 | | |
| 84 | TABLE ACCESS BY INDEX ROWID | COM_RPTORGANIZATION | 1 | 14 | |
|* 85 | INDEX UNIQUE SCAN | COM_RPTORG_PK | 1 | | |
| 86 | TABLE ACCESS BY INDEX ROWID | COM_ORGANIZATION | 1 | 16 | |
|* 87 | INDEX UNIQUE SCAN | COM_ORG_PK | 1 | | |
| 88 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 43 |
|* 89 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 90 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 |
|* 91 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 92 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 93 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 95 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
Predicate Information (identified by operation id):
16 - filter("J"."TREE"='HLPDK')
18 - access("J"."ORGID"="A"."ORGID")
20 - filter( EXISTS (SELECT /*+ */ 0 FROM "LCC"."VHD_CALLDESK_HISTORY" "Q" WHERE "Q"."CALL_ID"=:B1
"Q"."CALL_ID" HAVING MIN("Q"."UPDDATE")=:B2))
22 - access("SYS_ALIAS_2"."CALL_ID"="A"."CALL_ID")
23 - filter(MIN("Q"."UPDDATE")=:B1)
26 - access("Q"."CALL_ID"=:B1)
28 - access("H"."MODE_ID"(+)="A"."MODE_ID")
30 - access("D"."APPL_ID"="A"."APPL_ID")
32 - access("F"."CALL_TYPE_ID"="A"."CALL_TYPE_ID")
34 - access("L"."TEAM_ID"(+)="A"."LAST_ACTION_TEAM")
36 - access("I"."APPL_ID"(+)="A"."APPL_ID" AND "I"."ENV_ID"(+)="A"."ENV_ID")
38 - access("E"."APPL_ID"="A"."APPL_ID" AND "E"."MODULE_ID"="A"."MODULE_ID")
40 - access("C"."CODE"="A"."ORGID")
42 - access("K"."USER_NAME"(+)="A"."LAST_ACTION_USER")
44 - access("B"."USER_NAME"(+)="A"."CALLER_ID")
46 - access("G"."USER_NAME"(+)="A"."UPDUSERID")
48 - access("LU"."USER_NAME"(+)=NVL("SYS_ALIAS_4"."UPDUSERID_162","SYS_ALIAS_4"."UPDUSERID_25"))
65 - filter( EXISTS (SELECT /*+ */ 0 FROM "LCC"."VHD_CALLDESK_HISTORY" "Q" WHERE "Q"."CALL_ID"=:B1
"Q"."CALL_ID" HAVING MIN("Q"."UPDDATE")=:B2))
67 - access("SYS_ALIAS_2"."CALL_ID"="SYS_ALIAS_1"."CALL_ID")
68 - filter(MIN("Q"."UPDDATE")=:B1)
71 - access("Q"."CALL_ID"=:B1)
73 - access("H"."MODE_ID"(+)="SYS_ALIAS_1"."MODE_ID")
75 - access("D"."APPL_ID"="SYS_ALIAS_1"."APPL_ID")
77 - access("F"."CALL_TYPE_ID"="SYS_ALIAS_1"."CALL_TYPE_ID")
79 - access("L"."TEAM_ID"(+)=TO_NUMBER("SYS_ALIAS_1"."LAST_ACTION_USER"))
81 - access("I"."APPL_ID"(+)="SYS_ALIAS_1"."APPL_ID" AND "I"."ENV_ID"(+)="SYS_ALIAS_1"."ENV_ID")
83 - access("E"."APPL_ID"="SYS_ALIAS_1"."APPL_ID" AND "E"."MODULE_ID"="SYS_ALIAS_1"."MODULE_ID")
85 - access("SYS_ALIAS_1"."ORGID"="J"."ORGID" AND "J"."TREE"='HLPDK')
87 - access("C"."CODE"="SYS_ALIAS_1"."ORGID")
89 - access("B"."USER_NAME"(+)="SYS_ALIAS_1"."CALLER_ID")
91 - access("SYS_ALIAS_1"."UPDUSERID"="G"."USER_NAME"(+))
93 - access("K"."USER_NAME"(+)="SYS_ALIAS_1"."LAST_ACTION_USER")
95 - access("LU"."USER_NAME"(+)=NVL("SYS_ALIAS_3"."UPDUSERID_162","SYS_ALIAS_3"."UPDUSERID_25"))
Note: cpu costing is off

I've tried to look thru your sql and changed it a bit. Of course not testet :-)
Your problem isn't the archive table! I tried to remove the 2 selects from the select-clause. Furthermore you have a lot of nested loops in your explain, which is a performance-killer. Try getting rid of them, perhaps use /*+ USE_HASH(?,?) */.
SELECT a.call_id, a.entry_date,
       NVL (INITCAP (b.full_name), caller_name) AS caller_name, c.description AS org_desc, a.env_id, i.env_desc, a.appl_id,
       d.appl_desc, a.module_id, e.module_desc, a.call_type_id, f.call_type_desc, a.priority, a.upduserid,
       INITCAP (g.full_name) AS lastupdated_username, a.call_desc, h.mode_desc, a.received_time, a.assignment_team, a.status,
       ROUND (lcc.pkg_com.fn_datediff ('MI', a.entry_date, a.status_date)) AS elapsed_time,
       ROUND (lcc.pkg_com.fn_datediff ('MI', a.entry_date, a.status_date)) AS resolved_min,
       CASE
          WHEN a.orgid IN (1, 100, 200)
             THEN a.orgid
          ELSE j.regionorgid
       END AS region,
       COALESCE (stat.upddate, a.upddate) AS stat_upddate,
       t.team_desc, a.eta_date,
       COALESCE (a.caller_contact, b.telephone) AS caller_contact,
       COALESCE (a.caller_email, b.email) AS email, a.affected_users,
       a.outage_time, a.qa_done, a.last_action_team, a.last_action_user,
       INITCAP (k.full_name) AS last_action_username, a.last_action_date,
       l.team_desc AS last_action_teamdesc, a.refid,
       INITCAP (lu.full_name) AS logged_name, a.pmreview,
       a.status AS main_status
FROM lcc.vhd_calldesk_archive a, lcc.lcc_userinfo_details b, lcc.com_organization c,
       lcc.vhd_applications d, lcc.vhd_modules e, lcc.vhd_calltypes f, lcc.com_rptorganization j,
       lcc.lcc_userinfo_details g, lcc.vhd_callmode h, lcc.vhd_environment i, lcc.lcc_userinfo_details k,
       lcc.vhd_teams l,
      (SELECT call_id, upduserid
       FROM lcc.vhd_calldesk_history p
       WHERE upddate IN (SELECT   MIN (upddate)
                         FROM lcc.vhd_calldesk_history q
                         WHERE q.call_id = p.call_id
                         GROUP BY call_id)) ku,
       lcc.lcc_userinfo_details lu,
      (SELECT call_id, MAX (upddate)
       FROM lcc.vhd_callstatus
       GROUP BY call_id) stat,
       lcc.vhd_teams t
WHERE a.caller_id        = b.user_name(+)
    AND a.orgid            = c.code
    AND a.appl_id          = d.appl_id
    AND a.appl_id          = e.appl_id
    AND a.module_id        = e.module_id
    AND a.call_type_id     = f.call_type_id
    AND a.orgid            = j.orgid
    AND j.tree             = 'HLPDK'
    AND a.upduserid        = g.user_name(+)
    AND a.mode_id          = h.mode_id(+)
    AND a.appl_id          = i.appl_id(+)
    AND a.env_id           = i.env_id(+)
    AND a.last_action_user = k.user_name(+)
    AND a.last_action_user = l.team_id(+)
    AND a.call_id          = ku.call_id(+)
    AND NVL (ku.upduserid, a.upduserid) = lu.user_name(+)
    AND a.call_id          = stat.call_id
    AND a.assignment_team = t.team_id;

Full table scan and how to avoid it

Hello,
I have two tables, one with 425,000 records, and the other with 5,200,000 records in it. The smaller table has an index on its unique primary key, and the bigger table has an index on the foreign key of the smaller table.
When joining these two tables, I keep getting full table scans on both of these tables, and I would like to understand the philosophy behind it as well as ways to avoid this.
Thanks

Are you manipulating the join columns in any fashion? Such as applying a function to them like in
to_char(column_a) = to_char(column_b)Because any manipulation like that will obviate your index (assuming you don't have function based indexes).
Really though, without your tables, indexes and query, we're left with voodoo, which is cool, but not really that effective.
*note to any and all practicing witch doctors, i really do think voodoo is cool and effective, please don't persecute me for my speakings.
Message was edited by:
Tubby

Full table scans and EUL

Hi All,
I am using Discoverer Version 10.1.2.1.
I have few reports in which tables used in queries (used in Custom folders) go into full table scans inspite of all efforts in tuning.
I came to know that full table scans also come from the way EUL is built and maintained.
Can anyone please throw some light on how does EUL and full table scan relate.
Also one more thing here, which is better to use, Database View on which we can base our folder or writing the complete complex query in the folder.
Any help in this case will be appreciated.
Regards,
Ankur

Hi,
Can anyone please throw some light on how does EUL and full table scan relateThe database cost base optimiser processes the SQL that has been generated by Discoverer and creates an execution plan for the SQL. Now the execution plan will contain full table scans if the CBO calculates that FTS will give the best results. The CBO mainly uses the statistics held against the tables and the conditions in the SQL to calculate whether FTS would be better than using an index. The table join conditions are usually defined in the EUL but other conditions are usually in the workbook.
So there are many factors which control whether the database uses an FTS and only a few of them are affected by how the EUL is built.
Database View on which we can base our folder or writing the complete complex query in the folderIn general, it is always better to create a database view if that option is available to you. You can control and monitor the SQL in a database view much more easily than using a query in a custom folder.
Rod West

Question about Full Table Scans and Tablespaces

Good evening (or morning),
I'm reading the Oracle Concepts (I'm new to Oracle) and it seems that, based on the way that Oracle allocates and manages storage the following premise would be true:
Premise: A table that is often accessed using a full table scan (for whatever reasons) would best reside in its own dedicated tablespace.
The main reason I came to this conclusion is that when doing a full table scan, Oracle does multiblock I/O, likely reading one extent at a time. If the Tablespace's datafile(s) only contain data for a single table then a serial read will not have to skip over segments that contain data for other tables (as would be the case if the tablespace is shared with other tables). The performance improvement is probably small but, it would seem that there is one nonetheless.
I'd like to have the thoughts of experienced DBAs regarding the above premise.
Thank you for your contribution,
John.

Good morning :) Aman,
>
A little correction! A segment(be it a table,index, cluster, temporary) , would stay always in its own tablespace. Segments can't span tablespaces!
>
Fortunately, I understood that from the beginning :)
You mentioned fragmentation, I understand that too. As rows get deleted small holes start existing in the segment and those holes are not easily reusable because of their limited size.
What I am referring to is different though.
Let's consider a tablespace that is the home of 2 or more tables, the tablespace in turn is represented by one or more OS datafiles, in that case the situation will be as shown in the following diagram (not a very good diagram but... best I can do here ;) ):
Tablespace TablespaceWithManyTables
(segment 1 contents)
    TableA Extent 1
      TableA Block 1
      TableA Block 2
      Fragmentation may happen in these blocks or
      even across blocks because Oracle allows rows
      to span blocks
      TableA Block n
    End of TableA Extent 1
    more extents here all for TableA
(end of segment 1 contents)
(segment 2 contents)
    TableZ Extent 5
      blocks here
    End of TableZ Extent 5
    more extents here, all for tableZ
(end of segment 2 contents)
    and so on
(more segments belonging to various tables)
end of Tablespace TablespaceWithManyTablesOn the other hand, if the tablespace hosts only one table, the layout will be:
Tablespace TablespaceExclusiveForTableA
(segment 1 contents)
    TableA Extent 1
      TableA Block 1
      TableA Block 2
      Fragmentation may happen in these blocks or
      even across blocks because Oracle allows rows
      to span blocks
      TableA Block n
    End of TableA Extent 1
    another extent for TableA
(end of segment 1 contents)
(segment 2 contents)
    TableA Extent 5
      blocks here
    End of TableA Extent 5
    more extents for TableA
(end of segment 2 contents)
and so on
(more segments belonging to TableA)
end of Tablespace TablespaceExclusiveForTableAThe fragmentation you mentioned takes place in both cases. In the first case, regardless of fragmentation, some segments don't belong to the table that is being serially scanned, therefore they have to be skipped over at the OS level. In the second case, since all the extents belong to the same table, they can be read serially at the OS level. I realize that in that case the segments may not be read in the "right" sequence but they don't have to because they can be served to the client app in sequence.
It is because of this that, I thought that if a particular table is mostly read serially, there might be a performance benefit (and also less work for Oracle) to dedicate a tablespace to it.
I can't wait to see what you think of this :)
John.

Update doing full table scan and taking long time

Hi All,
I am running an update statement which is doing a full table scan.
UPDATE Database.TABLE AS T
SET COMMENTS = CAST(CAST(COALESCE(T.COMMENTS,0) AS INTEGER) + 1 AS
CHARACTER)
WHERE T.TRACKINGPOINT = 'NDEL'
AND T.REFERENCENUMBER =
SUBSTRING(Root.XML.EE_EAI_MESSAGE.ReferenceNumber || '
' FROM 1 FOR 32);
Any advice.
Regards,
Umair

Mustafa,
No Developer is writing it in his program.
Regards,
Umair

Full Table Scans and LRU

Hello,
In a full table scan I understand that the memory block used for a newly read table block is placed at the end of the LRU.
When the second table block is read, is the same memory block replaced?
What I am asking basically is whether for a full table scan only one block in the data buffer is ever used, with the same single block being recycled for the entire content of the table.
Kind regards,
Peter Strauss

Hi Fidel,
> In oracle 10g it changes a little the behavior. It is
> recommended not to set MULTIBLOCK_READ_COUNT. You
> calculate system statistics and Oracle "decides" the
> best value.
Take care... oracle 10gR2 uses the system statistic values to calculate the costs (= execution plan) including the i/o statistics but for the multiple i/o it uses the parameter DB_FILE_MULTIBLOCK_READ_COUNT.
So the result is: For calculating it uses the system statistic and for the work itself it uses DB_FILE_MULTIBLOCK_READ_COUNT (if set).
http://jonathanlewis.wordpress.com/2007/05/20/system-stats-strategy/
For the LRU thing ... oracle has a nice explanation:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/memory.htm
Regards
Stefan

Star Query Full Table Scan

Hi, Folks:
I have a complex SQL statement that runs very slowly.
Following is the statement:
SELECT
T3.POSITION_ID,
T12.PR_POSTN_ID,
T12.PR_TERR_ID,
T12.PR_REP_MANL_FLG,
T9.CREATED,
T10.PR_EMP_ID,
T9.MODIFICATION_NUM,
T12.DEDUP_TOKEN,
T12.LOCATION_LEVEL,
T12.PR_PRTNR_OU_ID,
T12.PR_OU_TYPE_ID,
T12.PAR_DUNS_NUM,
T3.ACCNT_NAME,
T11.ATTRIB_16,
T6.PAR_ROW_ID,
T3.INVSTR_FLG,
T6.ROW_ID,
T12.DUNS_NUM,
T12.BU_ID,
T10.ROW_ID,
T2.LAST_NAME,
T3.SRV_PROVDR_FLG,
T12.X_PR_MERCH_NBR_ID,
T3.ROW_STATUS,
T12.NAME,
T11.PAR_ROW_ID,
T6.LAST_UPD_BY,
T6.MODIFICATION_NUM,
T3.PRIORITY_FLG,
T10.NAME,
T3.ASGN_SYS_FLG,
T9.PROFIT,
T12.PR_BL_ADDR_ID,
T12.PR_REP_ASGN_TYPE,
T9.LAST_UPD_BY,
T3.FACILITY_FLG,
T12.LAST_UPD_BY,
T12.PR_SHIP_ADDR_ID,
T11.MODIFICATION_NUM,
T11.LAST_UPD_BY,
T5.LOGIN,
T3.ASGN_MANL_FLG
FROM
S_ADDR_ORG T1,
S_CONTACT T2,
S_ACCNT_POSTN T3,
S_ORG_INT T4,
S_EMPLOYEE T5,
S_ORG_EXT_FNX T6,
S_ORG_SYN T7,
S_INDUST T8,
S_ORG_EXT_T T9,
S_POSTN T10,
S_ORG_EXT_X T11,
S_ORG_EXT T12
WHERE
T12.BU_ID = T4.ROW_ID (+) AND
T12.PR_CON_ID = T2.ROW_ID (+) AND
T12.ROW_ID = T7.OU_ID AND
T12.ROW_ID = T11.PAR_ROW_ID (+) AND
T12.ROW_ID = T6.PAR_ROW_ID (+) AND
T12.ROW_ID = T9.PAR_ROW_ID (+) AND
T12.PR_INDUST_ID = T8.ROW_ID (+) AND
T12.PR_ADDR_ID = T1.ROW_ID (+) AND
T12.PR_POSTN_ID = T10.ROW_ID AND
T12.PR_POSTN_ID = T3.POSITION_ID AND
T12.ROW_ID = T3.OU_EXT_ID AND
T10.PR_EMP_ID = T5.ROW_ID (+) AND
(T12.X_BMO_CUST_FLG = 'Y') AND
(T7.NAME IS NULL );
***** SQL Statement Execute Time: 31.703 seconds *****
I do a explain plan and found the table S_ORG_EXT (T12)
get a full table scan.
But I found the table S_ORG_EXT did have lots of indexes
build on each column shown in the where statement.
Our database use RULE base optimizer and it should use
index instead of full table scan.
Then, I look at this SQL and realize it is a star query.
One more thing is that the table S_ORG_SYN (T7) defined
the column NAME as NOT NULL. If the query process, it
should return no row.
But I still don't know for what reason the Oracle use
full table scan and ignore the S_ORG_SYN.NAME should be
NOT NULL
If I want to avoid the full table scan, how can I do by
not switching to COST base optimizer mode ?
Thanks,
Ke

Michael:
A nice explanantion. In my experience, in versions up to 8.1.7, the RBO seems to be faster in the large majority of queries than the CBO. In our payroll application (version 8.0.5), removing statistics cut the time for the calculation run from 6.5 hours to under 2.
The CBO seems to be significantly faster in 9i. We only have one application currently running in a 9.0.1 database. In this app, a large stored procedure took about 2 minutes to run when there were no statistics, and about 10 seconds after we analyzed the tables.
As more of our vendors migrate to 9 (we just got the last vendor migrated off 7.3 to 8.0.6 a couple of months ago), I may become a bigger fan of the CBO. John,
I remember having a discussion with you about the CBO in a thread once and am aware of your opinion of the CBO. My opinion has been test which works for you RBO or CBO - in our case we verified that CBO worked better for us. Anyway, I was searching metalink and it looks like you'll be forced to become a "bigger fan" of the CBO after 9i release 2. This is from part of Doc ID 189702.1 on metalink:
The rule-based optimizer (RBO) will be no longer be a valid optimization choice when Oracle9i is de-supported. The release after Oracle9i
(referred to in this article as Oracle10i) will only support the cost-based optimizer (CBO). Hence Oracle9i Release 2 is the last releases to
contain the RBO. Partners and customers should certify their applications with the CBO before that time.
...but of course Oracle has been warning people of the demise of the RBO for some time.
Al

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

Full Table Scan issue

Hi,
I have a two tables (TAB1, TAB2)
I wrote a SQL query on these two tables and included other tables..
Col1 & Col2 in TAB1 defined as Char(8)
Col1 & Col2 in TAB2 defined as VarChar(8)
in the query where clause I wrote like
TAB2.Col1 = TRIM(TAB1.Col1)
and TAB2.Col1 = TRIM(TAB1.Col2)
Problem: If I add TRIM(), it is doing a full table scan and query is very very slow..
How to fix this issue?
Thanks

Sorry, I am not giving full details here.. but here is some info..
(11) TABLE ACCESS FULL TAB1 [Analyzed]
(11) Blocks: 430 Est. Rows: 62,770 of 62,770 Cost: 67
(19) TABLE ACCESS FULL STAT_ONE [Analyzed]
(19) Blocks: 821 Est. Rows: 53,580 of 53,580 Cost: 63
Index? U mean on COL1 & COL2? no idea I will find out..
Thanks

Function based indexes doing full table scan

Guys,
I am testing function based indexes and whatever I do
it is doing a full table scan.
1)I have set the following init parameters as
QUERY_REWRITE_ENABLED=TRUE
QUERY_REWRITE_INTEGRITY=TRUSTED
2)CREATE INDEX i3 ON emp(UPPER(ename));
3) ANALYZE TABLE emp COMPUTE STATISTICS
ANALYZE INDEX I3 COMPUTE STATISTICS
4) DELETE plan_table;
5) EXPLAIN PLAN SET statement_id='Test1' FOR
SELECT ename FROM emp WHERE UPPER(ename) = 'KING';
6) SELECT LPAD(' ',2*level-2)||operation||' '||options||' '||object_name
query_plan
FROM plan_table
WHERE statement_id='Test1'
CONNECT BY prior id = parent_id
START WITH id = 0 order by id
7) And the query plan shows as
SELECT STATEMENT
TABLE ACCESS FULL EMP
I am using 9.0.1.4 !!!
Any help is appreciated !!!
Regards,
A.Kishore

One of the many new features in Oracle 8i is the Function-Based Index (we will refrain from using FBI, but only just). This allows the DBA to create indexes on functions or expressions; these functions can be user generated pl/sql functions, standard SQL functions (non-aggregate only) or even a C callout.
A classic problem the DBA faces in SQL Tuning is how to tune those queries that use function calls in the where clause, and result in indexes created on these columns not to be used.
Example
Standard B-Tree index on SURNAME with cost based optimizer
create index non_fbi on sale_contacts (surname);
analyze index non_fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'SALES_CONTACTS' (Cost=3 Card=16 Bytes=272)
Now we use a function based index
create index fbi on sale_contacts (UPPER(surname));
analyze index fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'FBI' (NON-UNIQUE) (Cost=2 Card=381 Bytes=6477)
The function-based index has forced the optimizer to use index range scans (retuning zero or more rowids) on the surname column rather than doing a full table scan (non-index lookup). Optimal performance does vary depending on table size, uniqueness and selectivity of columns, use of fast full table scans etc. Therefore try both methods to gain optimal performance in your database.
It is important to remember that the function-based B*Tree index does not store the expression results in the index but uses an "expression tree". The optimizer performs expression matching by parsing the expression used in the SQL statement and comparing the results against the expression-tree values in the function-based index. This comparison IS case sensitive (ignores spaces) and therefore your function-based index expressions should match expressions used in the SQL statement where clauses.
Init.ora Parameters
The following parameter must be set in your parameter file: QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
Grants
Grants To create function-based indexes the user must be granted CREATE INDEX and QUERY REWRITE, or alternatively be granted CREATE ANY INDEX and GLOBAL QUERY REWRITE. The index owner must have EXECUTE access on the function used for the index. If execute access is revoked then the function-based index will be "disabled" (see dba_indexes).
Disabled Indexes
If your function-based index has a status of "disabled" the DBA can do one of the following:
a) drop and create the index (take note of its current settings)
b) alter index enable, function-based indexes only, also use disable keyword as required
c) alter index unusable.
Queries on a DISABLED index fail if the optimizer chooses to use the index.Here is an example ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
All DML operations on a DISABLED index also fail unless the index is also marked UNUSABLE and the initialization parameter SKIP_UNUSABLE_INDEXES is set to true.
Some more Examples
CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
..or a composite index..
CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = 'JONES';
Restriction & Rule Summary
The following restrictions apply to function based indexes. You may not index:
a) LOB columns
b) REF
c) Nested table column
d) Objects types with any of the above data types.
Function-based indexes must always follow these rules:
a) Cost Based optimizer only, must generate statistics after the index is created
b) Can not store NULL values (function can not return NULL under any circumstance)
c) If a user defined pl/sql routine is used for the function-based index, and is invalidated, the index will become "disabled"
d) Functions must be deterministic (always return the same value for a known input)
e) The index owner must have "execute" access on function used in the function-based index. Revocation of the privilege will render the index "disabled"
f) May have a B-Tree and Bitmap index type only
g) Can not use expressions that are based on aggregate functions, ie. SUM, AVG etc.
h) To alter a function-based index as enabled, the function used must be valid, deterministic and the signature of the function matches the signature of the function when it was created.
Joel P�rez

Does Table Statistics collection have any effect on Full Table scan

We are using SQL Parallelism in Oracle 10g 10.2.0.4 (3 node RAC ).Most of the the big tables are going for FTS.
And these Table are truncated and loaded inside procedures and then used in next procedures in SELECT query.
As there is no stats or stale STATS available , does this affect the FTS performance.

Well, typically, it's a good idea to have up to date stats on your tables, so that the Optimiser has an idea what data is in the tables and can determine if an index or a full table scan is the best method of access. It doesn't necessarily remove full table scans, and a FTS is not necessarily a bad thing, but having up to date stats let's the optimiser choose what's best, based on the data, rather than making a wrong decision.

Avod full table scan help...

HI ,
I have sql with some filter and all the have index. the table size is huge index is there in explain plan though index it's going for full table scan it's not recognizing index. i used index hint/*+ INDEX (SYM.SYM_DEPL,SYM.SYDB_DE_N18) */ though it's not recoginizing index in explian plan going for full table scan. and qury take more time.
please help to resolve the issue and it should recognize index rather than full table scan..

user13301356 wrote:
HI ,
I have sql with some filter and all the have index. the table size is huge index is there in explain plan though index it's going for full table scan it's not recognizing index. i used index hint/*+ INDEX (SYM.SYM_DEPL,SYM.SYDB_DE_N18) */ though it's not recoginizing index in explian plan going for full table scan. and qury take more time.
please help to resolve the issue and it should recognize index rather than full table scan..What is database version? Are all columns in the table indexed? Copy and paste the query that you are executing.

Pluggin container makes flash player crash. all is up to date. How to avoid this?

Question
pluggin container makes flash player crash. all is up to date. How to avoid this?

First, download and run the Flash uninstaller: [http://kb2.adobe.com/cps/141/tn_14157.html http://kb2.adobe.com/cps/141/tn_14157.html] . You probably want the 64-bit version. After that has run, restart your computer, and then let's download a fresh version of Flash. Try downloading and installing it from [http://fpdownload.macromedia.com/pub/flashplayer/current/licensing/win/install_flash_player_11_plugin_32bit.exe here].
Once you have flash installed again, start Firefox up, and see if you are getting any errors. If it works, awesome, if not, let's move on.
Start Firefox up in [[Safe Mode|Safe Mode ]] (don't select any of the checkboxes that appear). If Flash works here, then it is one of your addons which is causing a problem.
If we are still having a problem, try [[Updating your graphics driver|Updating your graphics driver]] .
If none of these work, read [[Troubleshooting plugins|Troubleshooting plugins]] and let me know!

How to avoid this full table scan (and index FFS) ?

Similar Messages

Maybe you are looking for