October 29, 2013 at 3:14 am
Hello
I'm a bit of newbie when it comes to analysing a slow query, using a trace. Effectively, a user has reported that when saving a invoice from within a application, it takes far too long to do so. We've ensured that when they are saving the form, no one else is connected to the DB (UAT Environment) but we still experience the problem.
We've ran a trace to see if a bottleneck can be highlighted, having reviewed the results I cannot see anything hanging (taking the start and end time of each query into consideration).
I have though noticed that the application uses sp_prepexec to query the database, does anyone know of any issues relating to this?
Should I be looking at other things from within the trace?
Thanks.
October 29, 2013 at 3:42 am
If you are not getting anything in profiler for blocking during the invoice update process, then you might want to check execution plan of the underlying procedure doing the update process and pin point where exactly it is getting stuck. That may give some lead.
October 29, 2013 at 8:18 am
What would be the best way to view the execution plan, seeing how the queries are executed from the application? Would I need to replicate the process and perhaps view the Activity Monitor from the Instance?
October 29, 2013 at 4:47 pm
First, is the application executing a stored procedure or an Ad Hoc SQL Query? If it's Ad Hoc SQL you will want to put the query into a stored procedure. This will enable SQL Server to re-use query plans instead of creating a new one each time the query is ran.
wak_no1 (10/29/2013)
What would be the best way to view the execution plan, seeing how the queries are executed from the application?
To look at the execution plan you could: find out what query/stored procedure and parameters are being used when an end-user saves an invoice via the application and run it in SQL Server Management Studio (SSMS) using the same parameters. In SSMS, when you right-click the query window there is an option to "display estimated execution plan"; check that box and run your query.
Performance tuning a query is a huge topic. Some of the basic tips include: making sure that indexes are setup correctly, using the correct data type, setting your columns to NOT NULL except where NULLs are required, letting the application handle sorting (e.g. adding SORT BY can really slow queries down).
Troubleshooting SQL Server: A Guide for the Accidental DBA is an excellent book for identifying and correcting performance issues.
-- Itzik Ben-Gan 2001
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply