Profiler Trace: finding Stored Procedures that are slow(est) and resource-consuming

  • I am running a few traces capturing specifically these 2 events:

    RPC:Completed

    SP:StmtCompleted

    But what concerns me is that when I later analyze the trace data (querying table, aggregating, etc..), is that I may not be summarizing correct metrics. Because

    for example, for ONE RECORD for RPC:Completed event there may be 3 records for SP:StmtCompleted event, right? So for example DURATION value may be recorded four times in such case for same SP EXEC but in my analysis I will be summarizing all four? Which seems incorrect. Because for one EXEC <SPname> (RPC:Completed) the trace may contain many rows related to the same occurrence of EXEC this SP if there is a certain number of SQL Statements executed in it.

    Should I then NOT be using SP:StmtCompleted event, not to mess up my analysis/metrics of performance?

    what also concerns me is that there may be EXECs of SPs that are not reflected in RPC:Completed but ARE rather only in SP:StmtCompleted or BATCHCOMPLETED events (that I also trace..).

    Likes to play Chess

  • https://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1/

    Because for example, for ONE RECORD for RPC:Completed event there may be 3 records for SP:StmtCompleted event, right?

    Yes, so the question is, why are you tracing both if that problem exists?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply