Method 1.
This was my first though:- Drop Index ... /Create Index ...
- or Alter Index ... Rebuild
- Users cannot perform text searches during this operation,
- It does not solve problem for longer time, as index will still grow ...
Method 2.
While looking for root cause I've find out, that Index has never been optimized, so it kept old (obsolete) data. My solution was:SQL> exec ctx_ddl.optimize_index('MY_TEXT_I', 'FULL', 120);
SQL> alter table DR$MY_TEXT_I$I enable row movement;
SQL> alter table DR$MY_TEXT_I$I shrink space cascade;
With this method table DR$MY_TEXT_I$I took 30% of its original size.
So let me explain why this worked. With ctx_ddl.optimize_index context index was internally optimized. It means information about old documents were completely deleted and index was internally minimized. Remember - third parameter limits time (in minutes) allowed for optimization. If it is really big index it can take hours. But you can run this optimization many times, until your index will be fully optimized.
Then I've just shrunk table (shrink space cascade). But this operation requires to enable row movement on table first.
But this was one time operation. To avoid this problem in future I've scheduled job to run ctx_ddl.optimize_index on regular basis. Now this table has grown a little, but is no longer growing so fast.
Foot note:
- It was tested on Oracle EE 10gR2 (10.2.0.3),
- I'm not sure if row movement is supported by Oracle for Context Index table DR$<index>$I. It worked for me and I did not experience any problems since turning it on.
Cheers, Paweł
3 comments:
try to use ctx_ddl.optimize_index with REBUILD option and check the index size..
Ashish,
Rebuild option is not supported for CONTEXT index
There is a limitation on CTX_DDL.OPTIMIZE_INDEX(), it will "only" optimize 16000 documents id at a time.
http://download.oracle.com/docs/cd/B10501_01/text.920/a96518/cddlpkg.htm#27196
So you must run it a few times depending on how many rows your table has.
Schedulling a job is best.
Post a Comment