Rewrite NVL/TRUNC to make index usage .

Hi,
I'm on 9.2.0.8 and got query like that
select * from table
where      
        TRUNC (SYSDATE) BETWEEN TRUNC (NVL (data_od, SYSDATE))
                       AND TRUNC (NVL (data_do, SYSDATE));Is there any better way I can rewrite this to make index on data_od data_do ubeing used ?
Regards
GregG

smart000 wrote:
select * from table
where      
        TRUNC (SYSDATE) BETWEEN TRUNC (NVL (data_od, SYSDATE))
AND TRUNC (NVL (data_do, SYSDATE));The requirement reflected by the sql seems odd (although it may be what u want) You want to check that that today's date should be between 2 date fields. But, If any of the 2 fields is null then you are replacing by today's date
1. data_od cannot be a future date
2. data_do cannot be a past date
3. if data_od = null and data_do = null then you are thru', not check required
4. if data_od = null then data_do has to be equal to trunc(sysdate) to satisfy the condition
Please check whether the above in relation to your requirement, it may prompt something to rewrite the query.It's basically saying show me everything where data_od and data_do are set to today or either are null.
4. if data_od = null then data_do has to be equal to trunc(sysdate) to satisfy the conditionThat's not correct. If data_od is null then trunc(sysdate) has to be <= trunc(sysdate) i.e. ignore the condition. Same is true (with >=) for data_do

