I find that its not the number of indexes that is the problem but inappropriate indexing
Also if you use SLM then you will almost certainly need some additional indexes beyond the ootb ones once your DB gets over a certain size. We have added to additional indexes on SLM:Measurement to solve performance issues related to full table scans that we performed as part of the incident submit process. Also check Oracle AWR reports for long running queries this may provide some answers Stuart Schon Team Leader Fujitsu Australia Limited From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of John Sundberg Sent: Tuesday, 13 July 2010 08:16 To: [email protected] Subject: Re: Poor performance while saving Incidents ** DESIGN DISCUSSION... Although technically true (takes more time) -- has anybody ever seen an average index insert take > 1 second to insert the index info? Meaning -- you submit a record -- it took 1 second. After adding an index - it now takes 2 seconds. Index population is raw at the db level (no Remedy workflow involved) -- if I look at actual db inserts -- they are .001 seconds. (normally) I do not think additional indexes are that bad. -John On Jul 12, 2010, at 5:02 PM, Patrick Zandi wrote: ** My suggestion is too many indexes .... More indexes the slower the saving of the form. Test it Sent from my iPhone On Jul 12, 2010, at 4:14 PM, "Garrison, Sean (Norcross)" <[email protected]> wrote: ** Setting the field in the configuration file is not enough. You have to also run the stored procedure to update all of the tables to "In-Row" storage. Any new tables created by the arserver will use in-row storage. The lob storage conversion stored procedure is found in the "RemedyAndOracleCLOBs.pdf" document. Other things to check: 1. Do you have a lot of Indexes on HPD:HelpDesk? If so consider reducing any unnecessary indexes. The more indexes you add the slower the "INSERT INTO" sql statement ... 2. Do you have any custom workflow that may be causing a delay? 3. Have you considered increasing the memory available to the DB? (By far the biggest performance improvement you will get) 4. Do you have Oracle Cursor sharing set to SIMILAR on both the Oracle DB and in the ar.conf file? Thanks, Sean From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of SriSamSri Appecherla Sent: Monday, July 12, 2010 4:00 PM To: [email protected] Subject: Poor performance while saving Incidents ** Hi, Creating incidents is taking a lot of time. When I create an Incident, it is taking about 20-25 seconds to save, though I have set the Store LOB in row option from the server information window. I checked the SQL logs and found that a lot of time is wasted while setting the LOB fields. ARS 7.5, Patch 3 (in server group) Oracle 11g Sun Solaris 10 Please help. Regards, SriSamSri Appecherla Mobile# +91 991 610 6008 _attend WWRUG10 www.wwrug.com <http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com <http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ -- John Sundberg Kinetic Data, Inc. "Building a Better Service Experience" Recipient of the WWRUG09 Innovator of the Year Award [email protected] 651.556.0930 I www.kineticdata.com <http://www.kineticdata.com/> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email [email protected] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
