There is no error indicated in the log.
But in any event, what is your shared pool size and your sort area size?
sahred pool needs at least 12M
Have you created an index? What is the size of your table and nature of the
data?
Do you have archiving on? It does create a bunch of logs if you have large
amount of data
Do you have thematic indexing on? I believe the default in on, when you
create an index.
below is from MetaLink:
Is theme processing being used? In using a UTF8 database, EXTPROC process
can loop causing 100% utilization. This is a bug, however, development
states: Theme processing makes sense only in single-byte character sets, and
only in English. Using themes in this sense is improper use of the
product -- add parameters ('lexer ctxsys.basic_lexer')or some other lexer
preference which does not have index_themes on. When this was tested the
data indexed with no problems. This was an issue addressed by development in
bug (1350851).
"Robert Silver" <rss_at_ddsc.com> wrote in message
news:259cff91.0110021450.7b201574_at_posting.google.com...
> Yes ofcourse I have logging turned on, however, It does not tell me
> what is really going on other than the fact that it is Indexing
> and gets stuck and ORACLE80.EXE shoots up to 98% Utilization.
> Actually perhaps if someone could tell me how to tune the Context
> engines
> not to suck up so much CPU. I would be willing to let the job try to
> process.
> I get no resource errors like some table space is needed.
> So I am at a loss to tell my user anything but that the data in that
> set of
> policies is screwing up the server. I need a beter diagnostic. Is
> there a debug
> level I can set on the context engine?? Something that will show more
> than:
>
===
> Oracle ConText Option: Release 2.4.5.0.0 - Production on Mon Oct 1
> 21:22:1 2001
>
> (c) Copyright 1998 Oracle Corporation. All rights reserved.
>
>
> 21-22-01 10/01/01 === OCO server startup ===
> 21-22-01 10/01/01 Initialized CORE
> 21-22-02 10/01/01 Connected to database.
> 21-22-02 10/01/01 === Initializing dispatcher ===
> 21-22-02 10/01/01 === Server startup completed. ===
> 17-03-17 10/02/01 DML batch: batch=668612, cid=4522, number of rows=37
> 17-03-19 10/02/01 Begin document indexing
>
> What causes this behavior. Is it a bug in Oracle brought on from bad
> data?
> A resource issue that goes undocumented?
>
> I know the context servers are running on other batches of data to
> index.
> I am having a hard time getting anywhere here because the problem is
> underneath
> the Oracle covers so to speak.
> I know I have a working context in other sets of policies but not that
> one.
>
> Anyone who can tell me how to get more information about this process
> I will gladly reward $$. I need to get this problem resolved soon.
> The fangs are out
> for more blood now!!!
>
> As I said before I deleted the offending PPXCASE entries from the
> drq_pending
> queue table and restarted the server. My problem now is to figure out
> what
> the Context server does not like without driving the entire server
> into the ground in the process or disrupting service to the users who
> have no such problems. PPXCASE remains a problem. How can I trouble
> shoot it. All I get
> is the above error and then CPU time shoots up to 99% for ORCALE80.EXE
> under NT 4.0 SP5 runnging ORACLE 8.05
> The fangs are out!!!
>
>
> "timkarnold" <timkarnold_at_home.com> wrote in message
news:<Mqlu7.29053$Xz1.7296288_at_news1.rdc1.md.home.com>...
> > Do you have logging turned on?
> > If so, check logs; if not, turn on logging.
> >
> > But perhaps in the mean time, I'd suggest using ctxsrv -user
> > ctxsys/ctxsys -log mylog.txt
> > If you don't write an NT service, you will have to dedicate a
workstation
> > for indexing.
> >
> > Tim
> >
> >
> > "Robert Silver" <rss_at_ddsc.com> wrote in message
> > news:259cff91.0110020659.47b85555_at_posting.google.com...
> > > In an effort top fix some problems we experienced on the server
> > > yesterday I came accross this:
> > >
> > > it is exactly how Oracle recomends that you do it. Even to the point
> > > of
> > > truncating those tables. If you submitted this job as a batch job
> > > through
> > > the Context Admin utility you also need to execute dbms_job.delete to
> > > delete
> > > the job otherwise it will forever stay in the job cue and will never
> > > stop
> > > running.
> > >
> > >
> > > The context server needs to be better understood. Obviously the
> > > stalling problem we have with PPXCASE is local to that
> > >
> > > Here is why I think maybe a step or two was missed:
> > >
> > > Hindy if you are out there please reply! Anyone else would be welcome
> > > as well.
> > >
> > > Again on an NT/Oracle 8.05 server the context engine server DML
> > > stalled on
> > > a queued job. What would cause such a stall and how do possibly
> > > resolve it.
> > > Is there any special diagnostics anyone can suggest??
> > > Any help here would be appreciated. Also How do I know I cleaned out
> > > all the garbage are the folowing tables all that are involved:
> > > drq_pending
> > > drq_batches
> > > drq_batchno
> > > ctx_policies
> > > I do not understand the roll the following two play??
> > > ctx_svcq
> > > drq_waiting
> > >
> > > Any help in debuging this problem would be greatly appreciated
> > > If anyone is aware of any character sequences or characters that cause
> > > this
> > > stalling please let me know as well.
> > > I would be willing to pay for a good answer to this problem myself. I
> > > am being
> > > abused by users please help!
> > >
> > > They have nasty fangs and sharp teeth!!
Received on Wed Oct 03 2001 - 08:34:44 CDT
