E10 Upgrade Taking EXTREMELY Long Time

Hi All,

We are in the process of testing 10.2 upgrade for a potential Go Live later this year. Currently we are 10.0.700.4 and doing a monthly upgrade in our sandbox. One of the issues we are running into is the amount of time it is taking to Upgrade the Database from Epicor Administration Console. This last upgrade took almost 40 hours to complete. The process of “UpgradeDB ERP10.1.300.0” took about 28 hours (specifically UpdateBitFlag.sql process). Our database is around 170GB in size, but it doesn’t seem like this process should take THIS long (especially after talking to other). Is anyone else experiencing related issues or have any recommendations for us? I have also heard that some people are using a beefed up PC to do the upgrade instead of a server. If anyone has any insight to that, I would appreciate it. We attempted that but Epicor Admin Console failed to installed since we are running Windows 7 or 10 instead of having Windows Server. I appreciate any help!

Thanks,
Matt

Wow, what kind of hardware? We are doing > 1 TB in less time.
There must be something with your system we have not seen in your data.
Have you run the ERP Analyzer?

1 Like

Yes, we ran the ERP Analyzer. Nothing major jumped out from there. The hardware we have our Sandbox on (not the same hardware we will go live on) is a VM running Windows Server 2012 R2 with 4 vCPU Intel Xeon E5-2630 v2 @ 2.60Ghz 48GB RAM. SQL Server 2014 (v12.0.5571.0). During the upgrade process the CPU is 50% and Memory at 60%.

Here is the process that is taking the longest amount of time:
Upgrade Process ERP10.1.300.0 - Upgrade Process ERP10.1.300.0~: UpdateBitFlag.sql script takes 95217.9384 seconds to execute: DECLARE @SysRowID uniqueidentifier,

I wonder how many records it is trying to process.
Sounds like something got missed. Maybe an index? Ping support with that please. I’ll be curious our findings.

I do know there are over a million records last time we looked. I get an updated number… I also have our DB submitted to support and they are investigating. I’ll keep you posted.

1 Like

Hi,

I have found the upgrade scripts are actually creating index’s on large tables in my system like part tran and then trying to modify the tables.
I had 2 failed upgrade attempts before i finally worked out what was going on.
I dropped all the index’s manually on the problem tables and that fixed the issue and the upgrade actually went quickly.

Please make sure that kind of data gets into support. I don’t want the next person to suffer either

Yeah I will raise a ticket now - I forgot about it as soon as i had a successful upgrade.

1 Like

Hi Bart,
It looks like there is 12,171,347 records that it is trying to process.

Hi PatL,
That is good information to have. Could you explain how you dropped all the index’s manually? I’m not familiar with that process but would like to give it a try.
Thanks,
Matt

I also took a look at the .txt log file for the DB Migration and found this as the only error (Erp.ECORev only has 116,330 records).
Error Upgrade Process MigratePatchFldECORev.sql String or binary data would be truncated.
The statement has been terminated.
update Erp.ECORev
set ProcessMode = B.DataCharact
Execute Phase Complete: 96874.3999323 seconds

Truncated error message means the old db column is larger than the new. That’s very odd. I’m not familiar with that biz logic so have no value add to comment on about it.

Something doesn’t smell right. I’ll be curious what support uncovers.

Here was the response from Epicor support. I will test this today and relay my results.

Matt,

I have determined there is a option here to get past the BitFlag script. We have sent this to a few other customers and were successful. I have also done this here with your database and the migration completed without further issue.

  1. Locate the UpdatebitFlag.sql script here:
    C:\Program Files (x86)\Common Files\Epicor Software\Database Manager Extensions\3.2.200\DB Migration\DB Scripts\Erp Scripts\Upgrade\ERP10.1.300.0

  2. Place a copy this file to the desktop.

  3. Open the original file and delete all the text in it. (DO NOT delete the file itself) Save it as an empty file.

  4. Run the migration again.

You can run the original UpdateBitFlag.sql at a later time. The only thing that this would impact is that some of the indicators for Memos ChangeLogs, File attachments, etc, may not be correct for some records until this script is run to completion. We have already submitted a request with development to find out if this script can be optimized any further.

As an update:
The skipping of the UpdatebitFlag.sql did dramatically decrease the amount of time it took to do the Upgrade. However, it did still give the Erp.ECORev error.

So sounds like two issues need to be raised.

First the ECORev issue sounds like something happened is sizing. Get that raised.

Second, the perf issue around BitFlag. That domain I know very well. Some combination of indexing on your data must be having issue and I’d love to see that reported.

Thank you for the troubleshooting!