Session des Journées SQL Server 2014 - Christophe Laporte
---
DBA : Oui, ici le service DBA. Que se passe-t-il ?
Utilisateur : Je ne sais pas ce qu’il se passe, on est complétement bloqué sur l’application …
DBA : OK, on cherche la cause du problème …
Scène banale du métier de DBA. Mais par où commencer ? Les outils de diagnostics sont multiples, entre ceux fournis en standard avec SQL Server et les outils tiers, difficile de faire un choix.
Commençons donc par la base : quelle méthodologie pour un diagnostic et une résolution d’incident efficace ?
Les compteurs de performance et les DMVs font partie des outils standard. Mais difficile de s’y retrouver.
Durant cette session je vous propose de lister et commenter mes compteurs de performance favoris et les DMVs les plus utiles afin de diagnostiquer un problème dans SQL Server.
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