Hi,
The idea with RRR|Chive would be to first do a copy of the production while it
is still in use by your users. This might take days or even several weeks.
During this time, the impact of the production would be next to none.
When you are ready to do the final cutover, this will take no more than an
hour or two to do, while the last small changes are synchronized. This would
be your only downtime.
If you need to run production on your current database, you will also need
additional time to copy your "temp" database into the real database after the
final SYNCTOTARGET.
The Unicode translation will all be handled by the AR API, so that is not a
problem.
If you have a lot of multy-byte characters in your database, you may encounter
situations where data does not fit in a field when translated from 8-bit to
multibyte. But with the above aproach these things can be attended to in a
leasurly way, without additional downtime.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12):
* 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.
> Hi,
>
> we simply cannot afford copying the data from current installation to a new
> one because
>
> 1) we cannot stop our ARS based applications in production environment,
> which are used worldwide 24/24, for more than 24 hours, and since we have
> hundreds of custom tables with millions of data records we guess it would
> take days to do the job, even using tools like RRRChive or BMC DDM-Delta
> Data Migration.
>
> 2) we are not going to change the application and db servers, they have to
> stay the same that we currently use
>
> 3) finally, even if we used your suggested approach, we would be blocked
> already at step 1 just because of the UNICODE error
>
> any other ideas?
>
> thanks
> Antonello Monizza
>
>
> On Mon, Feb 11, 2013 at 8:51 PM, patchsk <[email protected]> wrote:
>
>> Why is option 2, not feasible? I think that is the most cleanest way.
>> There might be some hardwork for copying the data but you can use tools
>> like (RRRChive, BMC DDM-Delta Data Migration).
>> Yes there is some learning curve to understand those tools but once you
>> spend a day or two to test various scenarios the copying of data is pretty
>> much automated. Just execute a command and it does everything for you.
>>
>> I think what you could do is:
>> 1. First run the upgrade on ARS7.1(Just the ARS no Email,ARDBC etc..)
>> 2. Convert the objects to custom or overly as needed.
>> 3. Run the installer again to upgrade remaining components.
>> 4. Readjust overlays, custom objects as needed.
>> 5. Take a full export of all the def files.
>> 6. Now build a new ARS with OOTB objects with no sample data, just
>> plain vanilla remedy.
>> 7. Import your objects from Step5 into the new vanilla environment.
>> 8. Run the (RRRChive or BMC DDM) to copy the data from 7.1 to new version.
>> 9. Test all your integrations and applications.
>> 10. Fix all the bugs in the new environment.
>> 11. Rerun (RRRChive or BMC DDM) to copy the data from 7.1(PROD) to new
>> version env.
>> 12. Cut over the new environment as your production.
>> 13. Rebuild your dev,test environment from a copy of new production.
>>
>> We have actually upgraded from 7.1 to 8.x and things seems to be fine so
>> far.
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
