Yes, you'd have a join form between the two. The two fields needed would be, MinRecord and MaxRecord. When the MaxRecord is set a filter would set the MinRecord to be 10k less. Then you can just use 'Case ID' >= $MinRecord$ and 'Case ID' < $MaxRecord$ in your escalation qual. Have another escalation fire a safe time after the first to set the MaxRecord field 10k higher. Different then what we were using it for but it will serve the purpose.
------------- Dylan Wheeler Production Control Analyst Principal IT Operations Downey Savings & Loan Association, F.A. Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Robert Halstead Sent: Wednesday, December 19, 2007 2:02 PM To: [email protected] Subject: Re: Handling 10,000+ tickets in an escalation ** so then the escalation would run on a join form of the two correct? That's a great idea Dylan. Never thought of that. On Dec 19, 2007 2:57 PM, Wheeler, Dylan < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: As to the last part, you could use a helper form to store the highest record you want to process. Then after the escalation has run add 10k to the field. It's what we had to do with Remedy - LDAP integration back in 5.x when Remedy paging wasn't too swift. ------------- Dylan Wheeler Production Control Analyst Principal IT Operations Downey Savings & Loan Association, F.A. Email: [EMAIL PROTECTED] -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, December 19, 2007 1:48 PM To: [email protected] Subject: Re: Handling 10,000+ tickets in an escalation The admin queue is single threaded, but it is only used for admin (specific) operations. The escalation queue, in your version, is single threaded. The fast/list queues are multi-threaded; this is where the bulk of the work is performed. Each thread, for each queue, has its own db session. Take a closer look at what the escalation was doing (what are the filters doing that it trips). Axton Grams On Dec 19, 2007 4:24 PM, Robert Halstead <[EMAIL PROTECTED] > wrote: > ** Hello all, > > First off, we are using AR Server 6.3 patch 22. We have a escalation > that automatically moves our incident tickets from resolved to closed > after 48 hours of the ticket being resolved. We recently resolved > around 40,000 tickets a couple of days ago not thinking of this > escalation. Well, today, the escalation brought Remedy to a halt as > the escalation took over all resources. > > If I remember the docs correctly, the arsystem uses the admin queue > for all database connections correct? And if I also remember > correctly, you can only have one admin queue. Why is this limitation > in Remedy? And if there isn't a limit, what would be the suggested > number? We have a server group of two servers and one database, we're > thinking about using one server for all escalations and another that > the users can use so that if this happens again, only the escalation > server will be bogged down and not the server everyone is using. Is > this a valid setup for a server group? > > Also, is there some way to force Remedy to say only resolve a limited > number of tickets in a go? Like a SQL Limit statement? I'm sure we > are not the only ones who have ran into this problem, but how do you > guys handle that many tickets in a go? > > -- > "A fool acts, regardless; knowing well that he is wrong. The ignoramus > acts on only what he knows, but all that he knows. The ignoramus may > be saved, but the fool knows that he is doomed." > > Robert Halstead __20060125_______________________This posting was > submitted with HTML in it___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" This message and any attachments are for the intended recipient(s) only and may contain privileged, confidential and/or proprietary information about Downey Savings or its customers, which Downey Savings does not intend to disclose to the public. If you received this message by mistake, please notify the sender by reply e-mail and delete the message and attachments. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" -- "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on only what he knows, but all that he knows. The ignoramus may be saved, but the fool knows that he is doomed." Robert Halstead __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
