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.

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!

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.

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

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

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

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.

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.

Fast index creation suggestions wanted

Hi:
I've loaded a table with a little over 100,000,000 records. The table has several indexes which I must now create. Need to do this as fast as possible.
I've read the excellent article by Don Burleson (http://www.dba-oracle.com/oracle_tips_index_speed.htm) but still have a few questions.
1) If the table is not partitioned, does it still make sense to use "parallel"?
2) The digit(s) following "compress" indicate the number of consective columns at the head of the index that have duplicates. True?
3) How will the compressed index effect query performance (vs not compressed) down the line?
4) In the future I will be doing lots and lots of updates on the indexed columns of the records as well as lots of record deletes and inserts into/out-of the table. Will these updates/inserts/deletes run faster or slower given that the indexes are compressed vs if they were not?
5) In order to speed up the sorting, is it better to add datafiles to the TEMP table or create more TEMP tables (remember, running "parallel")
Thanks in Advance

There are people who would argue that excellent and Mr. Burleson do not belong in the same sentence.
1) Yes, you can still use parallel (and nologging) to create the index, but don't expect 20 - 30 times faster index creation.
2) It is the number of columns to compress by, they may not neccesarily have duplicates. For a unique index the default is number of columns - 1, for a non-unique index the default is the number of columns.
3) If you do a lot of range scans or fast full index scans on that index, then you may see some performance benefit from reading fewer blocks. If the index is mostly used in equality predicates, then the performance benefit will likely be minimal.
4) It really depends on too many factors to predict. The performance of inserts, updates and deletes will be either
A) Slower
B) The same
C) Faster
5) If you are on 10G, then I would look at temporary tablespace groups which can be beneficial for parallel operations. If not, then allocate as much memory as possible to sort_area_size to minimize disk sorts, and add space to your temporary tablespace to avoid unable to extend. Adding additional temporary tablespaces will not help because a user can only use one temporary tablespace at a time, and parallel index creation is only one user.
You might want to do some searching at Tom Kyte's site http://asktom.oracle.com for some more responsible answers. Tom and Don have had their disagreements in the past, and in most of them, my money would be on Tom to be corerct.
HTH
John

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.

Optimizing context index

I have created a context index and want to optimize it regularly. I issue the following statement:
ctx_ddl.optimize_index('MY_INDEX','FAST');
In the Enterprise Manager I can see, that there are a lot of Sort/Merge-operations, but the optimize process doesn't finish.
(During optimize there are inserts into the table and the index is updated by the ctx_ddl.sync_index procedure).
Can anyone tell me why the optimize doesn't finish? How can I avoid this situation?

How long did you leave it running?Optimizing ran more than 10 hours. So I cancelled it, because this is not acceptable.
Optimization is an intensive process, and can sometimes take longer than the original index creation.
If you want it to complete in less time, consider using FULL optimize, but setting a time limit on it. That way it will do as much as it can within the time limit, and then start again next time from where it finished last time.During the night, I start a FULL optimize with MAXTIME = 60 minutes. But this seems not to be enough. If I don't start FAST optimizing during the day, the index get to much fragmentated.
Alternatively, if optimization is taking a lot longer than creating the index, consider dropping the index and recreating it from scratch. This will require downtime on the system, unless you get clever and use the USER_DATASTORE to create two indexes on different, dummy, columns - and switch searching between them when you want to rebuild the index. Make sure you use a generous setting for INDEX_MEMORY to avoid fragmentation.
- Roger

Ctxsys.context index on registered schema xmltype column

9iR2
Is it possible to create a text index (indextype is ctxsys.context) on a schema registered xmltype column?
I tried it, the index creation works fine.
After the first insert statement the Oracle process seems to hang. (CPU 100%, increasing memory consumption)

