Oracle Text/Intermedia issue

Hi Friends,
To implement search capabilities in my oracle database, iam trying to install and configure intermedia. While doing this i came across a few issues:
1. In Our current setup we wish to use Oracle intermedia. All we need is to be able to create ctxsys.context index and query our tables using CONTAINS keyword. Do we need to install Oracle intermedia for this or Oracle Text is enough or these two are tied together?
2. After intermedia install, I found that 4-5 tables with names DR$indexname are created. Do we need to take into account any memory allocation issues while creating this index(ctxsys.context )?
3. Also the query takes longer time to retrieve results. What are the considerations to optimize the query? (The table that I am querying has about 5000 records and I created ctxsys.context index for two fields of sizes varchar2(4000) and varchar2(2000) )
Any help on this wd be highly appreciated.
Thanks in Anticipation.
Deeps

1. In Oracle 9i you need only Oracle Text, no need to install Intermedia
2. Yes and you can control in which tablespace you want to create this table. You can control this when creating the datastore (Please double check about datastore as I don't remember exactly where to specify the storage clause)
3. This is difficult to answer unless we have more details like tables, query and execution plan etc. But in general you should analyze the table and indexes as well. Are you using fuzzy, soundex, stem or % search?

Similar Messages

Oracle Text Storage Issue

Hi Everyone,
My name is John and I just have 3 small queries which your expertise and assistance is greatly needed and appreciated.
I'm currently using Oracle Text on Oracle 10g Enterprise Edition Release 10.2.0.2.0 database and experiencing some kind of space storage problem. I have a table with 2 BLOB columns. One of the column is storing the TIF image file and the other column is storing the TIF's OCR version in PDF format. We are indexing on the PDF format column for rapid text retrieval. As we are loading them into the table, the index and table tablespaces were used up very rapidly. I've used and created my context index storage using the statements below:
ctx_ddl.create_preference('OCR_DOC_OCR_CONTENT_I_STORAGE','BASIC_STORAGE');
ctx_ddl.set_attribute('OCR_DOC_OCR_CONTENT_I_STORAGE','I_INDEX_CLAUSE',
'tablespace TS_OCR_IDX_LGE compress 2');
ctx_ddl.set_attribute('OCR_DOC_OCR_CONTENT_I_STORAGE','I_TABLE_CLAUSE',
'tablespace TS_OCR_IDX_LGE');
ctx_ddl.set_attribute('OCR_DOC_OCR_CONTENT_I_STORAGE','K_TABLE_CLAUSE',
'tablespace TS_OCR_IDX_LGE');
ctx_ddl.set_attribute('OCR_DOC_OCR_CONTENT_I_STORAGE','N_TABLE_CLAUSE',
'tablespace TS_OCR_IDX_LGE');
ctx_ddl.set_attribute('OCR_DOC_OCR_CONTENT_I_STORAGE','P_TABLE_CLAUSE',
'tablespace TS_OCR_IDX_LGE');
ctx_ddl.set_attribute('OCR_DOC_OCR_CONTENT_I_STORAGE','R_TABLE_CLAUSE',
'tablespace TS_OCR_IDX_LGE lob (data) store as (cache)');
I've created my table using the following commands below:
create table OCR_DOCUMENT (
DOC_ID number
,DOC_NAME varchar2(255)
,DOC_DIRECTORY varchar2(255)
,DOC_EXTENSION varchar2(10)
,DOC_CONTENT blob
,OCR_EXTENSION varchar2(10)
,OCR_CONTENT blob
,HAS_BLOB varchar2(1)
,CREATED_DATETIME date
,FILE_NAME VARCHAR2(2000)
,DW_DOC_ID NUMBER
,PAGE_NO NUMBER
,DOC_TYPE VARCHAR2(100)
,DOC_CLASS VARCHAR2(100)
,DOC_DESCRIPTION VARCHAR2(2000)
,PAGES NUMBER(10)
,CLT_NUMBER NUMBER(10)
,TAXENT_NUMBER NUMBER(10)
,REG_DATE DATE
,TAX_YEAR VARCHAR2(20)
,ORIG_FILE_NAME VARCHAR2(2000)
tablespace TS_OCR_TBL_LGE
pctfree 5 initrans 2 maxtrans 255
nologging noparallel;
My first question is, is there anything wrong with my storage clauses so I can improve and save some additional space?
Second question is, is there a way that I can compress and save some space on the table blob columns, i.e. DOC_CONTENT and OCR_CONTENT, without affecting the document service retreival?
Because at the beginning of the project, I've used utl_compress.lz_uncompress to compress the BLOB content before storing them to the table but I soon ditched such idea after finding out when I attempt to retrieve the compressed BLOB content using ctx_doc.markup for highlight document service (to highlight the text which I've used in my searching), it displayed some sort of garbage text information and I could not find any workaround to it.
Also, if we are preapred NOT to use the THEME and GIST features of Oracle Text, can I perhaps remove them to save some addition space? Any feedback that I can save space would be welcomed and appreciated. Have a nice day.
Thanks and Regards,
John

The BEST solution to your problem is to move to 11gRelease1
I am not sure how feasible that will be on your part, but 11gR1 have exactly the same capabilities as you are looking for.
You can compress, deduplicate all the LOB fields (with SECUREFILE clause) in all the tables including internal index tables ($R etc) and the base table (OCR_DOCUMENT).
This is just for your information.
I dont reallyhave any other information to share with you to resolve your problem :(

APEX app using Oracle Text to index pages that require authorzation

Hi Gurus and APEX Dev team
My team need to develop an APEX App that will index all our documents spread across various servers. Some of the documents require Single sign on access (e.g. KIX.oraclecorp.com) and some require other authorization methods (e.g. Metalink) . The Question is , Is it possible to index the pages that require authorization using Oracle text. If yes How? I have implemented the demo app which can index pages that do not require authorization.
Thanks a million
regards
Bala

Hello,
Unless I misunderstand you, the fact that the pages require authentication doesn't really matter, it is the underlying data you want to index correct? If so then you would index them in exactly the same way that you would index any table data using Oracle Text/interMedia.
John.
Blog: http://jes.blogs.shellprompt.net
Work: http://www.apex-evangelists.com
Author of Pro Application Express: http://tinyurl.com/3gu7cd
REWARDS: Please remember to mark helpful or correct posts on the forum, not just for my answers but for everyone!

Issues using Oracle Text conditions

Hi all,
I'm facing an issue executing a query on a VIEW using Oracle Text Indexes.
The DB version I'm using is "Enterprise 9.2.0.5".
TEST_VIEW is an sql-view that has a query on several tables where one of them has two Oracle Text indexes, one on field FIELD2 and another on FIELD3
executing this query I get 10 rows:
select *
from TEST_VIEW
where FIELD1 = 1001 -- regular condition
and (contains(FIELD2, 'Blitz') > 0 ) -- Oracle text condition
But if I add another condition on an existent Oracle Text Index, I'll get only 1 row:
select *
from TEST_VIEW
where FIELD1 = 1001
where (contains(FIELD2, 'Blitz') > 0 OR contains(FIELD3, 'Blitz') > 0)
As you can see the third condition was added using a logical OR, so I should get at least 10 rows ...
Can anyone help me ?
ThaNks in advance.
Eduardo.

Eduardo,
Without a full test case, it is hard to see if there is something wrong or not. I did the following, and all worked fine on my 10g instance. I had to assume some things, but I at least think I have the basic gist of your inquiry in this example. Run it/change it to match your situation, and post back when you can.
Thanks,
Ron
CREATE TABLE Z_TEST1 (
FIELD1 VARCHAR2(30));
INSERT INTO Z_TEST1
VALUES ('QUICK');
INSERT INTO Z_TEST1
VALUES ('BROWN');
INSERT INTO Z_TEST1
VALUES ('FOX');
INSERT INTO Z_TEST1
VALUES ('QUICK');
INSERT INTO Z_TEST1
VALUES ('BROWN');
INSERT INTO Z_TEST1
VALUES ('FOX');
CREATE TABLE Z_TEST2 (
FIELD2 VARCHAR2(30));
INSERT INTO Z_TEST2
VALUES ('JUMPED');
INSERT INTO Z_TEST2
VALUES ('OVER');
INSERT INTO Z_TEST2
VALUES ('LAZY');
INSERT INTO Z_TEST2
VALUES ('DOG');
INSERT INTO Z_TEST2
VALUES ('QUICK');
INSERT INTO Z_TEST2
VALUES ('BROWN');
INSERT INTO Z_TEST2
VALUES ('FOX');
commit;
CREATE VIEW TEST_VIEW
AS
SELECT Z_TEST1.FIELD1 AS "FIELD1", Z_TEST2.FIELD2 AS "FIELD2"
FROM Z_TEST1, Z_TEST2;
CREATE INDEX Z_TEST1_IDX ON Z_TEST1(FIELD1)
INDEXTYPE IS CTXSYS.CONTEXT;
CREATE INDEX Z_TEST2_IDX ON Z_TEST2(FIELD2)
INDEXTYPE IS CTXSYS.CONTEXT;
select *
from TEST_VIEW
where CONTAINS(FIELD1, 'FOX') > 0;
14 rows
select *
from TEST_VIEW
where (CONTAINS(FIELD1, 'FOX') > 0 OR CONTAINS(FIELD2, 'FOX') > 0);
18 rows

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

Oracle text - issue with contains query

Hello,
Need urgent help.
Following code in my procedure is giving me error.
TYPE c_1 is ref cursor;
result_cursor c1;
i_text2 := 'NEW%';
open result_cursor for
'select /*+ INDEX_SS_DESC(e cad_addr_idx2 )*/
from cad_address
where
contains(text, {:i_text2}, 1) > 0
and rec_type in (1,2,3,4)
order by occur_count desc'
using
i_text2;
ORA-00936: missing expression
ORA-06512: at "AV_OWNER.MY_PROC", line 43
ORA-06512: at line 6
Oracle version is 11.2.0.3.0.
Thanks,

check your table is 'text indexed' on this 'Text' column.To knoow more about 'text index' go to
http://docs.oracle.com/cd/B19306_01/text.102/b14217/ind.htm
Also refer to the below thread where someone had faced issues with CONTAINS clause.
ORA-20000: Oracle Text error: DRG-10599: column is not indexed

Oracle Text Issue XE

I have an XE Database 11.2 on Windows, with Oracle text 11.2.0.2.0, all object verified, which has one imported Apex Application that was exported form Oracle 10 without issue.
I used data pump to populate the underlying application tables, which has also been successful, but need to recreate the text indexes in the target 11.2 instance.
I used ctx_report.create_index_script to create the 4 scripts I needed, no issue.
When running the first script on the target instance it all executed OK except for the "create index" section, and I cant seem to get around the issue.
The part of the script that fails is
create index "SCHEMA_OWNER"."A_INDEX1"
on "SCHEMA_OWNER"."A"
("A1")
indextype is ctxsys.context
parameters('
datastore       "A_INDEX1_DST"
filter              "A_INDEX1_FIL"
section group   "A_INDEX1_SGP"
lexer           "A_INDEX1_LEX"
wordlist        "A_INDEX1_WDL"
stoplist        "A_INDEX1_SPL"
storage         "A_INDEX1_STO"
Which returns the following errors
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-50857: oracle error in drvxtab.create_index_tables
ORA-00905: missing keyword
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 366
Can anyone help point me in the right direction, going slightly mad.

Thanks for the help, it's much appreciated.
I have truncated the stoplist, but otherwise here is the complete script as created by ctx_report.create_index_script.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
begin
ctx_ddl.create_preference('"A_INDEX1_DST"','DIRECT_DATASTORE');
end;
begin
ctx_ddl.create_preference('"A_INDEX1_FIL"','AUTO_FILTER');
end;
begin
ctx_ddl.create_section_group('"A_INDEX1_SGP"','HTML_SECTION_GROUP');
end;
begin
ctx_ddl.create_preference('"A_INDEX1_LEX"','BASIC_LEXER');
end;
begin
ctx_ddl.create_preference('"A_INDEX1_WDL"','BASIC_WORDLIST');
ctx_ddl.set_attribute('"A_INDEX1_WDL"','STEMMER','ENGLISH');
ctx_ddl.set_attribute('"A_INDEX1_WDL"','FUZZY_MATCH','GENERIC');
end;
begin
ctx_ddl.create_stoplist('"A_INDEX1_SPL"','BASIC_STOPLIST');
ctx_ddl.add_stopword('"A_INDEX1_SPL"','Mr');
ctx_ddl.add_stopword('"A_INDEX1_SPL"','Mrs');
ctx_ddl.add_stopword('"A_INDEX1_SPL"','Ms');
ctx_ddl.add_stopword('"A_INDEX1_SPL"','might');
ctx_ddl.add_stopword('"A_INDEX1_SPL"','yours');
end;
begin
ctx_ddl.create_preference('"A_INDEX1_STO"','BASIC_STORAGE');
ctx_ddl.set_attribute('"A_INDEX1_STO"','R_TABLE_CLAUSE','lob (data) store as (cache)');
ctx_ddl.set_attribute('"A_INDEX1_STO"','I_INDEX_CLAUSE','compress 2')
end;
begin
ctx_output.start_log('A_INDEX1_LOG');
end;
create index "SCHEMA_OWNER"."A_INDEX1"
on "SCHEMA_OWNER"."A"
      ("A1")
indextype is ctxsys.context
parameters('
    datastore       "A_INDEX1_DST"
    filter          "A_INDEX1_FIL"
    section group   "A_INDEX1_SGP"
    lexer           "A_INDEX1_LEX"
    wordlist        "A_INDEX1_WDL"
    stoplist        "A_INDEX1_SPL"
    storage         "A_INDEX1_STO"
begin
ctx_output.end_log;
end;
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Hope this helps

Intermedia text (oracle text) and excel

Hi,
is it possible to index just one single sheet instead of the whole excel-workbook in
oracle text? Or is it possible to name just one sheet (e.g. table1) in a 'contains'
query? Additionally, is it possible to searc for the number of occurences of a term
within one document (i.e. excel-sheet)? Thanks for your help in advance.
Best Regards,
Dan

Hi Dan,
is it possible to index just one single sheet instead of the whole excel-workbook in
oracle text? No
Or is it possible to name just one sheet (e.g. table1) in a 'contains'
query?No
Additionally, is it possible to searc for the number of occurences of a term
within one document (i.e. excel-sheet)? Thanks for your help in advance.I am not sure at the moment, maybe with some kind of rankin.
The problem is the the INSO-filter converts the excel file to a html file and oracle is reading this generated file. And in file there is no information about excel sheets.
Regards,
Thomas

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 Issue

Hi ,
Any Idea Of this Below Error
SQL> CREATE INDEX "TOTALPLANT"."IP_TAG_LONGTAGNAME_SEARCH" ON "IP_TAG"
2 ("LONG_TAGNAME" ) INDEXTYPE IS "CTXSYS"."CONTEXT" PARAMETERS ('SYNC (ON
3 COMMIT)') ;
CREATE INDEX "TOTALPLANT"."IP_TAG_LONGTAGNAME_SEARCH" ON "IP_TAG"
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-11000: invalid keyword ON
COMMIT
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 364

Try this:
CREATE INDEX IP_TAG_LONGTAGNAME_SEARCH ON IP_TAG(LONG_TAGNAME) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('SYNC (ON COMMIT)') ;i.e remove the quotes, etc. Just to see if something odd happened.

Text wrap issue:ShowDetaillItem chop-off in the PanelAccordion.

Issue: Text wrap issue in ShowDetailItem header. Tittle of the S+howDetaillItem+ chop-off does not display completely in the PanelAccordion.
I have a few texts that does not wrap in ShowDetailItem Header used for the panel accordion. I could not fix it after trying a few options like changing the css skin, and in the design property inspector.
Please suggest a way to fix this.
Oracle Jdeveloper 11.1.1.5 is the version.
Windows XP professional sp3
Edited by: 899970 on Nov 30, 2011 11:34 AM

Thanks for your response.
Yes, we dont have enough room on the page.
I want the text to wrap and display in the second line as it has more no. of letters compared to the other texts available.
Please suggest me a way to get the text displayed the way I want it to be.
Thanks
Sam
Edited by: 899970 on Nov 30, 2011 3:13 PM

Error while running the Oracle Text optimize index procedure (even as a dba user too)

Hi Experts,
I am on Oracle on 11.2.0.2 on Linux. I have implemented Oracle Text. My Oracle Text indexes are fragmented but I am getting an error while running the optimize_index error. Following is the error:
begin
ctx_ddl.optimize_index(idx_name=>'ACCESS_T1',optlevel=>'FULL');
end;
ERROR at line 1:
ORA-20000: Oracle Text error:
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_DDL", line 941
ORA-06512: at line 1
Now I tried then to run this as DBA user too and it failed the same way!
begin
ctx_ddl.optimize_index(idx_name=>'BVSCH1.ACCESS_T1',optlevel=>'FULL');
end;
ERROR at line 1:
ORA-20000: Oracle Text error:
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_DDL", line 941
ORA-06512: at line 1
Now CTXAPP role is granted to my schema and still I am getting this error. I will be thankful for the suggestions.
Also one other important observation: We have this issue ONLY in one database and in the other two databases, I don't see any problem at all.
I am unable to figure out what the issue is with this one database!
Thanks,
OrauserN

How about check the following?
Bug 10626728 - CTX_DDL.optimize_index "full" fails with an empty ORA-20000 since 11.2.0.2 upgrade (DOCID 10626728.8)

Pre-loading Oracle text in memory with Oracle 12c

There is a white paper from Roger Ford that explains how to load the Oracle index in memory : http://www.oracle.com/technetwork/database/enterprise-edition/mem-load-082296.html
In our application, Oracle 12c, we are indexing a big XML field (which is stored as XMLType with storage secure file) with the PATH_SECTION_GROUP. If I don't load the I table (DR$..$I) into memory using the technique explained in the white paper then I cannot have decent performance (and especially not predictable performance, it looks like if the blocks from the TOKEN_INFO columns are not memory then performance can fall sharply)
But after migrating to oracle 12c, I got a different problem, which I can reproduce: when I create the index it is relatively small (as seen with ctx_report.index_size) and by applying the technique from the whitepaper, I can pin the DR$ I table into memory. But as soon as I do a ctx_ddl.optimize_index('Index','REBUILD') the size becomes much bigger and I can't pin the index in memory. Not sure if it is bug or not.
What I found as work-around is to build the index with the following storage options:
ctx_ddl.create_preference('TEST_STO','BASIC_STORAGE');
ctx_ddl.set_attribute ('TEST_STO', 'BIG_IO', 'YES' );
ctx_ddl.set_attribute ('TEST_STO', 'SEPARATE_OFFSETS', 'NO' );
so that the token_info column will be stored in a secure file. Then I can change the storage of that column to put it in the keep buffer cache, and write a procedure to read the LOB so that it will be loaded in the keep cache. The size of the LOB column is more or less the same as when creating the index without the BIG_IO option but it remains constant even after a ctx_dll.optimize_index. The procedure to read the LOB and to load it into the cache is very similar to the loaddollarR procedure from the white paper.
Because of the SDATA section, there is a new DR table (S table) and an IOT on top of it. This is not documented in the white paper (the white paper was written for Oracle 10g). In my case this DR$ S table is much used, and the IOT also, but putting it in the keep cache is not as important as the token_info column of the DR I table. A final note: doing SEPARATE_OFFSETS = 'YES' was very bad in my case, the combined size of the two columns is much bigger than having only the TOKEN_INFO column and both columns are read.
Here is an example on how to reproduce the problem with the size increasing when doing ctx_optimize
1. create the table
drop table test;
CREATE TABLE test
(ID NUMBER(9,0) NOT NULL ENABLE,
XML_DATA XMLTYPE
XMLTYPE COLUMN XML_DATA STORE AS SECUREFILE BINARY XML (tablespace users disable storage in row);
2. insert a few records
insert into test values(1,'<Book><TITLE>Tale of Two Cities</TITLE>It was the best of times.<Author NAME="Charles Dickens"> Born in England in the town, Stratford_Upon_Avon </Author></Book>');
insert into test values(2,'<BOOK><TITLE>The House of Mirth</TITLE>Written in 1905<Author NAME="Edith Wharton"> Wharton was born to George Frederic Jones and Lucretia Stevens Rhinelander in New York City.</Author></BOOK>');
insert into test values(3,'<BOOK><TITLE>Age of innocence</TITLE>She got a prize for it.<Author NAME="Edith Wharton"> Wharton was born to George Frederic Jones and Lucretia Stevens Rhinelander in New York City.</Author></BOOK>');
3. create the text index
drop index i_test;
exec ctx_ddl.create_section_group('TEST_SGP','PATH_SECTION_GROUP');
begin
CTX_DDL.ADD_SDATA_SECTION(group_name => 'TEST_SGP',
                            section_name => 'SData_02',
                            tag => 'SData_02',
                            datatype => 'varchar2');
end;
exec ctx_ddl.create_preference('TEST_STO','BASIC_STORAGE');
exec ctx_ddl.set_attribute('TEST_STO','I_TABLE_CLAUSE','tablespace USERS storage (initial 64K)');
exec ctx_ddl.set_attribute('TEST_STO','I_INDEX_CLAUSE','tablespace USERS storage (initial 64K) compress 2');
exec ctx_ddl.set_attribute ('TEST_STO', 'BIG_IO', 'NO' );
exec ctx_ddl.set_attribute ('TEST_STO', 'SEPARATE_OFFSETS', 'NO' );
create index I_TEST
on TEST (XML_DATA)
indextype is ctxsys.context
parameters('
    section group   "TEST_SGP"
    storage         "TEST_STO"
') parallel 2;
4. check the index size
select ctx_report.index_size('I_TEST') from dual;
it says :
TOTALS FOR INDEX TEST.I_TEST
TOTAL BLOCKS ALLOCATED:                                                104
TOTAL BLOCKS USED:                                                      72
TOTAL BYTES ALLOCATED:                                 851,968 (832.00 KB)
TOTAL BYTES USED:                                      589,824 (576.00 KB)
4. optimize the index
exec ctx_ddl.optimize_index('I_TEST','REBUILD');
and now recompute the size, it says
TOTALS FOR INDEX TEST.I_TEST
TOTAL BLOCKS ALLOCATED:                                               1112
TOTAL BLOCKS USED:                                                    1080
TOTAL BYTES ALLOCATED:                                 9,109,504 (8.69 MB)
TOTAL BYTES USED:                                      8,847,360 (8.44 MB)
which shows that it went from 576KB to 8.44MB. With a big index the difference is not so big, but still from 14G to 19G.
5. Workaround: use the BIG_IO option, so that the token_info column of the DR$ I table will be stored in a secure file and the size will stay relatively small. Then you can load this column in the cache using a procedure similar to
alter table DR$I_TEST$I storage (buffer_pool keep);
alter table dr$i_test$i modify lob(token_info) (cache storage (buffer_pool keep));
rem: now we must read the lob so that it will be loaded in the keep buffer pool, use the prccedure below
create or replace procedure loadTokenInfo is
type c_type is ref cursor;
c2 c_type;
s varchar2(2000);
b blob;
buff varchar2(100);
siz number;
off number;
cntr number;
begin
    s := 'select token_info from DR$i_test$I';
    open c2 for s;
    loop
       fetch c2 into b;
       exit when c2%notfound;
       siz := 10;
       off := 1;
       cntr := 0;
       if dbms_lob.getlength(b) > 0 then
         begin
           loop
             dbms_lob.read(b, siz, off, buff);
             cntr := cntr + 1;
             off := off + 4096;
           end loop;
         exception when no_data_found then
           if cntr > 0 then
             dbms_output.put_line('4K chunks fetched: '||cntr);
           end if;
         end;
       end if;
    end loop;
end;
Rgds, Pierre

I have been working a lot on that issue recently, I can give some more info.
First I totally agree with you, I don't like to use the keep_pool and I would love to avoid it. On the other hand, we have a specific use case : 90% of the activity in the DB is done by queuing and dbms_scheduler jobs where response time does not matter. All those processes are probably filling the buffer cache. We have a customer facing application that uses the text index to search the database : performance is critical for them.
What kind of performance do you have with your application ?
In my case, I have learned the hard way that having the index in memory (the DR$I table in fact) is the key : if it is not, then performance is poor. I find it reasonable to pin the DR$I table in memory and if you look at competitors this is what they do. With MongoDB they explicitly says that the index must be in memory. With elasticsearch, they use JVM's that are also in memory. And effectively, if you look at the awr report, you will see that Oracle is continuously accessing the DR$I table, there is a SQL similar to
SELECT /*+ DYNAMIC_SAMPLING(0) INDEX(i) */
TOKEN_FIRST, TOKEN_LAST, TOKEN_COUNT, ROWID
FROM DR$idxname$I
WHERE TOKEN_TEXT = :word AND TOKEN_TYPE = :wtype
ORDER BY TOKEN_TEXT, TOKEN_TYPE, TOKEN_FIRST
which is continuously done.
I think that the algorithm used by Oracle to keep blocks in cache is too complex. A just realized that in 12.1.0.2 (was released last week) there is finally a "killer" functionality, the in-memory parameters, with which you can pin tables or columns in memory with compression, etc. this looks ideal for the text index, I hope that R. Ford will finally update his white paper :-)
But my other problem was that the optimize_index in REBUILD mode caused the DR$I table to double in size : it seems crazy that this was closed as not a bug but it was and I can't do anything about it. It is a bug in my opinion, because the create index command and "alter index rebuild" command both result in a much smaller index, so why would the guys that developped the optimize function (is it another team, using another algorithm ?) make the index two times bigger ?
And for that the track I have been following is to put the index in a 16K tablespace : in this case the space used by the index remains more or less flat (increases but much more reasonably). The difficulty here is to pin the index in memory because the trick of R. Ford was not working anymore.
What worked:
first set the keep_pool to zero and set the db_16k_cache_size to instead. Then change the storage preference to make sure that everything you want to cache (mostly the DR$I) table come in the tablespace with the non-standard block size of 16k.
Then comes the tricky part : the pre-loading of the data in the buffer cache. The problem is that with Oracle 12c, Oracle will use direct_path_read for FTS which basically means that it bypasses the cache and read directory from file to the PGA !!! There is an event to avoid that, I was lucky to find it on a blog (I can't remember which, sorry for the credit).
I ended-up doing that. the events to 10949 is to avoid the direct path reads issue.
alter session set events '10949 trace name context forever, level 1';
alter table DR#idxname0001$I cache;
alter table DR#idxname0002$I cache;
alter table DR#idxname0003$I cache;
SELECT /*+ FULL(ITAB) CACHE(ITAB) */ SUM(TOKEN_COUNT), SUM(LENGTH(TOKEN_INFO)) FROM DR#idxname0001$I;
SELECT /*+ FULL(ITAB) CACHE(ITAB) */ SUM(TOKEN_COUNT), SUM(LENGTH(TOKEN_INFO)) FROM DR#idxname0002$I;
SELECT /*+ FULL(ITAB) CACHE(ITAB) */ SUM(TOKEN_COUNT), SUM(LENGTH(TOKEN_INFO)) FROM DR#idxname0003$I;
SELECT /*+ INDEX(ITAB) CACHE(ITAB) */ SUM(LENGTH(TOKEN_TEXT)) FROM DR#idxname0001$I ITAB;
SELECT /*+ INDEX(ITAB) CACHE(ITAB) */ SUM(LENGTH(TOKEN_TEXT)) FROM DR#idxname0002$I ITAB;
SELECT /*+ INDEX(ITAB) CACHE(ITAB) */ SUM(LENGTH(TOKEN_TEXT)) FROM DR#idxname0003$I ITAB;
It worked. With a big relief I expected to take some time out, but there was a last surprise. The command
exec ctx_ddl.optimize_index(idx_name=>'idxname',part_name=>'partname',optlevel=>'REBUILD');
gqve the following
ERROR at line 1:
ORA-20000: Oracle Text error:
DRG-50857: oracle error in drftoptrebxch
ORA-14097: column type or size mismatch in ALTER TABLE EXCHANGE PARTITION
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_DDL", line 1141
ORA-06512: at line 1
Which is very much exactly described in a metalink note 1645634.1 but in the case of a non-partitioned index. The work-around given seemed very logical but it did not work in the case of a partitioned index. After experimenting, I found out that the bug occurs when the partitioned index is created with dbms_pclxutil.build_part_index procedure (this enables enables intra-partition parallelism in the index creation process). This is a very annoying and stupid bug, maybe there is a work-around, but did not find it on metalink
Other points of attention with the text index creation (stuff that surprised me at first !) ;
- if you use the dbms_pclxutil package, then the ctx_output logging does not work, because the index is created immediately and then populated in the background via dbms_jobs.
- this in combination with the fact that if you are on a RAC, you won't see any activity on the box can be very frightening : this is because oracle can choose to start the workers on the other node.
I understand much better how the text indexing works, I think it is a great technology which can scale via partitioning. But like always the design of the application is crucial, most of our problems come from the fact that we did not choose the right sectioning (we choosed PATH_SECTION_GROUP while XML_SECTION_GROUP is so much better IMO). Maybe later I can convince the dev to change the sectionining, especially because SDATA and MDATA section are not supported with PATCH_SECTION_GROUP (although it seems to work, even though we had one occurence of a bad result linked to the existence of SDATA in the index definition). Also the whole problematic of mixed structured/unstructured searches is completly tackled if one use XML_SECTION_GROUP with MDATA/SDATA (but of course the app was written for Oracle 10...)
Regards, Pierre

Oracle Text release 11.2.0.3.0 mandatory Patches (Doc ID 1386945.1)

I've been asked to draw people's attention to Support Note 1386945.1
This covers problems that some users have experienced when upgrading existing Oracle Text installations to version 11.2.0.3.
The most common problem is getting an error:
ORA-07445: exception encountered: core dump [druhfind()+370]
You could also see
ORA-20000: Oracle Text error:
DRG-50857: oracle error in textindexmethods.ODCIIndexInsert
ORA-20000: Oracle Text error:
DRG-10607: index meta data is not ready yet for queuing DML
DRG-50857: oracle error in drdmlv
ORA-01426: numeric overflow
ORA-30576: ConText Option dictionary loading error
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 752
or
DRG-10607: index meta data is not ready yet for queuing DML
DRG-50857: oracle error in drdmlv
ORA-01426: numeric overflow
There may also be issues with IPV6 URLs and the URL data store.
The recommended fixes are:
Apply generic Patch 13258936 to fix the meta data corruption.
Apply Patch 12960302 to fix the ORA-30576, DRG-10607 and ORA-1426 errors.
Apply generic Patch 13366268 to fix the core dump in function druhfind() from 'create index' statement and the import problem. This patch contains also the fix for Bug 13352423.
Apply Patch 12985184 to fix the IPv6 url problem.
Roger

Hi;
Is Oracle Database 11g Release 2 (11.2.0.3.0) available for IBM AIX on POWER Systems (64-bit),Yes
Or do we need to upgrade 11.2.0.1 to 11.2.0.3.0.Please clarifyYou dont need upgrade, download patchset from metalink and start your process.
Also see:
Oracle Database on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) [ID 169706.1]
PS:Please dont forget to change thread status to answered if it possible when u belive your thread has been answered, it pretend to lose time of other forums user while they are searching open question which is not answered,thanks for understanding
Regard
Helios

Differences between oracle text in enterprise and express editions

are there any differences between oracle text features found in express edition and ent. edition. if so what are they?

There is a list of features available in the online documentation. The only thing that it mentions as being missing from Oracle Text are the english and french knowledge bases. There isn't any Intermedia or Ultra Search or Data Mining. Here is a link to the 10g Express Edition features guide:
http://download-west.oracle.com/docs/cd/B25329_01/doc/license.102/b25456/toc.htm#BABDDIAE
There is a separate discussion group for 10g Express Edition, that requires a separate free registration:
Oracle Database Express Edition (XE)
There is a thread on this subject in the 10g Express discussion group:
Oracle Text
The above thread includes the following quick comparison:
If it's not in Standard Edition One, it is not in Express Edition. (Therefore everything that is in Enterprise but not in Standard Edition, is also not in Express Edition. That includes all EE-only options.)
If it requires Java in the database, it is not in Express Edition.
Other than that, it's mainly the size limits: 1 CPU (no parallel processing), 1 GB RAM, and 4 GB user-related tablespaces.

Oracle Text/Intermedia issue

Similar Messages

Maybe you are looking for