Yes, transactional data synced fine. Some of the configuration data for service targets does not travel well, since it is tied to the z-filters that are generated from that data. Editing SLM objects on production after pulling the db snapshot that you are upgrading from should be avoided (the BPCU / upgrade docs even state something like that).
I did a one-time update of these tables in June 2011 to update all of the new or changed records since the upgrade: SLM:Measurement (OVERLAID) RRR Sync SLM:EventSchedule RRR Sync SLM:MilestoneLogging RRR Sync SLM:SLACompliance RRR over SLM:SLAComplianceHistory RRR over SLM:RuleActionNotifier RRR Sync BMC.AM:BMC_InventoryStorage_ RRR over del 0 SLM:ServiceTarget RRR over del 0 SLM:Association RRR over del 0 SLM:SLADefinition RRR over del 0 SLM:Milestone RRR over del 0 SLM:RuleAction RRR over del 0 ...then ONLY updated these four (RRR Sync) in July and early August 2011 until cutover: SLM:Measurement SLM:EventSchedule SLM:MilestoneLogging SLM:RuleActionNotifier Those four are what I call SLM transactional data; they update/add records as incidents are created and service targets are attached to them, and subsequently updated. After you update the incident table, the SLM data should be synced to match. Just don’t allow duplicate escalation notifications to leave both servers during the time that they are run parallel. Don't ask me how BMC.AM:BMC_InventoryStorage_ got involved, but we identified is as SLM-related data – with only 1 record. SLM:Measurement ended up overlaid on the 7.6.04 server to accommodate 7.1 data: Form SLM:Measurement had a field enumeration in 7.1 that disappeared in 7.6 and blocked moving data from production. o 'Previous Status' (301412100) lost enumeration ID 2 "Pending" o This enumeration value set was restored to the SLM:Measurement form so that data could be refreshed from production using rrr|Chive. If you try to migrate your SLM data in its entirety, you will have to figure out how to migrate the z-filters as well. The SLM data records store pointers to the filters by an identifier, so it may take some tricks to get the objects to line up properly. By the time you get that figured out, you will probably have switched to single-malt scotch whiskey - straight! Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mary C. Sent: Monday, November 26, 2012 3:31 PM To: arslist@ARSLIST.ORG Subject: Re: AR System & ITSM Upgrades (we are WAY behind) Thank all of you for your input. Christopher, I had that glass of whiskey and finished off the whole fifth by the time I re-read your message a couple of times. I am pretty well convinced we should go with a new install - customize - migrate data approach. Christopher, you mentioned you were synching your old server data to new server data every night, including SLM transactional data. Was that 7.1 SLM data to 7.6 SLM data? I sort of assumed it would be impossible to migrate SLM transactional data. Thanks again, everybody! _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> attend wwrug12 www.wwrug12.com<http://www.wwrug12.com> ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
