Make sure the reconciliation job is only merging changed CIs ... we saw this same problem with the OOTB ADDM job ... every night it was updating the unchanged CIs as well. We went from 11.5 hours to 6.0 minutes after unchecking the box.
Thanks! .: Mike T :. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of William Rentfrow Sent: Monday, June 23, 2014 3:05 PM To: [email protected] Subject: Re: Reconciliation speed This is a merge job which is running ADDM data into BMC Asset. We haven't customized the workflow in that area at all, so I assume there is some base product logic which is running. On the plus side, our DBA's think they have a plan to improve this dramatically - we're still investigating that route as well. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Monday, June 23, 2014 2:53 PM To: [email protected] Subject: Re: Reconciliation speed William, OK, this seems to be part of the issue you are having. Are you running reconciliation rules that are reconciling the relationship class BMC_Impact? If so, stop reconciling his class. It no longer exists as a regular class within the system. The BMC_Impact class is a deprecated class (hence the BMC_Impact_D name). It really doesn't exist. It is a self join on the BMC_Relationship class as we are dynamically recreating the class in question by re-interpreting the impact attributes in existing relationships to generate a logical BMC_Impact relationship so that anyone querying that class can still work without recoding right away. Now, if you are not trying to reconcile relationship class BMC_Impact, I am not sure why there would be a query involving it -- definitely something to pursue for your situation as it makes no sense to worry about a deprecated class within a reconciliation run. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of William Rentfrow Sent: Monday, June 23, 2014 12:17 PM To: [email protected] Subject: Re: Reconciliation speed ***Re-sending as plain text since someone told me the message came across funny: I've done some more digging and I found some "genius" SQL. For every update, this SQL is run prior to the update - it takes 2+ minutes. SELECT T525.C1,C179 FROM T525 WHERE (((T525.C490008000 = 'OI-C977B38EDF4A11E2883C005056B30743') OR (T525.C490009000 = 'OI-C977B38EDF4A11E2883C005056B30743')) AND (T525.C400079600 = 'BMC.CORE:BMC_BASERELATIONSHIP') AND ((T525.C400129100 IS NULL) OR (T525.C400129100 = 0))) ORDER BY 1 ASC The "OR"s in there is an issue obviously. T525 is BMC.CORE.BMC_Impact_D, which is of course an inner join form (WHY?! WHY?! WHY!?!?!) of BMC Base Relationship to itself. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Peter Romain Sent: Monday, June 23, 2014 1:09 PM To: [email protected] Subject: Re: Reconciliation speed ** 7000 an hour is only 2 a second so I’d suggest there’s something wrong somewhere – I guess you’ve turned logging on? I’d expect around 10 a second for a system that hasn’t been tuned but this is just for merging, not for the initial identification. Is this a one-off load after which only deltas will be loaded? If you’ve got a million CI’s to reconcile every night then you’ll struggle unless you get the sort of architecture that BMC used for performance testing. Is there any custom workflow that could be disabled? Can you disable any normalisation? If the CI’s are being identified then this could be what is causing the poor performance. If so, do the CI’s need to be identified or can you just create the reconid’s as the CI’s are initially created? From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Cook Sent: 23 June 2014 17:48 To: [email protected] Subject: Re: Reconciliation speed ** Drop the indexes on the destination forms? Rick On Jun 23, 2014 9:47 AM, "William Rentfrow" <[email protected]> wrote: ** Hi - We're trying to get our recon jobs faster. We have hundreds of thousands of CI's in certain classes and we will have over a million in some other classes. Right now we're getting about 7000 per hour - which means the tool are basically unusable because it takes waaaaaaaaaaaaaaaaaaay too long to go through a recon job. This is with dedicated servers and having gone through many (all?) of BMC's performance tuning papers we're still not able to get much faster than that. William Rentfrow [email protected] Office: 715-204-3061 Cell: 715-398-5056 _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3972/7728 - Release Date: 06/23/14 _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3972/7728 - Release Date: 06/23/14 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
