\n

   1:<\/span> -- Lists the top statements by average input\/output usage for the current database  (Query 53) (Top IO Statements)<\/span><\/pre>\n
<\/p>\n
   2:<\/span> SELECT<\/span> TOP<\/span>(50) OBJECT_NAME(qt.objectid, dbid) AS<\/span> [SP Name],<\/pre>\n
<\/p>\n
   3:<\/span> (qs.total_logical_reads + qs.total_logical_writes) \/qs.execution_count AS<\/span> [Avg<\/span> IO], qs.execution_count AS<\/span> [Execution Count<\/span>],<\/pre>\n
<\/p>\n
   4:<\/span> SUBSTRING<\/span>(qt.[text][\/text],qs.statement_start_offset\/2, <\/pre>\n
<\/p>\n
   5:<\/span>     (CASE<\/span> <\/pre>\n
<\/p>\n
   6:<\/span>         WHEN<\/span> qs.statement_end_offset = -1 <\/pre>\n
<\/p>\n
   7:<\/span>      THEN<\/span> LEN(CONVERT<\/span>(nvarchar(max<\/span>), qt.[text][\/text])) * 2 <\/pre>\n
<\/p>\n
   8:<\/span>         ELSE<\/span> qs.statement_end_offset <\/pre>\n
<\/p>\n
   9:<\/span>      END<\/span> - qs.statement_start_offset)\/2) AS<\/span> [Query Text]    <\/pre>\n
<\/p>\n
  10:<\/span> FROM<\/span> sys.dm_exec_query_stats AS<\/span> qs WITH<\/span> (NOLOCK)<\/pre>\n
<\/p>\n
  11:<\/span> CROSS<\/span> APPLY sys.dm_exec_sql_text(qs.sql_handle) AS<\/span> qt<\/pre>\n
<\/p>\n
  12:<\/span> WHERE<\/span> qt.[dbid] = DB_ID()<\/pre>\n
<\/p>\n
  13:<\/span> ORDER<\/span> BY<\/span> [Avg<\/span> IO] DESC<\/span> OPTION<\/span> (RECOMPILE);<\/pre>\n
<\/p>\n
  14:<\/span>  <\/pre>\n
<\/p>\n
  15:<\/span> -- Helps you find the most expensive statements for<\/span> I\/O by<\/span> SP<\/pre>\n
<\/div>\n<\/div>\n
Figure 2: Query #53 Top IO Statements<\/strong><\/p>\n
This query shows you which query statements (which are often inside of stored procedures are causing the highest average I\/O activity in the current database. Again, if you are under internal memory pressure, or if you are seeing high I\/O latency for reads or for writes, the results of this query can point you in the right direction for further investigation.<\/p>\n
Perhaps you have a query that is doing a clustered index scan because it is missing a useful non-clustered index. Perhaps a query is pulling back more rows or columns of data than it really needs (although can be hard for you to confirm this as a DBA). Perhaps the table(s) that are involved in this query might have indexes that would be good candidates for SQL Server Data Compression. There are many, many possible issues and actions that you can investigate in this area!<\/p>\n","protected":false},"excerpt":{"rendered":"
For Day 23 of this series, we start out with Query #52, which is SP Logical Writes. This query retrieves information from the sys.procedures object catalog view and the sys.dm_exec_procedure_stats dynamic management view about the cached stored procedures that have the highest cumulative total logical writes in the current database. Query #52 is shown in […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[273],"tags":[272],"class_list":["post-1051","post","type-post","status-publish","format-standard","hentry","category-dmv-diagnostic-queries-detailed","tag-dmv-diagnostic-queries-detailed"],"yoast_head":"\n