Emmitt,
When you use page locks instead of row locks, there is less overhead because
you are locking larger pieces of the #2 file. Normally you are better off
with page locks unless you have lots of users in your system editing records
that are physically close together in the #2 file at the same time. Then you
would want to use row locks instead of page locks.
I don't think this is your problem, but you should get a little better
performance.
I would guess you either have a power problem, or a bad network card causing
your problems.
Troy
>===== Original Message From [EMAIL PROTECTED] =====
>>Emmitt,
>>
>>Try settings your qualcols to 10. This will change the system from row
level
>>locking to page locking. You may get better performance.
>
>I admit that I do not understand why page locking would be better than row
>locking, especially when dealing with file 1. Please help me
>understand. It isn't performance that is the issue, it is the WFATRR
>message. Performance is quite good otherwise.
>
>
>>Are you creating indexes on your temporary tables? I have seen this cause
>>problems.
>
>
>No.
>
>
>
>>How many users do you have? Do they all have UPSs on their machines?
>
>Six to ten at any given time on desktop machines, eight to ten at any given
>time via terminal servers, and a couple of robotic processes running on
>another server. The TS users don't need UPSs since Metaframe will not shut
>down their session in the event they lose a connection. I haven't gotten
>to the point of putting UPSs on all the desktops yet, but power is not a
>problem here.
>
>
>>Usually when you get the waiting for required resources message on a bunch
of
>>machines, one machine will have a message that says "DO NOT INTERRUPT THIS
>>PROCESS". This is machine that detected a problem w/ the database and is
>>probably rebuilding an index. Murphy's law states this happens on the
>>slowest
>>machine on your network.
>>
>>Troy Sosamon
>>
>> >===== Original Message From [EMAIL PROTECTED] =====
>> >One particular issue is an excess of "waiting for access to required
>> >resource" messages. I have reason to believe the contention is on the
.RB1
>> >file.
>> >
>> >We run with:
>> >
>> > STATICDB ON
>> > MULTI ON
>> > FASTLOCK ON
>> > QUALCOLS 2
>> > ROWLOCKS ON
>> >
>> >We also make extensive use of temporary tables and views. Frequently the
>> >WFATRR message will appear when a given command file is attempting to
>> >create a temporary table or view.
>> >
>> >This occurs for both fat and thin clients. (Fat client is a desktop user,
>> >thin client is a Citrix client to the Terminal Server.)
>> >
>> >Overall architecture: database resides on a 2-processor 733mhz P3 Xeon
>> >domain controller with 500 megs RAM. There are two terminal servers, one
a
>> >2-processor 733 mhz, the other a 2-processor 933 mhz, each with 1 gig
>> >RAM. They are interconnected through a 10/100 switch, each machine
sitting
>> >on its own segment. The entire network infrastructure is 10/100 ethernet,
>> >nearly all clients are 100 mhz capable.
>> >
>> >The R:Base version is 6.5++ Windows.
>> >
>> >I have tested the throughput between servers, and find no issues
>> >there. (Copy a 4.5 megabyte file from one to another in about 1.25
>> seconds.)
>> >
>> >Any thoughts, anyone?
>> >
>> >>I think this topic should be discussed on the list.
>> >>I would like to see this also.
>> >>
>> >>Troy
>> >>===== Original Message from [EMAIL PROTECTED] at 8/01/01 5:59 am
>> >> >Begging the List's pardon, would someone kindly respond via private
email
>> >> >with the tips on tuning for the above configuration?
>> >> >
>> >> >Many thanks ...
>> >
>> >Emmitt Dove
>> >Manager, DairyPak Business Systems
>> >Blue Ridge Paper Products, Inc.
>> >40 Lindeman Drive
>> >Trumbull, CT 06611
>> >(203) 673-2231
>> >[EMAIL PROTECTED]
>> >[EMAIL PROTECTED]
>>
>>Troy Sosamon
>>Denver Co
>>[EMAIL PROTECTED]
>
>Emmitt Dove
>Manager, DairyPak Business Systems
>Blue Ridge Paper Products, Inc.
>40 Lindeman Drive
>Trumbull, CT 06611
>(203) 673-2231
>[EMAIL PROTECTED]
>[EMAIL PROTECTED]
Troy Sosamon
Denver Co
[EMAIL PROTECTED]
