SQL Server Perfmon Counters of Interest

OS Memory & Paging Performance Countersi

Object
Memory Memory

Written by Kevin Kline (MVP) with Brent Ozar (MCM, MVP) and contributions by Christian Bolton (MCM, MVP), Bob Ward (Microsoft), Rod Colledge (MVP), and Raoul Illyaos.

OS Disk & Miscellaneous Countersii

Object
Physical Diskiii

MSSQL Buffer Manager & Memory Performance Counters

Object
SQL Server: Buffer Manager

MSSQL Workload Performance Counters

Object
SQLServer: SQL Statistics

MSSQL Users & Locks Performance Counters

Object
SQLServer: General Statistics

Counter
Available Mbytes Pages Input/Sec

You Want
> 100MB < 10

Description
Unused physical memory (not page file). Reads from hard disk per second to resolve hard pages. Often referenced in older documentation. Useful only in combination with Pages Input/Sec, %Usage, %Usage Peak. Amount of Page File in use, which indicates the server is substituting disk space for memory. Highest %Usage metric since the last time the server was restarted.

Counter
Avg. Disk Sec/Read

You Want
< 8ms

Description
A key measure of disk latency representing the average time, in milliseconds, of each read to disk where > 20 is poor, <20 is good/fair, <12 is better, <8 is best A key measure of disk latency representing the average time, in milliseconds, of each write to disk, where non-cached writes ( > 20 poor, <20 fair, <12 better, <8 best) differ significantly from cached writes (> 4 poor, <4 fair, <2 better, <1 best ). For OLTP databases, the lower this number the better, especially for disks holding the transaction log. The number of bytes sent and received over a specific network adapter, including framing characters. Be sure to record the throughput of your SQL Servers NIC card(s). Watch for this value possibly exceeding the NICs specifications, especially when conducting large and/ or multiple backups or copies to network drives. A high-speed network and/or a NIC dedicated to admin processes often alleviates this bottleneck. This counter is a sum of Network Interface\\Bytes Received/ sec and Network Interface\\Bytes Sent/ sec. In some situations, you may wish to determine both inbound and outbound network traffic separately.This counter is particularly useful in iSCSI environments where it can help to measure disk I/O when the NIC is dedicated to storage.

Counter
Free List Stalls/sec

You Want
<2

Description
Monitors the number of requests per second where data requests stall because no buffers are available. Any value above 2 means SQL Server needs more memory. Monitors the number of times per second that the Lazy Writer process moves dirty pages from the buffer to disk as it frees up buffer space. Lower is better with zero being ideal. When greater than 20, this counter indicates a need for more memory. Monitors the number of dirty pages, per second, that are flushed to disk when SQL Server invokes the checkpoint process. Checkpoint frequency is influenced by the recovery interval setting in sp_configure. High values for this counter may indicate insufficient memory or that the recovery interval is too high. Tells, on average, how many seconds SQL Server expects a data page to stay in cache. The target on an OLTP system should be at least 300 (5 min). When under 300, this may indicate poor index design (leading to increased disk I/O and less effective use of memory) or, simply, a potential shortage of memory. The number of requests to find a page in the buffer pool. When the ratio of batch requests to page lookups crests 100, you may have inefficient execution plans or too many adhoc queries. Number of physical database page reads issued per second. Normal OLTP workloads support 80 90 per second, but higher values may be a yellow flag for poor indexing or insufficient memory. Number of database pages physically written to disk per second. Normal OLTP workloads support 80 90 per second. Values over 90 should be crossed checked with lazy writer/sec and checkpoint counters. If the other counters are also high, then it may indicate insufficient memory. Number of data pages read per second in anticipation of their use. If this value is makes up even a sizeable minority of total Page Reads/sec (say, greater than 20% of total page reads), you may have too many physical reads occurring. Shows the number of page table entries (PTE) not in use on the server. PTEs are used to map virtual to physical memory addresses and are affected by the /PAE and /3GB Windows boot switches.

Counter
Batch Requests/Secv

You Want
See Description

