Hi,
If we are talking about the AR Server (not the apps), I have created a
perl-script that automates patching rrrPatch.pl. There is a Windows
executable of this same script.
I tried this on both Windows, Unix and Linux for 7.0.1, 7.1.0, 7.5.0 and
7.6.04 systems.
It will just do a file-by-file replace, and before a file is exchanged, it
will create a backup. If something fails, you can reverse the patch in a
minute or two.
When upgrading systems, I usually do a new install, after which I siphon
the data using RRR|Chive.
This will let me minimize downtime to the final delta-transfer of data
(rrrChive), which usually takes less than an hour.
This also allows you to do ample testing before you decide to do the final
switch.
Another tool I use is RRR|ConfDiff, to make sure that I do not miss any of
the system settings in my current production system.
Except for RRR|Patch, you can download the tools from our web site. If you
are interested in the most current version of RRR|Patch, let me know, and
I will publish that as well, along with recent tutorials for applying
7.6.04 SP1.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Hey everyone,
>
> Been a lot of interesting discussions around disaster recovery and how to
> fail over. I have another interesting inquiry that I am looking to see if
> anyone has some ideas on.
>
> We have ARS 7.6.04, CMDB, and the full ITSM suite installed in a
> Unix/Oracle environment. We use the multi-tendency in order to support a
> large number of customers and their user base.
>
> How does one go about updating the system with new patches, be it a minor
> or major upgrade, without impacting users that are inputting and updating
> tickets?
>
> An upgrade can potentially take hours to complete depending on the amount
> of data and the patching involved. This would block user access,
> preventing them from being able to log incidents for other issues
> occurring in the environment and/or updating existing tickets.
>
> We were thinking that we could break the database mirror and leave the
> one side up for users to work with. On the other side, we would do our
> upgrade. Once the upgrade is complete, users would be moved to the new
> environment.
>
> At this point we have and upgraded system with original records. In the
> other side, we have the old system with newer/modified records. This delta
> of data would need to be moved over somehow.
>
> How does one go about doing an upgrade without impacting users for a long
> period of time? I’m sure that big companies like DELL don’t have outages
> on their environments when doing upgrades. The large volume of incidents
> and inquiries tickets that would occur during that time period would still
> need to be logged and acted upon.
>
> Looking to see how others have gone about resolving this.
>
> Thanks,
>
> Brent...
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
