PerfMon_Counters_Digest_w_Highlights

Performance ObjectsCommonly used Performance Objects for SQL Server analysisPerformance ObjectSQL2000SQL2005SQL2008 (RC0)Memory***Network Interface***Paging File***LogicalDisk***PhysicalDisk***Process***Processor***System***SQL Server:Access Methods***SQL Server:Backup Device-**SQL Server:Broker Activation-**SQL Server:Broker Statistics-**SQL Server:Broker TO Statistics--*SQL Server:Broker /DBM Transport-**SQL Server:Buffer Manager***SQL Server:Buffer Node-**SQL Server:Buffer Partition-**SQL Server:Cache Manager*?*SQL Server:Catalog Metadata-**SQL Server:CLR-**SQL Server:Cursor Manager by Type-**SQL Server:Cursor Manager Total-**SQL Server:Database Mirroring-**SQL Server:Databases***SQL Deprecated Features--*SQL Server:Exec Statistics?**SQL Server:General Statistics***SQL Server:Latches***SQL Server:Locks***SQL Server:Memory Manager***SQL Server:Plan Cache-**SQL Server:Replication Agents?**SQL Server:Replication Dist.?**SQL Server:Replication LogReader?**SQL Server:Replication Merge?**SQL Server:Replication Snapshot?**SQL Server:Resource Pool--*SQL Server:SQL Errors***SQL Server:SQL Statistics***SQL Server:SSIS Service-**SQL Server:Transactions***SQL Server:User Settable***SQL Server:Wait Statistics-**SQL Server:Workload Group Stats--*SQL Server 2000 Performance ObjectsSQLServer:Access MethodsSQLServer:Buffer ManagerSQLServer:Buffer PartitionSQLServer:Cache ManagerSQLServer:DatabasesSQLServer:General StatisticsSQLServer:LatchesSQLServer:LocksSQLServer:Memory ManagerSQLServer:SQL StatisticsSQLServer:User SettableSQL Server 2005 Performance ObjectsMSSQL$SQL1:Access MethodsMSSQL$SQL1:Broker ActivationMSSQL$SQL1:Broker StatisticsMSSQL$SQL1:Broker/DBM TransportMSSQL$SQL1:Buffer ManagerMSSQL$SQL1:Buffer NodeMSSQL$SQL1:Buffer PartitionMSSQL$SQL1:Catalog MetadataMSSQL$SQL1:CLRMSSQL$SQL1:Cursor Manager by TypeMSSQL$SQL1:Cursor Manager TotalMSSQL$SQL1:Database MirroringMSSQL$SQL1:DatabasesMSSQL$SQL1:Exec StatisticsMSSQL$SQL1:General StatisticsMSSQL$SQL1:LatchesMSSQL$SQL1:LocksMSSQL$SQL1:Memory ManagerMSSQL$SQL1:Plan CacheMSSQL$SQL1:SQL ErrorsMSSQL$SQL1:SQL StatisticsMSSQL$SQL1:TransactionsMSSQL$SQL1:User SettableMSSQL$SQL1:Wait StatisticsSQL Server 2008 Performance Objects (pending)

