Well, I have used this setting at the form level, and it works very well; in my case, I currently use it at teh form level for some custom functionality that I developed that can create hundreds of entries in a very short period of time in two forms. Without this setting, I used to get ARS errors about database timeout, but with this setting configured for these specific forms I don't get these errors anymore.
Maybe at the entire AR System level the overhead created by this feature outweighs any benefits gained. I guess it depends on your specific implementation (how big the server where the Remedy app server is running, type of database, number of ARS threads, usage patterns, etc, etc). Anyway, my reply to Alkan was a a suggestion that may solve or may alleviate his problem. You can always undo / reset this parameter if the performance has not improved. As with any suggestions for fixes found on any public internet forum, the responsibility solely rests with the recipient of the suggestion if he / she chooses to implement such suggestion at his own risk and with whatever due diligence he / she follows Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Wednesday, June 08, 2011 1:59 PM To: arslist@ARSLIST.ORG Subject: Re: Looooooooooong update times on ARSCHEMA ** I see you have been afflicted with trusting the BMC sales...err...product documentation on that feature. If you have real experience that shows clearly that this makes a positive difference, I would love to hear about it. I have significant experience with using this setting, and after our data showed it actually diminishing performance, I had conversations with BMC engineering on the subject to help me understand why that was. According to the engineers, the nextId setting is only going to help if you have a very high volume of records being inserted into the same form from multiple sources simultaneously. This is likely to happen only in large installations having more than one automated ticket generation mechanism. My research and data validated their statement. This setting does reduce contention for new Entry Ids, but its effect is only seen under those circumstances. Again, my research showed using any number greater than zero (or one) outside of the parameters I outlined actually DIMINISHED performance. Rick On Jun 8, 2011 12:35 PM, "Guillaume Rheault" <guilla...@dcshq.com<mailto:guilla...@dcshq.com>> wrote: _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
