>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]
