John, In the bigger picture it's not really a matter of raw performance at the DB level -- it's a matter of resource contention.
Some actions performed while inserting or updating an index entry end up issuing a lock on the resource(s) being used. While it is locked, nothing else can insert, update, and some times even query. Nutshell: It doesn't matter if the action only takes .002 seconds if you have to wait 2 seconds for your turn. Start increasing the number of concurrent users creating tickets for your test and you will eventually get to your +1 second. Juan Ingles P.S. I don't think anyone is saying that indexes are a bad thing, just that you have to be careful. On Mon, Jul 12, 2010 at 3:16 PM, John Sundberg <[email protected]> wrote: > ** > 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 ARSlist: "Where the Answers Are"_ > > _attend WWRUG10 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 > > > > > > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
