PerfMon Counters Digest w Vital Signs Correlation v6

Performance Object SQL2000 SQL2005Memory * * *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 ObjectsSQL Server 2005 Performance Objects

Commonly used Performance Objects for SQL Server analysis

SQL2008 (RC0)

SQL Server 2008 Performance Objects (pending)

'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"

'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 Tools

Logman.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_Log

Relog.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.csv

Typeperf.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:05

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(*)\*"

http://support.microsoft.com/kb/303133

Logman cmd refhttp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_logman.mspx

Relog cmd refhttp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_relog.mspx

Typeperf 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/303133

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_logman.mspx

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_relog.mspx

http://technet.microsoft.com/en-us/library/bb490960.aspx

A17


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.

• 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.

If Sample_Log is the name of an existing performance log on the local computer, this command starts the log:

• 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.

To 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:

• Display all of the counters that are currently available on a particular local or remote computer.

To output the Memory counter, Available Bytes, from a remote computer that is named "XPPRO", every 5 seconds, you would use:

" -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(*)\*"







" -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(*)\*"

Performance Object Counter

Hardware 1° X Kernel Available MBytesHardware 2° X Kernel Cache BytesHardware 1° X Kernel Free System Page Table EntriesHardware 2° Kernel Page Faults/secHardware 1° X Kernel Pages/secHardware 2° X Kernel Pool NonPaged BytesHardware 2° X Kernel Pool Paged BytesHardware 2° X Kernel System Cache Resident BytesHardware 2° X Network Interface Bytes total/secHardware 2° X Network Interface Current BandwithHardware 2° X Network Interface Output Queue LengthHardware 2° X PhysicalDisk/LogicalDisk % Idle TimeHardware 1° X PhysicalDisk/LogicalDisk Avg. Disk sec/ReadHardware 1° PhysicalDisk/LogicalDisk Avg. Disk sec/TransferHardware 1° X PhysicalDisk/LogicalDisk Avg. Disk sec/WriteHardware 3° PhysicalDisk/LogicalDisk Disk Bytes/secHardware 3° PhysicalDisk/LogicalDisk Disk Read Bytes/secHardware 3° PhysicalDisk/LogicalDisk Disk Write Bytes/secHardware 2° X PhysicalDisk/LogicalDisk Disk Reads/secHardware 2° X PhysicalDisk/LogicalDisk Disk Transfers/secHardware 2° X PhysicalDisk/LogicalDisk Disk Writes/secHardware 3° PhysicalDisk/LogicalDisk Split IO/secHardware 2° Process % Processor TimeHardware 2° Process Page Faults/secHardware 1° X Process Handle CountHardware 1° X Process IO Data Operations/secHardware 1° X Process IO Other Operations/secHardware 1° X Process Private BytesHardware 1° X Process Thread CountHardware 1° X Process Working SetHardware 1° X Processor % Privileged TimeHardware 1° X Processor % Processor TimeHardware 1° X Processor % UserHardware 1° System Context Switches/secSQL Server 1° Access Methods Full Scans/secSQL Server 1° Access Methods Index Searches/secSQL Server 1° Buffer Manager Buffer Cache Hit RatioSQL Server 2° Buffer Manager Lazy writes/secSQL Server 1° Buffer Manager Page Life ExpectancySQL Server 1° Buffer Manager Procedure Cache PagesSQL Server 2° Plan Cache Cache PagesSQL Server 2° Buffer Manager Total pagesSQL Server 2° Cache Manager Cache Hit RatioSQL Server 2° Databases Log Flushes/secSQL Server 2° Databases Transactions/secSQL Server 2° Latches Average Latch Wait Time (ms)SQL Server 1° Latches Latch Waits/secSQL Server 1° Latches Total Latch Wait Time (ms)SQL Server 1° Memory Manager Memory Grants PendingSQL Server 1° Memory Manager Target Server MemorySQL Server 1° Memory Manager Total Server MemorySQL Server 1° SQL Statistics Batch Requests/secSQL Server 1° SQL Statistics SQL Compilations/secSQL Server 1° SQL Statistics SQL Recompilations/sec

Counters pending review:

CounterSource

MyStatus

VitalSigns

SQL Server:Buffer Manager Free list stalls/sec < 2SQL Server:Buffer Manager Free pages > 640SQL Server:Buffer Manager Lazy Writes/Sec < 20SQLServer:Buffer Manager Page lookups/sec (Page lookups/sec) / (Batch Requests/sec) < 100SQL Server:Buffer Manager Page reads/sec < 90SQL Server:Buffer Manager Page writes/sec < 90

