Thanks Joe.
________________________________ From: Joe D'Souza <[email protected]> To: [email protected] Sent: Fri, March 5, 2010 10:49:34 PM Subject: Re: Refreshing the DB for ITSM 7.1.0 ** I meant it always helps (and not never helps) in my last significant paragraph in my previous mail...... Friday night.. that's my excuse.. Joe -----Original Message----- >From: Joe D'Souza > [mailto:[email protected]] >Sent: Saturday, March 06, 2010 1:43 > AM >To: ARS Discussion List >Subject: RE: Refreshing the DB > for ITSM 7.1.0 > > >Shyam, > >There is no > real formal list to such forms if you ask me. It really depends on what you > got installed. > >I wish every > application really did have that kind of a list *you would think that this > should have been a part of admin documentation* but welcome to the real > world. > The real world is that there are some obvious areas you should be looking > at, > in terms of form data such as AIE configuration SRM configuration, > etc. > >The rest is > like fire fighting. Fire fighters do not get a documented list of steps you > should be performing to complete their rescue operation. Its just enough to > expect problems for a while - you can only hope that the precautions you > have > taken based on your knowledge and that of what others had to share so far > have > minimized the occurrences of those problems.. A similar thread this month > listed some data forms.. That should be a good beginning point to reduce > these > problems by about 75 to 80%. Maybe 100.. > >But it never helps to screen definitions by taking def > files and looking for hard coded server references even while you nail > things > down on application /configuration data. In my experience XML exports are > ideal for this, as you can replace server references found with @ directly > without really having to account for the string length. In fact I rely > solely > on XML exports ever since I realized with one of the team I have worked with > in the past, that it is a really safe and ideal way of doing > so.. > >Hope this > helps > >Cheers > >Joe >-----Original Message----- >>From: Action Request System >> discussion list(ARSList) [mailto:[email protected]]on Behalf Of >> Shyam Attavar >>Sent: Friday, March 05, 2010 9:40 >> PM >>To: [email protected] >>Subject: Re: Refreshing the >> DB for ITSM 7.1.0 >> >>** >> >> >>Chris, >> >>I >> would still be interested to know the LONG list of places to update that >> you >> refer to in your response. >> >>Would it be possible to share that >> information? >> >>Thanks, >>-- >>Shyam >> >> >> >> >> >> ________________________________ From: strauss >> <[email protected]> >>To: >> [email protected] >>Sent: >> Fri, March 5, 2010 12:17:11 PM >>Subject: Re: Refreshing the DB for ITSM >> 7.1.0 >> >>>> ** >> >> >>Customizations >> to the app are best moved with Migrator. You can build a fresh test >> server, migrate the customizations to it from development or production, >> then apply a patch or run an upgrade to see how it affects those >> customizations. Then later you can apply the same patch (or upgrade, >> but good luck with that) to development or production and then migrate >> the >> customizations back over from test. >> >>Typically >> I refresh development from production by restoring the db from a backup >> of >> production. Then there is a LONG list of places you have to update the >> clone on development to remove server and mid-tier references to the >> production environment (and remove notifications that are waiting to go >> out). Next you can apply a patch, then re-migrate customizations from >> production. Once you document everything that you have to do to >> restore customizations after patching, you can patch production and >> migrate the customizations back from development. That is essentially >> how we got from ITSM 7.0.03.007 to 009. >> >>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 >> Shyam Attavar >>Sent: Friday, March 05, 2010 2:00 >> PM >>To: [email protected] >>Subject: Re: Refreshing the >> DB for ITSM 7.1.0 >> >>** >>Thanks for the suggestion >> Saby, >> >>But I am looking for a way to move customizations only and not >> the data. >> >>Thanks to Joe D'Souza for his suggestion and I will most >> likely be using that for our >> needs. >> >>Regards, >>-- >>Shyam >> >> ________________________________ >>From:Sabyson Fernandes >> <[email protected]> >>To: [email protected] >>Sent: >> Fri, March 5, 2010 6:08:39 AM >>Subject: Re: Refreshing the DB for >> ITSM 7.1.0 >> >>** >>Hi Shyam, >> >>Have you looked into rrrChive? Its a >> great utility for copying over data from one server to another. I use it >> currently for copying data from a production server to a archive server >> and >> will shortly be using it to copy production data to our UAT environment >> so >> that users can test enhancements/fixes with production data. >> >> >>Regards, >>Saby >> >> ________________________________ >>From:Shyam Attavar >> <[email protected]> >>To: >> [email protected] >>Sent: Thu, March 4, 2010 4:59:45 >> PM >>Subject: Refreshing the DB for ITSM 7.1.0 >> >>** >>Dear Listers, >> >>I >> have a need to refresh the production database back onto a test >> environment >> we are building. Since there have been quite a few customizations, we >> would >> like to get to a point where we can start leveraging the Test environment >> without having to individually migrate the customizations over. >> >>If >> refreshing the DB from production environment is considered risky due to >> the >> various notifications, escalations and approvals that might be pending, >> we >> can even refresh from our development server. >> >>Here's the >> environment: >>ITSM 7.1.0 (except SRM) >>ARS 7.1.0 Patch 6 running in a >> server group with four nodes on RHEL >>Oracle 10gR3 RAC running on >> RHEL >> >>Has anyone attempted something like this and has been >> comfortable with the refresh process. I have done this in the past on >> ITSM >> 6.x running on Oracle. I do realize exporting the ARADMIN schema from one >> instance and importing into another instance would get me started. >> However, >> I am more concerned with the data driven nature of ITSM 7.1.0 and there >> is >> more to the refresh process than meets the eye. >> >>I have never >> attempted this on ITSM 7.1.0 - hence my concern and posting to the >> list. >> >>Any words of advice, things "to do", things "not to do", things >> to "watch out for", or not do this at all. >> >>Any feedback is >> welcome. >> >>Thanks in >> advance, >>-- >>Shyam_Platinum Sponsor: [email protected] ARSlist: "Where the Answers >>Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
