Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQL Server : L’effet Domino ou comment une simple lecture de données plante un serveur de bases de données

Pas facile de se rendre compte qu'un simple SELECT peu avoir des conséquences néfastes sur un serveur de base de données. Voici un petit descriptif de ce qui aurait pu vous arriver et pourrai peut être vous arriver !

Un SELECT nécessite, pour s'exécuter correctement, que les données nécessaires à son traitement soient préalablement chargées en mémoire. Certaines opérations peuvent se faire de manière séquentielle et ainsi permettre de traiter une première partie de données, puis les suivantes. D'autres plus gourmande nécessiteront la totalité des données, c'est le cas par exemple de tris ou de générations de tables de hachage. Dans ces cas le serveur qui n'a pas assez de mémoire à disposition va alors utiliser tempdb. Tempdb est une base de données commune à l'instance toute requête dans toute base de données peu être amenée à utiliser celle-ci en cas de besoin.

Toute écriture dans toute base de données va être journalisée, ce qui passe systématiquement par l'écriture dans le journal de transaction de cette base de données, ces écritures sont séquentielles et synchrones. Tempdb n'échappe pas à cette règle.

C'est là que va se produire un double problème, votre serveur manque de mémoire et va forcer l'écriture de données présentes dans le cache et modifiées. Votre requête en lecture vient de « purger » le cache et les nouvelles arrivantes se trouvent à court de cache et en attente de nouvelles données venant du disque. De plus comme SQL Server ne dispose pas d'assez de ressources mémoire il utilise tempdb et écrit dans le journal de transactions. Si par le plus grand des hasards les journaux de transaction de toutes les bases de données sont sur le même volume et bien vous bloquez les écritures de toutes les bases de données des serveurs. Les lectures, elles, eh bien sont bloquées par le manque de mémoire et l'obligation de les lire sur le disque.

Et si les logs et données sont sur les même disques, eh bien les lectures bloquent les écritures et inversement et on mal. Rassurez vous ce problème n'est que temporaire, mais illustre bien quelques point importants :

  • Pas de grosses requêtes manuelles en production (SELECT sans * /TOP & WHERE obligatoire)
  • Séparez les journaux de transaction et les données
  • Séparez Tempdb des autres bases de données
  • Dimensionnez la mémoire du serveur pour servir les données source de votre plus grosse requête (si celle-ci est relativement fréquente).
  • En cas de grandes concurrences entre écritures et lectures, pensez à séparez ces derniers dans des instances différente ou passez par un système type resource gouvernor dans SQL Server 2008 (si cela est possible bien sûr).

C'est l'effet domino, une requête en lecture sur une base X peut bloquer une écriture ou lecture sur une base Y. On recherche alors le bien de contention, qui dans mon exemple est le système disque. Bien d'autres exemple existe mais celui-ci reste intéressant et assez fréquent !

Bonnes requêtes…

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié mardi 12 mai 2009 20:06 par christian

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Créer un périphérique Windows To Go 10 ! par Blog de Jérémy Jeanson le 11-21-2014, 04:54

- RDV à Genève le 12 décembre pour l’évènement “SharePoint–Office 365 : des pratiques pour une meilleure productivité !” par Le blog de Patrick [MVP Office 365] le 11-19-2014, 10:40

- [IIS] Erreurs web personnalisées par Blog de Jérémy Jeanson le 11-19-2014, 00:00

- BDD/TDD + Javascript par Fathi Bellahcene le 11-16-2014, 16:57

- Sécuriser sans stocker de mots de passe par Blog de Jérémy Jeanson le 11-15-2014, 08:58

- Où télécharger la preview de Visual Studio 2015 ? par Blog de Jérémy Jeanson le 11-13-2014, 21:33

- Les cartes sont partout ! par Le blog de Patrick [MVP Office 365] le 11-13-2014, 17:26

- [ #Office365 ] Courrier basse priorité ! par Le blog de Patrick [MVP Office 365] le 11-12-2014, 08:56

- [Oracle] Fichier oranfsodm12.dll absent du package client par Blog de Jérémy Jeanson le 11-10-2014, 20:44

- [ #Office365 ] Le chapitre 1 des Groupes est écrit, et alors ? par Le blog de Patrick [MVP Office 365] le 11-10-2014, 20:23