Dedicated Indexers - The straight Stuff? (AREV Specific)
At 18 MAY 1998 05:57:05PM Jim Yeatrakas wrote:
I am looking for the straight story on Dedicated Indexers for AREV, all versions, but primarily 3.12.
I am bucking the IS staff on this, so my neck is out there. We do not have dedicated indexing set on our remote sites. These are large sites and not 4 or 5 folks linked in the office.
My position is that letting indexing occur on the workstation is an accident waiting to happen, and the position of IS is that since nothing bad has happened, nothing will. Additionally, a dedicated can run quite nicely on any of our old obsolete 386/486 we have lying around.
Well, I have finally run out of patience and pretty much said to hell with it, but I would like some of you who may have horror stories to tell, please share them with me. I will dutifully forward them to IS in bits and pieces until they recognize the threat.
*However*, if I am way off base here, please straighten me out and I will quit bugging them about this and will personally go down there and apologize on bended knee.
We have NT server and the NPP, though not the upgrade (considered *suspicious*)
TIA!
At 18 MAY 1998 07:49PM Jeff Blinn wrote:
I am looking for the straight story on Dedicated Indexers for AREV, all versions, but primarily 3.12.
I'll add my 2 cents worth:
We are using ARev 3.12 - and have two dedicated index PC's (for 2 groups of users/applications). You are correct that your older machines could more than likely handle the load - depending on the number of index transactions being written of course. Some of our reasons for using the dedicated indexing PC's are:
- Avoid workstation locking that can occur when more than one workstation starts updating indexes at the same time. When this happens, it often appears to the user as if they are 'locked up' and they give the PC the 3 key salute to get out - not good for data integrity.
- Indexes are generally kept much more current because of the increased frequency that an indexing PC can update indexes compared to the 'idle' workstations. Our users like this because they often want to look up a record they just entered - it is usually there rather quickly.
- Indexing happens in one place - you have far fewer corrupted indexes.
- You could realize a benefit in reduced network traffic by not having all the workstations polling for index updates - this would depend on your own circumstances.
At 19 MAY 1998 01:00AM Curt Putnam wrote:
Jim,
It has been my experience that:
1) - A dedicated indexer reduces network traffic significantly; especially if the indexer(s) have their own leg.
2) - The Station lockup appearance causes far more problems than a dis-used machine + NIC is worth.
3) - Without a dedicated indexer, you WILL have index problems.
Downsides:
*) - If you have a dedicated indexer and it is NOT running, users will NOT understand what is wrong with the app.
A dedicated indexer is a MUST. We require that customers provide one as a condition of sale for out app.
At 19 MAY 1998 02:01AM Andrew P McAuley wrote:
Panacea=NT Service/NLM
Nearly Panacea=Dedicated Indexer
Accident waiting to happen=none of the above
World Leaders in all things RevSoft
At 19 MAY 1998 11:23AM Lauren Floyd wrote:
We use Ceridian's Ensemble product with AREV v3.02 on Novell 4.11 with the NLM and a dedictated indexer. We have a mixture of Win v3.11 and 95 PCs and the indexer is a 486 running Win v3.11.
We had frequent GFEs until adding the NLM.
We had frequent corrupted indexes until adding the indexer.
With 5200+ employees and 3-4 payrolls a month, these events were more than a bit stressful.
Note: You can still get those "apparent lockups" if a user queries a table and causes an automatic index update while the indexer is updating indexes on the same table
Lauren Floyd
At 19 MAY 1998 01:26PM Victor Engel wrote:
OK. I'll be the devil's advocate here. There are some situations where not having a dedicated indexer is fine. Suppose the typical user on your system does not do much with Arev and remains idle a good deal of the time. With appropriate settings for index time, etc., this can work out satisfactorily.
In another scenario, the users are divided among those who hit the system hard and those that sit idle. Configuring only those who sit idle (or as many as a required to ensure at least one is always logged on) as indexing machines would be appropriate.
If you are running a multi-tasking environment, and you are using version 2.12 or later (I think that was the version that implemented the change although it might be as old as 2.1), then instead of requiring a separate machine, you can set up a separate task on the workstation.
All these scenarios, of course, make the system vulnerable to what we have come to see as normal situations where the system hangs for some reason or where a reboot is otherwise called for.
My preference has always been to not only have a dedicated indexer but also to put it on a real DOS machine to avoid any potential OS problems.
At 19 MAY 1998 05:01PM J. Yeatrakas wrote:
I want to thanks all of your for resonding to this posting. I was feeling pretty lonely taking the position I was taking.
At 27 MAY 1998 04:31PM Bob Rowland wrote:
I had similar experiences maintaing Ceridian's HR-1 for 4 years at MCI/Denver with AREV v3.02 on Novell 4.11 with the NLM and a
dedictated indexer. We have a mixture of Win v3.11 and 95 PCs and the indexer is a 486 running Win v3.11.
We had frequent GFEs until adding the NLM about one year ago. I tried to get management to get the NLM for a long time and they paid a very high price for not listening to me sooner.
We always ran a dedecated indexer.
We had 18,000 employees and 4 payrolls a month.
Be careful to reboot your indexer every morning (early) if you bring it down for nightly backups. With one indexer you have all your eggs in one basket. If you run with alot of updates with the indexer down for a few to several hours you could get GFE's or have to rebuild your indexes. At MCI this was a 24 hour undertaking.
A dedicated indexer is recommended (486 or better) and the NLM is a MUST….