Here is something else to consider. If I remember correctly whenever you
open a ticket for display in out of the box HD, all the table fields on all
tabs would refresh. To speed performance in this case I altered the
refresh of those table fields to occur only on a gain focus of the tab on
which the table field existed. When you begin to have large numbers of
tickets in the HD form, this can slow things down.
Christian Smerz
At 11:20 AM 1/8/2003 +0000, you wrote:
>I found indexing the Dup ID+ field on HPD:HelpDesk improved performance
>significantly when viewing an existing request; the table fields on the
>Duplicates tab are refreshed on opening the window - without an index this
>was taking over 5 seconds with 40000+ records.
>
>Martin Crothall
>Met Office, Bracknell, UK
>
> > -----Original Message-----
> > From: Fondse, Theo [SMTP:Theo.Fondse@ARS.SMC.SIEMENS.CO.ZA]
> > Sent: Wednesday, January 08, 2003 10:04 AM
> > To: ARSLIST@ARSLIST.ORG
> > Subject: Re: ARS Performance/Responsiveness
> >
> > Rick's correct! This is an issue I also have picked up with some of my
> > cutomers using HD4. If memory serves me right, Patch 678 solved this
> > issue,
> > but you have to apply the pacth just after you have installed HD4.
> > (DO NOT apply the patch if you have modified HD4!)
> >
> >
> > Best regards,
> >
> > Theo J. Fondse
> > Remedy Developer
> > Siemens Business Services
> >
> > Telephone: +27 11 652 7477
> > Mobile: +27 83 773 3075
> > e-Mail: theo.fondse@ars.smc.siemens.co.za
> > Web: http://www.siemens.co.za
> >
> > ==========================================================================
> > =
> >
> >
> > -----Original Message-----
> > From: Rick Cook [mailto:rcook@DENALIAI.COM]
> > Sent: 08 January 2003 00:51
> > To: ARSLIST@ARSLIST.ORG
> > Subject: Re: ARS Performance/Responsiveness
> >
> > Since you're using the Console, check the number of records in
> > SHR:ConsolidatedList, too. Sometimes old records don't get deleted as
> > they
> > should, and they can really accumulate, making queries longer.
> >
> > Rick
> >
> > -----Original Message-----
> > From: Charles Lowe [mailto:CLowe@RCCL.COM]
> > Sent: Tuesday, January 07, 2003 14:29 PM
> > To: ARSLIST@ARSLIST.ORG
> > Subject: Re: ARS Performance/Responsiveness
> >
> >
> > Thanks Mikhail,
> >
> > Our user base heavily relies on the Remedy Support console for access to
> > the various forms. I'll have to look into the macro thing, sounds like a
> > reasonable culprit.
> >
> > "There are no boundries for those with imagination and the ability to
> > wield
> > it."
> >
> > Regards,
> > Charles Lowe, Remedy Analyst
> > IT - Enterprise Technology & Operations
> > Royal Caribbean International & Celebrity Cruises
> > Phone (305)982-2937 Cell (786)218-0027
> >
> >
> >
> > Mikhail Gvozdev
> >
> > ARSLIST@ARSLIST.ORG
> > L.COM.AU> cc:
> > Sent by: "Action Subject: Re: ARS
> > Performance/Responsiveness
> > Request System
> > discussion
> > list(ARSList)"
> >
> > ORG>
> >
> >
> > 01/07/2003 05:11
> > PM
> > Please respond to
> > arslist
> >
> >
> >
> >
> >
> > Hello Charles,
> >
> > If you're using Remedy Help Desk application, these table scans are most
> > likely generated by badly written macros.
> > We had this issue with one of the customers. The system became practically
> > irresponsive after end user clicks 'Details...' button on Remedy Help Desk
> > Support or Remedy Help Desk Management consoles to bring the ticket
> > selected
> > from the table field.
> >
> > One of the macros which forces Oracle to perform table scans is
> > SHR:OpenForm, it is used by the following active links:
> > name
> >
> > -----------------------------------------------
> > RR:RSD-OpenFormDetails
> > RR:SHR-OpenFormDetails2
> > SHRA:AST-ShowRelatedDetails2
> > SHRC:CHG-ShowRelatedDetails2
> > SHRH:HPD-ShowRelatedDetails2
> > RR:MHR-OpenFormDetails
> > RR:MHR-OpenFormDetails-SLA
> > SHRAW:AW-ShowRelatedDetails2A4
> > SHRAS:AS-ShowRelatedDetails2A4
> > SHRAL:AL-ShowRelatedDetails2A4
> > SHRAM:AM-ShowRelatedDetails2A4
> > SHRSW:SW-ShowRelatedDetails2A4
> > RR:AA-ShowDetailsDownA4
> > RR:AA-ShowDetailsManagerA4
> > RR:AA-ShowDetailsOwnerA4
> > RR:AA-ShowDetailsRepairA4
> > RR:AA-ShowDetailsUserA4
> > AST:IN Details-Asset 2 AM4
> > AST:IN Details-Cmpnt 2 AM4
> > SHRM:SHR-ShowRelatedDetails2A4
> >
> > This macro uses value in 'Case ID+' field in HPD:HelpDesk form as a search
> > criteria, but out-of-the-box QBE setting for this field is set to
> > "Anywhere", which causes table scans on Oracle and clustered index scans
> > on
> > MS SQL Server.
> >
> > Looks like macro was recorded using fields in the form, not Advanced
> > Search
> > bar. We re-recorded this macro and it solved customer's problem.
> >
> > Another good candidate for table scans is 'Assignee Group' field, if it
> > stores multiple groups' IDs (so called row-level access feature).
> > In SQL log file you'll see like this feature builds SQL statements
> > containing multiple LIKEs with leading and trailing wildcards linked by
> > ORs
> > operators.
> > If you ask MS SQL Server to display the execution plan for such a query -
> > you'll see clustered index scan. Oracle does full table scan, quite scary
> > picture.
> >
> > I've spoken to Remedy Engineering Team about this feature and asked
> > whether
> > it is valid to have multi-valued columns in the table (it violates the
> > First
> > Normal Form for database normalisation) - they say this is absolutely
> > correct....
> >
> > Keep searching, and you'll find more beasts!
> >
> > Regards,
> >
> > Mikhail Gvozdev
> > Remedy Product Support
> > Planwell Technology Australia Ltd.
> > 1-5 Railway Street
> > CHATSWOOD NSW 2067
> >
> > Phone: +61 2 9412 - 8763
> > Fax: +61 2 9419 - 7803
> > mailto:mikhailg@planwell.com.au
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Charles Lowe [mailto:CLowe@RCCL.COM]
> > Sent: Wednesday, 8 January 2003 06:33 AM
> > To: ARSLIST@ARSLIST.ORG
> > Subject: ARS Performance/Responsiveness
> >
> >
> > Does anyone out there experience random slow downs in Remedy. Like when in
> > User and try to fill out a Helpdesk form or loading a form? We been
> > troubleshooting our system and think its bad SQL statements causing the
> > problem, forcing the db to blow its cache by doing full table scans. Only
> > problem is it seems the ARS server is generating this bad SQL
> > code...anyone
> > else seen or experiencing such issues? We are using ARS 4.03 & Oracle
> > 8.16.
> >
> > "There are no boundries for those with imagination and the ability to
> > wield
> > it."
> >
> > Regards,
> > Charles Lowe, Remedy Analyst
> > IT - Enterprise Technology & Operations
> > Royal Caribbean International & Celebrity Cruises
> > Phone (305)982-2937 Cell (786)218-0027
> >
> >
> >
> >
> >
> > You may control your subscription options, including UNSUBSCRIBE,and
> > ACCESS
> > THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send
> > eMail to support@arslist.org
> >
> >
> >
> >
> >
> > You may control your subscription options, including UNSUBSCRIBE,and
> > ACCESS
> > THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send
> > eMail to support@arslist.org
> >
> >
> >
> >
> > You may control your subscription options, including UNSUBSCRIBE,and
> > ACCESS
> > THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send
> > eMail to support@arslist.org
> >
> >
> >
> >
> > You may control your subscription options, including UNSUBSCRIBE,and
> > ACCESS
> > THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send
> > eMail to support@arslist.org
> >
> >
> >
> > You may control your subscription options, including UNSUBSCRIBE,and
> > ACCESS THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please
> > send eMail to support@arslist.org
>
>
>You may control your subscription options, including UNSUBSCRIBE,and
>ACCESS THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please
>send eMail to support@arslist.org
You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send eMail to support@arslist.org
Previous Topic
Index