Re: ctx_ddl.sync_index question

From: Rich Jesse <rjoralist_at_society.servebeer.com>
Date: Wed, 8 Apr 2009 09:41:26 -0500 (CDT)
Message-ID: <edd8b174d25c470534f2010db3a53541.squirrel_at_society.servebeer.com>

Vendors aren't responsible for your system -- YOU are. Push back to them with questions and requests for documentation.

Then again, there's no dev/test system -- is this a critical production system that can't sustain downtime? Can you create a copy of this database to test the effects of the index sync as well as possible performance tweaks (e.g. increasing the 12M index memory iteratively between test system restores or using the parallel option of the sync_index)?

I could have sworn from a past life that the creation of a CTX index automagically created a DBMS_JOB to sync the index in 10gR2, but there's no way for me to test this now. [insert malted hops / brain cell disclaimer here]

Finally, make sure you can restore exactly to the point before you run this resync. Whether that be database, external data, whatever -- do what you must to ensure that you can start over again if it goes wrong. There's all sorts of business decisions on that one that no one outside your company can ultimately make for you.

GL! Let us know how it goes!

Rich

> 10.2.0.4
>
> Redhat linux
>
> 2 cpu
>
> 12 GB ram
>
> COTS app: kana
>
>
>
> Kana is telling our developer that we need to run
>
> begin
>
> ctx_ddl.sync_index('kc_ctx_rawtext', '12M'); end;
>
> to resync the text index.
>
> The index is 2.5GB and there are 3 million records in ctx_user_pending. Of
> course, there is no dev/test or anything and they want to run it straight on
> prod. Why the app doesn't have a job predefined to do this I don't know. I'm
> trying to get a handle on what this will actually do under the covers. This
> will be run off peak load but is it so resource intensive that the system
> will essentially lock (from the users viewpoint) or any idea of how long
> this type of thing would take.
>
> I've told them we will just have to go with it as again we have no way of
> testing beforehand.

--
http://www.freelists.org/webpage/oracle-l

Received on Wed Apr 08 2009 - 09:41:26 CDT