Hmmm, this has got me thinking.... Has anybody changed the performance setting to "Optimize this computer for Background Services" rather than "Programs"?
Also, I think this KB article is right on the money for another tuning parameter. http://support.microsoft.com/default.aspx?scid=%2fsearch%2fviewDoc.aspx% 3fdocID%3dKC.Q228766%26dialogID%3d5631937%26iterationID%3d1%26sessionID% 3danonymous%7c3884245 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Emmitt Dove > Sent: Thursday, December 13, 2001 7:46 AM > To: [EMAIL PROTECTED] > Subject: More on R:Base 6.5++ and W2k Server > > 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 ================================================ 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