Description
Number of batch requests received per second, and is a good general indicator for the activity level of the SQL Server. This counter is highly dependent on the hardware and quality of code running on the server. The more powerful the hardware, the higher this number can be, even on poorly coded applications. A value of 1000 batch requests/sec is easily attainable though a typical 100Mbs NIC can only handle about 3000 batch requests/sec.Many other counter thresholds depend upon batch requests/sec while, in some cases, a low (or high) number does not point to poor processing power. You should frequently use this counter in combination with other counters, such as processor utilization or user connections.In version 2000, Transactions/ sec was the counter most often used to measure overall activity, while versions 2005 and later use Batch Requests/sec. Versions 2005 prior to SP2, measure this counter differently and may lead to some misunderstandings. Read the footnote for more details. Number of times that Transact-SQL compilations occurred, per second (including recompiles). The lower this value is the better. High values often indicate excessive adhoc querying and should be as low as possible. If excessive adhoc querying is happening, try rewriting the queries as procedures or invoke the queries using sp_executeSQL. When rewriting isnt possible, consider using a plan guide or setting the database to parameterization forced mode. Number of times, per second, that Transact-SQL objects attempted to be executed but had to be recompiled before completion. This number should be at or near zero, since recompiles can cause deadlocks and exclusive compile locks. This counters value should follow in proportion to Batch Requests/sec and SQL Compilations/ sec. This needs to be nil in your system as much as possible. Number of cancel and query timeouts per second or features used that are considered deprecated; that is, those features and commands that Microsoft will not support in a release or two. Run this counter when considering an upgrade to a newer version of SQL Server, then update the application accordingly. Number of cancels and query timeouts occurring per second. This number should be as low as possible. A high sustained number indicates frequent query timeout or end-user cancellation of queries. Number of active cursors when polled. Monitor cursor counters to see if there may be heavy use of server cursors since improper use can result in performance issues. Number of errors per second which takes a database offline or kills a user connection, respectively. Since these are severe errors, they should occur very infrequently.

Counter
Logins/sec and Logouts/sec

You Want
<2

Description
The number of user logins per second. Any value over 2 may indicate insufficient connection pooling. The number of users currently connected to the SQL Server. This counter should roughly track with Batch Requests/Sec. They should generally rise and fall together. For example, blocking problems could be revealed by rising user connections, lock waits and lock wait time coupled with declining batch requests/sec. The number of latches in the last second that had to wait. Latches are lightweight means of holding a very transient server resource, such as an address in memory. The average latch wait time, in milliseconds, for any latch requests that had to wait. This value should generally correlate to Latch Waits/sec and move up or down with it accordingly. The total latch wait time in milliseconds spent waiting for a latch in the last second. This value should stay stable compared to the number of latch waits per second. The total time spent waiting across all transactions, in milliseconds, to acquire a lock in the last second. Because SQL Server records a lock at the end of a locking event, remember that an application with huge transactions may have inflated lock wait times while still performing as expected. For example, an application that issues multi-million record updates might have very long lock wait times while performing exactly as it was designed. How many times users waited to acquire a lock over the past second. Values greater than zero indicate at least some blocking is occurring, while a value of zero can quickly eliminate blocking as a potential root-cause problem. As with Lock Wait Time, lock waits are not recorded by PerfMon until after the lock event completes. The average wait time, in milliseconds, for each lock request that had to wait. An average wait time longer than 500ms may indicate excessive blocking. This value should generally correlate to Lock Waits/sec and move up or down with it accordingly. Reveals a variety of areas in which SQL Server might be waiting. Worth examining when other more obvious avenues, such as locks and latches, have been exhausted. The number of new locks and locks converted per second. This metrics value should generally correspond to Batch Requests/sec. Values > 1000 may indicate queries are accessing very large numbers of rows and may benefit from tuning. Shows the number of lock requests per second that timed out, including internal requests for NOWAIT locks. A value greater than zero might indicate that user queries are not completing. The lower this value is, the better. Number of lock requests, per second, which resulted in a deadlock. Since only a COMMIT, ROLLBACK, or deadlock can terminate a transaction (excluding failures or errors), this is an important value to track. Excessive deadlocking indicates a table or index design error or bad application design. Percentage of work tables created whose initial two pages were immediately available from the worktable cache. A value less than 90% may indicate insufficient memory, since execution plans are being dropped, or may indicate, on 32-bit systems, the need for an upgrade to a 64-bit system. Number of times that SQL Server escalated locks from page- or row-level to table-level. This number should, generally, be low. Frequent or even occasional spiking in this value may indicate poorly coded transactions. The time, in seconds, of the longest running transaction. When blocking is high, check this counter to see if transactions are open for long periods of time.

