Loading context index in memory.

Hi,
I would like to be able to put my base table and the $I token table into memory if possible. So far I have managed to get about a third of the index and base table into the keep pool by issuing an alter table storage on the base and domain index tables and then running aggregate queries against them. Basically following the example from the oracle text main page.
Are there any techniques for ensuring that all the token index and base table are in memory and can they be pinned there?
The base table is approx 4.8 million rows and the DR$<string>$I table is around 5.2 million rows, there is 7 gigs or ram devoted to the instance.
I'm running 11.2.0.1.0 standard edition without partitioning.
Any advice on how to make this go really fast would be greatly appreciated.

Hi,
Basically following the example from the oracle text main page.Do you know this page ?
[http://www.oracle.com/technology/products/text/htdocs/mem_load.html]
Your problem is, that you could only load a third of the index and base table and you want to load
them completely. Is this correct ?
The base table is approx 4.8 million rows and the DR$<string>$I table is around 5.2 million rowsDid you check the sizes of
a) these tables and
b) the number of blocks loaded into the keep cache after your aggregate queries ?
there is 7 gigs or ram devoted to the instanceYou have then to check if there is enough space left to keep all blocks in cache.

Similar Messages

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

Context Index World Lexer ORA-03113: end-of-file on communication channel

I have release 10g Release 1 (10.1.0.2.0) for Windows and trying to take advantage of the World Lexer.
My table is:
create table worldtest(
filename char(32),
content blob
I've created a preference for the WORLD_LEXER:
     begin
     ctx_ddl.create_preference('wlex', 'WORLD_LEXER');
     end;
Right now I'm working with 10,000 records of PDF, MS-Word, Text, and HTM documents. When I try and create a context index using this lexer:
create index i_ctx_wc on worldtest(content)
indextype is ctxsys.context
parameters ('lexer wlex');
The following error is returned, and I have to use drop index force to remove the index. Without 'Force' a message is return saying the index is an a loading state, but nothing is occuring.
create index i_ctx_wc on worldtest(content)
indextype is ctxsys.context
ERROR at line 1:
ORA-03113: end-of-file on communication channel
The indexing works fine when I leave the world lexer preference out.
Any suggestions would be wonderful. I've been banging my head on this one for a while.
Thanks.

Hi,
I couldn't reproduce (different version which is perhaps the problem). Check out bug 4056162. ORA-3113 related to the use of the world lexer. The resolution is not published externally, so no help there, but the bug is closed so perhaps support can provide some insight.
Thanks.

Oracle 9.2 ConText index alternate_spelling problem

Hello everybody!
I'm having problems with a ConText index in Oracle 9.2, using the alternative_spelling parameter...
Here is my code
CREATE TABLE U2000P.TEST_FICHIER_INT
(ID NUMBER(6) NOT NULL,
NOM_FICHIER VARCHAR2(90) NULL,
MIME VARCHAR2(90) NULL,
FICHIER BLOB DEFAULT empty_blob(),
LNG VARCHAR2(3) NULL,
KEY_WORDS VARCHAR2(500) NULL,
CONSTRAINT PK_TEST_FICHIER_INT PRIMARY KEY (ID)
EXECUTE CTX_DDL.CREATE_PREFERENCE('ENGLISH_LEXER','BASIC_LEXER');
EXECUTE CTX_DDL.SET_ATTRIBUTE('ENGLISH_LEXER', 'INDEX_THEMES', 'YES');
EXECUTE CTX_DDL.SET_ATTRIBUTE('ENGLISH_LEXER', 'THEME_LANGUAGE', 'ENGLISH');
EXECUTE CTX_DDL.SET_ATTRIBUTE('ENGLISH_LEXER', 'BASE_LETTER', 'NO');
EXECUTE CTX_DDL.CREATE_PREFERENCE('FRENCH_LEXER','BASIC_LEXER');
EXECUTE CTX_DDL.SET_ATTRIBUTE('FRENCH_LEXER', 'INDEX_THEMES', 'NO');
EXECUTE CTX_DDL.SET_ATTRIBUTE('FRENCH_LEXER', 'BASE_LETTER', 'NO');
EXECUTE CTX_DDL.CREATE_PREFERENCE('GERMAN_LEXER','BASIC_LEXER');
EXECUTE CTX_DDL.SET_ATTRIBUTE('GERMAN_LEXER', 'INDEX_THEMES', 'NO');
EXECUTE CTX_DDL.SET_ATTRIBUTE('GERMAN_LEXER', 'BASE_LETTER', 'NO');
EXECUTE CTX_DDL.SET_ATTRIBUTE('GERMAN_LEXER', 'ALTERNATE_SPELLING', 'GERMAN');
EXECUTE CTX_DDL.CREATE_PREFERENCE('GLOBAL_LEXER','MULTI_LEXER');
EXECUTE CTX_DDL.ADD_SUB_LEXER('GLOBAL_LEXER', 'FRENCH', 'FRENCH_LEXER', '1');
EXECUTE CTX_DDL.ADD_SUB_LEXER('GLOBAL_LEXER', 'DEFAULT', 'GERMAN_LEXER');
EXECUTE CTX_DDL.ADD_SUB_LEXER('GLOBAL_LEXER', 'ENGLISH', 'ENGLISH_LEXER', '5');
CREATE INDEX IDX_F_TEST_FICHIER_INT
ON TEST_FICHIER_INT(FICHIER)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS('DATASTORE CTXSYS.DIRECT_DATASTORE
FILTER CTXSYS.INSO_FILTER
LEXER GLOBAL_LEXER LANGUAGE COLUMN LNG');
In one of the files that I load, I have the word 'paläontologie'
Here are my searches
select nom_fichier, score(1) from test_fichier_int where contains(fichier, 'paläontologie', 1) > 0;
-> no rows selected
select nom_fichier, score(1) from test_fichier_int where contains(fichier, 'palaontologie', 1) > 0;
-> Finds my document
Why does the first search not work?
If I don't use the 'alternate_spelling' parameter, both searches don't work, why is that???
Thanks in advance for your help
Best regards
Neil.

I found my error!!!! Thanks Neil... lol
In fact, it's my SQL*Plus that must be badly configured, and I am having problems with accentuated characters... If I search through a browser, it works!!!
Sorry about that...
Best regards
Neil.

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.

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...

Creation of context index on index-organized table

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.

Please ask questions about Oracle Text (formerly interMedia text) in the Oracle Text forum. You will get a quicker, more expert answer there.

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.

Error in Updating ctxsys.context index using ctxsrv

Environment :
Linux 6.2,
Oracle 8.1.6
character set : zhs16gbk or zhs16cgb231280
I can create an ctxsys.context index(using CHINESE_VGRAM_LEXER) on a long column, and i can rebuild this index with no parameters.
When i want to rebuild this index automatic using ctxsrv, this error occur ---
DRG-50857 Oracle error in drtldml(dml)
Ora-2000 error
anybody can help me?
null

the complete error:
Dml batch: cid=1023
End batch: return code is 1
DRG-50857: oracle error in drtldml(dml)
ORA_20000: interMedia text 4mNs
DRG-50857: oracle error in drsxsopen
ORA-01480: STR83V51dA?H1IY?U:sW:
null

CONTEXT index vs a CTXCAT index

I'm puzzled as to which of these indexes is meant for what purpose. I like the auto-update feature of the CTXCAT index, so I'm leaning that direction.
Here's our situation. We have a table with about 2 million rows, where there's an EMPLOYER_NAME field. Users are constantly executing queries like:
where EMPLOYER_NAME like '%CHEVRON%'The CTXCAT index is also described as "Typically, with this index type, you index small documents or text fragments". I would consider this EMPLOYER_NAME column (VARCHAR2(50)) to fit this description, more or less.
The main thing that has me confused is that our vendor is pushing for a CONTEXT index, as they've got experience setting these up. We're not storing "text consists of large coherent documents.", but we are storing plain text.
Could someone offer some guidance? Thanks for your help,
--=Chuck

Depends on whether the words are predictable. You indicated in your first post they are employer names. If they are then presumably there is a table/list of valid values. Otherwise a CTX index may be your best shot but understand that you will be indexing every word and, I assume, most will be irrelevant.

Use CONTEXT index on mview or use mview's rewrite directly

Please let me explain what I mean in Subject. I have 9 tables. Each of these tables has about 40,000 rows and one table has 2 million rows. Using first approach, I can build a join-only materialized view on top of nine table's mview log. then query on these nine tables directly. Advantage for doing that is use rewrite.
<p>
for second approach, I build a CONETXT index on several columns on the mview, and then query through CONTEXT index on mview directly. This is pretty much like Barbara did on CREATE INDEX book_idx ON book_search
[http]Indexing multiple columns of multiple tables using CTXCAT
but she used CTXCAT instead of CONTEXT index.
<p>
My question is will second approach better than first one and why. Unlike basic join several tables which gives you predictable performance, I often feel that CONTEXT index performance is unpredictable when tables have more than several thousands rows (maybe I did something wrong, but still looking for document regarding performance) .
<p>
I will appreciate someone could show hints on the issue.
<p>
Message was edited by:
qwe15933
Message was edited by:
qwe15933
Message was edited by:
qwe15933
Message was edited by:
qwe15933

The best method to find out what is best for any individual situation is to test and compare. In general, Oracle Text is best at searching unstructured data, such as large documents and has a lot of features that enable you to do different kinds of searches. If you only have structured data, with each column only containing one short thing and you only need simple searches, then you probably don't need Text. There are also a few things that can be done to indexes and/or queries to optimize performance. It would help to have an idea what your typical data is like and what sorts of searches you anticipate needing.

Performance of context index with sorting

Dear All,
I've got a problem and don't know how to solve this.
there has a table which have a XMLTYPE field to store the unstructred xml, and created with context index.
When I try to select a record from it by using contains (res, '[searchingfield]')>0, the response time is quick, but when I try to order by another field which in the same table, the response time is drop down slightly. (ex. select id, path, res, update_date from testingtbl where contains(res, 'shopper')>0 order by update_date desc.
Actually there is a context index build for field 'res', any other index build for field 'update_date', when sql without 'order by update_date', the context index will use, but the update_date index will not be used even have ordering criteria.
Is there any expect can tell how to solve this? how to keep the performance even doing the sorting process?
Thanks and Regards
Raymond

Thanks for your quick reply.
The mentions information provide after back to office, actually I just want to know if there is any method(s) which can use the context index (with contains keyword) and sorting without slow down the performance.
Thanks and Regards
Raymond

Context index and contains operator syntax how it works ?

Hi
I create a context index on four collumns (text_prof, text_gest, text_citizen, text)
of the same table content.
When i have more than one collumn being queryed using the contains syntax, oracle display the ora 29907 error saying found duplicated labels in primary invocations .
This query works:
SELECT * FROM content WHERE cod_type = '1'
AND (UPPER(title) LIKE UPPER('%tabagismo%')
OR contains (text, 'tabagismo',1)>0
This not works:
SELECT * FROM content
WHERE cod_type = '1' AND (
UPPER(title) LIKE UPPER('%tabagismo%')
OR contains (text, 'tabagismo',1)>0
OR contains (text_citizen,'tabagismo',1)>0
OR contains (text_gest,'tabagismo',1)>0
OR contains (text_prof,'tabagismo',1)>0
How can i fix it ?
I need to query all these colluns !
Does the contains operator can be used only in one collumn?
Thank´s in advance

Hi
I create a context index on four collumns (text_prof, text_gest, text_citizen, text)
of the same table content.
When i have more than one collumn being queryed using the contains syntax, oracle display the ora 29907 error saying found duplicated labels in primary invocations .
This query works:
SELECT * FROM content WHERE cod_type = '1'
AND (UPPER(title) LIKE UPPER('%tabagismo%')
OR contains (text, 'tabagismo',1)>0
This not works:
SELECT * FROM content
WHERE cod_type = '1' AND (
UPPER(title) LIKE UPPER('%tabagismo%')
OR contains (text, 'tabagismo',1)>0
OR contains (text_citizen,'tabagismo',1)>0
OR contains (text_gest,'tabagismo',1)>0
OR contains (text_prof,'tabagismo',1)>0
How can i fix it ?
I need to query all these colluns !
Does the contains operator can be used only in one collumn?
Thank´s in advance

Context Index Peformance

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 i.e synchronization??
2.Is there any problem from performace point of view creating context index on the table??
Thanks,
Sri

hi,
pls have a take a look this doc
http://docs.oracle.com/cd/B19306_01/text.102/b14217/ind.htm
http://stackoverflow.com/questions/1916244/how-to-sync-and-optimize-an-oracle-text-index
regards,

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

Loading context index in memory.

Similar Messages

Maybe you are looking for