Bad Query Performance in Oracle Text

Hello everyone, I have the following problem:
I have a table, TABLE_A from now on, a table of more or less 1,000.000 rows, with a CONTEXT index, using FILE_DATASTORE, CTXSYS.DEFAULT_STORAGE, CTXSYS.NULL_FILTER, CTXSYS.BASIC_LEXER and querying the index in the following way:
SELECT /*+FIRST_ROWS*/ A.ID, B.ID2, SCORE(1) FROM TABLE_A A, TABLE_B WHERE A.ID = B.ID AND CONTAINS(A.PATH, '<SOME KW>', 1) > 0 ORDER BY SCORE(1) DESC
where TABLE_B has another 1,000.000 rows.
The problem is that the query response time is much higher after some time of inactivity regarding those tables. How can I avoid this behavior?. The fact is that those inactivity times (not more than 20min) are core to my application, so I always get long long response times for my queries.
Is there any cache or cache time parameter that affects this behavior? I have checked the Oracle Text documentation without finding anything about that...
More data: I am using Oracle 9.2.0.1, but I have tested with the latest patches an the behavior is the same...
Thank you very much in advance.

Pablo,
This appears to be a generic database or OS issue, not a Text specific issue. It really depends on what your application is doing.
If your application is doing some other database activity such as queries or DMLs on other non-text tables, chances are Oracle Text related data blocks are being aged out of cache. You can either increase the db_cache_size init
parmater or try to keep the text tables and index tables blocks in cache using ALTER TABLE commands.
If your app is doing NON-database activity, then chances are your application is taking up much of the machine's physical memory such that OS is swapping ORACLE out of the memory. In which case, you may want to consider to add more memory to the machine or have ORACLE run on a separate machine by itself.