Memory

Pages/Sec

See Description

PhysicalDisk

Avg. Disk sec/Write

< 8ms (non cached) < 1ms (cached)

SQL Server: Buffer Manager

Lazy Writes/Sec

< 20

SQLServer: General Statistics

User Connections

See Description

Paging File

%Usage

< 70%

Paging File

%Usage Peak

< 70%

Network Interface

Bytes Total/sec

See Description

SQL Server: Buffer Manager

Checkpoint Pages/ sec

See Description

SQL Server: Latches

Latch Waits/sec

(Total Latch Wait Time) / (Latch Waits/ Sec) < 10 See Description

To learn more about the memory and paging counters, visit: http://sqlserverpedia.com/wiki/MemoryCounters

SQL Server: Latches

OS CPU & Processor Counters

Object
Process (sqlservr)

SQL Server: Buffer Manager

Page Life Expectancy

> 300

Avg Latch Wait Time (ms)

SQLServer: SQL Statistics

SQL Compilations/sec

Counter
%Processor Time

You Want
< 80%

Description
Percentage of processor time spent on SQL Server process threads.You may also wish to investigate other Process (sqlservr) such as Private Bytes, Virtual Bytes, Working Set, etc to get a fuller understanding of how SQL Server allocates certain segments of memory. Usually, these auxiliary counters provide contextual information and are not necessary for troubleshooting. Percentage of processor time spent on SSAS process threads. Percentage of elapsed time that the process threads spent executing code in privileged mode, like SQL Server I/O requests. Poor performance here may be caused by an old or inefficient hardware driver. Percentage of elapsed time the processor spends executing non-idle threads. Number of threads waiting for CPU cycles, where < 12 per CPU is good/fair, < 8 is better, < 4 is best. Number of execution contexts switched in the last second, where >6000 is poor, <3000 is good, and <1500 is excellent. SQL Server: Databases Log Bytes Flushed/ sec See Description

< 10% of the number of Batch Requests/Sec

SQL Server: Latches

Total Latch Wait Time (ms)

SQLServer: Buffer Manager

Page Lookups/sec

(Page lookups/ sec) / (Batch Requests/ sec) < 100 < 90

(Total Latch Wait Time) / (Latch Waits/ Sec) < 10

SQL Server: Locks

To learn more about the other counters, visit: http://sqlserverpedia.com/wiki/OtherCounters

SQL Server: Buffer Manager

Page Reads/sec

SQLServer: SQL Statistics

SQL Re-Compilations/sec

< 10% of the number of SQL Compilations/sec

Lock Wait Time (ms)

See Description

Process (msmdsrv) Processor

%Processor Time

< 80%

MSSQL User Databasevi Performance Counters

Monitor these counters to determine general benchmark levels set by your user databases and for tempdb.

%Processor Time

< 30% of total % Processor Time

Object
SQL Server: Databases

Counter
Data File(s) Size (KB)

You Want
See Description

Description
Cumulative size (KB) of all the data files in the database including any automatic growth. Monitoring this counter is useful, for example, for determining the correct size of tempdb. Total number of log bytes flushed per second. Useful for determining trends and utilization of the transaction log Cumulative size, in (KB), of all the transaction log files for the specific database. Useful for determining trends and utilization of the transaction log. The cumulative used size of all the log files in the database. Total wait time, in milliseconds, to write all transaction log pages. Effectively, the number of times per second that SQL Server must wait for pages to be written to the transaction log. Technically, the number of log pages flushed to the transaction log per second. Total number of times the transaction log for the database has been expanded. Each time the transaction log grows, all user activity must halt until the log growth completes. Therefore, you want log growths to occur during predefined maintenance windows rather than during general working hours. Total number of times the transaction log for the database has been shrunk. Total number of times the transaction log has been truncated for the database specified. Truncations should happen during log backups or, on databases in simple recovery mode, at checkpoint or the time period specified by recovery interval. Percentage of space in the log that is in use. Since all work in an OLTP database stops until writes can occur to the transaction log, its a very good idea to ensure that the log never fills completely. Hence, the recommendation to keep the log under 80% full.

