Portal Context Index Creation Performance issue

Recreating Portal Context Indexes takes around 36 hours at our site (after portal upgrade from 3.0.9.8.2 to 3.0.9.8.5 as per release notes). I was following the Note:158368.1 to rebuild the indexes. Is there anything that i can do to tune this ?
thanks
subu

Unfortunately indexing is generally a fairly intensive operation and can be time consuming.
There are some things that you can do to optimize the performance of your database as a whole which may in turn help the performance of your indexing operation. Look at the Performance Guide and Reference book in the database documentation.
Much of the time spent indexing is taken up by filtering binary documents and fetch content identified by URL attributes. In the case of the later, it might be worth checking in the ctx_user_index_errors view to ensure that you don't have a lot of URL requests that are timing out. The timeout is set to 30 seconds and if there are a lot or URLs where the host cannot be resolved or the fetch times out it might be costing a lot of time during the indexing operation. This is often the case if a proxy is required to reach the URLs but the proxy has not be configured correctly.

Similar Messages

CONTEXT index creation - performance!

Hi,
I have a table with about 5Million rows. The content that needs to be indexed is of RAW datatype. The average size (length) of this field is about 50 characters (it could be more).
I am trying to index this column to perform a keyword search. DEtails are furnished below.
table:
SQL> desc kwtai
Name Null? Type
TSD_HH24 DATE
COUNTRY_CODE_ALPHA_2 VARCHAR2(2)
ONETWORK NUMBER(6)
OADDRESS VARCHAR2(25)
DNETWORK NUMBER(6)
DADDRESS VARCHAR2(25)
MESSAGE_LENGTH NUMBER
MESSAGE_CONTENT RAW(2000)
Preferences:-
begin
Ctx_Ddl.Create_Preference('mc_storage', 'BASIC_STORAGE');
ctx_ddl.set_attribute('mc_storage','I_TABLE_CLAUSE',
'tablespace large_index storage (initial 10M next 10M)');
ctx_ddl.set_attribute('mc_storage', 'K_TABLE_CLAUSE',
'tablespace large_index storage (initial 10M next 10M)');
ctx_ddl.set_attribute('mc_storage', 'R_TABLE_CLAUSE',
'tablespace large_index storage (initial 1M) lob (data) store as (cache)');
ctx_ddl.set_attribute('mc_storage', 'N_TABLE_CLAUSE',
'tablespace large_index storage (initial 1M)');
ctx_ddl.set_attribute('mc_storage', 'I_INDEX_CLAUSE',
'tablespace large_index storage (initial 1M) compress 2');
ctx_ddl.create_preference('mc_lex', 'BASIC_LEXER');
ctx_ddl.set_attribute('mc_lex', 'skipjoins', '_-"''`~!@#$%^&*()+=|}{[]\:;<>?/.,');
ctx_ddl.set_attribute('mc_lex', 'INDEX_STEMS','NONE');
end;
create index kwtaidx on kwtai (message_content) indextype is ctxsys.context
parameters (' lexer mc_lex storage mc_storage memory 500M ')
parallel 16;
This create index takes about 4 hours to complete on a 8CPU dual core machine.
This is on Oracle 10g (10.2.0.4)
The reason i am creating the index as opposed to syncing it is because the data gets loaded into this table only once a day and it gets cleared once my keyword analysis is done.
Any pointers to speed up the index creation will be really appreciated! Thanks in advance!

