Hi,
It would take a long time, but it does not really matter, as the old
system can run alongside.
The important thing is that the SYNC-operation is fast, that do the
incremental data updates later on when you put it into production.
It does not really have to do with the size of the whole system, but the
size of the delta.
Best Regards - Misi, RRR AB, http://rrr.se
> How long would RRR|Chive take to move a 700gb db?
>
> Thanks,
> Axton
>
> The opinions, statements, and/or suggested courses of action expressed
> in this E-mail do not necessarily reflect those of BMC Software, Inc.
> My voluntary participation in this forum is not intended to convey a
> role as a spokesperson, liaison or public relations representative for
> BMC Software, Inc.
>
> On Fri, Sep 18, 2009 at 10:48 AM, Misi Mladoniczky <[email protected]> wrote:
>> 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"
>>
>
> _______________________________________________________________________________
> 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.
>
>
mi
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