Yes, I previously entered some data.
Test case:
1. register schema
begin
DBMS_XMLSCHEMA.REGISTERSCHEMA('http://localhost/JobPositionSeeker-1_1.xsd',
getDocument('JobPositionSeeker-1_1.xsd'), TRUE, TRUE, FALSE, FALSE
end;
2. create table
CREATE TABLE application_xml of XMLType
XMLSCHEMA "http://localhost/JobPositionSeeker-1_1.xsd" ELEMENT "JobPositionSeeker"
3. entered some data
4. created the index
create index applicant on application_xml ( SYS_NC_ROWINFO$)
indextype is ctxsys.context
5. select using index
select value(a).getClobVal() from application_xml a
where contains( value(a),'%ai% INPATH(//PersonalData/PersonName/FamilyName)')>0
6. insert another record
-> crash

Systemcopy using R3load - Index creation VERY slow

We exported a BW 7.0 system using R3load (newest tools and SMIGR_CREATE_DDL) and now importing it into the target system.
Source database size is ~ 800 GB.
The export was running a bit more than 20 hours using 16 parallel processes. The import is still running with the last R3load process. Checking the logs I found out that it's creating indexes on various tables:
(DB) INFO: /BI0/F0TCT_C02~150 created#20100423052851
(DB) INFO: /BIC/B0000530000KE created#20100423071501
(DB) INFO: /BI0/F0COPC_C08~01 created#20100423072742
(DB) INFO: /BI0/F0COPC_C08~04 created#20100423073954
(DB) INFO: /BI0/F0COPC_C08~05 created#20100423075156
(DB) INFO: /BI0/F0COPC_C08~06 created#20100423080436
(DB) INFO: /BI0/F0COPC_C08~07 created#20100423081948
(DB) INFO: /BI0/F0COPC_C08~08 created#20100423083258
(DB) INFO: /BIC/B0000533000KE created#20100423101009
(DB) INFO: /BIC/AODS_FA00~010 created#20100423121754
As one can see on the timestamps the creation of one index can take an hour or more.
x_cons is showing constant CrIndex reading in parallel, however, the througput is not more than 1 - 2 MB/sec. Those index creation processes are running now since over two days (> 48 hours) and since the .TSK files don't mentioned those indexes any more I wonder how many of them are to be created and how long this will take.
The whole import was started at "2010-04-20 12:19:08" (according to import_monitor.log) so running now since more than three days with four parallel processes. Target machine has 4 CPUs and 16 GB RAM (CACHE_SIZE is 10 GB). The machine is idling though with 98 - 99 %.
I have three questions:
- why does index creation take such a long time? I'm aware of the fact, that the cache may not be big enough to take all the data but that speed is far from being acceptable. Doing a Unicode migration, even in parallel, will lead to a downtime that may not be acceptable by the business.
- why are the indexes not created first and then filled with the data? Each savepoint may take longer but I don't think that it will take that long.
- how to find out which indexes are still to be created and how to estimate the avg. runtime of that?
Markus

i Peter,
I would suggest creating an SAP ticket for this, because these kind of problems are quite difficult to analyze.
But let me describe the index creation within MaxDB. If only one index creation process is active, MaxDB can use multiple Server Tasks (one for each Data Volume) to possibly increase the I/O throughput. This means the more Data Volumes you have configured, the faster the parallel index creation process should be. However, this hugely depends on your I/O system being able to handle an increasing amount of read/write requests in parallel. If one index creation process is running using parallel Server tasks, all further indexes to be created at that time can only utilize one single User Task for the I/O.
The R3load import process assumes that the indexes can be created fast, if all necessary base table data is still present in the Data Cache. This mostly applies to small tables up to table sizes that take up a certain amount of the Data Cache. All indexes for these tables are created right after the table has been imported to make use of the fact, that all the needed data for index creation is still in the cache. Many idexes may be created simultaneously here, but only one index at a time can use parallel Server Tasks.
If a table is too large in relation to the total database size, then its indexes are being queued for serial index creation to be started when all tables were imported. The idea is that the needed base table data would likely have been flushed out of the Data Cache already and so there is additional I/O necessary rereading that table for index creation. And this additional I/O would greatly benefit from parallel Server Tasks accessing the Data Volumes. For this reason, the indexes that are to be created at the end are queued and serialized to ensure that only one index creation process is active at a time.
Now you mentioned that the index creation process takes a lot of time. I would suggest (besides opening an OSS ticket) to start the MaxDB tool 'Database Analyzer' with an interval of 60 seconds configured during the whole import. In addition, you should activate the 'time measurement' to get a reading on the I/O times. Plus, ensure that you have many Data Volumes configured and that your I/O system can handle that additional loag. E.g. it would make no sense to have 25 Server Tasks all writing to a single local disk, I would assume that the disk would become a bottle neck...
Hope my reply was not too confusing,
Thorsten

Index creation; What should the ideal process be?

DB Version:11g R1
I maintain a db related to retailing and wareshousing. Last week, i issued a CREATE INDEX statement at around 8:00 pm which is a 'not so busy time' for DB and applications. But the temp tablespace ran out of space during this exercise. It was a nightmare.
Now, we have decided to follow a standardized process followed by experienced Oracle DBA professionals in the Industry. So, we would like to know what process you guys would follow if you are asked to CREATE or REBUILD Indexes.

I maintain a db related to retailing and wareshousing. Last week, i issued a CREATE INDEX statement at around 8:00 pm which is a 'not so busy time' for DB and applications. But the temp tablespace ran out of space during this exercise. It was a nightmare. Here are some tips:
http://searchoracle.techtarget.com/tip/Speed-up-Oracle-index-creation
http://mehrajdba.wordpress.com/2009/01/30/how-to-make-an-index-creation-faster/
HTH
Z.K.

Error creating Context Index

Hi,
Iam trying to create an context index in a table. After a logn run it gave an error. end-of-file on communication channel. How to resolve this error. And do i have any possibility to continue my index creation. How to recover it?
Urgent Help needed......
Thanks,
Sri

"End of file on communication channel" nearly always means the Oracle background process has crashed, which means either an Oracle bug or a hardware issue.
You would need to look at the database alert logs to get more information about the crash.
You probably won't be able to resume the indexing job from where it crashed, but will need to drop the index and recreate it.

Faster Context index creation!!

Similar Messages

Maybe you are looking for