Index Server Issue (OpenInsight 32-Bit)
At 05 JUN 2007 12:05:58PM chip fichot wrote:
I have seen this happen in both 32 and 16 bit, but I was wondering if anyone could shed some light as to why?
The index server will grab hold of an index file and will display that it is flushing that file. However, the gas gauge doesn't move (stays at 0%) and then after a certain period of time the index server window will completely gray out. Processor is pegged at 100% during this time and task manager shows OEngine.exe as "Not Responding".
Killing the process will either cause the index to be locked (therefore preventing any BTREE.EXTRACT reads of the index) or, upon restarting the index, will result in a repeat of the process.
LH Verify does not report any GFE's.
Any information would be appreciated.
At 06 JUN 2007 04:29AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Generally, this would happen because of a deadlock situation or the index nodes are very unbalanced.
In the former, this would usually be because multiple stations are updating indexes. You can resolve this by not calling index.flush and disabling the update indexes before filter flag. You can check who has what locks using the LIST_USER_LOCKS window.
As for the latter, that can be difficult to solve. If you have large amounts of identical fields indexed (like indexing on a boolean), then the system needs to push a key into the correct sort order, then balance out all the other keys.
Before you start the reindex process, have you checked that anything has actually happened to the index? Has anything actually flushed?
World leaders in all things RevSoft
Revelation Conference 2007, London - Wednesday 27th June Click here to register for the premier Revelation Software EMEA event of 2007
At 06 JUN 2007 09:17AM John Bouley wrote:
I have experience similar problems. Usually, it is a corrupt index. Sadly, the only way to know is to use AREV to update the index and see what errors are returned. The OEIndexer seems to "hide" any problems it encounters.
HTH,
John
At 06 JUN 2007 10:19AM chip fichot wrote:
Thanks to both of you.
As far as I can tell, there were still items to flush (based on review of items entered not appearing in an index lookup or BTREE.EXTRACT). However, subsequent attempts to flush were unsuccesful since killing the index server did not release the lock on the index file.
I don't believe that there is a call INDEX_UPDATE in the code so the dedicated indexing machine should be the only workstation indexing.
In the past, a reboot of the server and an index update through the database manager has flushed the remaining items. However, the problem has occurred at least three times over the last month on one particular table.
Aside from checking the 0 record of the ! table, is there any other place that needs to be checked to see if items still need to be flushed?
TIA
At 06 JUN 2007 10:37AM S Mecklenberg wrote:
Chip, FYI - LIST_USER_LOCKS only works with UDv3.0 - if you use it with any other network driver it crashes OI/Arev.
Typically I stop/start LH services in order to get the locks in the index released.
Are you running a replicator on your network while the indexing is running by chance? UD Heavy? or NeverFail? As these applications have given some of the symptoms you have described.
At 07 JUN 2007 04:00AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
If you go to the database manager, choose Database-]Environment settings, then click the Indexes/Report tab, is Update Before Query checked?
There might be code doing an index.flush() as well
Based on what you've been saying in the BTREE.EXTRACT - Lock the index? thread, it does seem like it's just taking a while to process the update.
World leaders in all things RevSoft
Revelation Conference 2007, London - Wednesday 27th June Click here to register for the premier Revelation Software EMEA event of 2007