LogMan'start a perfmon counter log from the command linelogman start dbPerfLog'stop a perfmon counter log from the command linelogman stop dbPerfLog'defining perfmon counter logs' options' -si 05 sample interval of 5s' -v nnnn append file version info' -max max size of log file' -o path' -c perf counters' for more info, execute logman -?'define a perfmon counter log for a SQL Server 2005 service named "SQLServer"call Logman create counter "dbPerfLog" -si 05 -v nnnnnn -max 100 -o "C:\perflogs\dbPerf" -c "\LogicalDisk(*)\*" "\PhysicalDisk(*)\*" "\Process(*)\*" "\Processor(*)\*" "\System\*" "\Network Interface(*)\*" "\Memory(*)\*" "\Paging File(*)\*" "\SQLServer:Access Methods(*)\*" "\SQLServer:Buffer Manager(*)\*" "\SQLServer:Buffer Node(*)\*" "\SQLServer:Buffer Partition(*)\*" "\SQLServer:Cursor Manager by Type(*)\*" "\SQLServer:Cursor Manager Total(*)\*" "\SQLServer:Databases(*)\*" "\SQLServer:Exec Statistics(*)\*" "\SQLServer:General Statistics(*)\*" "\SQLServer:Latches(*)\*" "\SQLServer:Locks(*)\*" "\SQLServer:Memory Manager(*)\*" "\SQLServer:Plan Cache(*)\*" "\SQLServer:SQL Errors(*)\*" "\SQLServer:SQL Statistics(*)\*" "\SQLServer:Wait Statistics(*)\*"'define a perfmon counter log for a Katmai service named "MSSQL$KATMAI"call Logman create counter "dbPerfLogSQL10" -si 05 -v nnnnnn -max 100 -o "U:\perflogs\dbPerf" -c "\LogicalDisk(*)\*" "\PhysicalDisk(*)\*" "\Process(*)\*" "\Processor(*)\*" "\System\*" "\Network Interface(*)\*" "\Memory(*)\*" "\Paging File(*)\*" "\MSSQL$KATMAI:Access Methods(*)\*" "\MSSQL$KATMAI:Buffer Manager(*)\*" "\MSSQL$KATMAI:Buffer Node(*)\*" "\MSSQL$KATMAI:Buffer Partition(*)\*" "\MSSQL$KATMAI:Cursor Manager by Type(*)\*" "\MSSQL$KATMAI:Cursor Manager Total(*)\*" "\MSSQL$KATMAI:Databases(*)\*" "\MSSQL$KATMAI:Exec Statistics(*)\*" "\MSSQL$KATMAI:General Statistics(*)\*" "\MSSQL$KATMAI:Latches(*)\*" "\MSSQL$KATMAI:Locks(*)\*" "\MSSQL$KATMAI:Memory Manager(*)\*" "\MSSQL$KATMAI:Plan Cache(*)\*" "\MSSQL$KATMAI:SQL Errors(*)\*" "\MSSQL$KATMAI:SQL Statistics(*)\*" "\MSSQL$KATMAI:Wait Statistics(*)\*"Per Burzin Patel: TIP: you can reduce the size of the command line by using the config option and passing in a parameter file.Description of the Windows XP Logman.exe, Relog.exe, and Typeperf.exe Toolshttp://support.microsoft.com/kb/303133Logman.exeYou can use the Logman.exe tool to: Remotely start and stop log file data collections from a central location by specifying the remote computer name. Configure a data collection on one computer and then copy that configuration to multiple computers from a central location. Query currently-running logs and traces.ExampleIf Sample_Log is the name of an existing performance log on the local computer, this command starts the log:logman start Sample_LogRelog.exeYou can use the Relog.exe tool to: Convert a log from one type to another, such as a Microsoft Windows NT 4.0 log to a Windows XP log, or a binary log file (.blg) to a comma-separated values (.csv) file. Resample a log file, and then create a new log file that is based on specified counters, a time period, or a sampling interval.ExampleTo convert a Windows 2000 log file that is named Win2k_log to a .csv log file that is named Win2k_log.csv, you would use:relog Win2k_log.blg -f CSV -o Win2k_log.csvTypeperf.exeYou can use the Typeperf.exe tool to: Write performance data to the command window or to a supported log file format. Display all of the counters that are currently available on a particular local or remote computer.ExampleTo output the Memory counter, Available Bytes, from a remote computer that is named "XPPRO", every 5 seconds, you would use:typeperf "Memory\Available Bytes" -s XPPRO -si 00:05Logman cmd refhttp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_logman.mspxRelog cmd refhttp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_relog.mspxTypeperf cmd refhttp://technet.microsoft.com/en-us/library/bb490960.aspx

Execute this from the command line to create a PerfMon counter log containing the necessary performance objects, counters, & instances for most performance needs; it doesn't include counters for e.g., replication, service broker, etc.http://support.microsoft.com/kb/303133http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_logman.mspxhttp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_relog.mspxhttp://technet.microsoft.com/en-us/library/bb490960.aspx

