Table update GP2010 - GP2013R2 (build 1745) - 2nd Problem

(0) Share

Report

Posted on by L Vail

65,271

This is the same company as the first problem, but it's being upgraded on the client's server, not my stand-alone machine.

This machine is a Virtual server. It's running SQL 2014 and Server 2012. The problem here is that the table update never completes. It hangs on various tables. It has hung on the SOP Amount History, PO Line and a couple of others. These were different attempts at the table update, once it's stuck, it's stuck.

The largest tables have the following number of records:

GL30000 - 2,123,883

SOP10105 - 1,418,267

RM30301 - 1,250,447

SOP10102 - 960,256

SOP30300 - 812,651

PM30600 - 780,416

The update running on the Virtual machine runs INCREDIBLY slow. I've never seen anything like it. Everything is slow. Including just bringing up any of the databases in Studio manager. It's because of this snail-like speed that I transferred a copy of the database to my personal machine.

That's all I've got. Any ideas?

Be sure to mark each of your responses as a 'suggested answer' whether it is or not. I want to be sure that I can see it :)

Kind regards,

Leslie

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (0)

Sort by

Suggested answer

Richard Wheeler 75,852 Moderator on at

Like (0)

Report
Copy link

Link copied!

Leslie, is this VM Ware or Hyper V? How are the drives configured? How big are the databases? How big do the transactions log file grow during the upgrade? Since this upgrade fails on different tables my thinking it is something in the SQL environment that is the problem. When you watch the progress monitor is it the processor that gets peg or memory or disk I/O or a combination of all three?

Was this reply helpful? Yes No
Suggested answer

L Vail 65,271 on at

Like (0)

Report
Copy link

Link copied!

Richard,

1. It's Hyper V

2. Drive is configured as a single partition.

3. Database in question is 16 gig

4. Transaction file is also 16 gig (I put it on SIMPLE recovery before the upgrade)

5. I have it running right now (slooooowwww), it's still progressing (kind of) the CPU is at 10%, memory is at 98%.

6. Here is the screens from the task manager:

\

That's how it looks right now. Thank you for taking a look.

I'm making my post a suggested answer to make you can see it :)

Kind regards,

Leslie

Was this reply helpful? Yes No

Suggested answer

Richard Wheeler 75,852 Moderator on at

Like (0)

Report
Copy link

Link copied!

Leslie, if the upgrade was not running, would other applications be equally slow? The fact that you see Dynamics GP not responding leads me to believe the issue resides within SQL. Does it slow down immediately or only after it hits certain tables? Are there any third party products involved or any customizations or sql triggers that may be causing this sluggishness? Have you tried running SQL Profiler while the upgrade is proceeding to see if it getting stuck in a loop? Is fixed assets part of this database? If you were to shrink the log file prior to starting the upgrade does it grow to 16GB again? I just remembered I had a situation like this and the cause was my client had a third party vendor insert records into the eConnect_Out table. Could that possibly be the answer? Once it removed these records the upgrade proceeded normally.

Was this reply helpful? Yes No
Suggested answer

L Vail 65,271 on at

Like (0)

Report
Copy link

Link copied!

Richard,

The only other applications are Office. I fired up Word and it seemed OK. Nobody else is accessing the virtual server, we are moving everything over to it. Let's see, new operating system, new 'machine', new version of SQL, new version of GP et al. Is there something we could have changed that we missed ? (grinning again).

3rd Party products. I have not loaded any 3rd parties as yet. They DO have an ecommerce solution with WebsitePipeline, but it's not interacting with this new machine. The eConnect service is installed, but disabled. There are no records in any of the three 'eConnect' tables.

In my heart I think it's an eConnect problem. Where else can I look for some process?

There are three Services installed:

1. eConnect for Microsoft Dynamics GP 2013 Integration Service - Disabled

2. eConnect Incoming Service for Microsoft Dynamics GP 2013 - not running - Manual

3. eConnect Outgoing Service for Microsoft Dynamics GP 2013 - not running - Manual

Fixed Assets is not part of the solution.

I'll have to pay more attention, but it hits the large tables and slows down (SOP Line, RM history, etc. they are listed above in an earlier post) It isn't always the same table. This time it's on Sales Transaction History. It has ran for 16 hours on this file before I killed it. This table contains about 500,000 records.

I'll shrink the log on my stand-alone installation, but that one has the cursor error. So, I haven't done anything to the log file as yet. It's running on Simple recovery since the upgrade started. All of the databases are, but I am only trying to upgrade the main company.

Any more ideas? Again, I'm marking this 'suggested' so others can see it.

Kind regards,

Leslie

Was this reply helpful? Yes No
Suggested answer

Richard Wheeler 75,852 Moderator on at

Like (0)

Report
Copy link

Link copied!

Leslie, the WebSitePipeline folks were the same ones that messed up my client's eConnect_Out_Setup table. They put records into that table by default whether they needed them or not. Try running this script. If you find any records, delete them.

SELECT * FROM eConnect_Out_Setup WHERE MAIN=1 AND DOCTYPE LIKE 'toWebSite%'

In our case when I tried to do the upgrade, it would run until the drive got full and then it would crash.

Was this reply helpful? Yes No
Jonathan Fear Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

It looks like SQL is probably using all the RAM. Did you try restarting the SQL instance and capping what SQL can use for RAM?

Was this reply helpful? Yes No