Rick, Thanks. I did this on one other project and saw no issues a month after go-live.
I am starting to think that it might be a arserver patch level issue. The system I did this on was 7.1 patch 2 or 3 this one is at patch 5. Thanks for the advice. Howard On Wed, Sep 16, 2009 at 12:37 PM, Rick Cook <remedyr...@gmail.com> wrote: > ** Howard, this looks like it's expected behavior. It doesn't sound like > the Block ID setting is what you really need. I did some extensive testing > of this when I first implemented 7.1, and found, through actual experience > and discussions with engineers and support personnel, that the only > instances in which it should really be used are when something like an NMS > program might be creating large numbers of records simultaneously. The site > I was at had more throughput than what you listed. 40K/month isn't a large > enough number to justify it - that's only 2000/day. IMO, you would need > about 10 times that to really get the benefit from it. > > It also did not work well in a server group environment, as it exhibits the > massive number skipping results you saw, because each server maintains its > own blocks. It's too involved to get into here, but you could easily end up > skipping hundreds of EntryID numbers with a single submission, depending on > which server was used for the creation. You may also end up with records > that are out of date order in a server group situation. This may mess up > reporting, which is another reason I would not use this function on a form > against which reporting was being done. > > So I would not use it - at all - for your Incident form, unless there is a > clear reason to do so. I mean a VERY clear reason. I was dumping over 20k > records into a form with an escalation (i.e. all at once, daily), and I saw > no benefit from using settings of 10 or 100. In fact, the measurements we > took indicated a slight performance DECREASE from doing so. > > Rick > > On Wed, Sep 16, 2009 at 8:35 AM, Howard Richter <hbr4...@gmail.com> wrote: > >> ** >> >> Good morning, afternoon and evening all, >> >> >> >> 4 weeks after going live, we saw that our incident numbers had increase >> from a starting point of 245,000 to over 900,000. However, the system has >> only added 40,000 tickets. >> >> >> >> First we are on 7.1 patch 5 and running ITSM 7.0.3 patch 8, on 4 servers, >> in a server group. We have the pre-cache of IDs set for 100. In an analysis >> of the tickets in the system we have seen some gaps of anywhere between 3 >> and 250 (we cannot find any larger then 250). >> >> For example on one day, you would have INCxxxxxx (then a gap of 8) then >> INCxxxxx (then a gap of 40) then INCxxxxx (gap of 81) and then it would be >> back to normal. >> >> >> >> There is nothing in the logs at this point, other than a couple of >> heartbeats lost in the server group logs (I looked at all 4 boxes). >> >> >> >> Per BMC, we are going to run sql logging and try an match it up with the >> heartbeat losses and then we might disable the pre-cache of the IDs. >> >> >> >> My question to the group has anyone ever seen something like this? >> >> >> >> As always thanks, >> >> Howard >> >> -- >> Howard Richter >> Red Hat Certified Technician >> CompTIA Linux+ Certified >> ITIL Foundation Certified >> E-Mail = hbr4...@gmail.com >> LinkedIn Profile = http://www.linkedin.com/in/hbr4270 >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ > > > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ -- Howard Richter Red Hat Certified Technician CompTIA Linux+ Certified ITIL Foundation Certified E-Mail = hbr4...@gmail.com LinkedIn Profile = http://www.linkedin.com/in/hbr4270 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
