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

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 to Reduce cost of full table scan or remove full table scan while execu

Dear Experts
need your help.
I execute a query and create a explain plan in that plan i found cost of a table is very high (2777) and it was full table scan.
Please guide me How to Reduce cost of full table scan or remove full table scan while execute the query.
Thanks

Need your help to tune this query..
SELECT DISTINCT ool.org_id, ool.header_id, ooh.order_number, ool.line_id,
ool.line_number, ool.shipment_number,
NVL (ool.option_number, -99) option_number, xcl.GROUP_ID,
xcl.attribute3, xcl.attribute4
FROM oe_order_headers ooh,
xxcn_comp_header xch,
xxcn_comp_lines xcl,
fnd_lookup_values_vl fvl,
oe_order_lines ool
WHERE 1 = 1
AND ooh.org_id = 1524
AND xch.src_ref_no = TO_CHAR (ooh.order_number)
AND xch.src_ref_id = ooh.header_id
AND xch.org_id = 1524
AND xcl.header_id = xch.header_id
AND ool.line_id = xcl.oe_line_id
AND ool.flow_status_code IN
('WWD_SHIPPED',
'FULFILLED',
'SHIPPED',
'CLOSED',
'RETURNED'
AND ool.org_id = 1524
AND ool.header_id = ooh.header_id
AND xch.org_id = 1524
AND fvl.lookup_type = 'EMR OIC SOURCE FOR OU'
AND fvl.tag = '1524'
AND fvl.description = xch.SOURCE
AND EXISTS (
SELECT 1
FROM oe_order_lines oe
WHERE oe.header_id = ool.header_id
AND oe.org_id = 1524
AND oe.line_number = ool.line_number
AND oe.ordered_item = ool.ordered_item
AND oe.shipment_number > ool.shipment_number
AND NVL (oe.option_number, -99) =
NVL (ool.option_number,
-99)
AND NOT EXISTS (
SELECT 1
FROM xxcn_comp_lines xcl2
WHERE xcl.GROUP_ID = xcl2.GROUP_ID
AND oe.line_id = oe_line_id))
call count cpu elapsed disk query current rows
Parse 1 0.07 0.12 12 25 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 103.03 852.42 176206 4997766 0 12
total 4 103.10 852.55 176218 4997791 0 12
In this LIO is very high...can u please help in resolving this performance issue

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');

Finding the Text of SQL Query causing Full Table Scans

Hi,
does anyone have a sql script, that shows the complete sql text of queries that have caused a full table scan?
Please also let me know as to how soon this script needs to be run, in the sense does it work only while the query is running or would it work once it completes (if so is there a valid duration, such as until next restart, etc.)
Your help is appreciated.
Thx,
Mayuran

Finding the Text of SQL Query Causing Full Table Scan

Finding the Text of SQL Query Causing Full Table Scan

Hi,
does anyone have a sql script, that shows the complete sql text of queries that have caused a full table scan?
Please also let me know as to how soon this script needs to be run, in the sense does it work only while the query is running or would it work once it completes (if so is there a valid duration, such as until next restart, etc.)
Your help is appreciated.
Thx,
Mayuran

You might try something like this:
select sql_text,
       object_name
from   v$sql s,
       v$sql_plan p
where s.address = p.address and
       s.hash_value = p.hash_value and
       s.child_number = p.child_number and
       p.operation = 'TABLE ACCESS' and
       p.options = 'FULL' and
       p.object_owner in ('SCOTT')
;Please note that this query is just a snapshot of the SQL statements currently in the cache.

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

Query doing full table scan

Hai all,
10.2.0.4 on solaris 10
SELECT sum(RechargeForPrepaid/10000), to_date(substr (TIMESTAMP, 1,8),'YYYY/MM/DD')
FROM medt.crm_t WHERE to_date(substr (TIMESTAMP, 1,8),'YYYY/MM/DD') >= trunc(sysdate)-1 and tradetype != '0' group by to_date(substr (TIMESTAMP, 1,8),'YYYY/MM/DD');The explain shows that it performs a full table scan on crm_t . I created indexes on the column
timestamp and tradetype too . collected stats too. but still it is doing a full table scan.
Please guide
Thanks
Kai

sybrand_b wrote:
The column is wrongly named --> timestamp is a reserved word.True:
SQL> select * from v$reserved_words where keyword = 'TIMESTAMP'
2 /
KEYWORD                                                              LENGTH
TIMESTAMP                                                                 9
1 row selected.
It is also of the wrong type--> dates shouldn't be stored as varchar2.All we know, is that the column is treated as if it is a VARCHAR2. It doesn't have to be a varchar2, because he might be relying on some implicit datatype conversion.
The design of this table is a complete mess.
Drop it and redesign.You'd better tell that to Oracle as well then :-) :
SQL> desc user_objects
Name                                                                      Null?    Type
OBJECT_NAME                                                                        VARCHAR2(128)
SUBOBJECT_NAME                                                                     VARCHAR2(30)
OBJECT_ID                                                                          NUMBER
DATA_OBJECT_ID                                                                     NUMBER
OBJECT_TYPE                                                                        VARCHAR2(18)
CREATED                                                                            DATE
LAST_DDL_TIME                                                                      DATE
TIMESTAMP                                                                          VARCHAR2(19)
STATUS                                                                             VARCHAR2(7)
TEMPORARY                                                                          VARCHAR2(1)
GENERATED                                                                          VARCHAR2(1)
SECONDARY                                                                          VARCHAR2(1)My point is that the TIMESTAMP datatype was introduced in version 9, and versions prior to that were free to use the name "TIMESTAMP". And all those older applications still function. A redesign would be ideal, but maybe not economically feasible. Oracle certainly didn't choose a redesign.
If you are going to build a new application, then I agree that you'd better not use that reserved word anymore.
Regards,
Rob.

Convert PDF to Word - Tables are in Text Boxes using Acrobat 11. How can this be avoided?

Hello All,
I am using Acrobat 11 to convert PDF's to MS Word .doc or .docx. The tables are converted correctly but they are inside Text Boxes. My documents have hundreds of tables and I cant manually remove the text boxes.
Is there a way to remove the Text Box that contains each table?
Regards Paul

Hello Anubha,
My apologies. Hopefully you can see the table is inside a text box. The Acrobat 7 doesn't behave like this, nor do some of the other PDF conversion products.
In my output there is 700 pages with average of 3 tables per page. A manual workaround to get the tables out of the text boxes wouldn't be practicable.
Can you confirm that this is not the expected behaviour. I thought I recently saw a video showing this behaviour as standard for Acrobat 11.
Regards Paul

We have an Iplanet 4.1 in front of an app server; request of the form .../?option=� fail with "Bad Request" if they contain a Spanish character... how can this be avoided?.

If we issue the request to the app server directly it does not fail; the web server is intercepting the request.

Hi,
Are you running iWS 4.x(SP3-SP5) version of iWS. If so the iWS 4.x strictly enforces US-ASCII requirements of the HTTP RFC and does not allow non-ascii characters in the field of a HTTP header.
There is a temporary workaround to relax the restriction on HTTP headers to non ASCII characters, Please add the following line to your web server magnus.conf file:
StrictHttpHeaders off
Please make sure that after changeing the values in magnus.conf file you restarted the iWS, for new changes take effect. The above workaround will work otherwise, you would need to write your own NSAPI code to scrub the HTTP headers for any non
US-ascii characters.
Hope this helps.
Regards,
Dakshin.
Developer Technical Support
Sun Microsystems
http://www.sun.com/developers/support.

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

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

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

Query is doing full table scan

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

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

Trunc causing Full Table Scans

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

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

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

Why full index scan is faster than full table scan?

Hi friends,
In the where clause of a query,if we give a column that contains index on it,then oracle uses index to search data rather than a TABLE ACCESS FULL Operation.
Why index searching is faster?

Sometimes it is faster to use index and sometimes it is faster to use full table scan. If your statistics are up to date Oracle is far more likely to get it right. If the query can be satisfied entirely from the index, then an index scan will almost always be faster as there are fewer blocks to read in the index than there would be if the table itself were scanned. However if the query must extract data from the table when that data is not in te index, then the index scan will be faster only if a small percentage of the rows are to be returned. Consiter the case of an index where 40% of the rows are returned. Assume the index values are distributed evenly among the data blocks. Assume 10 rows will fit in each data block thus 4 of the 10 rows will match the condition. Then the average datablock will be fetched 4 times since most of the time adjacent index entries will not be in the same block. The number of single datablock fetches will be about 4 times the number of datablocks. Compare this to a full table scan that does multiblock reads. Far fewer reads are required to read the entire table. Though it depends on the number of rows per block, a general rule is any query returning more than about 10% of a table is faster NOT using an index.

How can this query avoid full table scans?

Similar Messages

Maybe you are looking for