Re: Performance tuning Oracle Context

Hi:

This makes sense, but we are retrieving document id's from a meta table that includes descriptive information, but no LONG values. We decided to keep our LONG data elsewhere to prevent this type of problem.

That said, I do need to look at the joins after we rerieve the data from Oracle. I bet we can pick up some performance there.

  Rich

In article <741n2d$eb9$1_at_platinum.sge.net>,   "Rod Stewart" <rod.stewart_at_afp.gov.au> wrote:
> What are you retrieving for the results? Are you just retrieving an
> identifier for each document or the document itself? One of my clients has
> a similar number of documents, though they may be smaller in size on
> average. The whole lot takes up about 10 Gbytes of storage. We initially
> had performance problems (that sound very similar to yours) returning the
> list of results, which did not include retrieving the actual document. It
> turned out that disk IO was the problem, to get the 'title' of each document
> ( which was stored in the same table as the document), it was effectively
> having to read past each of the long raw documents. We did a little
> restructuring and indexing so that when we got a document ID from the
> context index, we were relating it to a document title in a table that did
> not include the documents themselves. The whole setup is very quick now.
>
> I hope all this makes some sense and is of some use to you.
>
> Rod J. Stewart
>
> rbelanger_at_forrester.com wrote in message
> <741e16$sdl$1_at_nnrp1.dejanews.com>...
> >Hello:
> >
> >We are working on a Context application that indexes about 1,000 large
> >documents (15-18 pages) and about 10,000 small documents (2-3 pages).
> >
> >Indexing performance seems to be pretty good, but retrieval performance is
> >only OK. We are using two-step queries and the average query is taking
> about
> >10 seconds. I would like to get it down to about 2-3 seconds.
> >
> >The database server is a Sun Enterprise 3500 with 512 Mb of memory, with
> >about a 320 Mb buffer cache, 60 Mb shared pool. We also have SORT_MEMORY
> >SIZE turned up to about 8M to keep most sorts in memory. The datafiles are
> >on an EMC Symmetrix and are distributed across a series of mirrored
> >partitions.
> >
> >During searches we see a fairly high IO load on the EMC, with almost no CPU
> >utilization.
> >
> >We have tuned our engine preferences to create large tables for the Context
> >index tables to prevent chaining and fragmentation.
> >
> >Any ideas on tuning approaches for Context would be appreciated.
> >
> >-----------== Posted via Deja News, The Discussion Network ==----------
> >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
>

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Wed Dec 02 1998 - 18:38:50 CST