SQL Server: Buffer Manager

Page Writes/sec

< 90

SQL Server: Deprecated Features

Usage

~0

SQL Server: Locks

Lock Waits/sec

Processor

%Processor Time

< 80%

System

Processor Queue Length

< 4 per CPU

SQL Server: Buffer Manager

Readahead/sec

< 20% of Page Reads/ sec

SQL Server: SQL Statistics

SQL Attention Rate/sec

~0

SQL Server: Locks

Avg Wait Time (ms)

<500

System

Context Switches/sec

< 4 per CPU

SQL Server: Databases

Log File(s) Size (KB)

See Description

Memory

Free System Page Table Entries

>10,000 > 24,000 on boot

To learn more about the CPU counters, visit: http://sqlserverpedia.com/wiki/CPUCounters

SQL Server: Databases SQL Server: Databases SQL Server: Databases

Log File(s) Used Size (KB) Log Flush Wait Time

See Description ~0

SQL Server: Cursor Manager by Type SQL Server: SQL Errors

Active Cursors

See Description

To learn more about the buffer counters, visit: http://sqlserverpedia.com/wiki/BufferCounters

MSSQL Data Access Performance Counters

Object
SQLServer: Access Methods SQLServer: Access Methods

MSSQL How is My Memory Being Used Performance Countersiv

Object
SQL Server: Buffer Manager SQL Server: Buffer Manager SQL Server: Buffer Manager SQL Server: Buffer Manager SQL Server: Buffer Manager SQL Server: Buffer Manager

Errors/sec \\ DB Offline Errors and Errors/sec \\ Kill Connection Errors

~0

SQL Server: Wait Statistics

See Description

See Description

Counter
Forwarded Records/sec

You Want
< 10 per 100 Batch Requests/Sec See Description

Description
Identifies use of a pointer which has been created when variable length columns have caused a row to move to a new page in a heap. Monitors the number of full scans on tables or indexes. Ignore unless high CPU coincides with high scan rates. High scan rates may be caused by missing indexes, very small tables, or requests for too many records. A sudden increase in this value may indicate a statistics threshold has been reached, resulting in an index no longer being used. Monitors the number of index searches when doing range scans, single index record fetches, and repositioning within an index. The threshold recommendation is strictly for OLTP workloads. Monitors the number of page splits per second which occur due to overflowing index pages and should be as low as possible. To avoid page splits, review table and index design to reduce non-sequential inserts or implement fillfactor and pad_index to leave more empty space per page. NOTE: A high value for this counter is not bad in situations where many new pages are being created, since it includes new page allocations. Number of work files created per second, usually as a part of tempdb processing when working with hashing joins and other hashing operations. High values can indicate thrash in tempdb and poorly coded queries. Number of work tables created per second, usually as a part of tempdb processing when working with spools such as table spools, index spools, etc.

Log Flush Waits/sec

~0

SQL Server: Locks

Counter
Database Pages

You Want
See Description

Description
Number of database pages in the buffer pool, as opposed to other usages for memory such as free pages, procedure cache, etc. Number of pages used to store compiled queries and objects.

To learn more about the workload counters, visit: http://sqlserverpedia.com/wiki/WorkloadCounters

Lock Requests/ sec

<1000

SQL Server: Databases SQL Server: Databases

Log Flushes/sec

See Description ~0

Full Scans / sec

Red Herring Counters

Microsoft SQL Server has a long and storied history. Some PerfMon counters, once among the most useful available, are now much less useful to the point of being counter-productive. In many cases, improvements to the hardware or internal processes within SQL Server mean these PerfMon counters, while once informative, no longer add value.

SQL Server: Locks

Log Growths

Procedure Cache Pages

See Description

Lock Timeouts/ sec

