4 Likes
320gb last I looked. Data goes back to 2008 which is why we need a purge.
Test conversion took about 32 hours going from 905.701 to 10.1.500.12.
Thatâs actual conversion time, not counting time between conversion steps.
Looking to put it on a faster box and go to 10.1.500.14+ to speed that part up also.
Regards,
Chris Wineinger
chris,
have you reached out to a partner or Epicor on that new conversion tool they talked about in the last mtg?
1 Like
That caused such a disturbance in the force and I was thrown back into this discussion.
My sincere apologies upfront, but, whoever led you to believe that it was OK to simply delete these records in SQL did you and your company a huge disservice.
Here is the pseudo logic of what the db purge and summarize does for PartTran records, emphasis is mine:
All PartTran records which have a TranDate <= Cutoff are deleted. For Inventory transactions a PartTran of TranType = ADJ-QTY will be created to represent the summarized ± quantity deleted for a company/PartNum/WareHouseCode/InvtyUOM/LotNum.
5 Likes
nice recap of the anarchists cook book nathanâŠ
2 Likes
i have reliable info that theyâve improved that conversion tool to be multi-threading for large table dumps, greatly improving migration performance.
I seem to have hit a nerve 
For the record I am only doing this with a DEV DB that we use before moving changes in Production. I just donât need 80GB of PartTran/TranGLC to do this and donât want to add storage to our SAN.
John
1 Like
Glad to hear it wasnât production, take your 80GB with you it is a lot better than botching your DB and then do a Purge Summarize in 10. Or run the Purge Summarize and then migrate but donât do it yourself in SQL 
1 Like
And as long as it wasnât production⊠however, to the statement made by someone somewhere on some other forum in a time long long ago where it was stated that all this database purge and summarize process does with PartTran records is to delete them - that is not accurate.
2 Likes
Not yet, thatâs on my todo
Regards,
Chris Wineinger
Iâm still waiting for Nathan to give us the SQL script that performs that summary, creates the QTY-ADJ, and deletes the PartTran records âŠ
Wow, I had no idea how entertaining a thread on the DB Purge and Summarize process could be until I jumped into this one! 
Mark_Wonsil - I was thinking about getting that same Tattoo only across my forehead! LMBO!
aidacra - I canât stop clicking the magic eightball to see if it says anything different! 
Not sure if this helps anyone but back in January, we performed a DB Purge and Summarize on all available Transactions/Options in our E9.05.702 Progress database. (We were also trying to clean up years of old, possibly bad/questionable data - due to some issues we had early on - and speed up our Migration to E10âŠ) Our company collectively made the decision to purge about 10 years worth of Transactions across the board. There was a LOT of testing of this process and its results ahead of time. Most of the testing was done in a VMWare TEST environment on our pretty beefy server but even with the PartTran fix it was taking an extremely long time to complete⊠Not sure that everyone has the money to put into something like a Falcon gaming machine but thatâs what we did and it was SOOO worth it! I wanted to cry when I saw how much faster the Purge Process was on this machine.
Just to give some idea (I collected the stats to help justify the purchase of the Falcon):
PartTran - 13954017 records - took over 2 days to complete on our VMServer versus 10.5 hours on the Falcon
Configuration Inputs - 8170073 records - 2 Hours on VMServer - 15 Minutes on Falcon
Change Log - 6294388 records - 3 Hours on VMServer - 24 Minutes on Falcon
For all other options the time was basically cut in halfâŠ
So for a 74GB Progress Database - Purging 10 years of Trans, for us, got us down to 30GB
(We did keep a copy of our Pre-Purged Database running on a VM in case anyone needed to access the âhistoricalâ data. Users have needed it at times but I hope we can eventually shut it down.)
Right after the Purge we performed a Dump and Load against the Database (the next weekend) which was obviously faster not only on the Falcon but also because we had less data to work with.
Our Progress to SQL Migration went from 53 hours to 14 hours on the Purged DB (and I havenât even tested it on the Falcon yet but Iâm getting ready to!).
So I guess all of this to say that the purge of that much data is do-able and can be a lot faster if you are on the âright versionâ, have the right fixes applied, and it REALLY helps to have the right hardware to run it onâŠand I would say, if you can, it is worth it to purchase a Purge/D&L/Migration/Conversion machine if you need to make things faster!
(Hope someone finds this data helpful! 
)
I feel like I need to add some sort of disclaimer on being very careful and running this in a test environment first and making sure that Purging is the right choice for you and your companyâŠyadda yadda yaddaâŠor something like that. 
2 Likes
What is this magical multi-threading conversion tool for migration that you speak of and how do I get my hands on it!?!?
Our CAMs can help facilitate getting into this program and provide the details of what is entailed. I think this program is truly amazing and every customer that hasnât formally started the move to E10.1 but looking to should absolutely look into it.
1 Like
said
EXCELLENT! This is the first Iâve heard about itâŠwhat do I ask for or do I just call it the âmagnificent magical mystical multi-threading migration toolâ? (Iâm sure that sounds WAY more exciting but itâs a mouthfulâŠlol) Thank you! 
No special phrase or secret handshake needed. Just ask for information regarding the new Epicor Upgrade Services to Epicor 10.1 and tell 'em Nathan your friendly neighborhood Epicor Support Engineer sent ya.
2 Likes
Aww, 
no secret handshake is definitely disappointing. 
But will do! Um, so do we get treated better or worse if we tell them you sent usâŠheh. Just kidding! 
Thanks!