Migrating the NTE:Notifier Log was not entirely successful. It would appear that in ITSM 7.0 it had an unlimited length field, Email Message Body (1000000827) that was 0 length, that in 7.6 is limited to a length of 3,964. Therefore, rrrchive failed to bring over 654 of my 577,462 records. I don't see any practical way to get the records moved that were skipped either, at least not with rrrchive, and an export / import is problematic when the 654 skipped records are randomly distributed between entry=NTL000000027822 and entry=NTL000000578616. Yes, rrrchive logged all of the failures in a 5,237 line long log file, but no, I don't want to have to query and report on each one of them.
That is probably the least of my worries, since I now know that I have notifications that include "Resolution" - a 0 length field - and will be trying to push that unlimited length field into an Email Message Body field which is now restricted to 3,964. Unless the BMC programmers inserted code to truncate input into that field, I suspect that all we will get is a failure to create the notification record - the transaction will be rolled back and fail. Has anyone else had to deal with this yet??? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of strauss Sent: Thursday, March 18, 2010 2:22 PM To: [email protected] Subject: Re: Taking out the garbage in ITSM 7.0 ** Okay, then I DO need to migrate the 577,462 records in the NTE:Notifier Log over if I want the Incident (etc.) Audit Log forms to work properly. I had already brought over 193,441 records from HPD:HelpDesk_AuditLogSystem, so that part of the Incident Audit Log is populated. I have rrrchive chewing on it now. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pargeter, Christie :CO IS Sent: Thursday, March 18, 2010 1:52 PM To: [email protected] Subject: Re: Taking out the garbage in ITSM 7.0 ** I know there is an escalation on NTE:Notifier that will delete records 21 days after creation. When you go to Incident/Change/...'s Audit Log and click on the Notification tab that table is displaying records from NTE:Notifier Log. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of strauss Sent: Thursday, March 18, 2010 11:10 AM To: [email protected] Subject: Taking out the garbage in ITSM 7.0 ** While migrating data at the table level from an ARS 7.1 - ITSM 7.0 system (cloned from current production) to an ARS 7.5 - ITSM 7.6 system I have noticed a fair amount of malingering data in the NTE subsystem, with transaction dates between 10/28/2008 and 2/25/2010 (when I took the snapshot of the production database). NTE:SYS-Individual NT Control - 106 records NTE:SYS-NT Process Control - 107 records SYS:Action - 106 records NTE:Notifier - 1,218 records (down from 12,666 at the time it was cloned on 2/25/2010; production has 22,937 today) The records from the first three tables appear to be related. All of the records in SYS:Action that correspond to records in the two NTE:SYS tables are flagged as Action either CHECKCMDBASSOC or INCREMENT_NUM_TIX. Has anyone figured out how these records are _supposed_ to be purged, and any reason(s) why they might not have been? How about the most appropriate way to delete them from the system? I'm pretty sure they are transactional chaff that I don't want to migrate to my 7.6 application. I wondered if they were artifacts of the many aremail service crashes we have been experiencing during the entire time (22 months) that we have had 7.1 in production, but the dates/times of the residual records do not match up with the dates/times of the areamail crash logs at all. The vast majority of the failed transactions are either "HPD-INC-CustomerReceiptConfirmation" or "HPD-INC-CustomerResolutionNT" events, with a few "HPD-INC-AssigneeAssignment" thrown in for variety. I don't plan to migrate any of the this data, especially since some of the tables were deprecated in 7.6 (NTE:SYS-Individual NT Control and NTE:SYS-Group NT Control were eliminated), but I would like to know why it was left behind. The records in NTE:Notifier may not be a problem at all. The dates on the 1,218 records in NTE:Notifier are all between the db clone date (2/25/2010) and 3/2/2010 (and there are 416 outgoing emails created between the same dates sitting in AR System Email Messages - service is disabled on clone - these are all SLM escalations) so maybe this is just normal traffic that is getting purged at regular intervals. Again, it isn't something that I would need to migrate to the 7.6. server. BTW, there are 577,462 records in the NTE:Notifier Log; I'm not sure that there is any value in migrating those, either. Anyone else had to explore the NTE subsystem for remnants, and take out the garbage? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