Similar Messages

  • Bad query performance - how to analyze it?

    Hi all,
    since 8 weeks we locate a bad query performance (round about 30% worse than before) in our BW system. At the moment we use a BIA on revision 49 with 4 blades (16GB).
    I have already read note 1318214 and analyzed that the most time is spend on the virtual provider(over 80%!).
    I´ve seen that a lot of time is spend on the "Datamanager":
    For example: It takes 0,76s to select 3.5million items in the relative provider and 78s!!! to select 0 items in the virtual provider.
    information from RSDDSTATTREXSERV:
    RFC Server    BIA client  BIA Kernel    ABAP RFC
    497          464              450               619
    So it seems to be a problem an the BW site, what can we do to improve the performance or analyse the query performance better.
    Best Regards,
    Jens

    Hi Jens,
    A few checks you may consider doing.
    BIA Availability :  Check the BI connection with BIA.
    Check if you need to rebuild BIA indices again. SAP recommends to do this often, to repair the degenerate indices or delete the indice which are not referenced any more.(eg data in the cube was compressed/deleted and the indices are no more needed.)
    Check the if BIA  reorganization is required - This is done to see the indices are evenly distribueded areoss the BIA Landscape.
    Try to find from BI Admin if major administration work was done within these 8 weeks.eg: Copy cube, dimension restructureing, copying data to some copy cube, archiving etc.
    You can use the BIA monitor to peform checks/monitor alerts from BIA servers
    [ BIA monitor|http://help.sap.com/saphelp_nw70/helpdata/en/43/7719d270d81a6ee10000000a11466f/content.htm]
    This link would tell you on the overall status of the BIA and any actions if required.
    Also it has sublinks to other important transaction of BIA monitoring and maintainnance.
    To go to BIA monitor : RSA!---> BIA monitor icon.
    Is your virtual provider reading data from R/3 or BW.
    Generally virtual providers are used to read data from other systems , so it woulfd not have an indices in BIA, I believe if this is the case. except for some applications like BCS wher eyou may be reading data from BW itself.
    Hope this helps
    Bext regards,
    Sunmit.

  • OAF page : How to get its query performance from Oracle Apps Screen?

    Hi Team,
    How to get the query performance of an OAF page using Oracle Apps Screen ??
    regards
    sridhar

    Go through this link
    Any tools to validate performance of an OAF Page?
    However do let us know as these queries performance can be check through backend also
    Thanks
    --Anil
    http://oracleanil.blogspot.com/

  • Performance of Oracle Text

    Hi,
    I'm tasked to help design an application that will have Oracle Text powering the searching logic. The application will have millions of records (in the 30 million to 50 million range), but there's a restriction that 95% of all searches must be able to complete in 1 second or less (!)
    So, my question is, is it possible for Oracle Text to meet this criteria? Assuming we have the best hardware, etc. Or should I look for another solution/approach?
    Regards,
    Roy

    Hi Roy,
    It's pretty hard to give a yes/no answer based on the limited information. I will say that Oracle's method of indexing is fairly standard (dictionary/postings list) so you are not likely to find a better solution if your records are stored in Oracle. The Oracle Text advantage - tight integration with the database already. You have storage and query optimization features of Oracle when using Oracle Text. < 1 sec response time is pretty tight for any search, but I don't think you'd have any better chance at hitting it with another solution.
    Thanks,
    Ron

  • Bad Query Performance

    Hi Experts,
    I have a Query which was built on a multiprovider,Which has a slow preformance.
    I think the main problem comes from selecting to many records from
    I think it selects 1,1 million rows to display about 500 rows in the result.
    Another point could be that the complicated restricted and calculated keyfigures, especially might spend a lot of time in the OLAP processor.
    Here are the Statistics of the Query.
    OLAP Initialization      :  3,186906
    Wait Time, User         :   56,971169
    OLAP: Settings               0,983193
    Read Cache                     0,015642
    Delete Cache                   0,019030
    Write Cache                    0,087655
    Data Manager                   462,039167
    OLAP: Data Selection      0,671566
    OLAP: Data Transfer       1,257884.
    ST03 Stat:
    %OLAP       :22,74
    %DB           :77,18
    OLAP Time  :29,2
    DBTime        :99,1
    It seems that the maximum time is consuming in the Database
    Any suggestion to speed up this Query response time would be great.
    Thanks in advance.
    BR
    Srini.

    Hi,
    You need to have standard Query performance tuning done for the underlying cubes like better design, aggregates, etc
    Improve Performance of Queries/Reports on Multi Cubes
    Refer SAP Note Number: 869487
    Performance optimization for MultiCubes
    How to Create Efficient Multi-Provider Queries
    Please see the How to Guide "How to Create Efficient MultiProvider Queries" at http://service.sap.com/bi > SAP NetWeaver 2004 - Release-Specific Information > How-to Guides > Business Intelligence
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/biw/how%20to%20create%20efficient%20multiprovider%20queries.pdf
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/3f66ba90-0201-0010-ac8d-b61d8fd9abe9
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/afbad390-0201-0010-daa4-9ef0168d41b6
    Performance of MultiProviders
    Multiprovider performance / aggregate question
    Query Performance
    Multicube performances
    Create Efficient MultiProvider Queries
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b03b7f4c-c270-2910-a8b8-91e0f6d77096
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/751be690-0201-0010-5e80-f4f92fb4e4ab
    Also try
    Achieving BI Query Performance Building Business Intelligence
    http://www.dmreview.com/issues/20051001/1038109-1.html
    tuning, short dumps
    Performance tuning in BW:
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/afbad390-0201-0010-daa4-9ef0168d41b6
    Also notes
    0000903559 MultiProvider optimization is only partially active
    0000825396 Performance in reports with many selections
    multiprovider explanation i need
    Note 629541 - Multiprovider: Parallel Processing 
    Thanks,
    JituK

  • Slow query performance in Oracle 10.2.0.3

    Hi,
    We have Oracle 10.2.0.3 installed on RHEL 5(64 bit).We have two queries out of which one is a query using select while other query is using a insert.First we executed insert query which inserts 10000 rows in a table and then select query on this table.This works fine in one thread.But when we do samething in 10 threads, at that time INSERT is fine but select is taking very long time for 10 threads.Any bug related to parallel execution of queries for SELECT in 10.2.0.3?Any suggestion??
    Thanks in advance.
    Regards,
    RJ.

    Justin,
    We have a same queries for INSERT and Select in 10 manual sessions outof which select query is taking more time to execute.Please refer to WAITs given below.No there is no bottleneck as far as hardware is concerned because we tested it on different configuration of servers.
    Event                    Waits            Time(s)          Avg Wait(ms)     % Total Call Time     Wait Class
    CPU time                52                                    93.2     
    latch: cache buffers chains     45,542          6          0               10.7               Concurrency
    log file parallel write          2,107          3          1               5.2               System I/O
    log file sync               805          2          2               3.5               Commit
    latch: session allocation     5,116          1          0               2.6               Other Wait Events
    •     s - second
    •     cs - centisecond - 100th of a second
    •     ms - millisecond - 1000th of a second
    •     us - microsecond - 1000000th of a second
    •     ordered by wait time desc, waits desc (idle events last)
    Event                    Waits     %Time-outs     Total Wait Time (s)     Avg wait (ms)     Waits /txn
    latch: cache buffers chains     45,542     0.00          6                    0     22.99
    log file parallel write          2,107     0.00          3                    1     1.06
    log file sync               805     0.00          2                    2     0.41
    latch: session allocation     5,116     0.00          1                    0     2.58
    buffer busy waits          20,482     0.00          1                    0     10.34
    db file sequential read          157     0.00          1                    4     0.08
    control file parallel write     1,330     0.00          0                    0     0.67
    wait list latch free          39     0.00          0                    10     0.02
    enq: TX - index contention     632     0.00          0                    0     0.32
    latch free               996     0.00          0                    0     0.50
    SQL*Net break/reset to client     1,738     0.00          0                    0     0.88
    SQL*Net message to client     108,947     0.00          0                    0     55.00
    os thread startup          2     0.00          0                    19     0.00
    cursor: pin S wait on X          3     100.00          0                    11     0.00
    latch: In memory undo latch     136     0.00          0                    0     0.07
    log file switch completion     4     0.00          0                    7     0.00
    latch: shared pool          119     0.00          0                    0     0.06
    latch: undo global data          121     0.00          0                    0     0.06
    buffer deadlock               238     99.58          0                    0     0.12
    control file sequential read     1,735     0.00          0                    0     0.88
    SQL*Net more data to client     506     0.00          0                    0     0.26
    log file single write          2     0.00          0                    2     0.00
    SQL*Net more data from client     269     0.00          0                    0     0.14
    reliable message          12     0.00          0                    0     0.01
    LGWR wait for redo copy          26     0.00          0                    0     0.01
    rdbms ipc reply               6     0.00          0                    0     0.00
    latch: library cache          7     0.00          0                    0     0.00
    latch: redo allocation          2     0.00          0                    0     0.00
    enq: RO - fast object reuse     2     0.00          0                    0     0.00
    direct path write          21     0.00          0                    0     0.01
    cursor: pin S               1     0.00          0                    0     0.00
    log file sequential read     2     0.00          0                    0     0.00
    direct path read          8     0.00          0                    0     0.00
    SQL*Net message from client     108,949     0.00          43,397                    398     55.00
    jobq slave wait               14,527     49.56          35,159                    2420     7.33
    Streams AQ: qmn slave idle wait     246     0.00          3,524                    14326     0.12
    Streams AQ:qmn coordinator-
    idle wait                451     45.45          3,524                    7814     0.23
    wait for unread message on -
    broadcast channel          3,597     100.00          3,516                    978     1.82
    virtual circuit status          120     100.00          3,516                    29298     0.06
    class slave wait          2     0.00          0                    0     0.00 Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv
    Message was edited by:
    RJiv

  • Poor performance using Oracle Text

    We are currently using wildcard queries and we have setup substring or prefix index which is recommended in Oracle's documentation in order to improve performance but we have not seen any improvements. Does anyone have any other recommendations?

    We are currently using wildcard queries and we have setup substring or prefix index which is recommended in Oracle's documentation in order to improve performance but we have not seen any improvements. Does anyone have any other recommendations?

  • Oracle text performance

    hi all.
    i have useing orcle text for the indexing purposes ..
    the below query goes for an wildcard search and it performance is very poor ..
    /* Formatted on 2009/08/11 16:06 (Formatter Plus v4.8.5) */
    SELECT *
      FROM (SELECT z.*, ROWNUM r
              FROM (SELECT   *
                        FROM (SELECT *
                                FROM (SELECT score (1) score,
                                             SUBSTR (note, 1, 200) note, tmplt_id,
                                             appl_name, appl_use, appl_reference,
                                             appl_entity, effctv_start_date,
                                             effctv_end_date, eq_name, note_id,
                                             Bfcommon.getvaluebasedontemplate
                                                                 (tmplt_id,
                                                                  note_id
                                                                 ) VALUE,
                                             (SELECT em_name
                                                FROM ip_eq
                                               WHERE eq_name = a.eq_name) em_name,
                                             Bfcommon.is_edit_allowed_note1
                                                       (a.note_id,
                                                        'PACRIM1\E317329',
                                                        SYSDATE,
                                                        SYSDATE
                                                       ) LOCKED
                                        FROM bf_note a
                                       WHERE tmplt_id NOT IN (19, 14, 16)
                                         AND effctv_start_date >=
                                                TO_DATE ('08/12/2008 00:00:00',
                                                         'MM/DD/YYYY HH24:MI:SS'
                                         AND (   effctv_end_date <=
                                                    TO_DATE
                                                          ('08/12/2009 00:00:00',
                                                           'MM/DD/YYYY HH24:MI:SS'
                                              OR effctv_end_date IS NULL
                                         AND contains (note, '%test%', 1) > 0) r
                              UNION
                              SELECT score (1) score, SUBSTR (note, 1, 200) note,
                                     tmplt_id, appl_name, appl_use,
                                     appl_reference, appl_entity,
                                     effctv_start_date, effctv_end_date, eq_name,
                                     a.note_id, b.trgt_name VALUE,
                                     (SELECT em_name
                                        FROM ip_eq
                                       WHERE eq_name = a.eq_name) em_name,
                                     Bfcommon.is_edit_allowed_note1
                                                       (a.note_id,
                                                        'PACRIM1\E317329',
                                                        SYSDATE,
                                                        SYSDATE
                                                       ) LOCKED
                                FROM bf_note a, om_limit_hist b
                               WHERE (   date_changed =
                                            (SELECT MAX (date_changed)
                                               FROM om_limit_hist h1
                                              WHERE date_changed <
                                                       (SELECT MAX (date_changed)
                                                          FROM om_limit_hist h2
                                                         WHERE h2.trgt_name =
                                                                       b.trgt_name)
                                                AND h1.trgt_name = b.trgt_name)
                                      OR date_changed =
                                               (SELECT MAX (date_changed)
                                                  FROM om_limit_hist h1
                                                 WHERE h1.trgt_name = b.trgt_name)
                                 AND b.note_id = a.note_id(+)
                                 AND tmplt_id = 19
                                 AND effctv_start_date >=
                                        TO_DATE ('08/12/2008 00:00:00',
                                                 'MM/DD/YYYY HH24:MI:SS'
                                 AND (   effctv_end_date <=
                                            TO_DATE ('08/12/2009 00:00:00',
                                                     'MM/DD/YYYY HH24:MI:SS'
                                      OR effctv_end_date IS NULL
                                 AND contains (note, '%test%', 1) > 0)
                    ORDER BY 1 DESC) z
             WHERE ROWNUM <= 50)
    WHERE r >= 1here it goes for the wild card search for the string test ...Plz tell me how to index it in this case ..
    and its plan is
    Execution Plan
    Plan hash value: 3535478881
    | Id  | Operation                            | Name                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                     |                     |    50 |   128K|       |   632   (1)| 00:00:08 |
    |*  1 |  VIEW                                |                     |    50 |   128K|       |   632   (1)| 00:00:08 |
    |*  2 |   COUNT STOPKEY                      |                     |       |       |       |         |     |
    |   3 |    VIEW                              |                     |    69 |   177K|       |   632   (1)| 00:00:08 |
    |*  4 |     SORT ORDER BY STOPKEY            |                     |    69 |   177K|   376K|   632   (1)| 00:00:08 |
    |   5 |      VIEW                            |                     |    69 |   177K|       |   590   (1)| 00:00:08 |
    |   6 |       SORT UNIQUE                    |                     |    69 |  7281 |       |   590   (2)| 00:00:08 |
    |   7 |        UNION-ALL                     |                     |       |       |       |         |     |
    |*  8 |         TABLE ACCESS BY INDEX ROWID  | BF_NOTE             |    68 |  7140 |       |   585   (1)| 00:00:08 |
    |*  9 |          DOMAIN INDEX                | BF_NOTE_TEXT_SEARCH |       |       |       |   221   (0)| 00:00:03 |
    |* 10 |         FILTER                       |                     |       |       |       |         |     |
    |  11 |          NESTED LOOPS                |                     |     1 |   141 |       |     3   (0)| 00:00:01 |
    |  12 |           TABLE ACCESS FULL          | OM_LIMIT_HIST       |     1 |    36 |       |     2   (0)| 00:00:01 |
    |* 13 |           TABLE ACCESS BY INDEX ROWID| BF_NOTE             |     1 |   105 |       |     1   (0)| 00:00:01 |
    |* 14 |            INDEX UNIQUE SCAN         | BF_NOTE_PK          |     1 |       |       |     1   (0)| 00:00:01 |
    |  15 |          SORT AGGREGATE              |                     |     1 |    23 |       |         |     |
    |* 16 |           INDEX RANGE SCAN           | OM_LIMIT_HIST_IDX1  |     1 |    23 |       |     0   (0)| 00:00:01 |
    |  17 |            SORT AGGREGATE            |                     |     1 |    23 |       |         |     |
    |* 18 |             INDEX RANGE SCAN         | OM_LIMIT_HIST_IDX1  |     1 |    23 |       |     0   (0)| 00:00:01 |
    |  19 |            SORT AGGREGATE            |                     |     1 |    23 |       |         |     |
    |* 20 |             INDEX RANGE SCAN         | OM_LIMIT_HIST_IDX1  |     1 |    23 |       |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("R">=1)
       2 - filter(ROWNUM<=50)
       4 - filter(ROWNUM<=50)
       8 - filter("EFFCTV_START_DATE">=TO_DATE(' 2008-08-12 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "TMPLT_ID"19 AND "TMPLT_ID"14 AND "TMPLT_ID"16 AND ("EFFCTV_END_DATE" IS NULL OR
                  "EFFCTV_END_DATE"<=TO_DATE(' 2009-08-12 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
       9 - access("CTXSYS"."CONTAINS"("NOTE",'%test%',1)>0)
      10 - filter("DATE_CHANGED"= (SELECT /*+ */ MAX("DATE_CHANGED") FROM "OM_LIMIT_HIST" "H1" WHERE
                  "H1"."TRGT_NAME"=:B1 AND "DATE_CHANGED"< (SELECT /*+ */ MAX("DATE_CHANGED") FROM "OM_LIMIT_HIST" "H2" WHER
    E
                  "H2"."TRGT_NAME"=:B2)) OR "DATE_CHANGED"= (SELECT /*+ */ MAX("DATE_CHANGED") FROM "OM_LIMIT_HIST" "H1"
                  WHERE "H1"."TRGT_NAME"=:B3))
      13 - filter("TMPLT_ID"=19 AND "EFFCTV_START_DATE">=TO_DATE(' 2008-08-12 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND "CTXSYS"."CONTAINS"("NOTE",'%test%',1)>0 AND ("EFFCTV_END_DATE" IS NULL OR
                  "EFFCTV_END_DATE"<=TO_DATE(' 2009-08-12 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
      14 - access("B"."NOTE_ID"="A"."NOTE_ID")
      16 - access("H1"."TRGT_NAME"=:B1 AND "DATE_CHANGED"< (SELECT /*+ */ MAX("DATE_CHANGED") FROM
                  "OM_LIMIT_HIST" "H2" WHERE "H2"."TRGT_NAME"=:B2))
           filter("DATE_CHANGED"< (SELECT /*+ */ MAX("DATE_CHANGED") FROM "OM_LIMIT_HIST" "H2" WHERE
                  "H2"."TRGT_NAME"=:B1))
      18 - access("H2"."TRGT_NAME"=:B1)
      20 - access("H1"."TRGT_NAME"=:B1)

    What version of Oracle are you using?
    Your sample query is a good example of the benefits and costs of 'mixed' queries, and the challenges of mixed query performance. Oracle 11g has some very helpful new features (search for SDATA) that can really improve performance. (Specifically, it looks like your query does some useful date-range bounding. You need to get that into the FT index).
    In the end, it's not going to be easy to look at your reasonably complex query, understand the data and relationships, and wave the magic wand to make the thing go fast.

  • Weblogic 8.1.6 and Oracle 9.2.0.8 - query performance

    Folks,
    We are upgrading WebLogic from 8.1.5 to 8.1.6 and Oracle from 9.2.0.6 to 9.2.0.8. We use the Oracle thin client driver for 9.2.0.8 to connect from the application to Oracle.
    When we use the following combination of the stack we see SQL query performance degradation: -
    Oracle 9.2.0.8 database, Oracle 9.2.0.8 driver, WL 8.1.6
    Oracle 9.2.0.8 database, Oracle 9.2.0.1 driver, WL 8.1.6
    We do not see the degradation in case of the following: -
    Oracle 9.2.0.8 database, Oracle 9.2.0.1 driver, WL 8.1.5
    Oracle 9.2.0.6 database, Oracle 9.2.0.1 driver, WL 8.1.5
    This shows that the problem could be with the WL 8.1.6 version and I was wondering if any of you have faced this before? The query retrieves a set of data from Oracle none of which contain the AsciiStream data type, which is noted as a problem in WL 8.1.6, but that too, only for WL JDBC drivers.
    Any ideas appreciated.

    Folks,
    We are upgrading WebLogic from 8.1.5 to 8.1.6 and Oracle from 9.2.0.6 to 9.2.0.8. We use the Oracle thin client driver for 9.2.0.8 to connect from the application to Oracle.
    When we use the following combination of the stack we see SQL query performance degradation: -
    Oracle 9.2.0.8 database, Oracle 9.2.0.8 driver, WL 8.1.6
    Oracle 9.2.0.8 database, Oracle 9.2.0.1 driver, WL 8.1.6
    We do not see the degradation in case of the following: -
    Oracle 9.2.0.8 database, Oracle 9.2.0.1 driver, WL 8.1.5
    Oracle 9.2.0.6 database, Oracle 9.2.0.1 driver, WL 8.1.5
    This shows that the problem could be with the WL 8.1.6 version and I was wondering if any of you have faced this before? The query retrieves a set of data from Oracle none of which contain the AsciiStream data type, which is noted as a problem in WL 8.1.6, but that too, only for WL JDBC drivers.
    Any ideas appreciated.

  • Poor query performance when joining CONTAINS to another table

    We just recently began evaluating Oracle Text for a search solution. We need to be able to search a table that can have over 20+ million rows. Each user may only have visibility to a tiny fraction of those rows. The goal is to have a single Oracle Text index that represents all of the searchable columns in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending order by score. What we're seeing is that query performance from TOAD is extremely fast when we write a simple CONTAINS query against the Oracle Text indexed table. However, when we attempt to first reduce the rows the CONTAINS query needs to search by using a WITH we find that the query performance degrades significantly.
    For example, we can find all the records a user has access to from our base table by the following query:
    SELECT d.duns_loc
    FROM duns d
    JOIN primary_contact pc
    ON d.duns_loc = pc.duns_loc
    AND pc.emp_id = :employeeID;
    This query can execute in <100 ms. In the working example, this query returns around 1200 rows of the primary key duns_loc.
    Our search query looks like this:
    SELECT score(1), d.*
    FROM duns d
    WHERE CONTAINS(TEXT_KEY, :search,1) > 0
    ORDER BY score(1) DESC;
    The :search value in this example will be 'highway'. The query can return 246k rows in around 2 seconds.
    2 seconds is good, but we should be able to have a much faster response if the search query did not have to search the entire table, right? Since each user can only "view" records they are assigned to we reckon that if the search operation only had to scan a tiny tiny percent of the TEXT index we should see faster (and more relevant) results. If we now write the following query:
    WITH subset
    AS
    (SELECT d.duns_loc
    FROM duns d
    JOIN primary_contact pc
    ON d.duns_loc = pc.duns_loc
    AND pc.emp_id = :employeeID
    SELECT score(1), d.*
    FROM duns d
    JOIN subset s
    ON d.duns_loc = s.duns_loc
    WHERE CONTAINS(TEXT_KEY, :search,1) > 0
    ORDER BY score(1) DESC;
    For reasons we have not been able to identify this query actually takes longer to execute than the sum of the durations of the contributing parts. This query takes over 6 seconds to run. We nor our DBA can seem to figure out why this query performs worse than a wide open search. The wide open search is not ideal as the query would end up returning records to the user they don't have access to view.
    Has anyone ever ran into something like this? Any suggestions on what to look at or where to go? If anyone would like more information to help in diagnosis than let me know and i'll be happy to produce it here.
    Thanks!!

    Sometimes it can be good to separate the tables into separate sub-query factoring (with) clauses or inline views in the from clause or an in clause as a where condition. Although there are some differences, using a sub-query factoring (with) clause is similar to using an inline view in the from clause. However, you should avoid duplication. You should not have the same table in two different places, as in your original query. You should have indexes on any columns that the tables are joined on, your statistics should be current, and your domain index should have regular synchronization, optimization, and periodically rebuild or drop and recreate to keep it performing with maximum efficiency. The following demonstration uses a composite domain index (cdi) with filter by, as suggested by Roger, then shows the explained plans for your original query, and various others. Your original query has nested loops. All of the others have the same plan without the nested loops. You could also add index hints.
    SCOTT@orcl_11gR2> -- tables:
    SCOTT@orcl_11gR2> CREATE TABLE duns
      2    (duns_loc  NUMBER,
      3       text_key  VARCHAR2 (30))
      4  /
    Table created.
    SCOTT@orcl_11gR2> CREATE TABLE primary_contact
      2    (duns_loc  NUMBER,
      3       emp_id       NUMBER)
      4  /
    Table created.
    SCOTT@orcl_11gR2> -- data:
    SCOTT@orcl_11gR2> INSERT INTO duns VALUES (1, 'highway')
      2  /
    1 row created.
    SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
      2  /
    1 row created.
    SCOTT@orcl_11gR2> INSERT INTO duns
      2  SELECT object_id, object_name
      3  FROM   all_objects
      4  WHERE  object_id > 1
      5  /
    76027 rows created.
    SCOTT@orcl_11gR2> INSERT INTO primary_contact
      2  SELECT object_id, namespace
      3  FROM   all_objects
      4  WHERE  object_id > 1
      5  /
    76027 rows created.
    SCOTT@orcl_11gR2> -- indexes:
    SCOTT@orcl_11gR2> CREATE INDEX duns_duns_loc_idx
      2  ON duns (duns_loc)
      3  /
    Index created.
    SCOTT@orcl_11gR2> CREATE INDEX primary_contact_duns_loc_idx
      2  ON primary_contact (duns_loc)
      3  /
    Index created.
    SCOTT@orcl_11gR2> -- composite domain index (cdi) with filter by clause
    SCOTT@orcl_11gR2> -- as suggested by Roger:
    SCOTT@orcl_11gR2> CREATE INDEX duns_text_key_idx
      2  ON duns (text_key)
      3  INDEXTYPE IS CTXSYS.CONTEXT
      4  FILTER BY duns_loc
      5  /
    Index created.
    SCOTT@orcl_11gR2> -- gather statistics:
    SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> -- variables:
    SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
    SCOTT@orcl_11gR2> EXEC :employeeid := 1
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
    SCOTT@orcl_11gR2> EXEC :search := 'highway'
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> -- original query:
    SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
    SCOTT@orcl_11gR2> WITH
      2    subset AS
      3        (SELECT d.duns_loc
      4         FROM      duns d
      5         JOIN      primary_contact pc
      6         ON      d.duns_loc = pc.duns_loc
      7         AND      pc.emp_id = :employeeID)
      8  SELECT score(1), d.*
      9  FROM   duns d
    10  JOIN   subset s
    11  ON     d.duns_loc = s.duns_loc
    12  WHERE  CONTAINS (TEXT_KEY, :search,1) > 0
    13  ORDER  BY score(1) DESC
    14  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 4228563783
    | Id  | Operation                      | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |                   |     2 |    84 |   121   (4)| 00:00:02 |
    |   1 |  SORT ORDER BY                 |                   |     2 |    84 |   121   (4)| 00:00:02 |
    |*  2 |   HASH JOIN                    |                   |     2 |    84 |   120   (3)| 00:00:02 |
    |   3 |    NESTED LOOPS                |                   |    38 |  1292 |    50   (2)| 00:00:01 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  5 |      DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  6 |     INDEX RANGE SCAN           | DUNS_DUNS_LOC_IDX |     1 |     5 |     1   (0)| 00:00:01 |
    |*  7 |    TABLE ACCESS FULL           | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("D"."DUNS_LOC"="PC"."DUNS_LOC")
       5 - access("CTXSYS"."CONTAINS"("D"."TEXT_KEY",:SEARCH,1)>0)
       6 - access("D"."DUNS_LOC"="D"."DUNS_LOC")
       7 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- queries with better plans (no nested loops):
    SCOTT@orcl_11gR2> -- subquery factoring (with) clauses:
    SCOTT@orcl_11gR2> WITH
      2    subset1 AS
      3        (SELECT pc.duns_loc
      4         FROM      primary_contact pc
      5         WHERE  pc.emp_id = :employeeID),
      6    subset2 AS
      7        (SELECT score(1), d.*
      8         FROM      duns d
      9         WHERE  CONTAINS (TEXT_KEY, :search,1) > 0)
    10  SELECT subset2.*
    11  FROM   subset1, subset2
    12  WHERE  subset1.duns_loc = subset2.duns_loc
    13  ORDER  BY score(1) DESC
    14  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- inline views (sub-queries in the from clause):
    SCOTT@orcl_11gR2> SELECT subset2.*
      2  FROM   (SELECT pc.duns_loc
      3            FROM   primary_contact pc
      4            WHERE  pc.emp_id = :employeeID) subset1,
      5           (SELECT score(1), d.*
      6            FROM   duns d
      7            WHERE  CONTAINS (TEXT_KEY, :search,1) > 0) subset2
      8  WHERE  subset1.duns_loc = subset2.duns_loc
      9  ORDER  BY score(1) DESC
    10  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- ansi join:
    SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
      2  FROM   duns
      3  JOIN   primary_contact
      4  ON     duns.duns_loc = primary_contact.duns_loc
      5  WHERE  CONTAINS (duns.text_key, :search, 1) > 0
      6  AND    primary_contact.emp_id = :employeeid
      7  ORDER  BY SCORE(1) DESC
      8  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- old join:
    SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
      2  FROM   duns, primary_contact
      3  WHERE  CONTAINS (duns.text_key, :search, 1) > 0
      4  AND    duns.duns_loc = primary_contact.duns_loc
      5  AND    primary_contact.emp_id = :employeeid
      6  ORDER  BY SCORE(1) DESC
      7  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- in clause:
    SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
      2  FROM   duns
      3  WHERE  CONTAINS (duns.text_key, :search, 1) > 0
      4  AND    duns.duns_loc IN
      5           (SELECT primary_contact.duns_loc
      6            FROM   primary_contact
      7            WHERE  primary_contact.emp_id = :employeeid)
      8  ORDER  BY SCORE(1) DESC
      9  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 3825821668
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN SEMI              |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2>

  • Oracle text Improve perfomance

    What is the best way to improve performance in Oracle text?
      I retrieve some data in a csv file, i verify the data in a table (CUSTOMER) to
      know if must make a INSERT or no.
    It make 10 seconds to process only two rows.
    How can i improve performance?

    What are you exactly doing? Do you have an Oracle Text index on that table, or are you just manipulating text in the table?
    Give us the code what you are doing and we can help you further.
    Herald ten Dam

  • How many ways can i improve query performance?

    Hi All,
    can any body help me
    How many ways can i improve query performance in oracle ?
    Thanks,
    narasimha

    As many as you can think of them!!!

  • Oracle text performance with context search indexes

    Search performance using context index.
    We are intending to move our search engine to a new one based on Oracle Text, but we are meeting some
    bad performance issues when using search.
    Our application allows the user to search stored documents by name, object identifier and annotations(formerly set on objects).
    For example, suppose I want to find a document named ImportSax2.c: according to user set parameters, our search engine format the following
    search queries :
    1) If the user explicitely ask for a search by document name, the query is the following one =>
         select objid FROM ADSOBJ WHERE CONTAINS( OBJFIELDURL , 'ImportSax2.c WITHIN objname' , 1 ) > 0;
    2) If the user don't specify any extra parameters, the query is the following one =>
         select objid FROM ADSOBJ WHERE CONTAINS( OBJFIELDURL , 'ImportSax2.c' , 1 ) > 0;
    Oracle text only need around 7 seconds to answer the second query, whereas it need around 50 seconds to give an answer for the first query.
    Here is a part of the sql script used for creating the Oracle Text index on the column OBJFIELDURL
    (this column stores a path to an xml file containing properties that have to be indexed for each object) :
    begin
    Ctx_Ddl.Create_Preference('wildcard_pref', 'BASIC_WORDLIST');
    ctx_ddl.set_attribute('wildcard_pref', 'wildcard_maxterms', 200) ;
    ctx_ddl.set_attribute('wildcard_pref','prefix_min_length',3);
    ctx_ddl.set_attribute('wildcard_pref','prefix_max_length',6);
    ctx_ddl.set_attribute('wildcard_pref','STEMMER','AUTO');
    ctx_ddl.set_attribute('wildcard_pref','fuzzy_match','AUTO');
    ctx_ddl.set_attribute('wildcard_pref','prefix_index','TRUE');
    ctx_ddl.set_attribute('wildcard_pref','substring_index','TRUE');
    end;
    begin
    ctx_ddl.create_preference('doc_lexer_perigee', 'BASIC_LEXER');
    ctx_ddl.set_attribute('doc_lexer_perigee', 'printjoins', '_-');
    ctx_ddl.set_attribute('doc_lexer_perigee', 'BASE_LETTER', 'YES');
    ctx_ddl.set_attribute('doc_lexer_perigee','index_themes','yes');
    ctx_ddl.create_preference('english_lexer','basic_lexer');
    ctx_ddl.set_attribute('english_lexer','index_themes','yes');
    ctx_ddl.set_attribute('english_lexer','theme_language','english');
    ctx_ddl.set_attribute('english_lexer', 'printjoins', '_-');
    ctx_ddl.set_attribute('english_lexer', 'BASE_LETTER', 'YES');
    ctx_ddl.create_preference('german_lexer','basic_lexer');
    ctx_ddl.set_attribute('german_lexer','composite','german');
    ctx_ddl.set_attribute('german_lexer','alternate_spelling','GERMAN');
    ctx_ddl.set_attribute('german_lexer','printjoins', '_-');
    ctx_ddl.set_attribute('german_lexer', 'BASE_LETTER', 'YES');
    ctx_ddl.set_attribute('german_lexer','NEW_GERMAN_SPELLING','YES');
    ctx_ddl.set_attribute('german_lexer','OVERRIDE_BASE_LETTER','TRUE');
    ctx_ddl.create_preference('japanese_lexer','JAPANESE_LEXER');
    ctx_ddl.create_preference('global_lexer', 'multi_lexer');
    ctx_ddl.add_sub_lexer('global_lexer','default','doc_lexer_perigee');
    ctx_ddl.add_sub_lexer('global_lexer','german','german_lexer','ger');
    ctx_ddl.add_sub_lexer('global_lexer','japanese','japanese_lexer','jpn');
    ctx_ddl.add_sub_lexer('global_lexer','english','english_lexer','en');
    end;
    begin
         ctx_ddl.create_section_group('axmlgroup', 'AUTO_SECTION_GROUP');
    end;
    drop index ADSOBJ_XOBJFIELDURL force;
    create index ADSOBJ_XOBJFIELDURL on ADSOBJ(OBJFIELDURL) indextype is ctxsys.context
    parameters
    ('datastore ctxsys.file_datastore
    filter ctxsys.inso_filter
    sync (on commit)
    lexer global_lexer
    language column OBJFIELDURLLANG
    charset column OBJFIELDURLCHARSET
    format column OBJFIELDURLFORMAT
    section group axmlgroup
    Wordlist wildcard_pref
    Oracle created a table named DR$ADSOBJ_XOBJFIELDURL$I which now contains around 25 millions records.
    ADSOBJ is the table contaings information for our documents,OBJFIELDURL is the field that contains the path to the xml file containing
    data to index. That file looks like this :
    <?xml version="1.0" encoding="UTF-8" ?>
    <fields>
    <OBJNAME><![CDATA[NomLnk_177527o.jpgp]]></OBJNAME>
    <OBJREM><![CDATA[Z_CARACT_141]]></OBJREM>
    <OBJID>295926o.jpgp</OBJID>
    </fields>
    Can someone tell me how I can make that kind of request
    "select objid FROM ADSOBJ WHERE CONTAINS( OBJFIELDURL , 'ImportSax2.c WITHIN objname' , 1 ) > 0;"
    run faster ?

    Below are the execution plan for both the 2 requests :
    select objid FROM ADSOBJ WHERE CONTAINS( OBJFIELDURL , 'ImportSax2.c WITHIN objname' , 1 ) > 0
    PLAN_TABLE_OUTPUT
    |     Id     | Operation                              |Name                         |Rows     |Bytes     |Cost (%CPU)|
    |     0     | SELECT STATEMENT                    |                              |1272     |119K     |     4     (0)     |
    |     1      | TABLE ACCESS BY INDEX ROWID     |ADSOBJ      |1272     |119K     |     4     (0)     |
    |     2      |     DOMAIN INDEX                    |ADSOBJ_XOBJFIELDURL     |          |          |     4     (0)     |
    Note
    - 'PLAN_TABLE' is old version
    Executed in 2 seconds
    select objid FROM ADSOBJ WHERE CONTAINS( OBJFIELDURL , 'ImportSax2.c' , 1 ) > 0
    PLAN_TABLE_OUTPUT
    |     Id     |Operation                              |Name                         |Rows     |Bytes     |Cost (%CPU)|
    |     0     | SELECT STATEMENT                    |                              |1272     |119K     |     4     (0)     |
    |     1     | TABLE ACCESS BY INDEX ROWID     |ADSOBJ                         |1272     |119K     |     4     (0)     |
    |     2     | DOMAIN INDEX                    |ADSOBJ_XOBJFIELDURL     |          |          |     4     (0)     |
    Sorry for the result formatting, I can't get it "easily" readable :(

  • Performance issues and options to reduce load with Oracle text implementation

    Hi Experts,
    My database on Oracle 11.2.0.2 on Linux. We have Oracle Text implemented for fuzzy search. Our oracle text indexes are defined as sync on commit as we can not afford to have stale data.  Now our application does literally thousands of inserts/updates/deletes to those columns where we have these Oracle text indexes defined. As a result, we are seeing a lot of performance impact due to the oracle text sync routines being called on each commit. We are doing the index optimization every night (full optimization every night at 3 am).  The oracle text index related internal operations are showing up as top sql in our AWR report and there are concerns that it is causing lot of load on the DB.  Since we do the full index optimization only once at night, I am thinking should I change that , and if I do so, will it help us?
    For example here are some data from my one day's AWR report:
    Elapsed Time (s)
    Executions
    Elapsed Time per Exec (s)
    %Total
    %CPU
    %IO
    SQL Id
    SQL Module
    SQL Text
    27,386.25
    305,441
    0.09
    16.50
    15.82
    9.98
    ddr8uck5s5kp3
    begin ctxsys.drvdml.com_sync_i...
    14,618.81
    213,980
    0.07
    8.81
    8.39
    27.79
    02yb6k216ntqf
    begin ctxsys.syncrn(:idxownid,...
    Full Text of above top sql:
    ddr8uck5s5kp3
    begin ctxsys.drvdml.com_sync_index(:idxname, :idxmem, :partname);
    end
    02yb6k216ntqf
    begin ctxsys.syncrn(:idxownid, :idxoname, :idxid, :ixpid, :rtabnm, :flg); end;
    Now if I do the full index optimization more often and not just once at night 3 PM, will that mean, the load on DB due to sync on commit will decrease? If yes how often should I optimized and doesn't the optimization itself lead to some load? Can someone suggest?
    Thanks,
    OrauserN

    You can query the ctx_parameters view to see what your default and maximum memory values are:
    SCOTT@orcl12c> COLUMN bytes    FORMAT 9,999,999,999
    SCOTT@orcl12c> COLUMN megabytes FORMAT 9,999,999,999
    SCOTT@orcl12c> SELECT par_name AS parameter,
      2          TO_NUMBER (par_value) AS bytes,
      3          par_value / 1048576 AS megabytes
      4  FROM   ctx_parameters
      5  WHERE  par_name IN ('DEFAULT_INDEX_MEMORY', 'MAX_INDEX_MEMORY')
      6  ORDER  BY par_name
      7  /
    PARAMETER                               BYTES      MEGABYTES
    DEFAULT_INDEX_MEMORY               67,108,864             64
    MAX_INDEX_MEMORY                1,073,741,824          1,024
    2 rows selected.
    You can set the memory value in your index parameters:
    SCOTT@orcl12c> CREATE INDEX EMPLOYEE_IDX01
      2  ON EMPLOYEES (EMP_NAME)
      3  INDEXTYPE IS CTXSYS.CONTEXT
      4  PARAMETERS ('SYNC (ON COMMIT) MEMORY 1024M')
      5  /
    Index created.
    You can also modify the default and maximum values using CTX_ADM.SET_PARAMETER:
    http://docs.oracle.com/cd/E11882_01/text.112/e24436/cadmpkg.htm#CCREF2096
    The following contains general guidelines for what to set the max_index_memory parameter and others to:
    http://docs.oracle.com/cd/E11882_01/text.112/e24435/aoptim.htm#CCAPP9274

  • Oracle Text Query taking too long

    When we run a query:
    select docid from Tbl1 where contains(doc,'queryterm',1)>0;
    on 2 million docs it runs in <2 seconds
    When we run an insert into another table based on a search:
    insert into Tbl2 (col1,col2) select 10,col2 from Tbl1 where rowid<2000; (10 in the select statement is a constant)
    it runs in <2 seconds
    Here's the kicker:
    insert into Tbl2 (col1,col2) select col1,col2 from Tbl1 where contains(doc,'queryterm',1)>0;
    it runs in 60 seconds and produces ~2k rows
    Is there any hint that we can use to fix this?
    TIA!

    We've looked hard at the performance notes for Oracle Text, the Application guide and the FAQ on it.
    We've dropped the index on the table being inserted, turn off logging and used the Parallel hint on the insert. There is still a bit of a disconnect between insert speed, select speed and both together. The index was built using the parallel option so the queries should be parallel if I understand the performance hints correctly.

Maybe you are looking for