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 INCxx (then a gap of 8) then
INCx (then a gap of 40) then INCx (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
