ABOUT query not affecting results or not using knowledge base

Hello again,
Another question here,
I've searched through the forum and have found other
posts on the same problem but no solutions, though
the problem isn't always the primary topic of the
forum. I've put this post up to hopefully put this
to rest as I'm pretty sure this is just a
configuration issue.
I am using an ABOUT operator in a CONTAINS query and
the query seems to return the same results as the
same query without the about operator, eg:
SELECT SCORE(0) AS scr,
file_repository.file_id,
file_repository.file_title
FROM file_repository
WHERE CONTAINS(index_url, 'ABOUT(australia)', 0) > 0
versus
SELECT SCORE(0) AS scr,
file_repository.file_id,
file_repository.file_title
FROM file_repository
WHERE CONTAINS(index_url, 'australia', 0) > 0
I have included documents based on the default
knowledge base should be found. For example I have
three documents, one containing the term 'Tasmania'
another containing 'Australia' and a third with
'Pacific Area'. The first query above should return
all three of these documents, but it only returns
the one containing 'Australia'.
I have used other examples from the default knowledge
base and have had no success. I have not attempted to
extend the knowledge base with a thesaurus as, from
what I can tell, I shouldn't need to do this for it
to work.
Any help would be much appreciated.

Hello.
Did you load the supplied english thesaurus as your DEFAULT thesaurus using the command line utility ctxload (or some other method)?
I had the same experience until I loaded the sample thesaurus in $ORACLE_HOME/ctx/sample/thes/. Now my ABOUT and SYN queries work as expected though I still have a concern about the incomplete nature of the sample thesauri (I'll open a new thread on that topic).
Hope this helps.

Similar Messages

  • About query not using extended knowledge base

    Hello,
    I compiled a small thesaurus to the knowledge base:
    ctxkbtc -user dcenter/dcenter -name THES_PLACE
    It contains:
    GERMAN
    USE FEDERAL REPUBLIC OF GERMANY
    UF FRG
    BT EUROPE
    NT BAVARIAN
    I have 2 record, 1 containing GERMAN, 1 containing BAVARIAN.
    Field is indexed with a context index, and the index is synchronized.
    I'm using 8.1.7.2 english.
    Using an ABOUT operator, I always get 1 hit.
    SQL> select count(*) from file_info where contains (places, 'about(BAVARIAN)') > 0;
    The (9i) doc says:
    When you augment the existing knowledge base with your new thesaurus, you query with the ABOUT operator which implicitly expands to synonyms and narrower terms.
    How can I get the ABOUT query to expand to the narrower term in 8.1.7.2? Is this a bug, do I have to upgrade, or am I missing something?
    Thanks

    Hello.
    Did you load the supplied english thesaurus as your DEFAULT thesaurus using the command line utility ctxload (or some other method)?
    I had the same experience until I loaded the sample thesaurus in $ORACLE_HOME/ctx/sample/thes/. Now my ABOUT and SYN queries work as expected though I still have a concern about the incomplete nature of the sample thesauri (I'll open a new thread on that topic).
    Hope this helps.

  • Why is this query not using the index?

    check out this query:-
    SELECT CUST_PO_NUMBER, HEADER_ID, ORDER_TYPE, PO_DATE
    FROM TABLE1
    WHERE STATUS = 'N'
    and here's the explain plan:-
    1     
    2     -------------------------------------------------------------------------------------
    3     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    4     -------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 2735K| 140M| 81036 (2)|
    6     |* 1 | TABLE ACCESS FULL| TABLE1 | 2735K| 140M| 81036 (2)|
    7     -------------------------------------------------------------------------------------
    8     
    9     Predicate Information (identified by operation id):
    10     ---------------------------------------------------
    11     
    12     1 - filter("STATUS"='N')
    There is already an index on this column, as is shown below:-
         INDEX_NAME INDEX_TYPE     UNIQUENESS     TABLE_NAME     COLUMN_NAME     COLUMN_POSITION
    1     TABLE1_IDX2 NORMAL     NONUNIQUE     TABLE1      STATUS     1
    2     TABLE1_IDX NORMAL     NONUNIQUE     TABLE1     HEADER_ID     1
    So why is this query not using the index on the 'STATUS' Column?
    I've already tried using optimizer hints and regathering the stats on the table, but the execution plan still remains the same, i.e. it still uses a FTS.
    I have tried this command also:-
    exec dbms_stats.gather_table_stats('GECS','GEPS_CS_SALES_ORDER_HEADER',method_opt=>'for all indexed columns size auto',cascade=>true,degree=>4);
    inspite of this, the query is still using a full table scan.
    The table has around 55 Lakh records, across 60 columns. And because of the FTS, the query is taking a long time to execute. How do i make it use the index?
    Please help.
    Edited by: user10047779 on Mar 16, 2010 6:55 AM

    If the cardinality is really as skewed as that, you may want to look at putting a histogram on the column (sounds like it would be in order, and that you don't have one).
    create table skewed_a_lot
    as
       select
          case when mod(level, 1000) = 0 then 'N' else 'Y' end as Flag,
          level as col1
       from dual connect by level <= 1000000;
    create index skewed_a_lot_i01 on skewed_a_lot (flag);
    exec dbms_stats.gather_table_stats(user, 'SKEWED_A_LOT', cascade => true, method_opt => 'for all indexed columns size auto');Is an example.

  • How to use knowledge base keywords"?

    I have found links to the the knowledge base document "how to use knowledge base keywords" online but all the links lead to a dead end. The document number is 75178, and explains the use of prefixes in the knowledge base keyword search. Has anyone any info on where this page is or if it still exists?
    Thanks
    Nadya

    Apparently, the document's no longer available.

  • Query Performance - Query not using proper plan

    Hello,
    I am experiencing a performance issue with queries that span multiple partitions/tablespaces. Specifically, a query utilizing a stored procedure does not use the indices, rather, full table scans are being done resulting in the query taking 30+ minutes to complete. The same query, when removed from the SP, returns results in milliseconds.
    In an attempt to correct the issue, table stats were updated, the stored procedure was re-compiled as well packages that may have been affected after the table stats update. In addition, the database was bounced (shutdown, restarted) but no noticable performance increase was acheived.
    I'm looking for any insight on how to correct this issue.
    I can provide additional information if required.
    Thanks,
    Scott.

    Post the query, the stored procedure, and the table structure. My first quess here is that the stored procedure is binding an incorrect datatype, but I need to see the requested info to be certain.

  • About operator not using thesaurus

    Hello,
    I'm trying to use about query, and extending my knowledge base by loading a thesaurus,
    but it doesn't seem like working...
    Can someone tell me what i'm doing wrong?...
    This is my table:
    X@dev> select * from test_table;
    NUM STR
    1 my car is big
    2 automobile is good
    3 the sea is blue
    4 the ocean is wide
    5 surf forever
    This is my thesaurus:
    Seas
    SYN Breakers
    SYN Estuaries
    SYN Surf
    SYN Waves
    NT Oceans
    Then loading:
    ctxload -user x/x@dev -thes -name default -file test
    Then compiling:
    ctxkbtc -user x/x@dev -name default
    Then:
    begin
    ctx_ddl.create_preference('mylex','BASIC_LEXER');
    ctx_ddl.set_attribute('mylex','index_themes','YES');
    ctx_ddl.set_attribute('mylex','index_text','YES');
    ctx_ddl.set_attribute ( 'mylex', 'mixed_case', 'NO');
    ctx_ddl.set_attribute ( 'mylex', 'PROVE_THEMES', 'NO');
    end;
    and creating the index:
    create index test_idx on test_table(str) indextype is ctxsys.context
    parameters ('LEXER mylex');
    but then:
    X@dev> select * from test_table where contains(str,'syn(sea)',1)>0;
    NUM STR
    3 the sea is blue
    X@dev> select * from test_table where contains(str,'syn(seas)',1)>0;
    NUM STR
    5 surf forever
    X@dev> select * from test_table where contains(str,'about(sea)',1)>0;
    NUM STR
    3 the sea is blue
    X@dev> select * from test_table where contains(str,'about(seas)',1)>0;
    NUM STR
    3 the sea is blue
    The about operator is not using the thesaurus. why?
    and also:
    X@dev> select * from test_table where contains(str,'about(SEA)',1)>0;
    no rows selected
    If the mixed_case is set to "NO" i'm supposed to get results with upper case as well, don't I?
    Thanks for your help!!

    Hi,
    Check this out - seems to match what you're experiencing:
    Expectations of the Thesaurus??????
    -Ron

  • Anbody used Hash partioning? - what about queries not using partition key

    Hi there,
    We have a table, will have over 3 billion rows when loaded and wish to implement partioning.
    Brief structure
    cal_id -- relates to date of transaction
    prod_id
    cust_id,
    sales_qty
    The id's are all surrogate id's/dimension keys
    About 80% of queries expected to use by on_sale_date of product rather than date of transaction hence considering using hash partition on product_id.
    Queries will hit > 1 partition in general and also some e.g 15% of queries wil be by date of transaction.
    Qusetions I have - how will these 15% of queries be affected. I expect will be poorer performance-wise because of partioning but becuase of size of table and 80% queries by product have to use partition.
    Also will partition-pruning work if queries use between rather than = operator
    Anbody used hash partioning - keen to hear other people's ideas/experience with hash partioning.
    Many Thanks

    Hi,
    When partition pruning is not used, then that depend on the access path.
    If it does a full table scan, then there is nearly no overhead to full scan all partitions (compared with full scanning the same non-partitioned table)
    If it is an index access and if indexes are local, then all indexes must be read. But with global index, again, there is no overhead in comparison with a non-partitioned table (except that indexes are a bit larger when global on partitioned table)
    However can be expected to partition even when reading all partitions, especially with parallel query.
    the between is not optimal with hash partitions, s it is hash partition, not range partition.
    Regards,
    Franck.

  • Query not using indexes

    select *
              from hrm_career x
              WHERE x.begin_date = ( SELECT MAX(begin_date)
                             FROM hrm_career y
                             WHERE y.employee_id = x.employee_id AND
                                  begin_date <= SYSDATE AND
                                  primary_job = 'Y') AND
                   x.primary_job = 'Y'
    I have the above query which is not using the index created on the BEGIN_DT column
    I tried to force using still not using
    but when i apply a value say
    select *
              from hrm_career x
              WHERE x.begin_date ='10-20-2007'
    It is using index and resulting in very fast response
    Can some throw some ideas on it...
    Where should i look into here ..

    SQL> set autotrace traceonly
    SQL> select *
    2 from hrm_career x
    3 WHERE x.begin_date = ( SELECT MAX(begin_date)
    4 FROM hrm_career y
    5 WHERE y.employee_id = x.employee_id AND
    6 begin_date <= SYSDATE AND
    7 primary_job = 'Y') AND
    8 x.primary_job = 'Y';
    13454 rows selected.
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1417 Card=152 Bytes=
    35568)
    1 0 FILTER
    2 1 SORT (GROUP BY) (Cost=1417 Card=152 Bytes=35568)
    3 2 HASH JOIN (Cost=254 Card=47127 Bytes=11027718)
    4 3 INDEX (FAST FULL SCAN) OF 'HRM_CAREER_PK' (UNIQUE) (
    Cost=12 Card=25026 Bytes=500520)
    5 3 TABLE ACCESS (FULL) OF 'HRM_CAREER' (Cost=81 Card=25
    335 Bytes=5421690)
    Statistics
    3671 recursive calls
    9 db block gets
    1758 consistent gets
    2130 physical reads
    0 redo size
    2217762 bytes sent via SQL*Net to client
    10359 bytes received via SQL*Net from client
    898 SQL*Net roundtrips to/from client
    128 sorts (memory)
    1 sorts (disk)
    13454 rows processed
    TKPROF
    TKPROF: Release 9.2.0.6.0 - Production on Wed Dec 12 18:40:56 2007
    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
    Trace file: qnhg_ora_500.trc
    Sort options: default
    count = number of times OCI procedure was executed
    cpu = cpu time in seconds executing
    elapsed = elapsed time in seconds executing
    disk = number of physical reads of buffers from disk
    query = number of buffers gotten for consistent read
    current = number of buffers gotten in current mode (usually for update)
    rows = number of rows processed by the fetch or execute call
    ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 1 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 0
    Misses in library cache during execute: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 1 0.00 0.00
    SQL*Net message from client 1 34.45 34.45
    select condition
    from
    cdef$ where rowid=:1
    call count cpu elapsed disk query current rows
    Parse 4 0.00 0.00 0 0 0 0
    Execute 4 0.00 0.00 0 0 0 0
    Fetch 4 0.00 0.00 0 8 0 4
    total 12 0.00 0.00 0 8 0 4
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: SYS (recursive depth: 1)
    Rows Row Source Operation
    1 TABLE ACCESS BY USER ROWID CDEF$
    select *
    from hrm_career x
    WHERE x.begin_date = ( SELECT MAX(begin_date)
    FROM hrm_career y
    WHERE y.employee_id = x.employee_id AND
    begin_date <= SYSDATE AND
    primary_job = 'Y') AND
    x.primary_job = 'Y'
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.07 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 898 0.00 2.39 2038 946 9 13454
    total 900 0.00 2.46 2038 946 9 13454
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    Rows Row Source Operation
    13454 FILTER
    25335 SORT GROUP BY
    67496 HASH JOIN
    25333 INDEX FAST FULL SCAN HRM_CAREER_PK (object id 25292)
    25336 TABLE ACCESS FULL HRM_CAREER
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    13454 FILTER
    25335 SORT (GROUP BY)
    67496 HASH JOIN
    25333 INDEX GOAL: ANALYZED (FAST FULL SCAN) OF 'HRM_CAREER_PK'
    (UNIQUE)
    25336 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'HRM_CAREER'
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 898 0.00 0.00
    SQL*Net more data to client 877 0.00 0.05
    db file sequential read 1 0.01 0.01
    db file scattered read 60 0.00 0.14
    direct path write 9 0.00 0.00
    direct path read 125 0.05 0.13
    SQL*Net message from client 898 0.02 1.47
    DELETE FROM PLAN_TABLE
    WHERE
    STATEMENT_ID=:1
    call count cpu elapsed disk query current rows
    Parse 2 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 6 6 6
    Fetch 0 0.00 0.00 0 0 0 0
    total 4 0.00 0.00 0 6 6 6
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    Rows Row Source Operation
    0 DELETE
    0 TABLE ACCESS FULL PLAN_TABLE
    Rows Execution Plan
    0 DELETE STATEMENT GOAL: CHOOSE
    0 DELETE OF 'PLAN_TABLE'
    0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 2 0.00 0.00
    SQL*Net message from client 2 14.77 14.79
    select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
    o.dataobj#,o.flags
    from
    obj$ o where o.obj#=:1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 0.00 0.00 0 3 0 1
    total 3 0.00 0.00 0 3 0 1
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: SYS (recursive depth: 1)
    EXPLAIN PLAN SET STATEMENT_ID='PLUS74964' FOR select *
    from hrm_career x
    WHERE x.begin_date = ( SELECT MAX(begin_date)
    FROM hrm_career y
    WHERE y.employee_id = x.employee_id AND
    begin_date <= SYSDATE AND
    primary_job = 'Y') AND
    x.primary_job = 'Y'
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.01 0 4 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.00 0.01 0 4 0 0
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 1 0.00 0.00
    SQL*Net message from client 1 0.00 0.00
    insert into plan_table (statement_id, timestamp, operation, options,
    object_node, object_owner, object_name, object_instance, object_type,
    search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
    bytes, other_tag, partition_start, partition_stop, partition_id,
    distribution, cpu_cost, io_cost, temp_space, access_predicates,
    filter_predicates )
    values
    (:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
    :20,:21,:22,:23,:24,:25,:26,:27)
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 6 0.00 0.00 0 3 6 6
    Fetch 0 0.00 0.00 0 0 0 0
    total 7 0.00 0.00 0 3 6 6
    Misses in library cache during parse: 1
    Misses in library cache during execute: 2
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN) (recursive depth: 1)
    Rows Execution Plan
    0 INSERT STATEMENT GOAL: CHOOSE
    select o.name, u.name
    from
    sys.obj$ o, sys.user$ u where obj# = :1 and owner# = user#
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 0 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 1 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 1
    Parsing user id: SYS (recursive depth: 1)
    SELECT ID ID_PLUS_EXP,PARENT_ID PARENT_ID_PLUS_EXP,LPAD(' ',2*(LEVEL-1))
    ||OPERATION||DECODE(OTHER_TAG,NULL,'','*')||DECODE(OPTIONS,NULL,'','
    ('||OPTIONS||')')||DECODE(OBJECT_NAME,NULL,'',' OF '''||OBJECT_NAME||'''')
    ||DECODE(OBJECT_TYPE,NULL,'',' ('||OBJECT_TYPE||')')||DECODE(ID,0,
    DECODE(OPTIMIZER,NULL,'',' Optimizer='||OPTIMIZER))||DECODE(COST,NULL,'','
    (Cost='||COST||DECODE(CARDINALITY,NULL,'',' Card='||CARDINALITY)
    ||DECODE(BYTES,NULL,'',' Bytes='||BYTES)||')') PLAN_PLUS_EXP,OBJECT_NODE
    OBJECT_NODE_PLUS_EXP
    FROM
    PLAN_TABLE START WITH ID=0 AND STATEMENT_ID=:1 CONNECT BY PRIOR ID=PARENT_ID
    AND STATEMENT_ID=:1 ORDER BY ID,POSITION
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 2 0.00 0.00 0 22 0 6
    total 4 0.00 0.00 0 22 0 6
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    Rows Row Source Operation
    6 SORT ORDER BY
    6 CONNECT BY WITH FILTERING
    1 NESTED LOOPS
    1 TABLE ACCESS FULL PLAN_TABLE
    1 TABLE ACCESS BY USER ROWID PLAN_TABLE
    5 NESTED LOOPS
    6 BUFFER SORT
    6 CONNECT BY PUMP
    5 TABLE ACCESS FULL PLAN_TABLE
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    6 SORT (ORDER BY)
    6 CONNECT BY (WITH FILTERING)
    1 NESTED LOOPS
    1 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
    1 TABLE ACCESS (BY USER ROWID) OF 'PLAN_TABLE'
    5 NESTED LOOPS
    6 BUFFER (SORT)
    6 CONNECT BY PUMP
    5 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 2 0.00 0.00
    SQL*Net message from client 2 0.09 0.09
    SELECT ID ID_PLUS_EXP,OTHER_TAG OTHER_TAG_PLUS_EXP,OTHER OTHER_PLUS_EXP
    FROM
    PLAN_TABLE WHERE STATEMENT_ID=:1 AND OTHER_TAG IS NOT NULL ORDER BY ID
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 0.00 0.00 0 3 0 0
    total 3 0.00 0.00 0 3 0 0
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    Rows Row Source Operation
    0 SORT ORDER BY
    0 TABLE ACCESS FULL PLAN_TABLE
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    0 SORT (ORDER BY)
    0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 2 0.00 0.00
    SQL*Net message from client 2 0.00 0.00
    ALTER SESSION SET EVENTS '10046 trace name context off'
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 30 (ADMIN)
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 7 0.00 0.09 0 4 0 0
    Execute 8 0.00 0.00 0 6 6 6
    Fetch 901 0.00 2.39 2038 971 9 13460
    total 916 0.00 2.49 2038 981 15 13466
    Misses in library cache during parse: 6
    Misses in library cache during execute: 1
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 906 0.00 0.00
    SQL*Net message from client 906 34.45 50.82
    SQL*Net more data to client 877 0.00 0.05
    db file sequential read 1 0.01 0.01
    db file scattered read 60 0.00 0.14
    direct path write 9 0.00 0.00
    direct path read 125 0.05 0.13
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 7 0.00 0.00 0 0 0 0
    Execute 11 0.00 0.00 0 3 6 6
    Fetch 5 0.00 0.00 0 11 0 5
    total 23 0.00 0.00 0 14 6 11
    Misses in library cache during parse: 4
    Misses in library cache during execute: 2
    9 user SQL statements in session.
    6 internal SQL statements in session.
    15 SQL statements in session.
    5 statements EXPLAINed in this session.
    Trace file: qnhg_ora_500.trc
    Trace file compatibility: 9.02.00
    Sort options: default
    3 sessions in tracefile.
    12 user SQL statements in trace file.
    8 internal SQL statements in trace file.
    15 SQL statements in trace file.
    11 unique SQL statements in trace file.
    5 SQL statements EXPLAINed using schema:
    ADMIN.prof$plan_table
    Default table was used.
    Table was created.
    Table was dropped.
    3945 lines in trace file.
    Message was edited by:
    Maran Viswarayar

  • Sql query not using parallel option

    I am working in oracle 11.2.0.2.0 .
    I am trying to execute one query using parallel options but in explain plan it is not using that PX option ...
    UPDATE /*+PARALLEL (emp,4) */
    cust_sku_allocation_data emp
    set emp.mean=
    (select sum(dep.stock_to_sales)/count(distinct dep.destination_facility)
    FROM cust_sku_allocation dep
    WHERE dep.stock_to_sales_ratio NOT IN (0,9999)
    AND dep.sku_id = emp.sku_id);
    Any idea where to check..

    Sorry I meant:
    You cannot parallelize UPDATE or DELETE operations on a nonpartitioned table, or when the update only affects 1 partition in a partitioned one.

  • SQL Query not using Composite Index

    Hi,
    Please look at the below query:
    SELECT pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    ,SUM(decode(pde.distribution_type
    ,'FORFEITURE'
    ,pde.forfeited_quantity *
    pde.sold_price * cc.rate
    ,pde.distributed_quantity *
    pde.sold_price * cc.rate)) AS gross_Amt_pref_Curr
    FROM part_distribution_exec pde
    ,currency_conversion cc
    ,currency off_curr
    WHERE pde.participant_uid = 4105
    AND off_curr.currency_iso_code =
    pde.offering_currency_iso_code
    AND cc.from_currency_uid = off_curr.currency_uid
    AND cc.to_currency_uid = 1
    AND cc.latest_flag = 'Y'
    GROUP BY pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    In oracle 9i, i"ve executed this above query, it takes 6 seconds and the cost is 616, this is due to non usage of the composite index, Currency_conversion_idx(From_currency_uid, To_currency_uid, Latest_flag). I wonder why this index is not used while executing the above query. So, I've dropped the index and recreated it. Now, the query is using this index. After inserting many rows or say in 1 days time, if the same query is executed, again the query is not using the index. So everyday, the index should be dropped and recreated.
    I don't want this drop and recreation of index daily, I need a permanent solution for this.
    Can anyone tell me, Why this index goes stale after a period of time???? Please take some time and Solve this issue.
    -Sankar

    Hi David,
    This is Sankar here. Thankyou for your reply.
    I've got the plan table output for this problematic query, please go thro' it and help me out why the index CURRENCY_CONVERSION_IDX is used now and why it's not using while executing the query after a day or inserting some records...
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 26 | 15678 | 147 |
    | 1 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 89 | 2 |
    |* 2 | INDEX UNIQUE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 61097 | | 1 |
    | 3 | SORT AGGREGATE | | 1 | 67 | |
    |* 4 | FILTER | | | | |
    |* 5 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | 67 | 2 |
    | 6 | SORT AGGREGATE | | 1 | 94 | |
    |* 7 | FILTER | | | | |
    |* 8 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 94 | 3 |
    |* 9 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | | 2 |
    |* 10 | FILTER | | | | |
    |* 11 | HASH JOIN | | 26 | 15678 | 95 |
    |* 12 | HASH JOIN OUTER | | 26 | 11596 | 91 |
    |* 13 | HASH JOIN | | 26 | 10218 | 86 |
    | 14 | VIEW | | 1 | 82 | 4 |
    | 15 | SORT GROUP BY | | 1 | 116 | 4 |
    |* 16 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_LEDGER | 1 | 116 | 2 |
    |* 17 | INDEX RANGE SCAN | PARTICIPANT_UID_IDX | 1 | | 1 |
    |* 18 | HASH JOIN OUTER | | 26 | 8086 | 82 |
    |* 19 | HASH JOIN | | 26 | 6006 | 71 |
    | 20 | NESTED LOOPS | | 36 | 5904 | 66 |
    | 21 | NESTED LOOPS | | 1 | 115 | 65 |
    | 22 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 18 | 756 | 2 |
    |* 23 | INDEX RANGE SCAN | KLS_IDX_CURRENCY_CONV | 3 | | 1 |
    | 24 | VIEW | | 1 | 73 | 4 |
    | 25 | SORT GROUP BY | | 1 | 71 | 4 |
    | 26 | TABLE ACCESS BY INDEX ROWID| PART_AWARD_VALUE | 1 | 71 | 2 |
    |* 27 | INDEX RANGE SCAN | PAV_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 28 | TABLE ACCESS BY INDEX ROWID | PARTICIPANT_AWARD | 199 | 9751 | 1 |
    |* 29 | INDEX UNIQUE SCAN | PARTICIPANT_AWARD_PK1 | 100 | | |
    |* 30 | INDEX FAST FULL SCAN | PARTICIPANT_AWARD_TYPE_PK1 | 147 | 9849 | 4 |
    | 31 | VIEW | | 1 | 80 | 10 |
    | 32 | SORT GROUP BY | | 1 | 198 | 10 |
    |* 33 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 1 | 42 | 2 |
    | 34 | NESTED LOOPS | | 1 | 198 | 8 |
    | 35 | NESTED LOOPS | | 2 | 312 | 4 |
    | 36 | TABLE ACCESS BY INDEX ROWID| PART_DISTRIBUTION_EXEC | 2 | 276 | 2 |
    |* 37 | INDEX RANGE SCAN | IND_PARTICIPANT_UID | 1 | | 1 |
    | 38 | TABLE ACCESS BY INDEX ROWID| CURRENCY | 1 | 18 | 1 |
    |* 39 | INDEX UNIQUE SCAN | CURRENCY_AK | 1 | | |
    |* 40 | INDEX RANGE SCAN | CURRENCY_CONVERSION_AK | 2 | | 1 |
    | 41 | VIEW | | 1 | 53 | 4 |
    | 42 | SORT GROUP BY | | 1 | 62 | 4 |
    |* 43 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_VESTING | 1 | 62 | 2 |
    |* 44 | INDEX RANGE SCAN | PAVES_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 45 | TABLE ACCESS FULL | AWARD | 1062 | 162K| 3 |
    | 46 | TABLE ACCESS BY INDEX ROWID | CURRENCY | 1 | 18 | 2 |
    |* 47 | INDEX UNIQUE SCAN | CURRENCY_AK | 102 | | 1 |
    Predicate Information (identified by operation id):
    2 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2
    "PAPS"."INSTALLMENT_NUM"=1)
    4 - filter(4105=:B1)
    5 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    7 - filter(4105=:B1)
    8 - filter("PAPS"."STATUS"='OPEN')
    9 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    10 - filter("CC_A_P_CURR"."FROM_CURRENCY_UID"= (SELECT /*+ */ "CURRENCY"."CURRENCY_UID" FROM
    "EWAPDBO"."CURRENCY" "CURRENCY" WHERE "CURRENCY"."CURRENCY_ISO_CODE"=:B1))
    11 - access("SYS_ALIAS_7"."AWARD_CODE"="A"."AWARD_CODE")
    12 - access("SYS_ALIAS_7"."AWARD_CODE"="PVS"."AWARD_CODE"(+))
    13 - access("SYS_ALIAS_8"."AWARD_CODE"="PALS"."AWARD_CODE" AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PALS"."AWARD_TYPE")
    16 - filter(TRUNC("PAL1"."LEDGER_ENTRY_DATE")<=TRUNC(SYSDATE@!) AND "PAL1"."ALLOC_TYPE"='IPU')
    17 - access("PAL1"."PARTICIPANT_UID"=4105)
    filter("PAL1"."PARTICIPANT_UID"=4105)
    18 - access("SYS_ALIAS_8"."AWARD_CODE"="PDES"."AWARD_CODE"(+) AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PDES"."AWARD_TYPE"(+))
    19 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_8"."AWARD_CODE")
    23 - access("CC_A_P_CURR"."TO_CURRENCY_UID"=1 AND "CC_A_P_CURR"."LATEST_FLAG"='Y')
    27 - access("PAV"."PARTICIPANT_UID"=4105)
    filter("PAV"."PARTICIPANT_UID"=4105)
    29 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_9"."AWARD_CODE" AND
    "SYS_ALIAS_7"."PARTICIPANT_UID"=4105)
    30 - filter("SYS_ALIAS_8"."PARTICIPANT_UID"=4105)
    33 - filter("CC"."LATEST_FLAG"='Y')
    37 - access("PDE"."PARTICIPANT_UID"=4105)
    filter("PDE"."PARTICIPANT_UID"=4105)
    39 - access("OFF_CURR"."CURRENCY_ISO_CODE"="PDE"."OFFERING_CURRENCY_ISO_CODE")
    40 - access("CC"."FROM_CURRENCY_UID"="OFF_CURR"."CURRENCY_UID" AND "CC"."TO_CURRENCY_UID"=1)
    43 - filter("PV"."VESTING_DATE"<=SYSDATE@!)
    44 - access("PV"."PARTICIPANT_UID"=4105)
    filter("PV"."PARTICIPANT_UID"=4105)
    47 - access("CURRENCY"."CURRENCY_ISO_CODE"=:B1)
    Note: cpu costing is off
    93 rows selected.
    Please help me out...
    -Sankar

  • Condition in 7.0 query not used when mapped to dropdownlist in 3.5 web temp

    Hi Experts
    I have a 7.0 query with a condition so that it only shows topN records for a given KF. The query is shown in a chart in a 3.5 web template and here is the condition working just fine. However in the same web template has I made a dropdownlist which is based on the same query as the chart but here is the condition not used.
    Do you know how I get the system to apply the condition to the dropdownlist as well?
    I have tried to set the "Read mode" to the possible values (posted values, master data table, dimension table) on the dropdownlist element in the 3.5 web template but it didn't help.
    Thanks and kind regards,
    Torben

    No replies... closed...

  • Query not using the index

    Query
    SELECT case.case_objid FROM [email protected] case, table_x_cwp_tickect_details_vw t WHERE CASE.case_condition_cd IN ('OPEN', 'OPEN-DISPATCH', 'OPEN-REJECT', 'OPEN-RETURNED') AND case.case_type_cd in ('CUSTOMER FAULT', 'CHRONIC','SCHEDULED ACTIVITY','PROBLEM') AND ROWNUM <= 500 AND case.case_objid = t.ticket_objid AND ( ( case.account_id = '672286' ) ) ORDER BY case.case_id DESC
    From PROD
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 2,629 Bytes: 221,500 Cardinality: 500
         37 SORT ORDER BY Cost: 2,629 Bytes: 221,500 Cardinality: 500
              36 COUNT STOPKEY
                   35 NESTED LOOPS OUTER Cost: 2,628 Bytes: 279,533 Cardinality: 631
                        33 HASH JOIN OUTER Cost: 2,627 Bytes: 275,116 Cardinality: 631
                             31 NESTED LOOPS OUTER Cost: 2,249 Bytes: 266,282 Cardinality: 631
                                  28 NESTED LOOPS Cost: 1,766 Bytes: 257,448 Cardinality: 631
                                       26 NESTED LOOPS Cost: 1,765 Bytes: 253,031 Cardinality: 631
                                            24 NESTED LOOPS Cost: 1,764 Bytes: 248,614 Cardinality: 631
                                                 22 NESTED LOOPS Cost: 1,763 Bytes: 244,197 Cardinality: 631
                                                      19 NESTED LOOPS Cost: 1,258 Bytes: 235,363 Cardinality: 631
                                                           17 NESTED LOOPS Cost: 1,257 Bytes: 230,946 Cardinality: 631
                                                                14 NESTED LOOPS OUTER Cost: 752 Bytes: 217,695 Cardinality: 631
                                                                     12 HASH JOIN Cost: 751 Bytes: 213,278 Cardinality: 631
                                                                          1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                          11 HASH JOIN Cost: 748 Bytes: 208,861 Cardinality: 631
                                                                               2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                               10 HASH JOIN Cost: 746 Bytes: 204,444 Cardinality: 631
                                                                                    3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                    9 HASH JOIN Cost: 743 Bytes: 200,027 Cardinality: 631
                                                                                         4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                         8 NESTED LOOPS Cost: 741 Bytes: 195,610 Cardinality: 631
                                                                                              5 REMOTE REMOTE CASE Cost: 235 Bytes: 156,488 Cardinality: 631
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                     13 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                16 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                     15 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                           18 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      21 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                           20 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                 23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                            25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                       27 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                  30 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                       29 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                             bold 32 TABLE ACCESS FULL TABLE SA.TABLE_MOD_LEVEL Cost: 376 Bytes: 1,442,084 Cardinality: 103,006 bold
                        34 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    From DEV platform
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 591 Bytes: 61,134 Cardinality: 138
         37 SORT ORDER BY Cost: 591 Bytes: 61,134 Cardinality: 138
              36 COUNT STOPKEY
                   35 HASH JOIN Cost: 590 Bytes: 61,134 Cardinality: 138
                        1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                        34 HASH JOIN Cost: 588 Bytes: 60,168 Cardinality: 138
                             2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                             33 HASH JOIN Cost: 585 Bytes: 59,202 Cardinality: 138
                                  3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                  32 HASH JOIN Cost: 583 Bytes: 58,236 Cardinality: 138
                                       4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                       31 NESTED LOOPS OUTER Cost: 580 Bytes: 57,270 Cardinality: 138
                                            29 NESTED LOOPS OUTER Cost: 579 Bytes: 56,304 Cardinality: 138
                                                 27 NESTED LOOPS OUTER Cost: 469 Bytes: 54,372 Cardinality: 138
                                                      24 NESTED LOOPS Cost: 363 Bytes: 52,440 Cardinality: 138
                                                           22 NESTED LOOPS Cost: 362 Bytes: 51,474 Cardinality: 138
                                                                20 NESTED LOOPS Cost: 361 Bytes: 50,508 Cardinality: 138
                                                                     18 NESTED LOOPS Cost: 360 Bytes: 49,542 Cardinality: 138
                                                                          15 NESTED LOOPS Cost: 249 Bytes: 47,610 Cardinality: 138
                                                                               13 NESTED LOOPS Cost: 248 Bytes: 46,644 Cardinality: 138
                                                                                    10 NESTED LOOPS OUTER Cost: 138 Bytes: 43,746 Cardinality: 138
                                                                                         8 NESTED LOOPS Cost: 137 Bytes: 42,780 Cardinality: 138
                                                                                              5 REMOTE REMOTE CASE Cost: 26 Bytes: 34,224 Cardinality: 138
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                                         9 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                                    12 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                                         11 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                                               14 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                          17 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                                               16 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                                     19 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                21 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                           23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      26 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                                           25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                                       bold           28 INDEX RANGE SCAN INDEX SA.IND_PART_INFO2PART_NUM Cost: 1 Bytes: 14 Cardinality: 1 bold
                                            30 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    Conclusion:
    IND_PART_INFO2PART_NUM is not in use in Production environment
    PROD
    1. SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR
    IND_PART_INFO2PART_NUM 103023 46488
    DEV environment
    SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR,table_name from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR TABLE_NAME
    IND_PART_INFO2PART_NUM 101982 45722 TABLE_MOD_LEVEL
    1. Index is rebuild
    2. stats are up to date
    3. Redef on table is done.
    Still no change in the plan .

    Osama-mustafa wrote:
    Aman.... wrote:
    Osama-mustafa wrote:
    alter index <index-name> rebuild ;Why?
    Aman....I faced this issue with query and indexes was need rebuildWhat issue Osama-that query wasn't using index and after rebuild it did start using it? Not just that this reply is wrong , this is OP has mentioned that he has done already. Please note that index rebuild is not the answer when the query is not using the index. There can be many reasons behind it. Have a look at Richard Foote's blog where he explains all of this in a very detailed way and in many posts.
    Aman....

  • Query not using aggregate when written against multiprovider

    We have a multiprovider that contains one infocube. The infocube has aggregates defined to it. When writing a query against the infocube, an aggregate is used. However, when writting the identical query against the multiprovider, an aggegate is not used. We are running BI 7.0, Netweaver 2004s, patch set 10. Is there something that needs to be done to the multiprovider to get it to recognize the aggregate?

    We have determined the issue to be one of the navigational attributes. It is not used in our query and is not in our aggregate. For some reason, the query against the multiprovider wanted it to be there. After adding it to the aggregate, we were fine. We found this using RSRT and specifying the 'Select Aggregate' option. This gave us a good message as to why the aggregate was not being used. Thanks to everyone for their suggestions.

  • Query not using remote table primary key.

    Hello all,
    My following query is not using the PK of remote database. vem_business_event_attribute is having a PK on ATTRIBUTE_TYPE_ID and business_event_id. The table is last analyzed on 04-dec-2010. It has around 5 milloin rows.
    select /*+ DRIVING_SITE(ve) */
    ve.ATTRIBUTE_TYPE_ID ,
    ve.BUSINESS_EVENT_ID ,
    ve.ATTRIBUTE_VALUE ,
    ve.ATTRIBUTE_AS_NUMBER
    from
    vem_business_event_attribute@hello ve,
    vem_attribute_types@hello va,
    delta_insert_businessevent de
    where
         ve.ATTRIBUTE_TYPE_ID = va.ATTRIBUTE_TYPE_ID
    ve.business_event_id = de.business_event_id
         and de.business_event_id < 90000000;
    Pls help.
    Regards

    If you need to move 150 million rows from one database to another, it is going to take some time, and a full scan would definitely be the most efficient sql way to do it. I would be surprised if 15 inserts of 10 million rows each would be faster than a single insert of 150 million rows.
    Depending on your exact requirements, it might be faster to use datapump to export the rows from the remote database and import them on the local database, but you will still be moving those 150 million rows across the network. You might get some advantage from the export/ftp/import option if you compress the dump file before the ftp, and uncompress it on the target, but that would depend on the additional time required to compress and uncompress.
    John

  • Due to Upper() query not using Indexes.......

    Hi,
    I have query as under:
    SELECT max(A.REGION_ID)
      FROM SOP_REGION_COUNTRY_MAP  A,
           SOP_REGION_PRODLINE_MAP B,
           SOP_REGION_ACTIVITY_MAP C
    WHERE A.REGION_ID = B.REGION_ID
       AND A.REGION_ID = C.REGION_ID
       AND upper(trim(COUNTRY_NAME)) = upper(trim(:Var3))
       AND upper(trim(STATE_NAME)) = upper(trim(:Var2))
       AND upper(trim(PRODLINE_NAME)) = upper(trim(:Var1))
       AND A.BATCH_JOB_IND = 1
       AND B.BATCH_JOB_IND = 1The plan of the above query is as under:
         SELECT STATEMENT, GOAL = CHOOSE                                   Cost=7     Cardinality=1     Bytes=73
    SORT AGGREGATE                                                       Cardinality=1     Bytes=73
      NESTED LOOPS                                                  Cost=7     Cardinality=1     Bytes=73
       HASH JOIN                                                  Cost=6     Cardinality=1     Bytes=68
        TABLE ACCESS FULL     Object owner=SOP     Object name=SOP_REGION_COUNTRY_MAP     Cost=3     Cardinality=1     Bytes=25
        TABLE ACCESS FULL     Object owner=SOP     Object name=SOP_REGION_PRODLINE_MAP     Cost=3     Cardinality=1     Bytes=43
       INDEX RANGE SCAN     Object owner=SOP     Object name=FK1_SOP_REGION_ACTIVITY_MAP     Cost=2     Cardinality=48     Bytes=240Now, this query does full table access of sop_region_country_map and sop_region_prodline_map even though it has index on country_name,state_name and prodline_name columns but as i have used Upper function the index is not used. Now, I need this upper function as business req. states that none of the comparison should be missed jsut because user has entered country,state and prodline in mixed cases...
    Can you pls let me know what to do if i want to avoid this FTA and instaed use indexes.. without sacrificing Upper() functionlaity..?
    Thx

    okay...its something like query rewrite grant for user...
    when i give that...i can create functional index now..
    but still i can use trunc() for functional index...it tells me that functional index can be created only for pure function...what is pure and impure function in oracle.

Maybe you are looking for

  • How can I delete unsupported content songs from my iPad?

    How can I delete unsupported content songs from my iPad?

  • Save as PDF Page Formatting

    Hi All, I built a tool in Excel 2007 which allows the user to publish a formatted output to PDF.  To get around the fact that the excel pulls the printer metrics from the active printer, I had the tool load up the MODI printer and use its metrics so

  • Problemas con la re-instalación de Acrobat 7.0 professional

    Instale el programa en el ordenador. Me dice que lo tengo que activar. Lo que ya no se puede hacer por internet. En mi sección de usuario de Adobe, veo que en  mis productos ya sale el registro en un año anterior y con el número de serie que tengo en

  • No more JPEG thumbnails in Finder (also no cover flow!)

    I don't see any thumbnails anymore in Finder.. I have several JPG's exported by Photoshop, and they look fine in Preview, also in column layout, when you click the file, it shows a thumb, but in icon view and cover flow, I only get to see the JPG ico

  • Pdf files flash open then close immediately

    Whenever I try to open a pdf file using Adobe Reader, they just flash open and close and I get a plethora of error messages which I have to X out of.