Hi,
You might want to try out RRR|Chive, which can do delta-migrations in a
very fast and robust way.
In my experience creates of this type does not get much faster if you do
it in parallel to the same form. It will be the database that limits the
speed. And if you run parallel without private threads, multiple threads
are used anyway. So using private threads should not make a difference
except for other users accessing the system.
RRR|Chive can automatically disable indexes and recreate them when you are
done, but that would not be automatic for forms you update via workflow.
When you sync data via RRR|Chive you can trigger filters on
$CLIENT-TYPE$=666.
Sample sync script for all records and which drops indexes on HPD:Help Desk:
source_server = old
source_user = Demo
source_password =
source_form = HPD:HelpDeskOld
target_server = new
target_user = Demo
target_password =
target_form = HPD:Help Desk
target_dropindexes = YES
splitsearch = YES
maxerrorsperform = 100
transfertype = SYNCTOTARGET
skipfields = \
'SkipField1',\
'SkipField2',\
DISPLAYONLY
fieldmapping = \
'OldField1'=>'NewField1',\
'OldField2'=>'NewField2'
setfields = \
'NewField3'="hardvalue",\
'NewInteger'=111,\
'NewSeletion'=3
clientcharset = UTF-8
logfile = AUTO
progressbar = YES
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* 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 All,
>
>
>
> We are doing data migration activity through import tool for a customer.
> The target is to migrate 1.5 million records in next 1 week.
>
> We started off this activity a few weeks back and were able to complete
> 1/2
> or 0.5 million records until now. Go-live date is approaching and now we
> need to find a way to speed up the migration activity.
>
> * *
>
> *Background:*
>
> 1) 1.5 million 6.3 HPD and CHG records are required to be migrated.
>
> 2) Custom mappings created for import tool.
>
> 3) Custom filters written to populate some fields, create SR records,
> Worklogs, etc..
>
> * *
>
> *Activities done so far to speed up the migration:*
>
> 1) Archived HPD and SR records, so that HPD:Helpdesk table would become
> lighter.
>
> 2) No scope for further code optimization.
>
> 3) No scope for further reducing the network latency.
>
> 4) Parallel imports through multiple machines throw unwanted timeout
> errors. *Is this a recommended approach?*
>
> 5) Will disabling escaltions improve migration speed? We tried this on Dev
> server and found that there is no significant improvement.
>
> * *
>
> *We are trying the below steps:*
>
> *1. Increase the JRE run time
> parameters on the laptop\DeskTop in the registry. By default the
> parameters
> are
> low. To accomodate the larger data items of the BMC Import you will need
> to
> set
> the -Xms to a value of 512m and -Xmx to value of 2048m.(32 bit
> requirements
> of
> JRE run time will not allow it be set higher)
>
> 2. In the .bat and .ini files of the Import Tool you will need to match up
> the
> same parameters in each file.*
>
> *3. In the Chunking value of the tool you can increase as well so the
> Bulk*
> *Transaction is not used as much so the memory does not gather up too
> large. 500*
> *to a 1000 is a good setting for this.*
>
>
>
> Can anyone please suggest any more ways to improve the migration speed?
>
>
>
>
>
> Regards,
>
> *Veeral Oza*
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
