oplock problem

[David Collier-Brown]

Johann Zuschlag wrote:
| That seems logical for me since caching is switched off if several
clients access
| one, e.g. database, file. The funny thing is that since a database
client
| software update we got oplock breaks. Switching oplocks off fixed the
problem. I
| guess the WIN95/98 clients aren't behaving well. And finally, if one
machine
| crashes you  lose the cached data leaving you with an inconsistent
database.

	I often worry about cache consistency when one is doing
	any kind of update-in place (as opposed to "write the whole
	file after rechecking it hasn't changed on disk").  MS client
	code doing this makes me more worried than usual (;-))


| The real question is: What are the best settings for multiuser
database 
| applications concerning speed (index searching). I tried different
things like
| changes in the  socket options, didn't change anything. After I
updated to fast
| ethernet the database access speed didn't really change. The database
(45Mbyte)
| seems to fit in the  memory of Linux (2.0.35 with Samba 1.9.18.p8,
198Mbyte RAM).
| No disk access is needed (and seen) but still index searching is
pretty slow,
| while single dataset access is good. 

...
| Just to make my point clear: If a single user accesses the database
with
| oplocks=true, index search is really fast. But that is not the
scenario I'm
| looking for.

	Index searches, or any other full-table-scans, will want
	options aimed at maximizing data transfer speed and cutting
	latency...  However, in my considered opinion, doing full-table
	scans by copying the data to a client and scanning there
	this is exactly what you **don't** want to do.  I claim (and most
	database vendors agree) that searching on the database server is
	several orders of magnitude faster than shipping the data to
	the client.  The only time you want to do that is when the dataset
	will be looked at over and over, and the looking process is
	cpu-intensive. Or there is only one client!


	Is the program a "real" database, that can do the searches locally,
	or is it strictly something that has to be run over nfs or smb?
	
	Be aware that some vendors sell inexpensive versions of their
	database that work ok for one or two users over nfs/smb, but 
	don't scale. This then allows them to sell you a back-room machine 
	to run the real version of the program, which works with remote 
	clients but does all the hard stuff on the database server.  
	Access is an example of this style of program[1].

	The marketing approach used is "here, have a free sample of
	crack cocaine" (;-))

--dave
[1. Warning: look at my return address before assuming anything I say
    about Access is without bias]
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com