Chris, how did the weekend's recovery go? Any more questions or lessons learned that you could share with us?
Rick On Fri, Jun 6, 2008 at 1:02 PM, Rick Cook <[EMAIL PROTECTED]> wrote: > Well, that's an unfortunate fact that I'm afraid I don't know any way > around. The bulk of the time is really going to be recovering and possibly > cleaning the data that's been gathered since your last backup. Once you get > that done, importing shouldn't take all that long, since I wouldn't think > that most of your foundation data has changed all that much in a few days, > and even a few thousand Incidents wouldn't take but an hour or two, tops. > So you're really looking at history tables, work logs, etc., and the > IM/PM/CR tables, and maybe a few others. > > As far as data import tools, whether BMC's or Effective's, they're both > intended to import NEW data, not data with a history. There are some fields > that I don't think exist in the templates that would be necessary to import > pre-existing records with history. And they don't deal with Incidents, > Problems, etc. - just foundation data. So I don't know that I would waste > my time down that rabbit hole. This is probably going to be a manual > effort. > > I hope there's a good pizza place near your office - I'm afraid you'll be > there a good part of the weekend. :-( > > Rick > > > On Fri, Jun 6, 2008 at 12:21 PM, Moore, Christopher Allen < > [EMAIL PROTECTED]> wrote: > >> ** >> >> Rick- thanks again for your advice! >> >> >> >> Our problem is that if we have to do this import by form, we're looking at >> an incredible amount of time. I estimate an average of 30 minutes per form, >> and with over 1500 forms on the server, and guessing at least 2/3 or them >> could have been touched in the last week….you see how long this could take. >> >> >> >> A tech for BMC suggested a tool which was available as a patch- 9003- the >> tool is ITSM Data Management. Its primary use is for doing server >> migrations and moving data, but it could help us- I'm still reading through >> the documentation on it. Unfortunately when trying to install it we got an >> error that we were at an incompatible patch level, so I'm waiting to talk to >> BMC again about it. >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [EMAIL PROTECTED] *On Behalf Of *Rick Cook >> *Sent:* Friday, June 06, 2008 1:57 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: backup and recovery >> >> >> >> ** The problem, Chris, is that it's all data. If it can be read by an AR >> System, you can export it and import it. You may be able to get it from >> your DBA, too, but unless you get it out in an ARS-readable format, you'll >> have to import it that way as well, and that's going to be a bit >> unpredictable, and probably unsupported. Have your DBA make a copy of the >> DB as it sits now. >> >> >> That will determine the last point in time where all of the tables, from >> Company to Incident, were in sync with one another. Then you'll have to >> export the data, either directly from the DB. Or perhaps you could get a >> temp AR Server license, hook that up to the new DB, and use that to extract >> the data into csv/arx or something. Then Import the data, starting with the >> bottom end forms first (just like the order of migration in ITSM 6), i.e. >> all of the base associated records first, and ending with the actual >> Incidents, Changes, etc. Use the Admin console as a guide to the order of >> the data restore. >> >> For $deity$'s sake, remember to import the existing GUIDs, or your data >> relationships will probably not be clean. I would also recommend starting >> with just a tiny slice of all of the form data as a practice run, because >> sure as shooting, there will be some glitch in the code that overwrites a >> GUID, or uses an Entry ID differently, or changes a Modified Date or >> something, and that will fire workflow you don't intend. >> >> Workflow. Make sure that you turn off workflow that will fire on Merge, >> unless you really want it to fire. I would turn off escalations, too, >> because you don't want them firing on an incomplete data set. >> >> I'm sure I'm leaving something out, but that should get you in the >> ballpark. >> >> Rick >> >> On Fri, Jun 6, 2008 at 11:31 AM, Moore, Christopher Allen < >> [EMAIL PROTECTED]> wrote: >> >> ** >> >> Hey Rick- thanks! >> >> >> >> So the BMC tech said she doesn't know a way to do this, but here's my >> question. We're recovering from our last known good configuration, Friday >> night. In the meantime however we've had thousands of records updated. Is >> there a way, for the entire DB (all forms) to extract just the data and not >> attributes/configuration to import into our recovered database so we don't >> have to go by form? >> >> >> >> Thanks! >> Chris >> >> >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [EMAIL PROTECTED] *On Behalf Of *Rick Cook >> *Sent:* Friday, June 06, 2008 10:12 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: backup and recovery >> >> >> >> ** The Interface_Create form might be necessary to have your consoles be >> populated correctly. I would check at least all of the table fields on each >> of the main forms, and ensure that all of the feeding forms are also >> updated. This will catch Assignment records, Work Entries, Templates, etc. >> >> Rick >> >> On Fri, Jun 6, 2008 at 8:00 AM, Moore, Christopher Allen < >> [EMAIL PROTECTED]> wrote: >> >> ** >> >> Related to my last post- we're going to have to recover from a backup >> created on Thursday night. The problem is that thousands of tickets have >> been created since which we'd like to save. >> >> >> >> Does anyone have any advice on how to get those tickets? I've done >> recoveries before, but never tried to capture data since the backup after >> recovering. >> >> >> >> We're planning to just export from incident, change, problem, all work >> info forms, user, people and import them- will that be enough? Any advice >> is welcome! >> >> >> >> Thanks, >> >> Chris >> >> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> html___ >> >> >> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> html___ >> >> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> html___ >> >> >> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> html___ >> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> html___ >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