Instance Threshold

<10MB fatal, <100MB cause for concern

< a few hundred is desirable, in the thousands acceptable if other memory counters are OK (see Process object)>2500/s bad for modern servers; much less for older servers; avg/sustained <25% of HDD or <10% RAM; MUCH less for SQL Server 32-bit: 100MB-260MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)32-bit: 120MB-480MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)

* <40% good; 40%-65% caution; 65%-100% critical Machine-Specific* <80%* 0 healthy; 1-2 caution; >2 critical* 50% good; 15%-50% warning; 0%-15% busy* Disk Latency <=5 ms Excellent* Disk Latency 5-10 ms Good* Disk Latency 10-20 ms Reasonable* Disk Latency is a great metric because it is independent of spindle count*** }~150 (for random) Source: readme.txt sqlio v1.5 11/17/99* }* }* Fewer the better_Total,<sqlservr>_Total,<sqlservr> < a few hundred is desirable, in the thousands acceptable if other memory counters are OK_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>

SQL Server is a USER MODE app!5,000/s x # of CPUs; somewhat flexible if other CPU-related counters (Index Searches/sec)/(Full Scans/sec) > 1000(Index Searches/sec)/(Full Scans/sec) > 100098% OK, 99% better, 99.8% desirablebaseline<300s "official" threshold; >1,000 or >10,000s much bett Memory Matte(2000) prefer stable values, otherwise cache thrash may Memory Matte(2005) prefer stable values, otherwise cache thrash may be occurringbaseline<99.9 excellent; <99 good; >98 not optimalbaselinebaseline~(Total Latch Wait Time) / (Latch Waits/Sec) < 10(Total Latch Wait Time) / (Latch Waits/Sec) < 10>0 is cause for concern Memory Mattehigh or rising value indicates insufficient memory Memory Matters~=Physical Ram Memory MattersOLTP workloads: server should support ~2,500/s/coreif compiles > 10% of Batch Requests, then app may not be caching effectivelyRecompiles > 10% of Compilations should be investigated CACHING WhitePaper

<5,000 bad, <3,000 very bad; <7,000 threshold to removed /3GB (per Uttam Parui)

Note: Recent thinking (Greg Moss) is that Disk Queues for SQL Server must be

http://www.sql-server-performance.com/sql_server_performance_audit2.asphttp://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htmhttp://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm

http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556

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

http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556

Per Grumpy Old DBA: For “Lock Wait Time” it is recommended to look beyond the Avg value. Look for any peaks that are close to (or exceed) 60 sec. Though this counter counts how many total milliseconds SQL Server is waiting on locks during the last second, the counter actually records the end of locking event. So most probably the peaks represent one huge locking event. If those events exceed more than 60 seconds then they may have extended blocking. In such cases, thoroughly analyze blocking script output. Some applications are written for timing out after 60 seconds and that’s not acceptable response for those applications.

Per Grumpy Old DBA: The "Lock Waits/sec" 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 counter—it 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.

http://www.sql-server-performance.com/sql_server_performance_audit2.asp

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







Free 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.Total number of pages on all free lists.

(Page lookups/sec) / (Batch Requests/sec) < 100 Number 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. Number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.Number 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, it’s memory constraint.

This 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.



< a few hundred is desirable, in the thousands acceptable if other memory counters are OK (see Process object)>2500/s bad for modern servers; much less for older servers; avg/sustained <25% of HDD or <10% RAM; MUCH less for SQL Server 32-bit: 100MB-260MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)32-bit: 120MB-480MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)

Spikes<50 Ruling out Disk-Bound Problems

ReasonableDisk Latency is a great metric because it is independent of spindle count

Source: readme.txt sqlio v1.5 11/17/99

< a few hundred is desirable, in the thousands acceptable if other memory counters are OK

; <7,000 threshold to removed /3GB (per Uttam Parui)

<http://www.microsoft.com/technet/prodtechnol/exchange/Guides/TrblshtE2k3Perf/5bcdd349-dcc6-43eb-9dc3-54175f7061ad.mspx>

Note: Recent thinking (Greg Moss) is that Disk Queues for SQL Server must be zero

http://www.sql-server-performance.com/sql_server_performance_audit2.asphttp://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htmhttp://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm

http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556

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




