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

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

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

Similar Messages

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

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

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

  • How can this query avoid full table scans?

    It is difficult to avoid full table scans in the following query because the values of column STATUS reiterant numbers. There are only 10 numbers values for the STATUS column (1..10)
    But the table is very large. there are more than 1 million rows in it. A full table scanning consumes too much time.
    How can this query avoid full table scans?
    Thank you
    SELECT SYNC,CUS_ID INTO V_SYNC,V_CUS_ID FROM CONSUMER_MSG_IDX
                      WHERE CUS_ID = V_TYPE_CUS_HEADER.CUS_ID AND
                            ADDRESS_ID = V_TYPE_CUS_HEADER.ADDRESS_ID AND
                            STATUS =! 8;Edited by: junez on Jul 23, 2009 7:30 PM

    Your code had an extra AND. I also replaced the "not equal" operator, which has display problems with the forum software
    SELECT SYNC,CUS_ID
       INTO V_SYNC,V_CUS_ID
      FROM CONSUMER_MSG_IDX
    WHERE CUS_ID = V_TYPE_CUS_HEADER.CUS_ID AND
           ADDRESS_ID = V_TYPE_CUS_HEADER.ADDRESS_ID AND
           STATUS != 8;Are you sure this query is doing a table scan? Is there an index on CUS_ID, ADDRESS_ID? I would think that would be mostly unique. So I'm not sure why you think the STATUS column is causing problems. It would seem to just be a non-selective additional filter.
    Justin

  • Is it really another error about full table scans for small tables....?????

    Hi ,
    I have posted the following :
    Full Table Scans for small tables... in Oracle10g v.2
    and the first post of Mr. Chris Antognini was that :
    "I'm sorry to say that the documentation is wrong! In fact when a full table scan is executed, and the blocks are not cached, at least 2 I/O are performed. The first one to get the header block (where the extent map is stored) and the second to access the first and, for a very small table, only extent."
    Is it really wrong....????
    Thanks...
    Sim

    Fredrik,
    I do not say in any way that the documentation in this point is wrong.....
    In my first post , i have inserted a link to a thread made in another forum:
    Full Table Scans for small tables... in Oracle10g v.2
    Christian Antognini has written that the documentation is wrong....
    I'm sorry to say that the documentation is wrong!
    In fact when a full table scan is executed, and the
    blocks are not cached, at least 2 I/O are performed. The
    first one to get the header block (where the extent map
    is stored) and the second to access the first and, for a
    very small table, only extent.I'm just wondering if he has right......!!!!!!!
    Thanks..
    Sim

  • Avoid Full table scan

    Hi,
    My Query generation needs to be fine tuned. There are several queries generated that force full table scans of large tables. My question over here is whether functions and decodes need to be removed so that the queries take full advantage of the indexes on the table? I have used decode, Sum, case functions. So does it forces a full table scan of item price table (> 200 million records) as many times I have used these functions?
    How can I optimized it in more better way?

    How to see execution plan? Is it like explain plan you are saying? Can you please brief me on same.
    My query is
    Select S_ACCT_INFO.CUST_ACCT_NAM as CUST_ACCT_NAM,
           S_SLS_CRMEM_ITEM.CUST_ACCT_ID as CUST_ACCT_ID,
           S_SLS_CRMEM_ITEM.CUST_CNTRC_ID as CUST_CNTRC_ID,
           S_MCK_ITEM.GNRC_ID as GNRC_ID,
           S_MCK_ITEM.GNRC_NAM as GNRC_NAM,
           S_MCK_ITEM.SELL_DSCR_TXT as SELL_DSCR_TXT,
           S_MCK_ITEM.ITEM_STAT_CD_DSPSTN as ITEM_STAT_CD_DSPSTN,
           S_MCK_ITEM.RETL_LBL_CNT as RETL_LBL_CNT,
           S_MCK_ITEM.LBL_NAM as LBL_NAM,
           S_MCK_ITEM.MFG_SIZ_QTY as MFG_SIZ_QTY,
           S_SLS_CRMEM_ITEM.EM_ITEM_NUM as EM_ITEM_NUM,
           S_MCK_ITEM.NDC_NUM as NDC_NUM,
           S_MCK_ITEM.SPLR_ITEM_SEQ_NUM as SPLR_ITEM_SEQ_NUM,
           S_MCK_ITEM.SPLR_ACCT_NAM as SPLR_ACCT_NAM,
           S_MCK_ITEM.SPLR_ACCT_ID as SPLR_ACCT_ID,
           S_MCK_ITEM.UPC_NUM as UPC_NUM,
           S_IW_CNTRC_LEAD.CNTRC_LEAD_NAM as CNTRC_LEAD_NAM,
           DECODE(S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID, NULL, 'N', 'Y') CNTRC_IND_HIST,
           S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID as CNTRC_LEAD_TP_ID,
           S_SLS_CRMEM_ITEM.SLS_DOC_NUM as SLS_DOC_NUM,
           SUM(S_SLS_CRMEM_ITEM.SLS_AMT) INV_EXT_PRC_3,
           S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT as SLS_PROC_WRK_DT,
           CASE
             WHEN S_SLS_CRMEM_ITEM.GRS_SLS_QTY <> 0 THEN
              ROUND(S_SLS_CRMEM_ITEM.GRS_SLS_AMT / S_SLS_CRMEM_ITEM.GRS_SLS_QTY,
                    2)
             ELSE
              0
           END INV_PRC_PKG_2,
           SUM(S_SLS_CRMEM_ITEM.SLS_QTY) NET_QTY_3,
           S_SLS_CRMEM_ITEM.CUST_PO_NUM as CUST_PO_NUM,
           CASE
             WHEN S_SLS_CRMEM_ITEM.CUST_OMIT_IND IN
                  ('L', 'U', 'R', 'F', 'A', 'X') THEN
              SUM(S_SLS_CRMEM_ITEM.ORDR_QTY - S_SLS_CRMEM_ITEM.GRS_SLS_QTY)
             ELSE
              0
           END QTY_OMTD_MUS_1,
           S_ACCT_INFO.NATL_SUB_GRP_CD as NATL_SUB_GRP_CD,
           S_ACCT_INFO.CUST_STOR_NUM as CUST_STOR_NUM,
           S_MCK_ITEM.PKG_SIZ as PKG_SIZ,
           SUM(S_SLS_CRMEM_ITEM.GRS_SLS_QTY) INV_QTY_1,
           SUM(S_SLS_CRMEM_ITEM.ORDR_QTY) ORDR_QTY_2,
           SUM(S_SLS_CRMEM_ITEM.ORDR_QTY - S_SLS_CRMEM_ITEM.GRS_SLS_QTY) QTY_OMTD_1,
           SUM(S_SLS_CRMEM_ITEM.GRS_RTN_QTY) RTRN_QTY_1
      from S_SLS_CRMEM_ITEM
      LEFT OUTER JOIN S_MCK_ACCT_ITEM_PRC ON (S_SLS_CRMEM_ITEM.CUST_ACCT_ID =
                                             S_MCK_ACCT_ITEM_PRC.CUST_ACCT_ID AND
                                             S_SLS_CRMEM_ITEM.EM_ITEM_NUM =
                                             S_MCK_ACCT_ITEM_PRC.ITEM_NUM)
      LEFT OUTER JOIN S_ACCT_CNTRC_LEAD_TYP ON (S_MCK_ACCT_ITEM_PRC.CUST_ACCT_ID =
                                               S_ACCT_CNTRC_LEAD_TYP.CUST_ACCT_ID AND
                                               S_MCK_ACCT_ITEM_PRC.CNTRC_LEAD_ID =
                                               S_ACCT_CNTRC_LEAD_TYP.CNTRC_LEAD_ID)
      LEFT OUTER JOIN S_IW_CNTRC_LEAD ON (S_MCK_ACCT_ITEM_PRC.CNTRC_LEAD_ID =
                                         S_IW_CNTRC_LEAD.CNTRC_LEAD_ID)
    INNER JOIN S_ACCT_INFO ON (S_SLS_CRMEM_ITEM.CUST_ACCT_ID =
                               S_ACCT_INFO.CUST_ACCT_ID)
      LEFT OUTER JOIN S_VA_CUST_CNTRC ON (S_SLS_CRMEM_ITEM.CUST_ACCT_ID =
                                         S_VA_CUST_CNTRC.CUST_ACCT_ID AND
                                         S_SLS_CRMEM_ITEM.EM_ITEM_NUM =
                                         S_VA_CUST_CNTRC.ITEM_NUM)
    INNER JOIN S_MCK_ITEM ON (S_SLS_CRMEM_ITEM.EM_ITEM_NUM =
                              S_MCK_ITEM.EM_ITEM_NUM)
    where ((((((((S_SLS_CRMEM_ITEM.CUST_ACCT_ID in ('110718') or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000001')) or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000002')) or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000003')) or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000005')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000001')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000002')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000003')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000005'))
       and S_MCK_ITEM.SPLR_ACCT_ID IN
           ('34227', '34232', '34233', '34228', '34229', '34230', '34231',
            '34235', '34236', '78063', '84230', '90014', '98014')
       and (S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT between
           to_date('04/01/2007', 'MM/DD/YYYY') and
           to_date('06/30/2007', 'MM/DD/YYYY'))
    GROUP BY S_ACCT_INFO.CUST_ACCT_NAM,
              S_SLS_CRMEM_ITEM.CUST_ACCT_ID,
              S_SLS_CRMEM_ITEM.CUST_CNTRC_ID,
              S_MCK_ITEM.GNRC_ID,
              S_MCK_ITEM.GNRC_NAM,
              S_MCK_ITEM.SELL_DSCR_TXT,
              S_MCK_ITEM.ITEM_STAT_CD_DSPSTN,
              S_MCK_ITEM.RETL_LBL_CNT,
              S_MCK_ITEM.LBL_NAM,
              S_MCK_ITEM.MFG_SIZ_QTY,
              S_SLS_CRMEM_ITEM.EM_ITEM_NUM,
              S_MCK_ITEM.NDC_NUM,
              S_MCK_ITEM.SPLR_ITEM_SEQ_NUM,
              S_MCK_ITEM.SPLR_ACCT_NAM,
              S_MCK_ITEM.SPLR_ACCT_ID,
              S_MCK_ITEM.UPC_NUM,
              S_IW_CNTRC_LEAD.CNTRC_LEAD_NAM,
              DECODE(S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID, NULL, 'N', 'Y'),
              S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID,
              S_SLS_CRMEM_ITEM.SLS_DOC_NUM,
              S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT,
              CASE
                WHEN S_SLS_CRMEM_ITEM.GRS_SLS_QTY <> 0 THEN
                 ROUND(S_SLS_CRMEM_ITEM.GRS_SLS_AMT /
                       S_SLS_CRMEM_ITEM.GRS_SLS_QTY,
                       2)
                ELSE
                 0
              END,
              S_SLS_CRMEM_ITEM.CUST_PO_NUM,
              S_SLS_CRMEM_ITEM.CUST_OMIT_IND,
              S_ACCT_INFO.NATL_SUB_GRP_CD,
              S_ACCT_INFO.CUST_STOR_NUM,
              S_MCK_ITEM.PKG_SIZ
    order by S_MCK_ITEM.NDC_NUM               asc,
              S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT asc,
              S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT asc

  • Full Table Scans for small tables... in Oracle10g v.2

    Hi,
    The Query optimizer may select to do a full table scan instead of an index scan when the table is small (it consists of blocks the number of which is less than the the value of db_file_multiblock_read_count).
    So , i tried to see it using the dept table......
    SQL> select blocks , extents , bytes from USER_segments where segment_name='DEPT';
        BLOCKS    EXTENTS      BYTES
             8          1      65536
    SQL> SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT;
    NAME                                 TYPE        VALUE
    db_file_multiblock_read_count        integer     16
    SQL> explain plan for SELECT * FROM DEPT
      2    WHERE DEPTNO=10
      3  /
    Explained
    SQL>
    SQL>  select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 2852011669
    | Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Tim
    |   0 | SELECT STATEMENT            |         |     1 |    23 |     1   (0)| 00:
    |   1 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    23 |     1   (0)| 00:
    |*  2 |   INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:
    Predicate Information (identified by operation id):
       2 - access("DEPTNO"=10)
    14 rows selectedSo , according to the above remarks
    What may be the reason of not performing full table scan...????
    Thanks...
    Sim

    No i have not generalized.... In the Oracle's extract
    i have posted there is the word "might".....
    I just want to find an example in which selecting
    from a small table... query optimizer does perform a
    full scan instead of a type of index scan...Sorry for that... I don't mean to be rude :)
    See following...
    create table index_test(id int, name varchar2(10));
    create index index_test_idx on index_test(id);
    insert into index_test values(1, 'name');
    commit;
    -- No statistics
    select * from index_test where id = 1;
    SELECT STATEMENT ALL_ROWS-Cost : 3
      TABLE ACCESS FULL MAXGAUGE.INDEX_TEST(1) ("ID"=1)
    -- If first rows mode?
    alter session set optimizer_mode = first_rows;
    select * from index_test where id = 1;
    SELECT STATEMENT FIRST_ROWS-Cost : 802
      TABLE ACCESS BY INDEX ROWID MAXGAUGE.INDEX_TEST(1)
       INDEX RANGE SCAN MAXGAUGE.INDEX_TEST_IDX (ID) ("ID"=1)
    -- If statistics is gathered
    exec dbms_stats.gather_table_stats(user, 'INDEX_TEST', cascade=>true);
    alter session set optimizer_mode = first_rows;
    select * from index_test where id = 1;
    SELECT STATEMENT ALL_ROWS-Cost : 2
      TABLE ACCESS BY INDEX ROWID MAXGAUGE.INDEX_TEST(1)
       INDEX RANGE SCAN MAXGAUGE.INDEX_TEST_IDX (ID) ("ID"=1)
    alter session set optimizer_mode = all_rows;
    select * from index_test where id = 1;
    SELECT STATEMENT ALL_ROWS-Cost : 2
      TABLE ACCESS BY INDEX ROWID MAXGAUGE.INDEX_TEST(1)
       INDEX RANGE SCAN MAXGAUGE.INDEX_TEST_IDX (ID) ("ID"=1) See some dramatic changes by the difference of parameters and statistics?
    Jonathan Lewis has written a great book on cost mechanism of Oracle optimizer.
    It will tell almost everything about your questions...
    http://www.amazon.com/Cost-Based-Oracle-Fundamentals-Jonathan-Lewis/dp/1590596366/ref=sr_1_1?ie=UTF8&s=books&qid=1195209336&sr=1-1

  • Slow query due to large table and full table scan

    Hi,
    We have a large Oracle database, v 10g. Two of the tables in the database have over one million rows.
    We have a few queries which take a lot of time to execute. Not always though, it that seems when load is high the queries tend
    to take much longer. Average time may be 1 or 2 seconds, but maxtime can be up to 2 minutes.
    We have now used Oracle Grid to help us examine the queries. We have found that some of the queries require two or three full table scans.
    Two of the full table scans are of the two large tables mentioned above.
    This is an example query:
    SELECT table1.column, table2.column, table3.column
    FROM table1
    JOIN table2 on table1.table2Id = table2.id
    LEFT JOIN table3 on table2.table3id = table3.id
    WHERE table1.id IN(
    SELECT id
    FROM (
    (SELECT a.*, rownum rnum FROM(
    SELECT table1.id
    FROM table1,
    table2,
    table3
    WHERE
    table1.table2id = table2.id
    AND
    table2.table3id IS NULL OR table2.table3id = :table3IdParameter
    ) a
    WHERE rownum <= :end))
    WHERE rnum >= :start
    Table1 and table2 are the large tables in this example. This query starts two full table scans on those tables.
    Can we avoid this? We have, what we think are, the correct indexes.
    /best regards, Håkan

    >
    Hi Håkan - welcome to the forum.
    We have a large Oracle database, v 10g. Two of the tables in the database have over one million rows.
    We have a few queries which take a lot of time to execute. Not always though, it that seems when load is high the queries tend
    to take much longer. Average time may be 1 or 2 seconds, but maxtime can be up to 2 minutes.
    We have now used Oracle Grid to help us examine the queries. We have found that some of the queries require two or three full table scans.
    Two of the full table scans are of the two large tables mentioned above.
    This is an example query:Firstly, please read the forum FAQ - top right of page.
    Please format your SQL using tags [code /code].
    In order to help us to help you.
    Please post table structures - relevant (i.e. joined, FK, PK fields only) in the form - note use of code tags - we can just run table create script.
    CREATE TABLE table1
      Field1  Type1,
      Field2  Type2,
    FieldN  TypeN
    );Then give us some table data - not 100's of records - just enough in the form
    INSERT INTO Table1 VALUES(Field1, Field2.... FieldN);
    ..Please post EXPLAIN PLAN - again with tags.
    HTH,
    Paul...
    /best regards, Håkan

  • Full table scans

    Dear all,
    While doing a stress testing I found that there was a lot a full table scans due to which there was preformance drop. How can I avoid full table scans. Please suggest some ways as I am in clients place.
    Waiting for your help.
    Regards and thanks in advance
    SL

    Hi SL,
    How can I avoid full table scansFull table scans are not always bad! It depends foremost on your optimizer goal (all_rows vs. first_rows), plus your multiblock read count, table size, percentage of rows requested, and many other factors.
    Here are my notes:
    http://www.dba-oracle.com/art_orafaq_oracle_sql_tune_table_scan.htm
    To avoid full table scans, start by running plan9i.sql and then drill-in and see if you have missing indexes:
    http://www.dba-oracle.com/t_plan9i_sql_full_table_scans.htm
    You can also run the 10g SQLTuning advisor to find missing indexes, and also, don't forget to consider function-based indexes, a great way to eliminate unncessary lage-table full-table scans:
    http://www.dba-oracle.com/oracle_tips_index_scan_fbi_sql.htm
    Hope this helps. . .
    Donald K. Burleson
    Oracle Press author

  • Full Table Scans on Auto Ship Confirm Report (WSHRDASC) Causing

    Severe performance issue with Auto Ship Confirm report WSHRDASC.
    From the statspack reports, a single sql statement that iscurrently consuming approximately 50% of all physical disk I/O.
    2 full table scans coming from this problem query :-
    Rows Row Source Operation
    SORT ORDER BY
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    TABLE ACCESS FULL WSH_NEW_DELIVERIES
    TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS
    INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 (object id 81392)
    TABLE ACCESS BY INDEX ROWID HZ_PARTIES
    INDEX UNIQUE SCAN HZ_PARTIES_U1 (object id 172682)
    TABLE ACCESS BY INDEX ROWID WSH_EXCEPTIONS
    INDEX RANGE SCAN WSH_EXCEPTIONS_N9 (object id 133587)
    TABLE ACCESS BY INDEX ROWID WSH_DELIVERY_LEGS
    INDEX RANGE SCAN WSH_DELIVERY_LEGS_N1 (object id 46224)
    TABLE ACCESS BY INDEX ROWID WSH_DOCUMENT_INSTANCES
    INDEX RANGE SCAN WSH_DOCUMENT_INSTANCES_N1 (object id 46405)
    TABLE ACCESS FULL WSH_PICKING_BATCHES
    TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES
    INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (object id 34010)
    Please help i have applied one patch for this issue Patch 5531283. Then also same issue

    Hi;
    WHat is your EBS version?
    If note Full Table Scans on Auto Ship Confirm Report (WSHRDASC) Causing Performance Issues [ID 393014.1] doesnt help than I suggest rise SR
    Regard
    Helios

  • Full table scan

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

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

  • SIDs for Full table scan wait events in db

    Guys,
    10.2.0.5/ 2 node RAC / RHEL-3
    CanAnyone provide me an sql to find all SID doing full table scans in a db?
    Thanks!
    Hari

    You ought to be able to query v$sql_plan for those sql plans with a full scan in them and if you want all the recent plans that contain a full table scan in them. You can join this back to v$session for those session currently executing a full table scan but if the sql in question was a previous statement executed by the session the join will not show the session because that statement is no longer the current statement.
    1 select p.sql_id, s.sid, p.object_name, p.operation, p.options
    2 from v$sql_plan p, v$session s
    3 where p.options like '%FULL%'
    4* and s.sql_id = p.sql_id
    You will probably want to filter out internal operations (operation = "FIXED TABLE")
    HTH -- Mark D Powell --

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

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

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

  • 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.

  • 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.

  • 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

Maybe you are looking for