Targeting SQL Profiler to determine performance problems

If you are a database administrator, you probably wish you could keep track of the badly performing commands within SQL Server instances in order to analyze them, or even send them to the development teams on a regular basis.

Do these laments sound familiar?

  • "Our SQL Server environment reaches 100% CPU for more than 10 minutes every day and we have to restart the instance."
  • "Our users complain that the applications' performance degrades every day at lunch time."
  • "The new version of the application was deployed in production and suddenly we have performance problems."

    • This article explains how to use SQL Profiler and SQL Traces to determine application inefficiencies and how to assist development teams that capture them.

    What should I trace?
    If you have a lot of activity in your SQL Server instance, you should trace only T-SQL commands that use comparably more resources (CPU, IO, Duration). This way, you will end up with a list of just the badly performing commands. Your choice of filter threads will depend on your specific environments.

    My advice is to run Profiler with initial threads of:

  • CPU > 500
  • Duration > 500 (half a second)
  • Reads > 10,000
  • Writes > 5000

    Test how many commands you are getting with these filters and change the threads accordingly until you get at least one event traced in five minutes. Also, if you get too many rows, it will be difficult to analyze the output.

    It might

      • Requires Free Membership to View

      Login

    Join the conversationComment

    Share
    Comments

      Results

      Contribute to the conversation

      All fields are required. Comments will appear at the bottom of the article.
      Back to top