Find Offending SQL Bottlenecks!

TnT Admin — Tue, 12 Jan 2010 07:54:30 +0000

After the tune-able parameters are changed for optimal performance, your system still fails miserably with a poor response time. The most likely step you should take is to do a deep diagnostics on the system. Break the system up into different components such as application server where diagnostics using probes is required, database servers where SQL statements and stored procedures become the next to be scrutinized, etc…

In this post, we will not be covering on the diagnostics of the application server, but we will cover the basic signs of database bottlenecks at the SQL statement level. The 1^st symptom is a collective symptom that the application server (and all other servers) with the exception of the database server in the architecture are performing reasonably well. E.g. memory available is well maintained without any exception decrease of this value, the processor % time is always low for the servers.

The 2^nd symptom is a constant high utilization of the processor % time and low memory usage (page faults, page reads and available memory) in the database server. This provides a tell-tale sign that the database server is processing some instructions, likely to be SQL statement that is taking too long. It would not be the database buffer or SQL buffer that utilizes the memory as the consumption is low meaning reuse of the buffer is high.

Now with these two symptoms, you are ready to go down deeper. Access MS SQL and run the following query:

SELECT scheduler_id, current_tasks_count, runnable_tasks_count
FROM sys.dm_os_schedulers WHERE scheduler_id < 255

This query will sys.dm_os_schedulers will give you information of how many runnable tasks that exists. Values other than zero indicate that tasks are waiting to run, and high values are an indication that the CPU is bottlenecking your performance. Another query that directly targets at SQL statement is the following:

SELECT TOP 50 SUM(qs.total_worker_time) AS total_cpu_time,
(SELECT [TEXT] FROM sys.dm_exec_sql_text(plan_handle)),
SUM(qs.execution_count) AS total_execution_count,
COUNT(*) AS number_of_statements, qs.plan_handle
FROM sys.dm_exec_query_stats qs
GROUP BY qs.plan_handle
ORDER BY SUM(qs.total_worker_time) DESC

This query shows which batches or procedures are consuming the most CPU and will also include the actual SQL statement. The query aggregates by a specific plan handle. If the plan handle contains more than one SQL statement you must drill into each statement to determine where the greatest CPU contribution comes from.

Codes illustrated in this post are taken from DotNet Bob on SQL.

LoadRunner TnT » Stored Procedures

Find Offending SQL Bottlenecks!