Andy,Stop AR Server Clear Contect of Collection Directory Restart ARS and
reindex from FTS tab Do this on Primary FTS server if you have Server group and
start secondary FTS after starting Primary FTS and Indexing
In the latest doc BMC suggest not to increase thread and go with Default
settings
Also Restarting AR server will not cause FTS to start again.
Ravi
Date: Tue, 28 May 2013 13:18:47 -0500
From: and...@hicox.com
Subject: Re: how to identify FTS-indexed fields from the DB?
To: arslist@ARSLIST.ORG
**
aah yes, FT_PENDING ...
I had perhaps falsely presumed this was a cache mechanism to queue fields for
the indexer while the indexer was busy doing things (for instance re-indexing,
as it is now, or for instance to queue records if the indexer is still working
on the last run at the next scan interval).
I see a relatively small number of records in FT_PENDING (around 9k). However,
I don't think the indexer is stuck. It is consistently writing to the
collection directory (albeit excruciatingly slowly), and also it's logging like
mad. It should have several million records to scan ... each with multiple
indexed fields, so I would expect this to run for a while, but at the same time
... at this point, I need to get an idea of what it's doing ... how much longer
it has to go. People have questions, and I don't have answers :-/
I should mention that we've taken the obvious steps of allocating more threads
to the FTS RPC queue and also in the FTS plugin config.
I should also mention that for a period of about a week and a half, we had some
external issues which were causing the arserverd process to hang, die and
restart at least twice daily ... does anyone know if arsystem restart causes
an in-progress FTS re-index to dump it's work and begin again? I wonder if this
could be part of our problem? By that same token I can't seem to find any
obvious way to force FTS to abort a re-index procedure and begin again
(presuming that's not what happens by default when you restart arsystem).
thanks for the pointers to the docs and the kb guys ... I'll have another
search through those.
-Andy
On May 28, 2013, at 12:53 PM, Tauf Chowdhury wrote:I may be fuzzy on this but
there is a table called FT_Pending that
holds some data on what is being indexed and then dropped once it is
in the collection directory. If your indexing is running for more than
a month though, I'm pretty sure it's hung and not doing anything. The
size of FT_Pending should always be small if the indexing is in
progress.
Sent from my iPhone
On May 28, 2013, at 1:47 PM, Andrew Hicox <and...@hicox.com> wrote:
Hello everyone,
I currently find myself in the third circle of ARS hell ... debugging FTS on
ARS 7.6.03 (it's a long story on why we're not on 7.6.04 yet, but suffice it to
say, I have no immediate control of that situation).
We have had an FTS re-index procedure running for more than a month now. I need
to get an idea on where it is, and how much longer it needs to finish. I can
trace some of this through the arftsindex.log(s). It seems to iterate per-form,
per-indexed field. So ... form A, indexed field 1 ... then indexed field 2,
etc, etc cycling through every record in the form N times where N is the number
of indexed columns in the form.
So ... part of this is that I need to be able to know exactly how many such
fields and forms I'm looking at.
I need a better way of doing this than to open each form on the server, and
pick through the field properties on every form.
I've tried running the sql log on server startup to try and capture whatever it
is the ft dispatcher executes in the DB to find the indexed fields, but if it's
there I sure as heck can't find it. There do not appear to be any obvious
columns on the 'FIELD' table that would indicate FTS indexing mode, nor do
there appear to be any adjunct tables (like the various FIELD_* tables) that
would contain this data.
I'd like very much to be able to execute a query on the DB that would return
schemaid and fieldid of all the fields that the FTS indexer is going to try and
run through.
Does anyone know of a way to do this?
-Andy
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
_ARSlist: "Where the Answers Are" and have been for 20 years_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
