eG Monitoring
 

Measures reported by MsSqlQryStatTest

SQL Server maintains a cache, but not with canned results for queries. In an OLTP system, many tables are frequently updated; it is therefore highly unlikely that the same query yields the same result twice. Similarly, the likelihood of the same query reappering with exactly the same parameters is also very less. What SQL Server stores in its cache therefore, are recently accessed data pages, as well as query plans for recently submitted queries and invoked stored procedures. This makes it possible to retrieve the result of a query without accessing the disk for frequently accessed tables. Too few queries in the cache means more direct disk accesses! To minimize reads/writes to physical disks, more number of queries should execute in the cache.

Using this test, you can determine the number of queries that are currently executing in the cache and also figure out the impact of cache misses on the physical disks. These metrics reveal whether/not cache usage is at a desired level. In the process, the test also measures the resource usage of and the I/O activity generated by the cached queries and sheds light on time-consuming, resource-intensive and I/O-intensive queries that are executing in the cache.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Physical_reads Indicates the rate at which the queries directly executed on and read from the physical disk. Reads/Sec A high value could indicate that direct disk accesses are occurring too frequently. This in turn implies poor cache usage. You may consider resizing your cache to accommodate more number of queries, so that direct disk reads are reduced.
Avg_physical_reads Indicates the average number of reads performed by the queries that executed directly on the physical disk. Number A high value indicates that one/more queries are reading too frequently from the physical disk. This is an unhealthy practice and can be attributed poor cache usage.

Use the detailed diagnosis of this measure to know which queries are not executing in the cache and the number of times each of these queries read directly from the physical disk. This way, you can quickly identify that query which exerts the maximum pressure on the physical disk.

Logical_reads Indicates the rate of data reads performed by queries to the cache. Reads/Sec A high value is desired for this measure. A low value is indicative of ineffective cache usage, typically caused by improper cache size.
Avg_logical_reads Indicates the average number of data reads performed by queries to the cache. Number A high value is desired for this measure. A low value is indicative of ineffective cache usage, typically caused by improper cache size.

You can also use the detailed diagnosis of this measure to view the top-5 queries in terms of number of logical reads. This way, you can precisely identify the most I/O-intensive query to the cache.

Logical_writes Indicates the rate at which the cached queries performed writes. Writes/Sec A high value is desired for this measure. A low value is indicative of ineffective cache usage, typically caused by improper cache size.
Avg_logical_writes Indicates the average number of times data writes were performed by a query to the cache. Number A high value is desired for this measure. A low value is indicative of ineffective cache usage, typically caused by improper cache size.

You can also use the detailed diagnosis of this measure to view the top-5 queries in terms of number of logical writes. This way, you can precisely identify the most I/O-intensive query to the cache.
Cpu_time Indicates the percentage of time for which the cached queries hogged the CPU. Percent A high value is indicative of excessive CPU usage by the cached queries. Use the detailed diagnosis of this measure to know which query is CPU-intensive.
Max_elapsed_time Indicates the maximum time taken by the cached queries for execution. Secs If the value of this measure is very high, it could either indicate that the database is unable to process the queries quickly or that one/more queries to the database are taking too long to execute. Improper indexing and fragmented tables in the database are common causes for slowdowns at the database-level. Besides the above, queries that are improperly structured can also take time to execute. The longer a query executes on the database, higher would be the resource consumption of that query. It is therefore imperative that such resource-intensive queries are quickly isolated and fine-tuned, so as to prevent degradations in the performance of the database server. Using the detailed diagnosis of this measure, you can rapidly identify the resource-intensive queries to the database.
No_of_recent_exec_qry Indicates the number of queries that executed in the cache since the last measurement period. Number A consistent rise in the value of this measure is a sign of optimal cache usage and minimal direct disk accesses.