Session des Journées SQL Server 2014 - Benjamin Vesan
---
Revue et critique des « grandes vérités » proposées régulièrement sur les forums ou les blogs, et qui peuvent être plus destructives que bénéfiques sur des problèmes de performance.
4. #JSS2014
Présentation
Leader SGBD reconnu en France
www.capdata.fr
Conseil
Service
Formation
DBA à distance
Management d’infrastructures IT hétérogènes
www.osmozium.com
Support Management
Technical Management
Data Management
Production Management
#sqlhelp
http://blog.capdata.fr
http://www.youtube.com/user/CapdataTV/
Benjamin Vesan
bvesan@capdata-osmozium.com
@captain_BV
6. #JSS2014
• Appliquer une résolution empirique
• Suivre les conseils d’une source externe (blog, forum).
Fausse bonne idée ?
7. #JSS2014
• SQL Server, c’est au moins 7 versions, sur plus de vingt ans.
• Le moteur a considérablement évolué, certaines faiblesses et lacunes
d’anciennes versions n’existent plus, et les solutions historiques de résolution
des problèmes de performance peuvent ne plus être pertinentes.
Mythes et idées ayant la vie dure 1/4
8. #JSS2014
Beaucoup d’informations incorrectes sont suivies
• Articles anciens devenus obsolètes
• Confusion lorsque des experts ont des avis opposés (et conflictuels)
• Règle du Net: « Nombre d’apparitions fait loi »
Mythes et idées ayant la vie dure 2/4
9. #JSS2014
Les nouvelles fonctionnalités d’une version de SQL Server ont donné lieu à des
fantasmes, potentiellement devenues solutions universelles aux problèmes de
performances.
Exemples:
• ColumnStore Index
• Snapshot Isolation
Mythes et idées ayant la vie dure 3/4
10. #JSS2014
SQL Server n’est pas implémenté comme d’autres moteurs. Les préconisations
concernant d’autres moteurs peuvent ne pas être pertinentes pour SQL Server.
Exemples:
• Concurrence d’accès
• Escalade de verrous
• Gestion du parallélisme
• Fragmentation
• …
Mythes et idées ayant la vie dure 4/4
11. #JSS2014
• Ne pas analyser la cause exacte d’un problème, c’est risquer de passer à côté
de la cause racine, et de ne pas résoudre le problème.
• Appliquer une solution empirique, c’est risquer d’aggraver le problème.
Empirique VS Analytique
14. #JSS2014
• Ce ne sont pas des tables en mémoire
• Pas de Statistiques
• Pas adaptées à une grosse volumétrie
• Tables Hekaton à partir de 2014 (Enterprise Edition)
Cas concret : Variables Tables
16. #JSS2014
Fausse bonne idée:
• Max Degree Of Parallelism à 1
Attitude correcte:
• Comprendre les raisons du CXPACKET, et les requêtes en cause
• Utiliser les leviers Cost threshold for Parallelism et OPTION (MAXDOP)
• Regarder la contention CPU associée
Cas concret : CXPACKET
18. #JSS2014
Fausse bonne idée:
• Blâmer l’infrastructure réseau et ne rien faire en base !
Attitude correcte:
• Identifier le ou les traitements victimes de cette attente,
• Comprendre le fonctionnement du DataReader, et voir comment adapter le
traitement.
Cas concret : ASYNC_NETWORK_IO
20. #JSS2014
Fausse bonne idée:
• Suivre sans recul les recommandations du Missing Indexes.
Pourquoi ?
• Le MI ne sait pas ordonner la liste des colonnes
• Il ne tient pas compte de l’impact sur l’activité transactionnelle sur la table
• Il n’ira jamais aussi loin que la (rapide) analyse fonctionnelle de la requête.
Cas concret : Missing Indexes
22. #JSS2014
Fausse bonne idée:
• Faire l’amalgame entre requêtes lourdes/lentes et requêtes qui contribuent à
la charge sur l’instance.
• Se limiter à Activity Monitor pour le suivi de performances
Attitude correcte:
• Revenir aux tâches en attente, et en cours d’exécution.
Cas concret : Slow Queries
23. #JSS2014
• Méfiez-vous des conseils empiriques
• Préférez les approches scientifiques: Théorie, Tests, Validation
• Restez conscient de la portée d’une modification
– Niveau instance: tous les traitements
– Niveau objet: tous les traitements liés
– Niveau requête: concurrence à l’exécution
• Utilisez les outils de diagnostic intégrés à SQL Server: DMVs et DMF
Session de Christophe Laporte
Conclusion
« Small queries on one core, Big queries on multiple cores ».
IL NE FAUT PAS CHERCHER A FAIRE DISPARAITRE COMPLETEMENT CXPACKET !!!
Exemple simple de RBAR avec un gros SELECT lancé depuis Management Studio en local. Observation des attentes liées: ASYNC_NETWORK_IO.
Exemple avec un petit programme en C qui consomme les lignes les unes après les autres. Même programme lancé en consommant les lignes par lot, et l’attente disparaît.
On parlait des speakers, il y a une chose qui leur tient à cœur !