Hi,
In most cases I actually do not do it in in batches. But using the
maxerrorsperform=100 or similar is good practice.
Because of the Delta Data Migration capabilities, data that succeeded will not
be copied the next time you run it.
Some qualifications will actually disable the Delta Data Migration
capabilities of RRR|Chive. The same query will be cone on both servers, and if
you use something like 'Last Modified By' > "2014-01-01", you might get into
trouble. So the main strategy should be to move all data.
splitsearch = 1
qual =
transfertype = SYNCTOTARGET
maxerrorsperform = 100
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* 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.
> Yes, rrrChive will do this just fine.
> I suggest you move the data in batches rather than all at once.
> rrrChive allows qualifications, so you can select the oldest first, in groups
> of less than 100k records each.
> Starting with the oldest records will reveal problems early in the process;
> for example, trying to bring in records with out of bounds values that WERE
> valid before changes.
> rrrChive also lets you set a maximum # of errors that will stop the process.
> By setting this to 10, you don't have the same error for 100k records and
> nothing copied.
>
> It's a very powerful utility, so RTFM, as the documentation is clear and
> comprehensive.
>
> During the week leading up to the final cut-over, run rrChive every night; the
> last update is only one day's activity, which will go very quickly.
>
> Joel
> Joel Sender [email protected] 310.829.5552
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Grooms, Frederick W
> Sent: Saturday, November 15, 2014 8:57 AM
> To: [email protected]
> Subject: Re: Ticket Data Migration from 7.5 to 8.1
>
> I know others are going to say the same Go get RRR|Chive from
> http://www.rrr.se
>
> Fred
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Kiran Patil
> Sent: Saturday, November 15, 2014 1:11 AM
> To: [email protected]
> Subject: Ticket Data Migration from 7.5 to 8.1
>
> **
> Hi All,
>
> We are doing upgrading customer Remedy 7.5 to 8.1 Here is background - 1.
> Customer has 750GB-800GB transnational data of Incident, Change, Problem.
> 2. We are not doing in-place or staged In-Place upgrade. We will implementing
> new 8.1 system and migrating data from Remedy 7.5 to Remedy 8.1.
> 3. Core Req:
> 1 - Customer wants all historical data to be migrated into
> Remedy 8.1 along with work logs (with
> attachments), Related other tickets, task, SLA, Approvals
> (For change), audit log.
> 2 - Customer wants to retain old ticket number in system and
> dont want new ticket Id to be generated
> during migration process.
>
> Our Solution:
> 1. Using UDM we can import transaction data and disable new Id creation and
> can retain old ticket number however we cannot control on C1 to retain
> from old system.
> UDM approach has 64000 records limitation per batch so migrating 750GB
> will take months or may be years to migrate data.
>
> Is anyone has migrated ticket data using this approach, I would like to hear
> issues/challenges occurs during activity. As per BMC somehow they dont
> recommend it.
>
> Any suggestion or idea will be welcomed.
>
> Thanks
> Kiran Patil
>
> --
> ?
> Regards
>
> Kiran Patil
> Mobile: +91 9890377125
>
>
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers
> Are, and have been for 20 years"
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
> _______________________________________________________________________________
> 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"
