Oracle Text Index taking Much time for retreiving records

Hi,
I an using the context based index on the table with the xmltype column and using the mentioned preferences, fuzzy, stemming and substring.
I m also using the INPATH and the HASPATH operators to search on the XML contents.
The total no of records in the table is 1,14,24,340.
When i execute the query on the table it is taking atleast 20 secs to return the results.
Could anyone suggest some method to improve the performance ?

Hi,
Please find belwo the details,
Table Structure - sample_t(id NUMBER, type VARCHAR2(10),smpl_xml XMLTYPE)
Preference:
begin
ctx_ddl.create_preference('SAMPLE_PREF', 'BASIC_WORDLIST');
ctx_ddl.set_attribute('SAMPLE_PREF','FUZZY_MATCH','ENGLISH');
ctx_ddl.set_attribute('SAMPLE_PREF','FUZZY_SCORE','0');
ctx_ddl.set_attribute('SAMPLE_PREF','FUZZY_NUMRESULTS','200');
ctx_ddl.set_attribute('SAMPLE_PREF','SUBSTRING_INDEX','TRUE');
end;
Index Creation:
CREATE INDEX sample_dmn_idx ON sample_t(smpl_xml)
INDEXTYPE IS CTXSYS.CONTEXT FILTER BY type PARAMETERS
('LEXER basic_lexer_pref
WORDLIST SAMPLE_PREF
SECTION GROUP CTXSYS.PATH_SECTION_GROUP');
Query :
select ts.id from sample_t ts
WHERE CONTAINS (ts.smpl_xml, 'HASPATH(/ROOT/VAL/chars/_7= "POWDERED FRUIT DRINKS")
AND HASPATH(/ROOT/VAL/chars/_46= "POUCH")
AND HASPATH(/ROOT/VAL/chars/_62= "LEMONADE")
AND HASPATH(/ROOT/VAL/chars/_88= "PIED")
AND HASPATH(/ROOT/VAL/chars/_732= "SWEET")
AND HASPATH(/ROOT/VAL/chars/_2971= "ALL FAMILY")
AND HASPATH(/ROOT/VAL/chars/_3115= "UNKNOWN")
AND HASPATH(/ROOT/VAL/chars/_3182= "YES")
AND HASPATH(/ROOT/VAL/chars/_3340= "OTHER")',1) > 0
AND ts.type = 'ITEM'
Query Data:_     
ID TYPE           smpl_xml
1      ITEM                <ROOT> <CODE>927</CODE> <VAL> <chars> <_7>AFTER SHAVE LOTIONS..</_7> <_27>OLD SPICE..</_27> <_46>REMAINING..</_46> <_4006>OLD SPICE..</_4006> </chars> </VAL> </ROOT>
Plan hash value: 1588539682
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 562K| 52M| 308K (1)| 01:01:43 |
|* 1 | TABLE ACCESS BY INDEX ROWID| sample_t               | 562K| 52M| 308K (1)| 01:01:43 |
|* 2 | DOMAIN INDEX | sample_dmn_idx     | | | 222K (0)| 00:44:34 |
Predicate Information (identified by operation id):
1 - filter("TS"."ENTY_TYP_MNM"='ITEM')
2 - access("CTXSYS"."CONTAINS"(SYS_MAKEXML(0,"SYS_NC00004$"),'HASPATH(/ROOT/VAL/chars/_7= "POWDERED FRUIT DRINKS") AND
HASPATH(/ROOT/VAL/chars/_46= "POUCH") AND
HASPATH(/ROOT/VAL/chars/_62= "LEMONADE") AND
HASPATH(/ROOT/VAL/chars/_88= "PIED") AND
HASPATH(/ROOT/VAL/chars/_732= "SWEET") AND
HASPATH(/ROOT/VAL/chars/_2971= "ALL FAMILY") AND
HASPATH(/ROOT/VAL/chars/_3115= "UNKNOWN") AND
HASPATH(/ROOT/VAL/chars/_3182= "YES") AND
HASPATH(/ROOT/VAL/chars/_3340= "OTHER")',1)>0)
Edited by: user13780543 on Aug 17, 2011 2:12 AM
Edited by: user13780543 on Aug 17, 2011 2:13 AM
Edited by: user13780543 on Aug 17, 2011 2:14 AM

Similar Messages

  • Taking much time for loading data

    Dear All
    While loading data in <b>PRD system</b> (for master data and transaction data), it's taking much time. For ex., 2LIS_05_QOITM, I am loading delta data only in <b>PSA</b> from R/3. Some times (yesterday) it's taking 2 mins and some times (today) it's taking 5 hrs not yet completed (it's yellow). Actually yesterday, we went to SM58 in R/3 side and executed that LUW for some other data sources. Now also we can do but we don't want to like that. Because we are expecting permanent soulution. Could u please advice me. I am getting below message in status tab
    Errors while sending packages from OLTP to BI
    Diagnosis
    No IDocs could be sent to BI using RFC.
    System Response
    There are IDocs in the source system ALE outbox that did not arrive in the ALE inbox of BI.
    Further analysis:
    Check the TRFC log.
    You can access this log using the wizard or the menu path "Environment -> Transact. RFC -> In source system".
    Error handling:
    If the TRFC is incorrect, check whether the source system is fully connected to BI. In particular, check the authorizations of the background user in the Errors while sending packages from OLTP to BI
    Diagnosis
    No IDocs could be sent to BI using RFC.
    System Response
    There are IDocs in the source system ALE outbox that did not arrive in the ALE inbox of BI.
    Further analysis:
    Check the TRFC log.
    You can access this log using the wizard or the menu path "Environment -> Transact. RFC -> In source system".
    Error handling:
    If the TRFC is incorrect, check whether the source system is fully connected to BI. In particular, check the authorizations of the background user in the source system.
    I am loading data through Process chain and user is <b>BWREMOTE (authorized user).</b>
    Please help me.
    Thanks a lot in advance
    Raja

    Dear Karthik
    No I couldn't resolve till now
    But Everything is fine.
    Now status is yellow only (209 from 209). Now what i want to do.
    Im getting below message <b>in status tab</b>
    Missing data packages for PSA Table
    Diagnosis
    Data packets are missing from PSA Table . BI processing does not return any errors. The data transport from the source system to BI was probably incorrect.
    Procedure
    Check the tRFC overview in the source system.
    You access this log using the wizard or following the menu path "Environment -> Transact. RFC -> Source System".
    Error handling:
    If the tRFC is incorrect, resolve the errors listed there.
    Check that the source system is connected properly to BI. In particular, check the remote user authorizations in BI.
    <b>In detail tab</b>, I am getting below message
    Info IDoc 2 : sent, not arrived ; IDoc ready for dispatch (ALE service)
    Thanks in advance
    Raja

  • How much time for Microphone Recording Nano Plus 1 g

    Title asks. Can the NANO Plus Gig record from the Microphone for as long as 30 minutes?

    Yes it can - I have recorded well over this in this past. I think it will carry on recording until it runs out of room which is a lot of hours!
    Don't forget, it is only a voice recorder - it doesn't have a very good frequency range so music sounds muffled.
    PB

  • Oracle text indexes

    Can anybody know is it possible to create two oracle text indexes on one column, for example, CTXCAT index and CTXRULE index and what will be during the querying of that column? is it a good practise?
    Thanks in advance.

    When in doubt, test and see.  Yes, you can create two different types of Oracle Text indexes on the same column.  If you create a CTXCAT index and a CTXRULE index, then queries using CATSEARCH will use the CTXCAT index and queries using MATCHES will use the CTXRULE index.  When querying with CATSEARCH, it will find all rows where the terms searched for are found within the column value.  When querying with CTXRULE, it does the opposite, and finds all rows where the column values are found within the terms searched for.  Please see the demonstration below.  As to whether it is a good practice, it depends on what you need.  If you need both types of searches, then yes.  If not, then no, it would be unnecessary overhead.
    SCOTT@orcl_11gR2> create table test_tab (test_col  varchar2(60))
      2  /
    Table created.
    SCOTT@orcl_11gR2> insert all
      2  into test_tab values ('test')
      3  into test_tab values ('data')
      4  into test_tab values ('test data')
      5  into test_tab values ('other stuff')
      6  select * from dual
      7  /
    4 rows created.
    SCOTT@orcl_11gR2> create index ctxcat_idx on test_tab (test_col)
      2  indextype is ctxsys.ctxcat
      3  /
    Index created.
    SCOTT@orcl_11gR2> create index ctxrule_idx on test_tab (test_col)
      2  indextype is ctxsys.ctxrule
      3  /
    Index created.
    SCOTT@orcl_11gR2> set autotrace on explain
    SCOTT@orcl_11gR2> select * from test_tab
      2  where  catsearch (test_col, 'test data', null) > 0
      3  /
    TEST_COL
    test data
    1 row selected.
    Execution Plan
    Plan hash value: 399706479
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |            |     1 |    44 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST_TAB   |     1 |    44 |     3   (0)| 00:00:01 |
    |*  2 |   DOMAIN INDEX              | CTXCAT_IDX |       |       |            |          |
    Predicate Information (identified by operation id):
       2 - access("CTXSYS"."CATSEARCH"("TEST_COL",'test data',NULL)>0)
    Note
       - dynamic sampling used for this statement (level=2)
    SCOTT@orcl_11gR2> select * from test_tab
      2  where  matches (test_col, 'test data') > 0
      3  /
    TEST_COL
    test
    data
    test data
    3 rows selected.
    Execution Plan
    Plan hash value: 1476734355
    | Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |             |     1 |    44 |     1   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST_TAB    |     1 |    44 |     1   (0)| 00:00:01 |
    |*  2 |   DOMAIN INDEX              | CTXRULE_IDX |       |       |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("CTXSYS"."MATCHES"("TEST_COL",'test data')>0)
    Note
       - dynamic sampling used for this statement (level=2)
    SCOTT@orcl_11gR2>
    Message was edited by: BarbaraBoehmer

  • OBIEE 10g taking long time for login

    Hello Experts,
    I am using     Oracle BI applications 7.9.6.2 with OBIEE 10.1.3.4.2.
    When any user tries to login it is taking much time for the process(50-60 sec) but after login other query responce is good.
    Can you suggest me how can i reduce this login interval ?
    Thank You

    Pls. disable unwanted VARIABLES in repository & check for any Init block initialization taking more time.

  • Taking much time when trying to Drill a characterstic in the BW Report.

    Hi All,
    When we are executing the BW report, it is taking nearly 1 to 2 mins then when we are trying to drill down a characterstic it is taking much time nearly 30 mins to 1 hour and througing an error message that,
    "An error has occared during loading. Plese look in the upper frame for further information."
    I have executed this query in RSRT and cheked the query properties,
    this quey is bringing the data directly form Aggregates but some chares are not avalable in the Agrregtes.
    So... after execution when we are trying to drill down the chars is taking much time for chars which are not avilable in the Aggregates. For other chars which are avilable in the Aggregates it is taking only 2 to 3 mins only.
    How to do the drill down for the chars which are not avilable in the Aggregates with out taking much time and error.
    Could you kindly give any solution for this.
    Thanks & Regards,
    Raju. E

    Hi,
    The only solution is to include all the char used in the report in the aggregates or this will the issue you will face.
    just create a proposal for aggregates before creating any new aggregates as it will give you the idea which one is most used.
    Also you should make sure that all the navigation characteristics are part of the aggregates.
    Thanks
    Ajeet

  • Why oracle text index column taking long  time

    why oracle text index column is taking long time to return result.I created text index on a column if I run the query on a single table result is very fast.If I join table with other table (10 records only )
    it is taking long time but in explain plan it is searching by index only.
    I created this index for searching a varchar2 column,the data is comma seperated values like ( UK,US,IT,BR) and the table having records 20 lakhs.Normally if I query with like operater
    ( like '%US%' ) it is taking full table scan because I am using '%' both sides. Please help me on this regard how to search the data with less time. Here is may sample code and explain plan.
    SQL*Plus: Release 9.2.0.1.0 - Production on Wed Jan 28 16:54:22 2009
    Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
    Connected to:
    Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.1.0 - Production
    SQL&gt; set timing on
    SQL&gt; set linesize 180
    SQL&gt; explain plan for SELECT T.esongid FROM (SELECT A.ESONGID FROM wcmedeco.EDECO_ESONGS_TERR_CTRY 
    A WHERE CONTAINS(A.TERR_CTRY_NAMES,'US')&gt;0  
      2  GROUP BY A.ESONGID)K,T
      3  WHERE  K.ESONGID=T.ESONGID;
    Explained.
    Elapsed: 00:00:00.01
    SQL&gt; select *from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id  | Operation                      |  Name                   | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT               |                         |     1 |    26 |     4 |
    |   1 |  NESTED LOOPS                  |                         |     1 |    26 |     4 |
    |   2 |   VIEW                         |                         |     1 |    13 |     4 |
    |   3 |    SORT GROUP BY               |                         |     1 |    89 |     4 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| EDECO_ESONGS_TERR_CTRY  |     1 |    89 |     2 |
    |   5 |      DOMAIN INDEX              | IDX_TERR_CTRY_NAMES     |       |       |     0 |
    |   6 |   INDEX RANGE SCAN             | IDX_ESONGID_T           |     1 |    13 |     1 |
    PLAN_TABLE_OUTPUT
    Note: cpu costing is off, 'PLAN_TABLE' is old version
    14 rows selected.
    Elapsed: 00:00:00.00
    SQL&gt; Regards,
    Rajasekhar

    You have not formatted your code properly so we cannot see the query you're executing. Please put some line breaks in.
    Secondly, how fresh are the statistics on those tables? Are you really returning one record out of twenty million?
    Cheers, APC
    blog: http://radiofreetooting.blogspot.com

  • About index memory parameter for Oracle text indexes

    Hi Experts,
    I am on Oracle 11.2.0.3 on Linux and have implemented Oracle Text. I am not an expert in this subject and need help about one issue. I created Oracle Text indexes with default setting. However in an oracle white paper I read that the default setting may not be right. Here is the excerpt from the white paper by Roger Ford:
    URL:http://www.oracle.com/technetwork/database/enterprise-edition/index-maintenance-089308.html
    "(Part of this white paper below....)
    Index Memory                                    As mentioned above, cached $I entries are flushed to disk each time the indexing memory is exhausted. The default index memory at installation is a mere 12MB, which is very low. Users can specify up to 50MB at index creation time, but this is still pretty low.                                   
    This would be done by a CREATE INDEX statement something like:
    CREATE INDEX myindex ON mytable(mycol) INDEXTYPE IS ctxsys.context PARAMETERS ('index memory 50M'); 
    Allow index memory settings above 50MB, the CTXSYS user must first increase the value of the MAX_INDEX_MEMORY parameter, like this:                                
    begin ctx_adm.set_parameter('max_index_memory', '500M'); end; 
    The setting for index memory should never be so high as to cause paging, as this will have a serious effect on indexing speed. On smaller dedicated systems, it is sometimes advantageous to temporarily decrease the amount of memory consumed by the Oracle SGA (for example by decreasing DB_CACHE_SIZE and/or SHARED_POOL_SIZE) during the index creation process. Once the index has been created, the SGA size can be increased again to improve query performance.&quot;
    (End here from the white paper excerpt)
    My question is:
    1) To apply this procedure (ctx_adm.set_parameter) required me to login as CTXSYS user. Is that right? or can it be avoided and be done from the application schema? This user CTXSYS is locked by default and I had to unlock it. Is that ok to do in production?
    2) What is the value that I should use for the max_index_memory should it be 500 mb - my SGA is 2 GB in Dev/ QA and 3GB in production. Also in the index creation what is the value I should set for index memory parameter  - I had left that at default but how should I change now? Should it be 50MB as shown in example above?
    3) The white paper also refer to rebuilding an index at some interval like once in a month:   ALTER INDEX DR$index_name$X REBUILD ONLINE;
    --Is this correct advice? i would like to ask the experts once before doing that.  We are on Oracle 11g and the white paper was written in 2003.
    Basically while I read the paper, I am still not very clear on several aspects and need help to understand this.
    Thanks,
    OrauserN

    Perhaps it's time I updated that paper
    1.  To change max_index_memory you must be a DBA user OR ctxsys. As you say, the ctxsys account is locked by default. It's usually easiest to log in as a DBA and run something like
    exec ctxsys.ctx_adm.set_parameter('MAX_INDEX_MEMORY', '10G')
    2.  Index memory is allocated from PGA memory, not SGA memory. So the size of SGA is not relevant. If you use too high a setting your index build may fail with an error saying you have exceeded PGA_AGGREGATE_LIMIT.  Of course, you can increase that parameter if necessary. Also be aware that when indexing in parallel, each parallel process will allocated up to the index memory setting.
    What should it be set to?  It's really a "safety" setting to prevent users grabbing too much machine memory when creating indexes. If you don't have ad-hoc users, then just set it as high as you need. In 10.1 it was limited to just under 500M, in 10.2 you can set it to any value.
    The actual amount of memory used is not governed by this parameter, but by the MEMORY setting in the parameters clause of the CREATE INDEX statement. eg:
    create index fooindex on foo(bar) indextype is ctxsys.context parameters ('memory 1G')
    What's a good number to use for memory?  Somewhere in the region of 100M to 200M is usually good.
    3.  No - that's out of date.  To optimize your index use CTX_DDL.OPTIMIZE_INDEX.  You can do that in FULL mode daily or weekly, and REBUILD mode perhaps once a month.

  • Database tableAUFM hitting is taking much time even secondary index created

    Hi Friends,
       There is report for Goods movement rel. to Service orders + Acc.indicator.
       We have  two testing Systems(EBQ for developer and PEQ from client side).
       EBQ system contains replica of PEQ every month.
       This report is not taking much time in EBQ.But it is taking much time in PEQ.For the selection criteria I have given,both systems  have same data(Getting same output).
    The report has the follwoing fields on the selection criteria:
    A_MJAHR     Material Doc. Year (Mandatory)
    S_BLDAT     Document Date(Optional)
    S_BUDAT     Posting Date(Optional)
    S_LGORT     Storage Location(Optional)
    S_MATNR     Material(Optional)
    S_MBLNR     Material Documen(Optional)t
    S_WERKS     Plant(Optional)
    Client not agrrying to make Material Documen as Mandatory.
    The main (first) table hit is on AUFM table .As there are non-key fileds as well in where condition,We have cretaed a secondary index as well for AUFM table on the following fields:
    BLDAT
    BUDAT
    MATNR
    WERKS
    LGORT 
    Even then also ,in PEQ sytem the report is taking very long time ,Some times not even getting the ALV output.
    What can be done to get teh report executed very fast.
    <removed by moderator>
    The part of report Soure code is as below:
    <long code part removed by moderator>
    Thanks and Regards,
    Rama chary.P
    Moderator message: please stay within the 2500 character limit to preserve formatting, only post relevant portions of the code, also please read the following sticky thread before posting.
    Please Read before Posting in the Performance and Tuning Forum
    locked by: Thomas Zloch on Sep 15, 2010 11:40 AM

    Hi Friends,
       There is report for Goods movement rel. to Service orders + Acc.indicator.
       We have  two testing Systems(EBQ for developer and PEQ from client side).
       EBQ system contains replica of PEQ every month.
       This report is not taking much time in EBQ.But it is taking much time in PEQ.For the selection criteria I have given,both systems  have same data(Getting same output).
    The report has the follwoing fields on the selection criteria:
    A_MJAHR     Material Doc. Year (Mandatory)
    S_BLDAT     Document Date(Optional)
    S_BUDAT     Posting Date(Optional)
    S_LGORT     Storage Location(Optional)
    S_MATNR     Material(Optional)
    S_MBLNR     Material Documen(Optional)t
    S_WERKS     Plant(Optional)
    Client not agrrying to make Material Documen as Mandatory.
    The main (first) table hit is on AUFM table .As there are non-key fileds as well in where condition,We have cretaed a secondary index as well for AUFM table on the following fields:
    BLDAT
    BUDAT
    MATNR
    WERKS
    LGORT 
    Even then also ,in PEQ sytem the report is taking very long time ,Some times not even getting the ALV output.
    What can be done to get teh report executed very fast.
    <removed by moderator>
    The part of report Soure code is as below:
    <long code part removed by moderator>
    Thanks and Regards,
    Rama chary.P
    Moderator message: please stay within the 2500 character limit to preserve formatting, only post relevant portions of the code, also please read the following sticky thread before posting.
    Please Read before Posting in the Performance and Tuning Forum
    locked by: Thomas Zloch on Sep 15, 2010 11:40 AM

  • Query taking long time for EXTRACTING the data more than 24 hours

    Hi ,
    Query taking long time for EXTRACTING the data more than 24 hours please find the query and explain plan details below even indexes avilable on table's goe's to FULL TABLE SCAN. please suggest me.......
    SQL> explain plan for select a.account_id,round(a.account_balance,2) account_balance,
    2 nvl(ah.invoice_id,ah.adjustment_id) transaction_id,
    to_char(ah.effective_start_date,'DD-MON-YYYY') transaction_date,
    to_char(nvl(i.payment_due_date,
    to_date('30-12-9999','dd-mm-yyyy')),'DD-MON-YYYY')
    due_date, ah.current_balance-ah.previous_balance amount,
    decode(ah.invoice_id,null,'A','I') transaction_type
    3 4 5 6 7 8 from account a,account_history ah,invoice i_+
    where a.account_id=ah.account_id
    and a.account_type_id=1000002
    and round(a.account_balance,2) > 0
    and (ah.invoice_id is not null or ah.adjustment_id is not null)
    and ah.CURRENT_BALANCE > ah.previous_balance
    and ah.invoice_id=i.invoice_id(+)
    AND a.account_balance > 0
    order by a.account_id,ah.effective_start_date desc; 9 10 11 12 13 14 15 16
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 544K| 30M| | 693K (20)|
    | 1 | SORT ORDER BY | | 544K| 30M| 75M| 693K (20)|
    |* 2 | HASH JOIN | | 544K| 30M| | 689K (20)|
    |* 3 | TABLE ACCESS FULL | ACCOUNT | 20080 | 294K| | 6220 (18)|
    |* 4 | HASH JOIN OUTER | | 131M| 5532M| 5155M| 678K (20)|
    |* 5 | TABLE ACCESS FULL| ACCOUNT_HISTORY | 131M| 3646M| | 197K (25)|
    | 6 | TABLE ACCESS FULL| INVOICE | 262M| 3758M| | 306K (18)|
    Predicate Information (identified by operation id):
    2 - access("A"."ACCOUNT_ID"="AH"."ACCOUNT_ID")
    3 - filter("A"."ACCOUNT_TYPE_ID"=1000002 AND "A"."ACCOUNT_BALANCE">0 AND
    ROUND("A"."ACCOUNT_BALANCE",2)>0)
    4 - access("AH"."INVOICE_ID"="I"."INVOICE_ID"(+))
    5 - filter("AH"."CURRENT_BALANCE">"AH"."PREVIOUS_BALANCE" AND ("AH"."INVOICE_ID"
    IS NOT NULL OR "AH"."ADJUSTMENT_ID" IS NOT NULL))
    22 rows selected.
    Index Details:+_
    SQL> select INDEX_OWNER,INDEX_NAME,COLUMN_NAME,TABLE_NAME from dba_ind_columns where
    2 table_name in ('INVOICE','ACCOUNT','ACCOUNT_HISTORY') order by 4;
    INDEX_OWNER INDEX_NAME COLUMN_NAME TABLE_NAME
    OPS$SVM_SRV4 P_ACCOUNT ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT CUSTOMER_NODE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_ACCOUNT_TYPE ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_PREVIOUS_INVOICE PREVIOUS_INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_LAST_MODIFIED_ACCOUNT LAST_MODIFIED ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE_ACCOUNT INVOICE_ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT SEQNR ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_INVOICE INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA CURRENT_BALANCE ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_LMOD LAST_MODIFIED ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_PAYMENT PAYMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADJUSTMENT ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_APPLIED_DT APPLIED_DATE ACCOUNT_HISTORY
    OPS$SVM_SRV4 P_INVOICE INVOICE_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE CUSTOMER_INVOICE_STR INVOICE
    OPS$SVM_SRV4 I_LAST_MODIFIED_INVOICE LAST_MODIFIED INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT ACCOUNT_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_BILL_RUN BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_INVOICE_TYPE INVOICE_TYPE_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_CUSTOMER_NODE CUSTOMER_NODE_ID INVOICE
    32 rows selected.
    Regards,
    Bathula
    Oracle-DBA

    I have some suggestions. But first, you realize that you have some redundant indexes, right? You have an index on account(account_name) and also account(account_name, account_id), and also account_history(invoice_id) and account_history(invoice_id, adjustment_id). No matter, I will suggest some new composite indexes.
    Also, you do not need two lines for these conditions:
    and round(a.account_balance, 2) > 0
    AND a.account_balance > 0
    You can just use: and a.account_balance >= 0.005
    So the formatted query isselect a.account_id,
           round(a.account_balance, 2) account_balance,
           nvl(ah.invoice_id, ah.adjustment_id) transaction_id,
           to_char(ah.effective_start_date, 'DD-MON-YYYY') transaction_date,
           to_char(nvl(i.payment_due_date, to_date('30-12-9999', 'dd-mm-yyyy')),
                   'DD-MON-YYYY') due_date,
           ah.current_balance - ah.previous_balance amount,
           decode(ah.invoice_id, null, 'A', 'I') transaction_type
      from account a, account_history ah, invoice i
    where a.account_id = ah.account_id
       and a.account_type_id = 1000002
       and (ah.invoice_id is not null or ah.adjustment_id is not null)
       and ah.CURRENT_BALANCE > ah.previous_balance
       and ah.invoice_id = i.invoice_id(+)
       AND a.account_balance >= .005
    order by a.account_id, ah.effective_start_date desc;You will probably want to select:
    1. From ACCOUNT first (your smaller table), for which you supply a literal on account_type_id. That should limit the accounts retrieved from ACCOUNT_HISTORY
    2. From ACCOUNT_HISTORY. We want to limit the records as much as possible on this table because of the outer join.
    3. INVOICE we want to access last because it seems to be least restricted, it is the biggest, and it has the outer join condition so it will manufacture rows to match as many rows as come back from account_history.
    Try the query above after creating the following composite indexes. The order of the columns is important:create index account_composite_i on account(account_type_id, account_balance, account_id);
    create index acct_history_comp_i on account_history(account_id, invoice_id, adjustment_id, current_balance, previous_balance, effective_start_date);
    create index invoice_composite_i on invoice(invoice_id, payment_due_date);All the columns used in the where clause will be indexed, in a logical order suited to the needs of the query. Plus each selected column is indexed as well so that we should not need to touch the tables at all to satisfy the query.
    Try the query after creating these indexes.
    A final suggestion is to try larger sort and hash area sizes and a manual workarea policy.alter session set workarea_size_policy = manual;
    alter session set sort_area_size = 2147483647;
    alter session set hash_area_size = 2147483647;

  • Oracle Text Index Query

    Hello
    Had a query on oracle Text Index.
    1. I have created a table with column ID as sequence & column description as Varchar2(500)
    2. Inserted 3 records
    3. I created the Oracle Text index on column "description" as INDEXTYPE IS CTXSYS.CONTEXT
    4. Run a select using "contains" , get the records as required.
    5. I insert another new record & commit;
    6. Run the same old query using contains but for the new records I get 0 records
    7. Drop the Index and Recreate the index using same old index on column "description" as INDEXTYPE IS CTXSYS.CONTEXT
    8. Run the same old query using contains but for the new records and now I get the records as required.
    Does that mean every time I insert new records I have to rebuild the Oracle Text Index ?
    Your Help will be much appreciated
    Regards
    Harshad

    You need to use some method of updating your index. You can drop and recreate or you can rebuild or you can use ctx_ddl.sync_index or you can include sync(on commit) in your parameters when you create the index or various other methods of periodic synchronization and optimization.

  • Performance issue with Oracle Text index

    Hi Experts,
    We are on Oracle 11.2..0.3 on Solaris 10. I have implemented Oracle Text in our environment and I am facing a strange performance issue that is happening in our environment.
    One sql having CONTAINS clause is taking forever - more than 20 minutes and still does not complete. This sql has a contains clause and an exists clause and a not exists clause.
    Now if I remove the exists clause and a not exists clause , it completes fast. but with those two clauses it is just taking forever. It is late night so i am not able to post the table and sql query details and will do so tomorrow but based on this general description, are there any pointers for me to review?
    sql query doing fine:
    SELECT
        U.CLNT_OID, U.USR_OID, S.MAILADDR
    FROM
        access_usr U
        INNER JOIN access_sia S
            ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
        WHERE U.CLNT_OID = 'ABCX32S'
        AND CONTAINS(LAST_NAME , 'TO%' ) >0
    --sql query that hangs forever:
    SELECT
        U.CLNT_OID, U.USR_OID, S.MAILADDR
    FROM
        access_usr U
        INNER JOIN access_sia S
            ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
        WHERE U.CLNT_OID = 'ABCX32S'
        AND CONTAINS(LAST_NAME , 'TO%' ) >0
    and exists (--one clause here wiht a few table joins)
    and not exists (--one clause here wiht a few table joins);
    --Now another strange thing I found is if instead of 'TO%' in this sql, if I were to use 'ZZ%' or 'L1%' it works fast but for 'TO%' it goes slow with those two exists not exists clauses!
    I will be most thankful for the inputs.
    OrauserN

    Hi Barbara,
    First of all, thanks a lot for reviewing the issue.
    Unluckily making the change to empty_stoplist did not work out. I am today copying the entire sql here that has this issue and will be most thankful for more insights/pointers on what can be done.
    Here is the entire sql:
    SELECT U.CLNT_OID,
           U.USR_OID,
           S.EMAILADDRESS,
           U.FIRST_NAME,
           U.LAST_NAME,
           S.JOBCODE,
           S.LOCATION,
           S.DEPARTMENT,
           S.ASSOCIATEID,
           S.ENTERPRISECOMPANYCODE,
           S.EMPLOYEEID,
           S.PAYGROUP,
           S.PRODUCTLOCALE
      FROM    ACCESS_USR U
           INNER JOIN
              ACCESS_SIA S
           ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
    WHERE     U.CLNT_OID = 'G39NY3D25942TXDA'
           AND EXISTS
                  (SELECT 1
                     FROM ACCESS_USR_GROUP_XREF UGX
                          INNER JOIN ACCESS_GROUP RELG
                             ON     RELG.CLNT_OID = UGX.CLNT_OID
                                AND RELG.GROUP_OID = UGX.GROUP_OID
                          INNER JOIN ACCESS_GROUP G
                             ON     G.CLNT_OID = RELG.CLNT_OID
                                AND G.GROUP_TYPE_OID = RELG.GROUP_TYPE_OID
                    WHERE     UGX.CLNT_OID = U.CLNT_OID
                          AND UGX.USR_OID = U.USR_OID
                          AND G.GROUP_OID = 920512943
                          AND UGX.INCLUDED = 1)
           AND NOT EXISTS
                      (SELECT 1
                         FROM    ACCESS_USR_GROUP_XREF UGX
                              INNER JOIN
                                 ACCESS_GROUP G
                              ON     G.CLNT_OID = UGX.CLNT_OID
                                 AND G.GROUP_OID = UGX.GROUP_OID
                        WHERE     UGX.CLNT_OID = U.CLNT_OID
                              AND UGX.USR_OID = U.USR_OID
                              AND G.GROUP_OID = 920512943
                              AND UGX.INCLUDED = 1)
           AND CONTAINS (U.LAST_NAME, 'Bon%') > 0;
    Like I said before if the EXISTS and NOT EXISTS clause are removed it works in sub-second. But with those EXISTS and NOT EXISTS CLAUSE IT TAKES ANY WHERE FROM 25 minutes to more than one hour.
    NOte also that it was not TO% but Bon% in the CONTAINS clause that is giving the issue - sorry that was wrong on my part.
    Also please see below the ORACLE TEXT index defined on the table ACCESS_USER:
    --definition of preferences used in the index:
    SET SERVEROUTPUT ON size unlimited
    WHENEVER SQLERROR EXIT SQL.SQLCODE
    DECLARE
       v_err       VARCHAR2 (1000);
       v_sqlcode   NUMBER;
       v_count     NUMBER;
    BEGIN
       ctxsys.ctx_ddl.create_preference ('cust_lexer', 'BASIC_LEXER');
       ctxsys.ctx_ddl.set_attribute ('cust_lexer', 'base_letter', 'YES'); -- removes diacritics
    EXCEPTION
       WHEN OTHERS
       THEN
          v_err := SQLERRM;
          v_sqlcode := SQLCODE;
          v_count := INSTR (v_err, 'DRG-10701');
          IF v_count > 0
          THEN
             DBMS_OUTPUT.put_line (
                'The required preference named CUST_LEXER with BASIC LEXER is already set up');
          ELSE
             RAISE;
          END IF;
    END;
    DECLARE
       v_err       VARCHAR2 (1000);
       v_sqlcode   NUMBER;
       v_count     NUMBER;
    BEGIN
       ctxsys.ctx_ddl.create_preference ('cust_wl', 'BASIC_WORDLIST');
       ctxsys.ctx_ddl.set_attribute ('cust_wl', 'SUBSTRING_INDEX', 'true'); -- to improve performance
    EXCEPTION
       WHEN OTHERS
       THEN
          v_err := SQLERRM;
          v_sqlcode := SQLCODE;
          v_count := INSTR (v_err, 'DRG-10701');
          IF v_count > 0
          THEN
             DBMS_OUTPUT.put_line (
                'The required preference named CUST_WL with BASIC WORDLIST is already set up');
          ELSE
             RAISE;
          END IF;
    END;
    --now below is the code of the index:
    CREATE INDEX ACCESS_USR_IDX3 ON ACCESS_USR
    (FIRST_NAME)
    INDEXTYPE IS CTXSYS.CONTEXT
    PARAMETERS('LEXER cust_lexer WORDLIST cust_wl SYNC (ON COMMIT)');
    CREATE INDEX ACCESS_USR_IDX4 ON ACCESS_USR
    (LAST_NAME)
    INDEXTYPE IS CTXSYS.CONTEXT
    PARAMETERS('LEXER cust_lexer WORDLIST cust_wl SYNC (ON COMMIT)');
    The strange thing is that, like I said, If I remove the exists clause the query returns very fast. Also if I modify the query to use only one NOT EXISTS clause and remove the other EXISTS clause it returns in less than one second.  Also if I remove the EXISTS clause and use only the NOT EXISTS  clause it returns in less than 4 seconds. But with both clauses it runs forever!
    When I tried to get dbms_xplan.display_cursor to get the query plan (for the case of both exists and not exists clause in the query), it said that previous statement's sql id was 0 or something like that so that I was not able to see the query plan. I will keep trying to get this plan (it takes 25 minutes to one hour each time but will get this info soon). Again any pointers are most helpful.
    Regards
    OrauserN

  • Discoverer report is taking much time to open

    Hi
    All the discoverer report are taking much time to open,even query in lov is taking 20 -25 min.s.We have restart the services but on result found.
    Please suggest what can be done ,my application is on 12.0.6.
    Regards

    This topic was discussed many times in the forum before, please see old threads for details and for the docs you need to refer to -- https://forums.oracle.com/forums/search.jspa?threadID=&q=Discoverer+AND+Slow&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
    Thanks,
    Hussein

  • ODS Activation is taking much time...

    Hi All,
    Some times ods activation is taking much time. Generally it takes 30 mins and some times it take 6 hours.
    If this activation is taking much, then if i check sm50 ...i can see that there is a piece of code is taking much time.
    SELECT
    COUNT(*) , "RECORDMODE"
    FROM
    "/BIC/B0000814000"
    WHERE
    "REQUEST" = :A0 AND "DATAPAKID" = :A1
    GROUP BY
    "RECORDMODE"#
    Could you please let me know what are the possiblites to solve this issue.
    thanks

    Hello,
    you have 2 options:
    1) as already mentioned, cleanup some old psa data or change log data from this psa table or
    2) create a addtional index for recordtype on this table via Tcode se11 -> indexes..
    Regards, Patrick Rieken.

  • Adding column is taking much time. How to avoid?

    ALTER TABLE CONTACT_DETAIL
    ADD (ISIMDSCONTACT_F NUMBER(1) DEFAULT 0 NOT NULL
    ,ISREACHCONTACT_F NUMBER(1) DEFAULT 0 NOT NULL
    Is there any way that to speed up the execution time of the query?
    It's more than 24 hrs completed after started running the above script.
    I do not know why it is taking much time.
    Size of the table is 30 MB.

    To add a column the row directory of every record must be rewritten.
    Obviously this will take time and produce redo.
    Whenever something is slow the first question you need to answer is
    'What is it waiting for?' You can do so by investigating by various v$ views.
    Also, after more than 200 'I can not be bothered to do any research on my own' questions, you should know you don't post here without posting a four digit version number and a platform,
    as volunteers aren't mind readers.
    If you want to continue to withheld information, please consider NOT posting here.
    Sybrand Bakker
    Senior Oracle DBA
    Experts: those who did read documentatiion and can be bothered to investigate their own problems.

Maybe you are looking for