Dynamics GP
Dynamics GP
Organizer:
- JOSE Organized by
-
-
Intermittently Slow Financial Series Posting
-
Intermittently Slow Financial Series Posting
We are having issues with our Financial Series Posting taking an excessive amount of time to process. There isn’t any consistency to when it will take an extended run time. This has been occurring for the past 3-4 weeks and doesn’t follow a pattern. One day things may post without issues and the next it’ll take an hour to run. Just this week, we’ve seen the posting of a few hours of manufacturing take an hour, and later in the same day, ten hours of manufacturing take 4 minutes to process. Today, we’ve seen things run smoothly, taking just a couple minutes until around 1pm, when the posting was hanging up. I’ve used Who Is Active to find the query running that is taking so long and pasted that below. This is consistently where it gets hung.
We are on the most recent release of GP2018 with Manufacturing. We do run a very high volume of Manufacturing Orders, so the financial batches do build up quickly. We are using a server with 128 GB RAM with ~90% reserved for SQL (the rest facilitates SSRS, EDI, and Windows). Our DB is 225 GB, with a 40 GB log file, both of which are backed up nightly; DYNAMICS is 60 GB with 40 GB log file on the same backup schedule. We have a weekly maintenance plan to Check DB Integrity, Reorganize and Rebuild Indexes and Update Statistics. None of our backup or maintenance plans are failing or returning errors. I used PSTL to update statistics last night. I aimed to update GL10000, but saw it was updating a whole lot more tables, so I may have misunderstood that utility. We do use a 3rd party scanning system – Collect for GP (it’s been through several “brands” – Accellos, Highjump, Koerber, Infios) which uses macros to process user input into GP.
Any ideas on how to resolve the slowness of this process?
insert into #records_to_insert
(
MANUFACTUREORDER_I ,
LNSEQNBR ,
MANUFACTUREORDERST_I,
JRNENTRY ,
CHANGEDATE_I
)
select distinct
a.SRCRFRNCNMBR,max(d.LNSEQNBR)+1,b.MANUFACTUREORDERST_I
, c.JRNENTRY , c.TRXDATE
from
IV30200 a
, WO010032 b
, deleted c
, MOP10213 d
where
a.SRCRFRNCNMBR = b.MANUFACTUREORDER_I
and a.TRXSORCE = c.BACHNUMB
and b.MANUFACTUREORDER_I=d.MANUFACTUREORDER_I
and (
substring(c.REFRENCE,1,3)<>'MO-'
or c.PSTGSTUS =99)
group by
a.SRCRFRNCNMBR,b.MANUFACTUREORDERST_I,c.JRNENTRY
, c.TRXDATE
order by
a.SRCRFRNCNMBR, c.JRNENTRY -
2 Replies
-
Logan,
I suggest you start logging the time, volume and speed every day. Then start looking for things to correlate the ‘slow processing times’ to. I would start by interrogating/logging other posting activities in GP. Accounts Receivable is a good place to start as it’s common for their volume of postings to impact other processing.
After you’ve interrogated and eliminated all GP processing, then start looking at any processing that is ‘GP related’. Anything that may be reading or writing to the GP database (i.e. reporting, mass imports, mass exports, etc.).
Then I’d look for anything putting an unusual load on the network or servers.
I hope this helps.
Chris
Log in to reply.