http://www.microsoft.com/technet/prodtechnol/exchange/Guides/TrblshtE2k3Perf/5bcdd349-dcc6-43eb-9dc3-54175f7061ad.mspx

http://www.sql-server-performance.com/sql_server_performance_audit2.asp








Free 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.

Number 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. Number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.Number 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, it’s memory constraint.




<http://www.microsoft.com/technet/prodtechnol/exchange/Guides/TrblshtE2k3Perf/5bcdd349-dcc6-43eb-9dc3-54175f7061ad.mspx>

http://www.microsoft.com/technet/prodtechnol/exchange/Guides/TrblshtE2k3Perf/5bcdd349-dcc6-43eb-9dc3-54175f7061ad.mspx

Free 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.

Number 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.

Number 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, it’s memory constraint.


Performance Objects & Counters

Performance Counter JWM

Physical Disk % Idle Time 3°Physical Disk % Disk Time 3°Physical Disk Avg. Disk Bytes/Read 3° XPhysical Disk Avg. Disk Bytes/Transfer 3°Physical Disk Avg. Disk Bytes/Write 3° XPhysical Disk Avg. Disk Queue Length 3° XPhysical Disk Avg. Disk sec/Read 1° X XPhysical Disk Avg. Disk sec/Transfer 1°Physical Disk Avg. Disk sec/Write 1° X XPhysical Disk Disk Bytes/sec 2°Physical Disk Disk Read Bytes/sec 2° XPhysical Disk Disk Write Bytess/sec 2° XPhysical Disk Disk Reads/sec 2° X XPhysical Disk Disk Transfers/sec 2°Physical Disk Disk Writes/sec 3° X X

Note: The I/O Predeployment article recommends either Physical Disk or Logical Disk, depending on "the specific storage configuration that is being tested".Note: I recommend capturing BOTH Physical Disk & Logical Disk to help discriminate challenges related, e.g., to shared disks.

References

Troubleshooting Performance Problems in SQL Server 2005

Sunil Agarwal, Boris Baryshnikov, Tom Davidson, Keith Elmore, Denzil Ribeiro, Juergen ThomasPredeployment I/O Best Practices

SQL Server Best Practices ArticleWriter: Mike RuthruffContributors: Michael Thomassy, Prem MehraTechnical Reviewers: Robert Dorr, Stuart Ozer, Juergen Thomas, Lindsey Allen, Burzin Patel, Bill Emmert, Bruce Worthington, Sanjay Mishra

Performance Object(see Notes below regarding Logical Disk)

Troubleshooting Performance

Problems in SQL Server 2005

I/O Predeployment

Best Practices

Inside Microsoft SQL Server 2005: Query Tuning and Optimization, edited by Kalen Delaney, Chapter 1 authored by Sunil Agarwal, "A Performance Tuning Methodology", I/O Bottlenecks section, pp. 32-37, Microsoft Press, ISBN 0735621969http://www.microsoft.com/MSPress/books/8565.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx

http://www.microsoft.com/MSPress/books/8565.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx

X

XX X

X X

XX X

XX

Note: The I/O Predeployment article recommends either Physical Disk or Logical Disk, depending on "the specific storage configuration that is being tested".Note: I recommend capturing BOTH Physical Disk & Logical Disk to help discriminate challenges related, e.g., to shared disks.

Technical Reviewers: Robert Dorr, Stuart Ozer, Juergen Thomas, Lindsey Allen, Burzin Patel, Bill Emmert, Bruce Worthington, Sanjay Mishra

Inside SQL 2005: Query Tuning &

Optimization

Vital Signs (Shane Creamer)

, edited by Kalen Delaney, Chapter 1 authored by Sunil Agarwal, "A Performance Tuning Methodology", I/O Bottlenecks section, pp. 32-37, Microsoft Press, ISBN 0735621969

PFE Shane Creamer

There is no other workshop on the planet like it.

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 he’s rumored to be updating it soon to a formal SKU.Whether you’re 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.

Vital Signs is a 3-day Microsoft workshop authored & offered by

[email protected]

I strongly encourage anyone interested in performance to take this class.

mailto:[email protected]

It is already available for public consumption, and he’s rumored to be updating it soon to a formal SKU.Whether you’re new to PerfMon or want to take your skills from Padawan to Jedi Master, the Vital Signs workshop is for you.

PerfMon Counters Digest w Vital Signs Correlation v6

Documents

Transcript of PerfMon Counters Digest w Vital Signs Correlation v6