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 <[email protected]> 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 = [email protected] > LinkedIn Profile = http://www.linkedin.com/in/hbr4270 > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers > Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
