RKL eSolutionsBlogs

Using Extended Events to Performance Tune Sage 500 – Part 7

Using Extended Events to Performance Tune Sage 500 - Part 7

Analyze the data for queries that aggregate to large impact

In this final post I am looking for queries that don’t show in the query for longest duration by individual run, but still have an impact because they are run over and over again, either in a loop that occurs in SQL Server or it may be in a loop in the Sage 500 client, and called repeatedly.  This is looking for the “Row by Agonizing Row” (RBAR) impact.

In this case there is one query that catches the eye. This one didn’t show up in the individual queries but it was executed 504 times for a total of 2.6 seconds, or an average of 5ms per run. This frequency is probably not something I would worry too much about in a Sage 500. However, I have used this technique and found an individual query that was run 30,000 times in a process and taking around 500 ms per execution.  The full process was taking around 6 hours to complete. Changing this one query dropped the overall execution time to less than 15 minutes.

I hope that you have learned something about using Extended Events to performance tune in Sage 500. If you have questions or need assistance, please feel free to reach out to our team >> Contact RKL eSolutions


Full Troubleshooting Series

Parsing an Extended Event Attach_Activity_ID into Component Parts with the String_Split Function

Using Extended Events to Performance Tune Sage 500 - Overview

Identifying the Sage 500 Task Name as seen in SQL Server

CREATE AN EXTENDED EVENTS SESSION FOR RECORDING ALL THE ACTIVITY UNDER A TASK

Running the XE Session and Brief View of Events

EXTRACT THE XE DATA FROM THE EVENT FILE AND LOAD IT INTO A SQL TABLE

ADD HELPER COLUMNS TO THE XE TABLE

ANALYZE THE DATA FOR LONG-RUNNING SINGLE QUERIES

Tagged With: Sage 500
John Puttman

Written by John Puttman

Questions? Need Support?
Get in Touch