|
I agree that this is _not_ an "interactive job," I would prefer to
think of it as a "very ugly interactive job." How often does someone
need a rate? More than once a day? A little design and coding
might go a long way...
On the other hand, you may have discovered your "parakeet"
that will tell you when your disk arms are too busy. Like the
miners that used a parakeet to warn them when the air in a mine
was getting bad, you may be able to tell how much disk queueing
backlog you have by measuring the response time on this
"read 200,000 records to get a number" routine. I suspect that
some "other" culprit (or collection of culprits) is making
your disks busy. Could be that journalling in the same ASP
is contributing to the problem. Journalling in a separate ASP
might help, if you end up with enough disk arms in the journalling
ASP, and don't starve the system ASP of disk arms. I am a big fan
of 2 and 4 gigabyte disks for this reason...
Charly Jones
Geezer in Gig Harbor
>As Al stated, no not on a read. Reads are not journaled and not
>able to be journaled prior to V5.
>
>Are you sure you're not reading for update and updating?
>Are you sure you're not reading for update and there are
>lock issues? Has an index changed? Have
>you put the job in debug and checked for index issues?>Next, an interactive program that reads 200,000 records
>is, IMO _not_ an interactive job, it's a batch job running
>in the interactive environment.
>As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