Similar Messages

  • SQL INDEX USAGE

    hi,
    I have a procedure which took 15-20 minutes in the past to execute.Suddently it is taking 2 hours.When i examined i came to know that the sql statement is not using one of the index.I dropped the index and created it.The explain plan is generated but still the index is not being used.I forced the index usage by using the index hint
    SELECT /*+ INDEX(test_his test_hist_idx )*/ column 1.....
    But still it does not use the index.Please suggest me some advice on this?
    Thanks

    user589320 wrote:
    I have a procedure which took 15-20 minutes in the past to execute.Suddently it is taking 2 hours.When i examined i came to know that the sql statement is not using one of the index.I dropped the index and created it.The explain plan is generated but still the index is not being used.I forced the index usage by using the index hint
    SELECT /*+ INDEX(test_his test_hist_idx )*/ column 1.....
    I think you're going to have to post the entire text of your query if you want an answer, or people will simply be trying to guess what you've done wrong.
    Do you also have the full execution plan from before and after the change in performance ?
    If you do post the text, and plans, please use the 'code' tags to make the text readable.
    p.s. My shot in the dark guess, based on the text you've supplied, is that you've used the table name in the hint, rather than the table alias.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The temptation to form premature theories upon insufficient data is the bane of our profession."
    Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • UNUSED EXISTING INDEXES / Index usage

    We are using CRM 2007, Netweaver 7.0 with DB2 UDB v9.1 fixpack4 on AIX.
    Is there a way to find out  UNUSED EXISTING INDEXES for tables ? We have close 12 indexes on the crmd_order_index table and want to find out if some of them can safely deleted. Is there any way to monitor index usage in SAP ? Is there any toold to aid this ?
    Pls advise.
    thank you
    regards
    Laxmi

    Laxmi,
    I am not aware of any such tools with DB2 9.1.  However, "last_used" columns are being added to various catalog tables in DB2 9.7.  Below is an excerpt from a slide presented in the  TLU2008A "DB2 LUW V9.7 Cobra u2013 Storage is Charmed" session.
    The last reference time of an object will now be maintained in the LASTUSED column of
    the corresponding catalog table for the object
    u2013 SYSCAT.INDEXES.LASTUSED (prior to V9.7 db2pd u2013tcbstats indexes)
    u2013 SYSCAT.TABLES.LASTUSED
    u2013 SYSCAT.DATAPARTITIONS.LASTUSED
    u2013 SYSCAT.PACKAGE.LASTUSED
    The LASTUSED column is of type DATE (default value is 1/1/0001)
    Use Cases:
    u2013 Detach table partitions that are no longer actively used (esp. when not partitioned by time)
    u2013 Determine inactive or infrequently used indexes
    u2013 Easily identify tables which are no longer in use
    u2013 Get rid of unused packages
    The presenter said the code will begin populating these columns in an upcoming fixpack.
    Regards,
    Rick

  • 'IS NOT NULL' & Index Usage

    Hi,
    there are many queries my one of my packages, which has the SQL as follows:
    Update table XYZ
    Set Column A = NULL
    Where Colum B IS NOT NULL;
    Column B has NUMBER datatype.
    Due to 'IS NOT NULL' the index (existing for Column B' is not being used in the above query, leading to Full table scan. Is there any ways of forcing teh index to be picked/used by the query?
    Thanks,
    Rosalin

    thansk again for response. Checked the % of the data
    fetched by this query and it ranges from 20% to 50
    %(varies due to teh fact the table data content could
    have different set of data depending on the days
    transactions done). So for sure index usage would
    help.
    Additionally this sql(used in multiple places) come
    up in the v$longsops output.
    so definitely needs tuning.
    Any suggestions?That's not really true though if you understand the mechanisms employed for a full table scan vs an index scan / table lookup (by rowid since the table must also be visited).
    Here's something good for you to read
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4433887271030
    A full tablescan reads the table using large sequential reads -- many blocks at a time.
    Sequential reads are the fastest type of IO you can do on a disk in general.
    An index read will do single block, random IO's. These are generally the slowest you can
    do.
    I would suggest to you that if you have statistics on the table/indexes that are representative of the data, the Optimizer will be smarter than you (most cases, not all).
    Message was edited by:
    Tubby

  • LIKE, LIKEC and Index usage

    I've table that contains about 20 million rows, and I've created index for varchar2(100) column. It works well if I do
    SELECT * FROM MY_TABLE WHERE MY_COL LIKE 'FOO%';
    But if I change query to use LIKEC (to make unicode escaped strings work):
    SELECT * FROM MY_TABLE WHERE MY_COL LIKEC 'FOO%';
    I always get full table scan in explain plan.
    I tried to use NVARCHAR, or index created by TO_NCHAR but I always end up hitting full table scan.
    Should I create index some special way or do something else before I get index working?

    Just a gut feeling : is the database using character semantics or byte semantics?
    My gut feeling, after looking up the documentation, is it should be character semantics.
    BTW: Not posting version info decreases the chance you get an adequate reply.
    Sybrand Bakker
    Senior Oracle DBA

  • Index Usage

    Hi All,
    Using Oracle 11.2.0.3 on a TEST server
    create index emp_job_sal_idx on emp(job,sal) ;
    SQL> create or replace view test1 as select d.deptno, d.dname, e.empno, e.job, e.sal from dept d, emp e where d.deptno=e.deptno and
    (e.job='CLERK' and e.sal > 1000) OR
    (e.job='ANALYST' and e.sal >= 3000) OR
    (e.job='SALESMAN' and e.sal >=1500);
    SQL> set autotrace on explain
    SQL> select * from test1;
    18 rows selected.
    Execution Plan
    Plan hash value: 4192419542
    | Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time       |
    |   0 | SELECT STATEMENT   |       |     1 |    67 |    10   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS        |       |     1 |    67 |    10   (0)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| DEPT |     4 |    88 |     3   (0)| 00:00:01 |
    |*  3 |   TABLE ACCESS FULL| EMP  |     1 |    45 |     2   (0)| 00:00:01 |
    ---------------------------------------------------------------------------The index is not used, mostly due to a OR condition. How can we make the index use without using hints ?

    sb92075 wrote:
    post EXPLAIN PLAN for problem SQL
    Execution Plan
    Plan hash value: 3466901445
    | Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |             |     1 |   331 |   383K  (7)| 01:16:40 |
    |*  1 |  HASH JOIN         |             |     1 |   331 |   383K  (7)| 01:16:40 |
    |*  2 |   TABLE ACCESS FULL| ENT_TRAN|     1 |   165 |   205K  (9)| 00:41:07 |
    |   3 |   TABLE ACCESS FULL| ENT_MAST         |    19M|  3111M|   177K  (3)| 00:35:31 |
    1 - access(NLSSORT("ENT_MAST"."ID",'nls_sort=''BINARY_CI''')=NLSSORT(
                  "ENT_TRAN"."RID",'nls_sort=''BINARY_CI'''))
       2 - filter(NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'''
                  )=HEXTORAW('616D616E616820736168616D206E6173696F6E616C2062657268616400')
                  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('343
                  73435377600')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_C
                  I''')=HEXTORAW('74656E616761206E6173696F6E616C2062657268616400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3230303
                  836367700')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('74656C656B6F6D206D616C61797369612062657268616400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3132383
                  734307000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('6167726F2062616E6B00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3831313
                  831307500')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('6272756365206C656520796565206C616D00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3530333
                  333373100')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('616B6261722074726164696E6700')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3030313
                  438383037397500')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('372D656C6576656E206D616C61797369612073646E2062686400')
                    AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3
                  132303936327000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('6368616E20796F6B65206368656E6700')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3637303
                  532372D30362D3534393600')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('646B7368206D616C61797369612073646E2062686400')
                    AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3
                  030343437367500')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('626574746572207B267D206265737420656E746572707269736500
                  ')  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW(
                  '3030313632353132347000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('6C696D20656E672073696F65206A756E6B657400')
                  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('743
                  5353138393300')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY
                  _CI''')=HEXTORAW('712E712E206A756E6B657400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('7331373
                  233363200')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('6572206B696D206B656F6E6700')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3539303
                  932302D31302D3538333700')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('726963686C616E64206C6569737572652067726F757000
                  ')  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW(
                  '3538303532382D30312D3539383500')  OR
                  NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('74
                  69656E2079756E20656E74657270726973652073646E2E206268642E00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3637303
                  332382D31302D3534363700')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('73686172696B617420686F636B2068696E00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3030303
                  234323136397000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('6D7964696E206D6F68616D656420686F6C64696E67732062686420
                  28666F726D65726C79206B6E6F776E206173206D7964696E206D6F68616D656420686F6C64
                  696E67732073646E206268642900')  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_so
                  rt=''BINARY_CI''')=HEXTORAW('3232313434386100')  OR
                  NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('65
                  7665726973652076656E74757265732073646E2062686400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3239353
                  137377000')  OR NLSSORT("EN)
    Statistics
              1  recursive calls
              0  db block gets
        1353887  consistent gets
        1353339  physical reads
              0  redo size
        1204784  bytes sent via SQL*Net to client
           4989  bytes received via SQL*Net from client
            408  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
           6092  rows processed
    {code}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Index Usage in 9i changed  when used rownum

    Hi List,My Application is in RBO
    Here is one more brain twister ?
    Assume following I Have table SHRI with a single column
    COL I have created Index on COL column say IND_COL.
    Now when I run Following query on 8i with AUTOTRACE ON
    I can see that 8i Uses the Index IND_COL Clearly .
    select * from shri where (h_name='ABC' or h_name='BOM')
    or (h_name ='BOM' or h_name='MOM')
    and rownum=1
    select * from shri where (COL='ABC' or COL='BOM')
    or (COL='ABC' or COL='BOM')
    and rownum=1
    (Note:Above example is just for ur understanding plz.dont see the usage)
    Now my problem is when I see the explain plan for above query in 8i I can see that Query uses IND_COL .
    But when I run the same in 9i It does not uses IND_COL Index (Strange!!!) .
    However when I remove "and rownum=1" clause then It again uses the index in 9i.
    Assume that such queries are existing many places .
    I am badly stuck because of this problem can anybody suggest the best way (Other than changing RBO to CBO) ?
    Regards
    Sripad.

    Run below query, you will get all the details of tablespaces.
    col "Tablespace" for a22
    col "Used MB" for 99,999,999
    col "Free MB" for 99,999,999
    col "Total MB" for 99,999,999
    select df.tablespace_name "Tablespace",
    totalusedspace "Used MB",
    (df.totalspace - tu.totalusedspace) "Free MB",
    df.totalspace "Total MB",
    round(100 * ( (df.totalspace - tu.totalusedspace)/ df.totalspace))
    "Pct. Free"
    from
    (select tablespace_name,
    round(sum(bytes) / 1048576) TotalSpace
    from dba_data_files
    group by tablespace_name) df,
    (select round(sum(bytes)/(1024*1024)) totalusedspace, tablespace_name
    from dba_segments
    group by tablespace_name) tu
    where df.tablespace_name = tu.tablespace_name ;

  • Outer Join and Index Usage

    I am simply trying to run the following query:
    select /*+ index (serialnumber trans) */ distinct device,
    device_path||device hierarchy,
    sn.serialnumber
    from z_xfmr_levels z
    left join serialnumber sn
    on z.device = sn.transformergrid(+);
    I am using Oracle 9i
    z_xfmr_levels has 75,000 distinct rows
    serialnumber has 204,000 distinct rows
    The explain plan shows a hash join and a full table scan on both tables.
    How can I get the query to use the index on the transformergrid field of the serialnumber table?

    user10441616 wrote:
    I am simply trying to run the following query:
    select /*+ index (serialnumber trans) */ distinct device,
    device_path||device hierarchy,
    sn.serialnumber
    from z_xfmr_levels z
    left join serialnumber sn
    on z.device = sn.transformergrid(+);
    I am using Oracle 9i
    z_xfmr_levels has 75,000 distinct rows
    serialnumber has 204,000 distinct rows
    The explain plan shows a hash join and a full table scan on both tables.
    How can I get the query to use the index on the transformergrid field of the serialnumber table?What makes you think an index access is more appropriate than the the two full scans and a hash join?
    If you have some legitimate reason, please share ... if not, please read this http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9422487749968

  • Make index entries hot links in Word version?

    I'm using RoboHelp 9 (yes, we're behind the times here). I have a question about something that's never worked, but it's been a low priority, so I just kept ignoring it.
    When I generate a Word version of my project, it has an index, but none of the index entries are hyperlinked. The TOC entries are hyperlinked, so why aren't the index entries?
    Environment:
    RoboHelp 9
    Word 2013, but it never worked with Word 2010
    Windows 7 Professional, 64-bit
    Project Settings:
    Add New Keywords to Index File (HHK)
    Binary Index
    What do I need to do to make the index entries hyperlinks when I generate the Word doc?

    Try asking that on Windows Secrets. http://windowssecrets.com/forums/
    See www.grainge.org for RoboHelp and Authoring tips
    @petergrainge

  • This Simple Change would Make the Usage Widget Actually Useful

    The usage meter widget on my Galaxy S4 tells me how much data I've used but it doesn't tell me as of when, which makes it not very useful.
    If my meter looks like this on day 3 of my cycle then I have a problem. If it's on day 28, no problem! Stream videos all day!
    What we need is a quick indicator of where we are in the cycle. Maybe you all know when your cycle starts and ends but I sure don't, not without checking my account. Here's an easy change that would make this widget one of the most useful:
    VOILA! Now I know at a glance that my cycle is 3/4 over but I've only used about half my data.
    REPLY BACK AND HELP US HELP VERIZON MAKE A BETTER WIDGET!!!!

    Thanks for the feedback. Some points in return:
    --I take the point that many people may have memorized their cycle date or for other reasons may not find the change I'm recommending to be useful. So consider the words "to me" added to the title of the post.
    --Re notes about the execution of the change, I threw those images up after about 20 seconds in Photoshop as an example of what I'm saying. Obviously one would fully develop the look and functionality and then beta, etc.
    --Those caveats aside, here's my basic point: Widgets are meant to save steps, providing the most information in the clearest way at a glance. Sure you could memorize your cycle date then figure out how far you are away from it and decide if your data usage is under, on track or over. A widget that saves steps by providing that information at a glance is, by definition, a better widget.
    OK folks, I'm going to back to do actual work now!

  • Wrong index usage in execution plan

    I have one large document in container created with DBXML_INDEX_NODES flag.
    There is an index by "high" attribute node
    self.container.addIndex ( "", "high", "edge-attribute-equality-double", self.uc )
    About 50% of elements in document have structure:
    <record><data high="XX.XX" /></record>
    Which are inside "session" element which is itself inside "log" element. Only one "log" and one "session" element exist in document
    Index by “high” attribute node is very selective. Below is execution plan (changing index to "node" doesn't change things). Index is used on "presence" of "high" attribute and not "value" of it. I think using it for value would improve the speed of the query. Here is the query produced the execution plan below "collection ( 'test.dbxml' )/log/session/record[data/@high=79.37]"
    <XQuery>
    <Navigation>
    <QueryPlanFunction result="collection" container="seasonal.dbxml">
    <OQPlan>P(edge-attribute-equality-double,prefix,data.@high)</OQPlan>
    </QueryPlanFunction>
    <Step axis="child" name="log" nodeType="element"/>
    <Step axis="child" name="session" nodeType="element"/>
    <Step axis="child" name="record" nodeType="element"/>
    <DbXmlFilter>
    <Navigation>
    <Step axis="child" name="data" nodeType="element">
    <OQPlan>P(edge-attribute-equality-double,prefix,data.@high)</OQPlan>
    </Step>
    <Step axis="attribute" name="high" nodeType="attribute"/>
    <DbXmlCompare name="equal">
    <OQPlan>P(edge-attribute-equality-double,prefix,@high)</OQPlan>
    <Sequence>
    <AnyAtomicTypeConstructor value="79.37" typeuri="http://www.w3.org/2001/XMLSchema" typename="decimal"/>
    </Sequence>
    </DbXmlCompare>
    </Navigation>
    </DbXmlFilter>
    </Navigation>
    </XQuery>
    Also, why is the “typename” attribute of “AnyAtomicTypeConstructor” element is “decimal”?
    Removing flag DBXML_INDEX_NODES on the container increases speed significantly and produces this execution plan, speed is not acceptable though.
    <XQuery>
    <Navigation>
    <QueryPlanFunction result="collection" container="seasonal.dbxml">
    <OQPlan>P(edge-attribute-equality-double,prefix,data.@high)</OQPlan>
    </QueryPlanFunction>
    <Step axis="child" name="log" nodeType="element"/>
    <Step axis="child" name="session" nodeType="element"/>
    <Step axis="child" name="record" nodeType="element"/>
    <DbXmlFilter>
    <Navigation>
    <Step axis="child" name="data" nodeType="element"/>
    <Step axis="attribute" name="high" nodeType="attribute"/>
    <DbXmlCompare name="equal">
    <Sequence>
    <AnyAtomicTypeConstructor value="79.37" typeuri="http://www.w3.org/2001/XMLSchema" typename="decimal"/>
    </Sequence>
    </DbXmlCompare>
    </Navigation>
    </DbXmlFilter>
    </Navigation>
    </XQuery>
    Using index lookup allows achieving speed I need. I'd like to know how to properly write the query and what index to use in my case, though.

    Your query is not using the index because the numeric literal you are using is an xs:decimal, not an xs:double. Wrapping your literal in a cast should make the query use your index:
    collection ( 'test.dbxml' )/log/session/record[data/@high=xs:double(79.37)]
    Having said that, this is only the case for DB XML 2.2.13 and before. It turns out that DB XML has been choosing the wrong type to perform comparisons under - and this has been remedied in the forthcoming version. In your case, the new behaviour will mean that the comparison will always be performed as an xs:double.
    John

  • Index usage error

    i am having a table in my schema named provider_rate_history
    PROVIDER_RATE_HISTORY_ID      NOT NULL      NUMBER
    WORK_ORDER_HISTORY_ID      NOT NULL      NUMBER
    PROVIDER_RATE_TYPE_ID      NOT NULL      NUMBER
    CREATED_BY      NOT NULL      NUMBER
    DATE_CREATED      NOT NULL      DATE
    MODIFIED_BY           NUMBER
    DATE_MODIFIED           DATE
    I created an index named provider_rate_type_idx on the provider_rate_type_id column of the table, but when i am using the following query index is used, but if i replace count(*) keyword in the select statement with any of the column name of the table a ful table scan is performed. What could be the reason for this error and how to correct it
    select count(*) from provider_rate_history
    where rate_type_id=7;
    Index is used, if we replace count(*) with any column name of the table index is not used
    select work_order_history_id from provider_rate_history
    where rate_type_id=7;
    Index is not used

    Hi,
    Why count(*) will lead to full table scan?
    APC have clearly told reason for not using Index.
    Hope this illustration helps to clear the situation.
    SQL> create table test111 as select * from all_objects where rownum < 1001;
    Table created.
    SQL> desc test111
    Name Null? Type
    OWNER NOT NULL VARCHAR2(30)
    OBJECT_NAME NOT NULL VARCHAR2(30)
    SUBOBJECT_NAME VARCHAR2(30)
    OBJECT_ID NOT NULL NUMBER
    DATA_OBJECT_ID NUMBER
    OBJECT_TYPE VARCHAR2(19)
    CREATED NOT NULL DATE
    LAST_DDL_TIME NOT NULL DATE
    TIMESTAMP VARCHAR2(19)
    STATUS VARCHAR2(7)
    TEMPORARY VARCHAR2(1)
    GENERATED VARCHAR2(1)
    SECONDARY VARCHAR2(1)
    SQL> create index test111_indx1 on test111 (object_id);
    Index created.
    SQL>
    SQL> set autotrace on
    SQL> select count(1) from test111;
    COUNT(1)
    1000
    Execution Plan
    Plan hash value: 1326770390
    | Id | Operation | Name | Rows | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
    | 1 | SORT AGGREGATE | | 1 | | |
    | 2 | INDEX FAST FULL SCAN| TEST111_INDX1 | 1000 | 3 (0)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    Statistics
    5 recursive calls
    0 db block gets
    23 consistent gets
    3 physical reads
    0 redo size
    206 bytes sent via SQL*Net to client
    239 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    SQL>
    SQL> select count(distinct owner) from test111;
    COUNT(DISTINCTOWNER)
    3
    Execution Plan
    Plan hash value: 991123090
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 17 | 5 (0)| 00:00:01 |
    | 1 | SORT GROUP BY | | 1 | 17 | | |
    | 2 | TABLE ACCESS FULL| TEST111 | 1000 | 17000 | 5 (0)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    Statistics
    27 recursive calls
    0 db block gets
    33 consistent gets
    0 physical reads
    0 redo size
    233 bytes sent via SQL*Net to client
    239 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    1 rows processed
    SQL>

  • Index usage depends on columns selected

    Hi, somehow cannot understand why index is not used, please help.
    in Oracle Database 11g Release 11.2.0.3.0 - 64bit Production
    1.     Included only indexed column and got a perfect plan
    explain plan for2 select s.x_cnt
    3 from reported_summary s
    4 where s.x_cnt>0;
    PLAN_TABLE_OUTPUT
    Plan hash value: 2674489506
    | Id | Operation | Name | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 306 (8)|
    |* 1 | INDEX FAST FULL SCAN| S_NUI01 | 306 (8)|
    Predicate Information (identified by operation id):
    1 - filter("s"."x_CNT">0)
    2.     Included some other column and got TABLE ACCESS FULL
    explain plan for2 select s.x_cnt,s.ru_id
    3 from reported_summary s
    4 where s.x_cnt>0;
    PLAN_TABLE_OUTPUT
    Plan hash value: 2142873335
    | Id | Operation | Name | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 2421 (3)|
    |* 1 | TABLE ACCESS FULL| REPORTED_SUMMARY | 2421 (3)|
    Predicate Information (identified by operation id):
    1 - filter("s"."x_CNT">0)
    3.     Included all other columns and got TABLE ACCESS FULL as well
    explain plan for2 select s.x_cnt,s.*
    3 from reported_summary s
    4 where s.x_cnt>0;
    PLAN_TABLE_OUTPUT
    Plan hash value: 2142873335
    | Id | Operation | Name | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 2421 (3)|
    |* 1 | TABLE ACCESS FULL| REPORTED_SUMMARY | 2421 (3)|
    Predicate Information (identified by operation id):
    1 - filter("s"."x_CNT">0)
    Thanks a lot

    Thanks all, just to clarify
    "select s.x_cnt from reported_summary s..." is using index;
    "select 'Y' y from reported_summary s..." is using index;
    "select <any ohter column> from reported_summary s..." is causing TABLE ACCESS FULL;
    no differences in where clause, no order by at all
    the index script is
    CREATE INDEX S_NUI01 ON REPORTED_SUMMARY (OFFSET_CNT) TABLESPACE X_INDEXES;
    jgarry, thanks for the answer, the only problem that I have clone of the database (32 bit) with same CBO parameters
    where it does not behave this way:
    explain plan for2 select s.offset_cnt
    3 from reported_summary s
    4 where s.offset_cnt>0;
    PLAN_TABLE_OUTPUT
    Plan hash value: 2359470296
    | Id | Operation | Name | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 9 (0)|
    |* 1 | INDEX RANGE SCAN| S_NUI01 | 9 (0)|
    Predicate Information (identified by operation id):
    1 - access("s"."OFFSET_CNT">0)
    explain plan for2 select s.offset_cnt,s.ru_id
    3 from reported_summary s
    4 where s.offset_cnt>0;
    PLAN_TABLE_OUTPUT
    Plan hash value: 3732627180
    | Id | Operation | Name | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 67 (0)|
    | 1 | TABLE ACCESS BY INDEX ROWID| REPORTED_SUMMARY | 67 (0)|
    |* 2 | INDEX RANGE SCAN | S_NUI01 | 9 (0)|
    Predicate Information (identified by operation id):
    2 - access("s"."OFFSET_CNT">0)
    Thanks again.

  • Index usage making SQL slower.

    Hello,
    While working on a performance tuning activity on Oracle 10.2.0.4 on Solaris 10, I encountered a problem wherein one of our DBA's suggested indexing 2 columns of a certain table. One of the queries which is being run on that table has a RULE hint, and it is seen to be making use of this newly created index. Before the index was created, this query was running fine and getting completed within 30 mins or so. However after the index is created, it is now taking 12 hours on average to complete. Please note that in both the above cases, the CURSOR_SHARING parameter was set to EXACT. Yes, after the index was created its statistics were computed, and for both the index and the base table statistics were gathered. The query is making use of bind variables and is being run via the SQR engine of PeopleSoft.
    Please advice what can be the possible reasons for such delays being caused?
    For any information, please let me know and I would provide the same in this forum/
    Note for moderators: I could not find the section for Performance tuning, so I am asking this question in the general forum. Apologies.
    Thank You,
    Prashant.

    Index scans are not always faster.
    Full table scans are not always bad.
    I doubt that the RULE hint is necessary.
    In general, [url http://www.centrexcc.com/Tuning%20by%20Cardinality%20Feedback.pdf]the CBO does an excellent job of finding the best access plan for a given sql provided it is able to accurately estimate the cardinalities of the row sources in the plan.
    See advice and information required in the template tuning threads:
    [url https://forums.oracle.com/forums/thread.jspa?threadID=863295]How to post a sql tuning request
    [url https://forums.oracle.com/forums/thread.jspa?messageID=1812597]When your query takes too long

  • Index usage in depending on where clause changes.

    Hello Friends,
    I need your help for one issue.
    I have one query , which is using two table Say T1 and T2, where C1 is common column using which both are joined.
    C1 is primary key in T1, but no index available in T2 for C1. T1C2 is the column which we want to select.
    (Note that Either of table can be a Master table)
    Now see the query:
    Select T1C2
    From T1, T2
    where T2.C1 = T1.C1
    Here where clause may have other conditions and From clause may have others tables as per requirements.
    I want to know that, if, I change the query like following to let my query use the available index of T1.C1.
    Select T1C2
    from T1, T2
    where T1.C1 = T2.C1
    Then, Will the query use the available index of T1. and Will i get better performance. Even a little improvement in performance may help me a lot as this kind of query is being used within a where loop (so it is going to be executed multiple times).
    Please advise on this..
    Regards,
    Dipali..

    Hi,
    18:43:17 rel15_real_p>create table t1(c1 number primary key, c2 number);
    Table created.
    18:43:26 rel15_real_p>create table t2(c1 number, c2 number);
    18:45:08 rel15_real_p>
    18:45:09 rel15_real_p>begin
    18:45:09   2  for i in 1..100
    18:45:09   3  loop
    18:45:09   4        insert into t1(c1,c2) values (i,i+100);
    18:45:09   5  end loop;
    18:45:09   6  commit;
    18:45:09   7  end;
    18:45:09   8  /
    PL/SQL procedure successfully completed.
    18:45:09 rel15_real_p>
    18:45:09 rel15_real_p>
    18:45:09 rel15_real_p>begin
    18:45:09   2  for i in 1..100
    18:45:09   3  loop
    18:45:09   4        insert into t2(c1,c2) values (i,i+200);
    18:45:09   5  end loop;
    18:45:09   6  commit;
    18:45:09   7  end;
    18:45:09   8  /
    18:45:23 rel15_real_p>select count(*) from t1;
      COUNT(*)
           100
    18:45:30 rel15_real_p>select count(*) from t2;
      COUNT(*)
           100
    18:45:49 rel15_real_p>select index_name,index_type from user_indexes where table
    _name='T1';
    INDEX_NAME                     INDEX_TYPE
    SYS_C0013059                   NORMAL
    18:48:21 rel15_real_p>set autotrace on
    18:52:25 rel15_real_p>Select T1.C2
    18:52:29   2  From T1, T2
    18:52:29   3  where T2.C1 = T1.C1
    18:52:29   4  /
            C2
           101
           102
           103
           104
           105
            C2
           200
    100 rows selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=100 Bytes=
              900)
       1    0   HASH JOIN (Cost=7 Card=100 Bytes=3900)
       2    1     TABLE ACCESS (FULL) OF 'T1' (TABLE) (Cost=3 Card=100 By
              es=2600)
       3    1     TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 By
              es=1300)
    Statistics
              0  recursive calls
              0  db block gets
             21  consistent gets
              0  physical reads
              0  redo size
           1393  bytes sent via SQL*Net to client
            562  bytes received via SQL*Net from client
              8  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
            100  rows processed
    18:52:31 rel15_real_p>analyze table t1 compute statistics;
    Table analyzed.
    18:55:35 rel15_real_p>analyze table t2 compute statistics;
    18:55:38 rel15_real_p>set autotrace on
    18:55:42 rel15_real_p>Select T1.C2
    18:55:43   2  From T1, T2
    18:55:45   3  where T2.C1 = T1.C1
    18:55:46   4  /
            C2
           101
           102
           103
           104
           105
            C2
           200
    100 rows selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=100 Bytes=7
              00)
       1    0   MERGE JOIN (Cost=6 Card=100 Bytes=700)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE) (Cost=2 Ca
              rd=100 Bytes=500)
       3    2       INDEX (FULL SCAN) OF 'SYS_C0013059' (INDEX (UNIQUE)) (
              Cost=1 Card=100)
       4    1     SORT (JOIN) (Cost=4 Card=100 Bytes=200)
       5    4       TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 B
              ytes=200)
    Statistics
              1  recursive calls
              0  db block gets
             23  consistent gets
              0  physical reads
              0  redo size
           1393  bytes sent via SQL*Net to client
            562  bytes received via SQL*Net from client
              8  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
            100  rows processed
    18:56:56 rel15_real_p>Select T1.C2
    18:56:56   2  From T1, T2
    18:56:56   3  where T1.C1 = T2.C1
    18:56:58   4  /
            C2
           101
           102
           103
           104
           105
            C2
           200
    100 rows selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=100 Bytes=7
              00)
       1    0   MERGE JOIN (Cost=6 Card=100 Bytes=700)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE) (Cost=2 Ca
              rd=100 Bytes=500)
       3    2       INDEX (FULL SCAN) OF 'SYS_C0013059' (INDEX (UNIQUE)) (
              Cost=1 Card=100)
       4    1     SORT (JOIN) (Cost=4 Card=100 Bytes=200)
       5    4       TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 B
              ytes=200)
    Statistics
              1  recursive calls
              0  db block gets
             23  consistent gets
              0  physical reads
              0  redo size
           1393  bytes sent via SQL*Net to client
            562  bytes received via SQL*Net from client
              8  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
            100  rows processed- Pavan Kumar N

Maybe you are looking for