My base table has the text that needs to be indexed stored in the "MESSAGE_CONTENT" column which for now is RAW data type. The data stored in this table are in hex representation.
Some examples -
MESSAGE_CONTENT
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461206E69F16F
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461206E69C3B16F
6865792E2C2C77686174277320676F696E67206F6E2E2E2E7066206368616E67277320697320736F6D652072657374617572616E742E2074686579206172652070736564756F2D636F6F6C
54686520477265656B20616C7068616265742069732074686520736372697074207468617420686173206265656E
54686520477265656B20616C7068616265742069732074686520736372697074207468617420686173206265656E20706F73742D64617461
Now with your suggestion i tried to bypass this. So what i did was added a format column to my base table and updated it to "TEXT". My database is in UTF8.
Now when i create the index with the following preferences it takes less than a minute.
begin
Ctx_Ddl.Create_Preference('kwta_storage', 'BASIC_STORAGE');
ctx_ddl.set_attribute('kwta_storage','I_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 10M next 10M)');
ctx_ddl.set_attribute('kwta_storage', 'K_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 10M next 10M)');
ctx_ddl.set_attribute('kwta_storage', 'R_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M) lob (data) store as (cache)');
ctx_ddl.set_attribute('kwta_storage', 'N_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M)');
ctx_ddl.set_attribute('kwta_storage', 'I_INDEX_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M) compress 2');
ctx_ddl.create_preference('mylex', 'BASIC_LEXER');
ctx_ddl.set_attribute('mylex', 'skipjoins', '_-"''`~!@#$%^&*()+=|}{[]\:;<>?/,');
ctx_ddl.set_attribute('mylex','punctuations','.?!');
ctx_ddl.set_attribute('mylex', 'INDEX_STEMS','NONE');
ctx_ddl.set_attribute('mylex', 'continuation','\-');
Ctx_Ddl.Create_Stoplist ( 'mystop' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'is' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'has' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'the' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'that' );
end;
create index kwtaidx on kwtai (message_content) indextype is ctxsys.context
parameters ('filter ctxsys.auto_filter format column fmt stoplist mystop lexer mylex storage kwta_storage memory 500M')
parallel 16;
When i select distinct tokens from the $I table i get the following
TOKEN_TEXT
RESTAURANT
GREEK
WHATS
ARE
DELTA
ZETA
ALPHA
ALPHABET
EPSILON
PF
PSEDUOCOOL
SOME
CHANGS
NIÃO
ON
POSTDATA
SCRIPT
BEEN
GAMMA
GOING
HEY
NI
O
THEY
BETA
Now what i am also wondering is if the text (message_content column) is being converted to UTF8 (database characterset) by using AUTO_FILTER. Is my assumption correct? Not sure how to validate this?
And, would you kindly share of why RAW must not be used in this case?
Thanks for all your pointers!

Mappings Creation Performance Issue:

Mappings Creation Performance Issue
I am having a performance problem when linking attributes from Splitter Transformation (has app. 80 input ports and 9 different filter condition for 9 target tables) to other transformations. It takes app. 6 minutes to link one attribute from Splitter Transformation to other transformations; generally it should take less than a second. This is the problem only with Splitter Transformation, other transformations works very well.
Any thoughts on this will be very helpful.
Thanks
Ragu Mandala

Ragu,
Unfortunately this issue was introduced in 9.0.3.36.3 (lower versions did not have this... 'feature'). The issue has been rolled into the 9.2.0.3 version, but there is no backport for 9.0.3.
Any chance you can migrate to 9.2? or go back to 9.0.3.35?
Mark.

Faster Context index creation!!

Hi Experts,
I am new to the concept of CONTEXT in Oracle and I havent worked on it. My problem is that we have monthly process of rebuilding the context index on a table ( varchar column). This process takes about 8hrs. When I created it the last time I increased the sort_area_size parameter for the session to 500M,increased sort_multiblock_read_count and db_file_multiblock_read_count depending upon the OS limitations,and the index was created in 4 hrs. But this is just DBA trick to do things faster and i beleive it can be done more faster.
Can anyone suggest me what are the ways of speeding up the index creation process from the CONTEXT perspective
,like increasing default memory with Ctx_Adm.Set_Parameter ( 'DEFAULT_INDEX_MEMORY', '500M'); .
Also having default_index_memory and sort_area_size as 500, will this take 1000M of memory during the index creation?
Also i read somewhere that before creating index truncating the table DR$INDEX_ERROR will help speeding index creation. Is this right? I think it should not make a difference .
Any suggestion on speeding up the index creation would be helpful. i cannot create the index in parallel as I am running Oracle 8.1.6 and base table is not partitioned.
Thanks.
Ankur

