By way of sharing information on the above subject:
(Environment: 10/100 mbps LAN with 10-15 users connected to the db at any
given time)
Yesterday I twice observed a condition where an R:Base task running on W2k
Server, connected to a database on a share from another W2k Server, got the
"Waiting for access to required resource" message, displayed the 25%, and
stopped. I think the first time I found this it had been sitting at 25%
for several hours.
Again, on two occasions, the same task was found at the R>. The code that
was running would do this:
DISCONNECT
SET STATICDB ON
SET MULTI ON
SET FASTLOCK ON
SET QUALCOLS 2
CONNECT dbname
I determined that the CONNECT failed. (The same database was connected
before the DISC, so it is not a question of access rights or anything
else.) Entering "CONN dbname" at the R>, without doing anything else,
connects the database. My interpretation of this problem is that the time
between the DISC and the CONN is so brief that the rest of the system, that
is the link from the box on which the process is running over the network
to the server with the share, had not had the opportunity to recover from
processing the DISC (from the OS perspective a directive to close 4 files)
before the CONN (an OS directive to open four files) came along, and the
CONN wasn't processed as a result.
In fact, if I insert a PAUSE FOR 1 right before the CONN in the code above,
it will work every time.
So I interpret the net result of this to indicate that the client, in this
case also W2k Server running on a dual processor Pentium III at 733
mHz, is too fast for the server (dual processor Pentium III at 733 mHz in
a domain controller role) - that is to say that the server in some
instances simply cannot keep up with the client on OS level file operations.
I further believe that the proliferation of "waiting for access" messages
is related to contention for file 1, again because the server OS-level
operations are getting backed up. Take the example of inserting a row into
a table. My understanding of the process, and this may be somewhat
inaccurate on sequence but should be inclusive of the steps required,
involves placing a lock on file 1, rereading file 1 into memory, inserting
the row into file 2, maintaing the indexes, flushing file 1 back to disk,
and releasing the lock on file 1. The reason for the lock on file 1 is
that R:Base maintains this data in memory for rapid access, rereading it as
necessary. When a row is inserted into a table, data in file 1 has to be
updated for that table. R:Base has to be sure that while the insert
operation is in process no one else can change the data in file 1 for that
table (and file 2, for that matter). If any part of this process gets
bogged down by the OS on the server, other users attempting to get a lock
on file 1 will hit the "waiting for access" message.
There are likely several other scenarios that could produce the same
result. My bottom line is that I have a problem with the server holding
the database not servicing the file i/o requests quickly enough. In other
words, it isn't an R:Base problem, it is a Windows problem. Refer back to
my message yesterday wherein I indicated that our next installation will
have a dedicated database server running dual Xeons at 1.something gigahertz.
Any feedback on these musings? I'm no expert at this stuff, folks ... feel
free to poke holes in my theories - please!
Emmitt Dove
Manager, DairyPak Business Systems
Blue Ridge Paper Products, Inc.
40 Lindeman Drive
Trumbull, CT 06611
(203) 673-2231
[EMAIL PROTECTED]
[EMAIL PROTECTED]
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
