Hi,
Let me know off list, and I will get you the newest RRR|Chive version that
is much faster in syncing two systems.
I would to it like this:
1. Do a new install of the new server 7.1/7.5
2. Import your custom groups
3. Import your custom forms using def-files
4. Analyze your core form customizations (probably some
permission-settings at least)
5. User RRR|DefHideExpandBox to get rid of the expand-box on field 2, 4 and 5
6. Use RRR|Chive to SYNC the data from your old production to the new
production server
7. Test and fix
8. Do a new RRR|Chive SYNC which will be much faster than the bulk transfer
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
> Paul,
> I would recommend a fresh install of everything in the destination. I
> recommend this because migration from version/platform will be extremely
> difficult. Particularly problematic will be your conversion from
> non-unicode to unicode....I do not believe this can be done easily...so I
> would recommend first setting up your 11G DB, then installing Remedy 7.5
> in
> their respective environments. Then doing a selective code migration from
> existing to new. Selective in that much has changed between 6.3 and
> 7.5...I
> would avoid migrating 'core' forms, instead re-customizing them manually.
> I
> recommend 7.5 instead of 7.1 because in less than a years time 7.1 will be
> R-2, which means it will be reaching it's end of support life, best to
> migrate to current 'R' and in a years time be slightly behind the curve
> instead of significantly. Regarding data, I would suggest you look into
> 'rrrChive'...a tool produced for free from RRR and has been used by many
> on
> the list including myself successfully in the past. This will allow you
> to
> move the data you care about into your newly setup server and forms with
> relative ease. Once you have the simple system setup, then install your
> second remedy server and get server groups configured and functional.
> Regarding 'hot backup' of your data, I have never personally worked with a
> hot backup db server and associated app server....the closest I worked on
> personally was an HP HA cluster with two nodes each capable of running
> both
> db and app, but connected to a raid5 san...so if any single piece of
> hardware were to fail it would switch to the other, or in the case of
> disk,
> simply wait for the replacement to be put in. I have been involved in
> countless disaster recovery discussions, but none have ever come to
> fruition
> for me, so I fear I can't speak authoritatively on that subject.
>
> _____
>
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Paul Blasquez
> Sent: Thursday, September 17, 2009 6:05 PM
> To: [email protected]
> Subject: Major 6.3 Migration Project
>
>
> **
> Hello,
>
> I have been tasked from moving our current production installation to a
> more
> robust/modern installation. Any and all help would be appreciated!
>
> Currently:
>
> -AR System 6.3 custom server (with modifications to forms User and AR
> System
> Email Messages)
> -Oracle 9iR2 non-unicode
> -Solaris 9
> -Application and Database reside on the same machine
>
> Goal:
>
> -AR System 7.1 or 7.5 (With form modifications intact)
> -Oracle 11g unicode
> -Linux Redhat 5
> -Application and Database on different machines
> -Disaster Recovery (DR) backup site (Using Oracle log-shipping)
> -Local High Availibility (HA) backup server (server groups?)
>
> I have at my disposal 4 Virtual Machines (VMs) to do development and
> testing, with an additional 2 VMs and 2 dedicated servers (for the DBs)
> reserved for the final production installation. (Please note that there
> will be Midtier servers involved in all of this, but their deployment is
> trivial so I'm not including them here.)
>
>>From my point of view I see that multiple operations must occur for this
> migration to be successful (in no particular order):
>
> 1) The Oracle 9iR2 DB
> -Must be upgraded to 11g
> -Must be translated into Unicode
> -Must be moved from the Solaris 9 machine to the Linux RH5 machine
>
> 2) The current 6.3 installation
> -Must be upgraded to 7.1 or 7.5
> -Must be configured for server groups
> -Must be moved from the Solaris 9 machine to the Linux RH5 machine
> -Must begin connecting to the DB remotely instead of locally
>
> 3) The finished AR System 7.x installation and Oracle 11g DB
> -Must begin log shipping (Data Guard) to the second DB
> -Must have a method for failing over to the second site
> -Must have a method for local server group failover (load
> balancer/quick
> TTL DNS)
>
> If you have completed any one of these tasks before, *please* share with
> me
> your experience and what you would recommend for my situation! I would
> save me hours of researching dead-ends!
>
>
> Finally, I would like input on what would be the correct order to complete
> all of these tasks, so that the cutover would be as smooth as possible
> with
> the least downtime possible. So far, I have tested the following scenario
> in Dev/Test:
>
> Fresh installation of 7.1/7.5
> -DEF import of workflow
> -ARX import of data
>
> This method seems stable but tedious, as there are many import errors I
> would need to repair. This would be the method I would fall back on if
> there were no more clever/sophisticated way to upgrade.
>
>
> Again, ANY input at all would be GREAT, as of course this project is on a
> tight timeline. THANK YOU to anyone who responds!
>
> ____________
> Paul Blasquez
> Senior Network Engineer/Remedy Developer
>
>
> _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"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
