Good thing ur not using srm the only way we have found to move stuff is db level. Migrator and def files do not work. Pain pain pain

Sent from my iPhone

On Mar 6, 2010, at 1:49 AM, Joe D'Souza <jdso...@shyle.net> wrote:

**
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:jdso...@shyle.net]
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:arsl...@arslist.org]on Behalf Of Shyam Attavar
Sent: Friday, March 05, 2010 9:40 PM
To: arslist@ARSLIST.ORG
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 <stra...@unt.edu>
To: arslist@ARSLIST.ORG
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:arsl...@arslist.org] On Behalf Of Shyam Attavar
Sent: Friday, March 05, 2010 2:00 PM
To: arslist@ARSLIST.ORG
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 <sebyr...@yahoo.com>
To: arslist@ARSLIST.ORG
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 <atta...@sbcglobal.net>
To: arslist@ARSLIST.ORG
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: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Reply via email to