MyCounterListCounterSourceMyStatusVitalSignsPerformance ObjectCounterInstanceThresholdHardware1XKernelAvailable MBytes 1000This counter monitors the number of full scans on base tables or indexes. Values greater than 1 or 2 indicate that we are having table / Index page scans. If we see high CPU then we need to investigate this counter, otherwise if the full scans are on small tables we can ignore this counter. A few of the main causes of high Full Scans/sec are Missing indexes Too many rows requestedQueries with missing indexes or too many rows requested will have a large number of logical reads and an increased CPU time.SQLServer:Access MethodsIndex Searches/sec(Index Searches/sec)/(Full Scans/sec) > 1000Number of index searches. Index searches are used to start range scans, single index record fetches, and to reposition within an index. Index searches are preferable to index and table scans. For OLTP applications, optimize for more index searches and less scans (preferably, 1 full scan for every 1000 index searches). Index and table scans are expensive I/O operations.SQLServer:Access MethodsPage Splits/sec< 20 per 100 Batch Requests/SecNumber of page splits per second that occur as the result of overflowing index pages. Interesting counter that can lead us to our table / index design. This value needs to be low as possible. If you find out that the number of page splits is high, consider increasing the fillfactor of your indexes. An increased fillfactor helps to reduce page splits because there is more room in data pages before it fills up and a page split has to occur.Note that this counter also includes the new page allocations as well and doesnt necessarily pose a problem. The other place we can confirm the page splits that involve data or index rows moves are the fragmented indexes on page splits.SQL Server:Buffer ManagerBuffer Cache hit ratio> 90%This counter indicates how often SQL Server goes to the buffer, not the hard disk, to get data. The higher this ratio, the less often SQL Server has to go to the hard disk to fetch data, and performance overall is boosted. Unlike many of the other counters available for monitoring SQL Server, this counter averages the Buffer Cache Hit Ratio from the time the last instance of SQL Server was restarted. In other words, this counter is not a real-time measurement, but an average of all the days since SQL Server was last restarted. In OLTP applications, this ratio should exceed 90-95%. If it doesn't, then you need to add more RAM to your server to increase performance. In OLAP applications, the ratio could be much less because of the nature of how OLAP works. In any case, more RAM should increase the performance of SQL Server OLAP activity.SQL Server:Buffer ManagerFree list stalls/sec< 2Free list stalls/sec is the frequency with which requests for available database pages are suspended because no buffers are available. Free list stall rates of 3 or 4 per second indicate too little SQL memory available.SQL Server:Buffer ManagerFree pages> 640Total number of pages on all free lists.SQL Server:Buffer ManagerLazy Writes/Sec< 20This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.SQL Server:Buffer ManagerPage Life Expectancy> 300This performance monitor counter tells you, on average, how long data pages are staying in the buffer. If this value gets below 300 seconds, this is a potential indication that your SQL Server could use more memory in order to boost performance.SQLServer:Buffer ManagerPage lookups/sec(Page lookups/sec) / (Batch Requests/sec) < 100Number of requests to find a page in the buffer pool. When the ratio of page lookups to batch requests is much greater than 100, this is an indication that while query plans are looking up data in the buffer pool, these plans are inefficient. Identify queries with the highest amount of logical I/O's and tune them.SQL Server:Buffer ManagerPage reads/sec< 90Number of physical database page reads issued. 80 90 per second is normal, anything that is above indicates indexing or memory constraint.SQL Server:Buffer ManagerPage writes/sec< 90Number of physical database page writes issued. 80 90 per second is normal, anything more we need to check the lazy writer/sec and checkpoint counters, if these counters are also relatively high then, its memory constraint.SQLServer:General StatisticsLogins/sec< 2> 2 per second indicates that the application is not correctly using connection pooling.SQLServer:General StatisticsLogouts/sec< 2> 2 per second indicates that the application is not correctly using connection pooling.SQLServer:General StatisticsUser ConnectionsSee DescriptionThe number of users currently connected to the SQL Server.Note: It is recommended to review this counter along with Batch Requests/Sec. A surge in user connections may result in a surge of Batch Requests/Sec. So if there is a disparity (one going up and the other staying flat or going down), then that may be a cause for concern. With a blocking problem, for example, you might see user connections, lock waits and lock wait time all increase while batch requests/sec decreases.SQL Server:LatchesLatch Waits/sec(Total Latch Wait Time) / (Latch Waits/Sec) < 10This is the number of latch requests that could not be granted immediately. In other words, these are the amount of latches, in a one second period that had to wait.SQL Server:LatchesTotal Latch Wait Time (ms)(Total Latch Wait Time) / (Latch Waits/Sec) < 10This is the total latch wait time (in milliseconds) for latch requests in the last secondSQL Server:LocksLock Wait Time (ms)See DescriptionTotal wait time (milliseconds) for locks in the last second.Note: For Lock Wait Time it is recommended to look beyond the Avg value. Look for any peaks that are close (or exceeds) to a wait of 60 sec. Though this counter counts how many total milliseconds SQL Server is waiting on locks during the last second, but the counter actually records at the end of locking event. So most probably the peaks represent one huge locking event. If those events exceeds more than 60seconds then they may have extended blocking and could be an issue.In such cases, thoroughly analyze the blocking script output. Some applications are written for timing out after 60 seconds and thats not acceptable response for those applications.SQL Server:LocksLock Waits/sec0This counter reports how many times users waited to acquire a lock over the past second. Note that while you are actually waiting on the lock that this is not reflected in this counterit gets incremented only when you wake up after waiting on the lock. If this value is nonzero then it is an indication that there is at least some level of blocking occurring. If you combine this with the Lock Wait Time counter, you can get some idea of how long the blocking lasted. A zero value for this counter can definitively prove out blocking as a potential cause; a nonzero value will require looking at other information to determine whether it is significant.SQL Server:LocksNumber of Deadlocks/sec< 1The number of lock requests that resulted in a deadlock.SQLServer:Memory ManagerTotal Server Memory(KB)See DescriptionThe Total Server Memory is the current amount of memory that SQL Server is using. If this counter is still growing the server has not yet reached its steady-state, and it is still trying to populate the cache and get pages loaded into memory. Performance will likely be somewhat slower during this time since more disk I/O is required at this stage. This behavior is normal. Eventually Total Server Memory should approximate Target Server Memory.SQLServer:SQL StatisticsBatch Requests/SecSee DescriptionThis counter measures the number of batch requests that SQL Server receives per second, and generally follows in step to how busy your server's CPUs are. Generally speaking, over 1000 batch requests per second indicates a very busy SQL Server, and could mean that if you are not already experiencing a CPU bottleneck, that you may very well soon. Of course, this is a relative number, and the bigger your hardware, the more batch requests per second SQL Server can handle. From a network bottleneck approach, a typical 100Mbs network card is only able to handle about 3000 batch requests per second. If you have a server that is this busy, you may need to have two or more network cards, or go to a 1Gbs network card.Note: Sometimes low batch requests/sec can be misleading. If there were a SQL statements/sec counter, this would be a more accurate measure of the amount of SQL Server activity. For example, an application may call only a few stored procedures yet each stored procedure does lot of work. In that case, we will see a low number for batch requests/sec but each stored procedure (one batch) will execute many SQL statements that drive CPU and other resources. As a result, many counter thresholds based on the number of batch requests/sec will seem to identify issues because the batch requests on such a server are unusually low for the level of activity on the server. We cannot conclude that a SQL Server is not active simply by looking at only batch requests/sec. Rather, you have to do more investigation before deciding there is no load on the server. If the average number of batch requests/sec is below5 and other counters (such as SQL Server processor utilization) confirm the absence of significant activity, then there is not enough of a load to make any recommendations or identify issues regarding scalability.SQLServer:SQL StatisticsSQL Compilations/sec< 10% of the number of Batch Requests/SecThe number of times per second that SQL Server compilations have occurred. This value needs to be as low as possible. If you see a high value such as over 100, then its an indication that there are lots of adhoc queries that are running, might cause CPU usage, solution is to re-write these adhoc as stored procedure or use sp_executeSQL.SQLServer:SQL StatisticsSQL Re-Compilations/sec< 10% of the number of SQL Compilations/secThis needs to be nil in our system as much as possible. A recompile can cause deadlocks and compile locks that are not compatible with any locking type.

http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm

Vital SignsVital Signs is a 3-day Microsoft workshop authored & offered byPFE Shane Creamershanec@microsoft.comThere is no other workshop on the planet like it.I strongly encourage anyone interested in performance to take this class.Most of the counters & thresholds cited in this class reflect the values from this class.Microsoft PFE Shane Cramer is the Yoda of PerfMon.He has created a workshop called Vital Signs.It is already available for public consumption, and hes rumored to be updating it soon to a formal SKU.Whether youre new to PerfMon or want to take your skills from Padawan to Jedi Master, the Vital Signs workshop is for you.Stay tuned for updates & URLs.

shanec@microsoft.com