Hi Alnoor
Would love to collaborate and share!
My customer is also on Virtual Server 2019, 2 processors, 62 gb ram. Their Sage 2016 was on a physical server I believe and either Server 2012 or Server 2016 (they have shut it down).
Their IM_140mb_BinLocationHistory is segmented out to .002 along with their IM_140mb_HistoryArchive is also segmented out to .002.
I have ran the IM/Utilities/MB Purge Detail History, archiving 2020 and prior and purging 2019 and prior. It seemed to help for a couple of days.
They have also had data corruption in their Sales Journal Updates, with an Invoice duplicating every so often. Haven't heard anything about a PO receipt duplicating though.
I sent IT an email tonight asking him to increase processors to 4 if possible, and spin up a new virtual with Server 2016. I also inquired if he is using HyperV for virtualization.
Will let you know his answers.
Thanks
N
------------------------------
Nancy Hanson
Blytheco LLC
Eagan MN
------------------------------
Original Message:
Sent: 06-14-2021 13:54
From: Alnoor Cassim
Subject: PO Receipts with Serial Numbers takes over 2 hrs to update.
Nancy I'm helping someone with a very similar story. Maybe we can share notes with each other as things progress.
My customer has Scanco MB too and after upgrading from v2016 Adv to v2019 Adv, the S/O Daily Sales Journal takes 2+ hours to complete the Update which used to take 10 - 12 minutes. In a test of invoice batches, the ones with serial number tier dist lines, which are most of them, take excessively long, just like you reported. They also have years of history and some segmented files too where after .M4T files reaches 1.8 GB, it then goes to .001 and up to .003 in the case of the IM_140 Whse Bin Location History table. It's strange that it's slow here on this Update only and nowhere else in Sage. They don't report slowness in P/O ROG Update but it might be they aren't doing any Serial / Lot Tier Distribution at that point.
But on v2016 it all works fine which is running on a Windows Server 2016 VM (Hyper-V) whereas v2019 is running on Server 2019 VM (Hyper-V). It also works fine if you take the v2019 \mas90 folder and put it on a different system with a different o/s. Long story short both the well known and many lesser known causes of slow performance have been explored and exhausted.
We will probably now proceed with a disk speed test run from the Hyper-V host, to test both the v2016 and v2019 disks. Also looking into an issue where a certain older version of VEEAM backup software with Server 2019 causes slowdown. Probably they are long shots.
------------------------------
Alnoor Cassim
Email: alnoor@asifocus.com
Ph: 949-689-9887
Orange County, CA
------------------------------