Sorry for posting this question here. I have put in on TEXT forum.

Time for context Index Creation

Hi,
I am creating an context index in table having 10 million rows. But it is still running from 10 hours. Waht may be the expected time for completion
of creating this index.
Immediate replies are more helpful
Thanks,
Sri

Hi,
the answer is "it depends".
- what are you indexing? 10M rows with PDF documents or just simple plain text?
- what is your hardware?
- how is your index made-up? Is it just a plain index or do you use all kind of features (substring etc)?
- Which version of Oracle are you using?
In the oracle documentation you can find information about this issue: http://docs.oracle.com/cd/E11882_01/text.112/e24435/aoptim.htm#i1006756
Herald ten Dam
http://htendam.wordpress.com

Context Index and performance

Hi,
I want to create a context index on one column which contains large text. And the table contains millions of records and daily inserts happen into the same table. My question is
1.Do we need to run any procedures after inserting the records daily?
2.Is there any problem from performace point of view creating context index on the table
Thanks,
Sri

sri333 wrote:
Hi,
I want to create a context index on one column which contains large text. And the table contains millions of records and daily inserts happen into the same table. My question is
1.Do we need to run any procedures after inserting the records daily?Not for what you describe. But you didn't describe much. I guess you will do something with this table data later. It depends from that. But since you only mentioned that you insert. Then no there is nothing to do after that.
2.Is there any problem from performace point of view creating context index on the tableSure. Creating the index takes time. If the index is there new inserts will take more time.
Edited by: Sven W. on Oct 10, 2012 12:02 PM

Context Indexing creation error...

I cannot use context cartridge...
When I try to create index, i receive following error message:
SQL> create index myindex on x(name) indextype is ctxsys.context
2 parameters ('lexer mylexer wordlist mywordlist stoplist mystoplist');
create index myindex on x(name) indextype is ctxsys.context
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: ConText error:
ORA-06520: PL/SQL: Error loading external library
ORA-06522: z: cannot open shared object file: No such file or directory
ORA-06512: at "CTXSYS.DRUE", line 122
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 34
ORA-06512: at line 1
I listed below the libraries Oracle Context have installed:
SQL> select library_name, file_spec from dba_libraries where library_name
like 'DR%'
LIBRARY_NAME FILE_SPEC
DR$LIB
DR$LIBX z
As you can see these libraries have strange file_specs, but i dont know what right file_specs i must use...
Please help...
Best regards
Oleg

But the status of the context index is VALID on the view USER_INDEXES...
Besides lsnrctl says following about extproc:
LSNRCTL> status e
Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROCKEY))
STATUS of the LISTENER
Alias e
Version TNSLSNR for Linux: Version 8.1.5.0.0 - Production
Start Date 23-OCT-00 13:19:31
Uptime 1 days 2 hr. 21 min. 49 sec
Trace Level off
Security OFF
SNMP OFF
Listener Parameter File /pt01/app/oracle/product/8.1.5/network/admin/listener.ora
Listener Log File /pt01/app/oracle/product/8.1.5/network/log/e.log
Services Summary...
extproc has 1 service handler(s)
The command completed successfully
So, all is right with extproc...

Ctxsys.context index creation :ORA-01031: insufficient privileges on sys.XMLType

Hi,
in the following enviroment:
Oracle9i Enterprise Edition Release 9.0.1.1.1 - Production
With the Partitioning option
JServer Release 9.0.1.1.1 - Production
On an MS 2K box
I experience the following problem:
if I create a table
create table test(c type);
where type is varchar2 o clob I then succesfully issue this
command:
create index test_ctx on test(c) indextype is ctxsys.context;
but if type is sys.XMLType I get :
ORA-01031: insufficient privileges.
Any suggestion
Thanks
Alex