<1

Target Pages

See Description

The ideal number of pages in the buffer pool according the maximum memory granted to SQL Server in sp_configure. Total number of pages in the buffer pool (including database, free, and stolen pages).

Counter
Physical Disk: % Disk Time

Explanation
SQL Server: Locks This counter is deceptive because it makes no accommodation for multiple spindles. Thus, the more spindles (i.e. physical hard disks) you have, the higher the percentile values can go. Conversely, if these spindles are shared across LUNs or other services, you may have high numbers on this counter without any correlation to SQL Server activity. In short, there are better ways to find out SQL Servers I/O performance. The way in which Windows measures disk queues, combined with the amount of cache that storage vendors provide with hard disk controllers, SANs, and hard disks themselves means that Windows might perceive that data is written all the way to disk, when in fact the data is actually sitting in a hardware-level cache somewhere. Using this counter, by itself, is not useful since you cannot tell how many reads or writes, separately, are happening. In addition, theres not really a useable You Want sort of threshold for this counter. This counter is still occasionally useful for a stalled I/O type of issue, but only in correlation with the other I/O counters mentioned earlier. Only useful on physical machines. Its value drops dramatically on virtual machines since you cannot know if CPU issues are due to CPU scheduling, a throttle set by the hypervisor, or a limited amount of CPU available due to other guest activity. Long a stalwart counter used by SQL Server DBAs, this counter is no longer very useful. It monitors the percentage of data requests answer from the buffer cache since the last reboot. However, other counters are much better for showing current memory pressure that this one because it blows the curve. For example, PLE (page life expectancy) might suddenly drop from 2000 to 70, while buffer cache hit ration moves only from 98.2 to 98.1. Only be concerned by this counter if its value is regularly below 90 (for OLTP) or 80 (for very large OLAP). SQL Server: Access Methods Table Lock Escalations/sec See Description Number of Deadlocks/sec <1

SQLServer: Access Methods

Index Searches/sec

1 Full Scan/sec per 1000 Index Searches/sec

SQL Server: Databases SQL Server: Databases

Log Shrinks

~0

Target Pages

See Description

Log Truncations

See Description

SQLServer: Access Methods

Page Splits/sec

< 20 per 100 Batch Requests/Sec

Free Pages

> 640

Total number of pages available across all free lists. A value less than 640 (5MB) indicates physical memory pressure. Tells how many pages were stolen from the buffer pool to satisfy other memory needs, such as plan cache and workspace memory. This number is a good metric to determine how much data is flowing into SQL Server caches and should remain proportionate to Batch Requests/sec. Also remember to look for where these stolen pages might be stolen from optimizer memory, lock memory, and so forth. Shows the amount of memory that SQL Server is currently using. This value should grow until its equal to Target Server Memory, as it populates its caches and loads pages into memory. When it has finished, SQL Server is said to be in a steady-state. Until it is in steady-state, performance may be slow and IO may be higher. Shows the amount of memory that SQL Server wants to use based on the configured Max Server Memory.

Physical Disk: Avg Disk Queue Lengths

SQL Server: Access Methods

Worktables From Cache Ratio

>90%

SQL Server: Databases

Percent Log Used

<80%

Stolen Pages/sec

See Description

Physical Disk: Transfer/sec

SQLServer: Access Methods

Workfiles Created/sec

<20

To learn more about the database counters, visit: http://sqlserverpedia.com/wiki/DatabaseCounters SQLServer: Memory Manager Total Server Memory(KB) See Description

Processor: % Processor Time

SQLServer: Access Methods

Worktables Created/sec

<20

SQL Server SQL Statistics Counters

Counter
Auto-Param Attempts/sec

SQL Server: Buffer Manager : Buffer Cache Hit Ratio

SQL Server: Transactions

Longest Running Transaction Time

See Description

Description
Number of auto-parameterization attempts per second. Total should be the sum of the failed, safe, and unsafe auto-parameterizations. Auto-parameterization occurs when an instance of SQL Server attempts to reuse a cached plan for a previously executed query that is similar to, but not the same as, the current query. For more information, see Autoparameterization in the SQL Server Books On-Line (BOL). Number of failed auto-parameterization attempts per second. This should be small. SQLServer: Memory Manager Target Server Memory(KB) See Description

