I guess to me I’m asking which specific flags would make the most sense.
I’ll dig up the sysadmin tech ref guide and see if they address what each of these flags are doing.
See which one gives you enough info to figure out the origins… For example if you enable:
trace://ice/fw/servicecaller
trace://ice/fw/restapi
profile://ice/fw/tableset
You might find out its a REST Call causing it. 
Try a few.
1 Like
Alright, trying in my dev environment.
You say the same query is happening over and over. Does it always reference the same OrderNum?
If so, I’d look into what’s possibly touching/reading that order. I see the tables: JobProd, PartPlant, FSRenewal referenced. Look at things that could need that info.
I know its not as good a method as actually using profiling and tracing, as those could be applied to any other future investigation, but it might get to your problem quicker.
Nah, different orders all for the same customer though… 
recalculating credit limit/usage?
Hmmmmmmmm. Doesn’t explain the weird query, but maybe!
How about turning on change logs for the Customer table, along with some suspect fields, and include one of the “changed on” dates? That should user stamp it, and let you dig more if it’s a PICNIC source.
We don’t have any change logs enabled, but I see where you are going, I guess I could do that.
Haso, I turned on the query flag and saw that it was starting to write queries underneath the business object calls in the server trace. That is good.
The next time this happens and I see the same query over and over in the SQL profiler, I will look for the same query in the app server log.
I recently had something similar and someone pointed me to an undocumented SQL stored procedure called sp_who2 (I think). This allowed me to find that an http call from a client called “website” was the culprit, and an email to all users, "hey, anyone have a computer called “website” that I don’t know about? " came up positive.
I’ll look it up Steve, it is coming from our app server though based on the profiler.
Yes sorry, I skipped over a bit 
But could anyone have built something that called those APIs and then automated it? Could Sessions in the admin console show who’s connected?
Maybe!
This feels like a long running report or process, but I can’t think of which one it would be… Have you cross checked all this against the System Monitor?
Reason I say this is because when I was troubleshooting Stock Status performance issues a while back, I also saw similar looking “ERP services” show up in Live memory inspection… Sometimes with those big reports there are processes that run before anything ever hits SSRS (so SSRS logs can be misleading), but you see them show up in Live memory inspection + SQL profiler, and ultimately in CPU spikes on the server (memory spikes too but most people give SQL a max memory cap so the server itself doesn’t blow up when SQL blows up)…
FYI, Sp_whoisactive is another great SQL monitoring tool. I don’t think it gets you anything you can’t get from Profiler but it’s super quick and easy to use.
1 Like
Tom, I appreciate it. But you would think that when you launch the stock status report there are some kind of actions that indicate it is starting, whether it is a svc call or something.
I mean doesn’t it hit the system monitor immediately?
I don’t think I’ve seen a report run that doesn’t hit the system monitor as an active task.
sp_whoisactive is generally going to return just the app server user that is set up to run the app pool, isn’t that right?
Right, it does always hit the System Monitor. In my case it would stay stuck in ACTIVE status for maybe an hour. If you’re not seeing anything running in the System Monitor with your issue then I am on the wrong track.
yes, I believe so.
I don’t see anything in system monitor when my CPU is spiking, that is the mystery.
Some of those “methods” you see in the Live memory inspection feel unique enough where a good Support person might be able to help track it down… “FindFirstCustCnt2”, “getAvailBTList”, “FindFirstPartWhse”
That’s what I was hoping…