5. #JSS2014
Faire un choix !
• 200 DMVs et DMFs …
– 166 vues
– 34 fonctions
• 449 compteurs de performance (sans compter les
instances)
– Répartis en 33 groupes
– Et cela ne concerne que le SGBD …
• A raison de 5 secondes par élément on obtiendrait
– Une session d’une heure …
– Un bon mal de tête
8. #JSS2014
Perfmon - CPU
• User Mode and Privileged Mode
– Processor (_Total) % Processor Time
– Processor (_Total) % Privileged Time
– Process (sqlsrvr)% Processor Time
– Process (sqlsrvr)% Privileged Time
• Eventuellement :
– SystemContext Switches /sec
– SystemProcessor Queue Length
• VM Processor(_Total)
– Effective VM Speed in MHz
– Host processor speed in MHz
9. #JSS2014
Perfmon – Bases de données
• SQL Server:Databases
– Percent Log Used
– Log Flush Wait Time
– Log Flush Waits/Sec
– Log Growths
– Log Shrinks
16. #JSS2014
Perfmon – Buffer Manager
• Memory
– Available MBytes
• SQL Server:Memory
– Memory Grants Pending
• SQL Server:Buffer Manager
– Page Life Expectancy
• 64GB BP & 300 secondes => 218.5MB/s !!!
• PLE threshold : ((MAXBP(MB)/1024)/4)*300 ) => 4800 secs !
– Checkpoint Pages/sec
– Free Pages
– Free List Stalls/sec
– Lazy Writes/sec
– Page Reads/sec
– Page Writes/sec
• VM Memory
– Memory Active in MB
– Memory Ballooned in MB
17. #JSS2014
Perfmon - Disque
• Logical Disk
– Avg Disk sec/Read
– Avg Disk sec/Write
– % Idle Time
– Avg Disk Bytes/Read
– Avg Disk Bytes/Write
– Disk Reads/sec (Disk Read Byte/sec)
– Disk Writes/sec (Disk Write Byte/sec)
20. #JSS2014
DMV & Catalog View
• La session porte sur les DMVs, pas le catalog view !
• Vous devez le maitriser, en particulier l’object catalog view
• Donc pour la suite vous devez maitriser sys.databases,
sys.master_files, sys.database_files, sys.tables, sys.indexes,
sys.columns, sys.stats , sys.partitions, sys.procedures,
sys.allocation_units, etc …
• Les DMVs et DMFs sont préfixées par sys.dm_*
On parlait des speakers, il y a une chose qui leur tient à cœur !
CPU READY : https://www.sqlskills.com/blogs/jonathan/cpu-ready-time-in-vmware-and-how-to-interpret-its-real-meaning/
Compilations : 10% des batch requests
Recompilations : 10% des compilations/ sec
Full scan : max 1/1000 du nombre de index searches
Forwarded records : 10% du nombre de batch requests
Pages split : 20% batch requests
http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx
The old recommendation was that PLE should have a minimum of about 300 seconds. This was from the days when SQL's BP was around 4GB or so. This therefore meant that for a read-mostly activity such as a report a PLE of 300 meant that the SAN was reading 4GB over 5 minutes, which calculates to about 3.4MB/s. These days we have BP's around the 64GB and above. So our 300 second threshold now means that the SAN would be reading about 218.5MB/s, which is a fair amount and likely to cause comment!
So what's a "good" PLE for a read-mostly operation like a report? Here's a handy formula I use to get a decent estimate:
PLE threshold = ((MAXBP(MB)/1024)/4)*300