To learn more about the access counters, visit: http://sqlserverpedia.com/wiki/AccessCounters

To learn more about the locks counters, visit: http://sqlserverpedia.com/wiki/LocksCounters

SQL Server : Plan Cache : Cache Manager Instance

Instances can be:_total (all instances in total), SQL Plans (cached query plans from ad-hoc Transact-SQL statements), Object Plans (query plans for stored procedures, user-defined functions and triggers), Bound Trees (normalized trees for views, rules, computed columns and check constraints), Extended stored procedures (number of these objects referenced in cache), Temporary tables & table variables (number of temp tables and table variables referenced in cache).

SQL Server: Memory Manager Counters

Counter
Granted Workspace Memory (KB) Maximum Workspace Memory (KB) Memory Grants Outstanding Memory Grants Pendingvii

To learn more about the memory counters, visit: http://sqlserverpedia.com/wiki/MemoryCounters

Description
Total amount of memory currently granted to executing processes such as hash, sort, bulk copy, and index creation operations. Maximum amount of memory available for executing processes such as hash, sort, bulk copy, and index creation operations. Total number of processes per second that have successfully acquired a workspace memory grant. Total number of processes per second waiting for a workspace memory grant. Numbers higher than 0 indicate a lack of memory. Total amount of dynamic memory the server can consume.

Failed AutoParams/sec Safe AutoParams/sec Unsafe AutoParams/sec

Getting Perfmon data from inside of SSMS

Number of safe auto-parameterization attempts per second.

A query is designated as unsafe when it has characteristics that prevent its cached plan from being shared.

Did you know that the SQL Server related performance counters covered in this poster can be accessed from a DMV using T-SQL? In the example below, were using the sys.dm_os_performance_ counters DMV to retrieve the Page Life Expectancy counter value from the Buffer Manager object. SELECT cntr_value FROM sys.dm_os_performance_counters WHERE object_name = SQLServer:Buffer Manager AND counter_name = page life expectancy Note that the objects & counters available through this DMV are limited to those exposed to PerfMon by SQL Server, so counters such as Avg. Disk Sec/Read are not available using this technique because they originate in Windows, not SQL Server. For the complete list of available counters, try a simple select against the DMV such as this: SELECT * FROM sys.dm_os_performance_counters This technique is a great alternative to PerfMon, especially for obtaining a quick overview of SQL Serverrelated performance information in real time by issuing simple T-SQL commands within SQL Server Management Studio (SSMS).

Counter
Ad hoc SQL Plans

Description
Query plans produced from an ad hoc Transact-SQL query, including auto-parameterized queries. SQL Server caches the plans for ad hoc SQL statements for later reuse if the identical Transact-SQL statement is later executed. Query plans that correspond to Transact-SQL statements prepared using sp_prepare, sp_cursorprepare, or auto-parameterization. User-parameterized queries (even if not explicitly prepared) are also monitored as Prepared SQL Plans. Query plans generated by creating a stored procedure.

Prepared SQL Plans

Refer to KB 889654, http://support.microsoft.com/kb/889654, for details. Use these counters for direct-attached storage devices (DASD) only! When using SSD or a SAN, use the performance tools and/or PerfMon counters recommended by the SAN vendor. iii Disk latency & queue length were especially important metrics in SQL Server 2000 and earlier. Now, these counters are much less valuable and may often be less than useful. Conversely, these counters should generally show zero on any application deployed on current generation hardware. iv Refer to SQLServerPedia.com for more information on AWE and NUMA counters. v Refer to KB 936637, http://support.microsoft.com/kb/936637, for details. vi These are recommended for each user database. In addition, always monitor tempdb as if it were an application database. vii Refer to http://technet.microsoft.com/en-us/library/cc917690.aspx for more information.
i ii

Procedure Plans

Target Server Memory (KB)

2010 Quest Software, Inc. ALL RIGHTS RESERVED. Quest Software is a registered trademark of Quest Software, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. HOD_SQLPerfmonPoster_Q2_2010.