Under user sys as sysdba the following happens:
SQL> create table test(c XMLType);
Table created.
SQL> create index test_ctx on test(c) indextype is
ctxsys.context;
create index test_ctx on test(c) indextype is ctxsys.context
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE
routine
ORA-20000: Oracle Text error:
DRG-50857: oracle error in drixtab.create_index_tables
ORA-00955: name is already used by an existing object
ORA-06512: at "CTXSYS.DRUE", line 157
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 176

MAT View Creation Performance Issue

Hello Experts,
Below query is executing approximately in 1-3 sec.
select
COMMITMENT_ID,
FUNDING_RULE_ID,
reporting_year||'-'||reporting_period as RepPeriod,
GET_START_DAY_OF_PERIOD (FUNDING_RULE_ID, reporting_year, reporting_period) START_DAY_OF_PERIODt,
GET_END_DAY_OF_PERIOD(FUNDING_RULE_ID, reporting_year, reporting_period) END_DAY_OF_PERIOD
from
(select
COMMITMENT_ID,
FR_ID as FUNDING_RULE_ID,
COMT_START_DATE,
--COMT_TERMINATION_DATE,
GETREPYEARFROMDATE(COMT_START_DATE,FR_ID) as reporting_year,
GETREPORTINGPERIOD(to_char(COMT_START_DATE, 'mm') ,FR_ID) as reporting_period
from
    select
    COMMITMENT_ID,
    COMT_START_DATE,
    --COMT_TERMINATION_DATE,
    COALESCE(CB_FUNDING_RULE_ID,NC_FUNDING_RULE_ID) FR_ID
    from
    (COMMITMENT_TABLE left outer join (CHILD_BENEFICIARY_TABLE left outer join FUNDING_RULE_TABLE a on
    a.FUNDING_RULE_ID = CB_FUNDING_RULE_ID )
    on COMT_BENEFICIARY_REF = CB_BENEFICIARY_REF
    left outer join (NON_CHILD_BENEFICIARY_TABLE left outer join FUNDING_RULE_TABLE b on
    b.FUNDING_RULE_ID = NC_FUNDING_RULE_ID)
    on
     COMT_BENEFICIARY_REF = NC_BENEFICIARY_REF)
The query is returning 4.5 lacks of rows.
I want to create a MAT view by using above query and refresh this on daily basis.
But the MAT view creation is taking more time near about 401sec (6.68min).
Why the MAT view is taking more time?
MAT_VIEW
CREATE MATERIALIZED VIEW "REP_PERIOD_START_END_DATE"
AS select
COMMITMENT_ID,
FUNDING_RULE_ID,
reporting_year||'-'||reporting_period as RepPeriod,
GET_START_DAY_OF_PERIOD (FUNDING_RULE_ID, reporting_year, reporting_period) START_DAY_OF_PERIODt,
GET_END_DAY_OF_PERIOD(FUNDING_RULE_ID, reporting_year, reporting_period) END_DAY_OF_PERIOD
from
(select
COMMITMENT_ID,
FR_ID as FUNDING_RULE_ID,
COMT_START_DATE,
--COMT_TERMINATION_DATE,
GETREPYEARFROMDATE(COMT_START_DATE,FR_ID) as reporting_year,
GETREPORTINGPERIOD(to_char(COMT_START_DATE, 'mm') ,FR_ID) as reporting_period
from
    select
    COMMITMENT_ID,
    COMT_START_DATE,
    --COMT_TERMINATION_DATE,
    COALESCE(CB_FUNDING_RULE_ID,NC_FUNDING_RULE_ID) FR_ID
    from
    (COMMITMENT_TABLE left outer join (CHILD_BENEFICIARY_TABLE left outer join FUNDING_RULE_TABLE a on
    a.FUNDING_RULE_ID = CB_FUNDING_RULE_ID )
    on COMT_BENEFICIARY_REF = CB_BENEFICIARY_REF
    left outer join (NON_CHILD_BENEFICIARY_TABLE left outer join FUNDING_RULE_TABLE b on
    b.FUNDING_RULE_ID = NC_FUNDING_RULE_ID)
    on
     COMT_BENEFICIARY_REF = NC_BENEFICIARY_REF)
Is there any way to make the MAT view creation within 3 minutes?

CREATE MATERIALIZED VIEW "REP_PERIOD_START_END_DATE"
AS
with tab as
select /*+ materialize */ commitment_id,
                       comt_start_date,
                       --COMT_TERMINATION_DATE,
                       coalesce (cb_funding_rule_id, nc_funding_rule_id)
                          fr_id
                  from (      commitment_table
                           left outer join
                              (   child_beneficiary_table
                               left outer join
                                  funding_rule_table a
                               on a.funding_rule_id = cb_funding_rule_id)
                           on comt_beneficiary_ref = cb_beneficiary_ref
                        left outer join
                           (   non_child_beneficiary_table
                            left outer join
                               funding_rule_table b
                            on b.funding_rule_id = nc_funding_rule_id)
                        on comt_beneficiary_ref = nc_beneficiary_ref)
select commitment_id,
       funding_rule_id,
       reporting_year || '-' || reporting_period as repperiod,
       get_start_day_of_period (funding_rule_id,
                                reporting_year,
                                reporting_period)
          start_day_of_periodt,
       get_end_day_of_period (funding_rule_id,
                              reporting_year,
                              reporting_period)
          end_day_of_period
from (select commitment_id,
               fr_id as funding_rule_id,
               comt_start_date,
               --COMT_TERMINATION_DATE,
               getrepyearfromdate (comt_start_date, fr_id) as reporting_year,
               getreportingperiod (to_char (comt_start_date, 'mm'), fr_id)
                  as reporting_period
          from tab);

Context Indexing Performance

If anyone can look at this that would be of great help.
The context index creation for a million rows is taking forever. We had let it run for 10 or so hours and it still was not finished so we had to cancel it.
We are creating the index as follows:
create index content_version_text_idx on content_version
(dummy_indexed_column)
indextype IS ctxsys.context parameters('datastore concat_cols_datastore sync (on commit)
section group ctxsys.auto_section_group');
The procedure used above in indexing is this:
CREATE OR REPLACE procedure concat_cols
(p_rowid IN ROWID,
p_clob IN OUT clob)
AS
v_clob CLOB :='';
title varchar2(7) := '<title>';
titlec varchar2(8) := '</title>';
detail varchar2(6) := '<DATA>';
detailc varchar2(7) := '</DATA>';
meta varchar2(6) := '<META>';
metac varchar2(7) := '</META>';
localecode varchar2(8) := '<LOCALE>';
localecodec varchar2(9) := '</LOCALE>';
BEGIN
FOR c1 IN
(SELECT content_id, content_data_id, version_number, content_title, isactive_flag
from content_version
WHERE ROWID = p_rowid
LOOP
FOR c0 IN
(SELECT ' ' || locale_iso_code as data
FROM content a1
WHERE c1.content_id = a1.content_id
LOOP
v_clob := v_clob || localecode;
v_clob := v_clob || c0.data;
v_clob := v_clob || localecodec;
END LOOP;
v_clob := v_clob || title;
v_clob := v_clob || c1.content_title;
v_clob := v_clob || titlec;
FOR c3 IN
(SELECT ' ' || content_data as data
FROM content_data b
WHERE b.content_data_id = c1.content_data_id
AND c1.isactive_flag = 1)
LOOP
v_clob := v_clob || detail;
v_clob := v_clob || c3.data;
v_clob := v_clob || detailc;
END LOOP;
FOR c4 IN
(SELECT ' ' || short_string_value || ' ' || long_string_value as data
FROM meta_value d
WHERE d.content_id = c1.content_id
AND d.version_number = c1.version_number
AND c1.isactive_flag = 1)
LOOP
v_clob := v_clob || meta;
v_clob := v_clob || c4.data;
v_clob := v_clob || metac;
END LOOP;
END LOOP;
p_clob := v_clob;
END concat_cols;
Anyone any ideas ?

OK have managed to reduce the indexing time by removing the xml tagging in the loop, instead am now using the sql to construct the tags when doing the select. so the sqls have now changed to
SELECT ' <data>'||content_data||'</data>' as data
FROM content_data b
WHERE b.content_data_id = c1.content_data_id
This change has brought the time for 30MB of data from around 8 mins to around 4.30 mins. Have noticed in the log that there are some rows that is taking lot of time to be indexed and because of that think that it is loosing around 40 seconds. Have turned on the logging to print the rowid but not sure what is causing these rows longer indexing time, these rows do not seem to contain any more data then the other rows.

Slow spatial index creation

Hi,
I am using v11.2.0.2 and it took 9.5 hours to create a spatial index for 88 million geodetic points. The table itself was created in 15 minutes (with a CTAS from another table with lat/lons) and only has two columns: ULL and GEOM. Does this seem excessive? What can I do to reduce the time to create the spatial index?
CREATE INDEX POINT_LL_SIDX ON POINT_LL (GEOM) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('TABLESPACE=ORDERS_IDX WORK_TABLESPACE=ORDERS_03 LAYER_GTYPE=POINT')Thanks,
David

Hi David,
If you have several CPU cores in your computer, you may try to create your spatial index in parallel,
especially, you can create a partitioned table and create a local spatial index on it in parallel.
BTW, on 11.2.0.2, bug 9588219 may affect index creation performance. Please get a patch for it,
or try your test case on 11.2.0.3.
Thanks,
Ying
Edited by: yhu on Jun 13, 2012 7:19 AM

Performance issues with the Vouchers index build in SES

Hi All,
We are currently performing an upgrade for: PS FSCM 9.1 to PS FSCM 9.2.
As a part of the upgrade, Client wants Oracle SES to be deployed for some modules including, Purchasing, Payables (Vouchers)
We are facing severe performance issues with the Vouchers index build. (Volume of data = approx. 8.5 million rows of data)
The index creation process runs for over 5 days.
Can you please share any information or issues that you may have faced on your project and how they were addressed?

Check the following logs for errors:
1. The message log from the process scheduler
2. search_server1-diagnostic.log in /search_server1/logs directory
If the build is getting stuck while crawling then we typically have to increase the Java Heap size for the Weblogic instance for SES>

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

Creation of context index on index-organized tables

I encountered a problem when creating a domain index(intermediate text context index) on a index-organised table in oracle 8i.
The description of the error is stated below:
"ORA-29866: cannot create domain index on a column of index-organized table "
I have configured intermediate text properly and even it worked for those tables which are not index-organised(ordinary tables).
This problem has occured only when i made the tables as index organised.
Please provide us a solution to this problem as early as possible.
In case if you require any more details i shall provide them.

creation of domain indexes (such as context) on iot's
is not currently supported in oracle.

Performance issue in Portal Reports

Hi
We are experiencing a serious performance issue, in a report, and need a urgent fix on this issue.
The report is a Reports From SQL Query report, I need to find a way to dynamically make/create the where clause otherwise I have to make the statement in a way the exclude the use of indexes.
Full-table-scan is not a valid option here; the number or records is simply too high (several millions its a datawarehouse solution). In the Developer packaged, we can make the where clause dynamically, this basic yet extremely important feature, is essential to all database application.
We need to know how to do it, and if this functionality is not natively supported, then this should be one of the priority one functionalities to implement in future releases.
However, what do I do for now?
Thank in advance

I have found a temporary workaround, by editing the where clause in the stored procedure manually. However this fix have to be done every time a change have been committed in the wizard, so it is still not a solution to go for indefinitely, but its ok for now.

Portal Context Index Creation Performance issue

Similar Messages

Maybe you are looking for