** Looking at the portion of the query that was submitted it looks like there is just the one where clause to filter the records; as if the user is doing an unqualified search. 250,000 records is  fairly small number of  rows for a database to handle but doing a full scan of it would be painful.

Is there anyway you can force the user to provide some other search criteria that would include and indexed column?

On 5/10/06, Axton < [EMAIL PROTECTED]> wrote:
One option to consider, though this would require a redesign of your
current app, is to use dynamic group fields instead of the assignee
group fields (this accomplishes one thing, a separate field for each
user/group needing access); then set the server to disallow multiple
assignee groups.  This will cause the query structure to be changed
from what you observe to something along the lines of this:

(((T285.C112 = 'CrombJo') OR ((T285.C112 = '0') OR ((T285.C112 = '53091') ...

On the flipside, you may not be able to effectively index these
columns since you will have so many to deal with; so your mileage with
this design may vary.

Axton Grams

On 5/10/06, Flynn, Tom (MTO) <[EMAIL PROTECTED] > wrote:
> Hello All,
> Our Remedy Admin Group is investigating methods to limit intermittent
> performance problems on our custom ARS 6.3 p13/ MSSQL 2000 infrastructure.
> Specifically, does anyone know of a way to limit query results on a per form
> basis? We've recently implemented useage of field 112 on our Helpdesk form
> (approx 250k rows), which definitely adds overhead on select statements and
> seems to be the cause of increased overall processing 'noise'. Bottom line
> is that we can't rely on users to run smart queries against this form, so we
> need a way to prevent system slowdowns through workflow or some other
> setting.
>
> Just for the heck of it to show what's going on with C112, here's a portion
> of what we see in SQL Profiler during a query:
> SELECT
> T285.C1,T285.C1,C7,C600000495,C600000065,C600000122,C600000024,C600000137,T2
> 85.C1,C600000122 FROM T285 WITH (NOLOCK)  WHERE (((T285.C112 LIKE
> '%;''CrombJo'';%') OR ((T285.C112 LIKE '%;0;%') OR ((T285.C112 LIKE
> '%;53091;%') OR ((T285.C112 LIKE '%;53100;%') OR ((T285.C112 LIKE
> '%;53091;%') OR (T285.C112 LIKE '%;50001;%'))))))
>
> We're not interested in disabling the global 'Allow Unqualfied Searches'
> setting, Results List data chunking isn't what we're after either, and data
> archiving is a few months away, and may not matter. We're also in the
> process arranging testing p15 which reportedly addresses a 112 memory leak.
>
> If anyone knows a method to assist us, or if I missed something obvious it
> would be greatly appreciated - go easy on me, I'm a first time poster...
>
> Thanks,
> > Tom Flynn
> > ITSM Process Lead
> > e-Ontario OCCSD Servicedesk Project
> > Ontario Ministry of Government Services
> > E-mail: [EMAIL PROTECTED]
> >
> >
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org



--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249 __20060125_______________________This posting was submitted with HTML in it___

Reply via email to