I’ve run the UOM conversion program in the past in Vantage 8.03.410 and it completed within a couple of hours against an SQL DB that was about 70 GB in size, however at my current employer the SQL DB is around 270 GB in size and the UOM conversion has so far has not completed successfully (in that after around 3 days I’ve just stopped it).
For example it starts off very rapidly, scanning thousands of rows a second, and after around 24 hours it slows to a crawl only scanning around 100 rows a second.
Am I just a victim of a very large SQL DB, and the conversion program can’t handle the volume of data, or is there any way of improving the performance of this conversion program?
(For refrence I’m running this in Windows Server 2008 R2, two seperate virtual machines for the application and SQL 2005 server, both with plenty of memory (they’re never starved of this), in VMware ESXi 5.5 with the datastore for both VM’s being a RAID 10 array using SSD’s and 20 cores in each VM (2x 10 core Xeon’s).
I wager your DB is too big… I’m assuming you are doing proper maintenance on it? Up to Date Stats, Indexes etc? Progress tends to choke on long running jobs. We had the same issue when Cirus first came out and @Edge had to work some magic to work around it for extremely large tables.
Thanks everyone, maintenance always done, the pain of Progress eh
I’m just going to have to leave it running for ages and get a successful pass, then work from this and do another nearer the time the live upgrade occurs.
The Cirrus Cloud Upgrade Services has some additional optimisations for Large table processing on progress - if possible please speak to your CAM about using the service even if you do everything else yourself it really is faster, repeatable and simple.
Sounds like these “additional optimisations for Large table processing on progress” would be welcome in a new Vantage 8.03.410a, however that wouldn’t generate any revenue for Epicor for what would be a one time customer event
This is only when we are extracting data from the progress DB to SQL as part of the migration/Upgrade - we run multiple threads if the table is over 1M rows and partition it. So it’s not a general type of optimisation. When we are converting on the Cloud Upgrade Services we know how many cores we have and SSD volumes so the process can be fine tuned.
