Re: ORACLE CONTEXT DML-RSS.

A couple things to add:
According to my system the folowing tables exist to support batch processing
of Context engine indexing:
what does DRQ_WAITING table do??
drq_pending is contains the queued elements but what is happening when an index is stuck. Is something getting locked? or what?? If the server is shutdown and restarted the locks could still be set???
It makes little sense. one would expect the locks to be cleared upon restart
of the server(s) but jobs stay stuck and the CPU utilization goes way up to 99%
Perhaps a better understanding of the tables below may shed light on what happened. Does anyone have any ideas here?? SQL> select table_name from user_tables;

TABLE_NAME

CTX_PROPER_NAME
CTX_SETTINGS
CTX_SVCQ
DR$CLASS
DR$CONTAINS
DR$OBJECT
DR$OBJECT_ATTRIBUTE
DR$OBJECT_ATTRIBUTE_LOV
DR$POLICY
DR$PREFERENCE
DR$PREFERENCE_ATTRIBUTE
DR$PREFERENCE_USAGE
DR$QUEUE
DR$RESTABS
DR$SECTIONS
DR$SECTION_GROUPS
DR$SERVER
DR$SOURCE
DR$SQE
DR$TEXT_INDEX
DR$TEXT_INDEX_LOG
DR$THS
DR$THS_BT
DR$THS_PHRASE

DRQ_BATCHES
DRQ_BATCHNO
DRQ_PENDING
DRQ_PENDING5058
DRQ_WAITING
NLS_MESSAGE

32 rows selected.
rss_at_ddsc.com (Robert Silver) 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 - 11:48:53 CDT