J'ai essayé la technique décrite dans cet article (notifications SQL Server) il y a pas mal d'années (fin 2006) sous SQL Server 2005.
L'environnement en question nous a permis de voir comment l'outil se comporte sous la charge (données qui changent très souvent, nombre d'applications clientes qui est rapidement passé de 2 à une petite dizaine...).
---
Nous avons été confrontés à un certains nombre de problèmes :
- une fois que l'événement
OnChange est levé, il est nécessaire de se réabonner. Le problème, c'est que si l'abonnement échoue pour une raison ou une autre (ex.: base surchargée) et qu'on ne le détecte pas correctement, alors on perd toute notification, plus rien n'est mis à jour et on ne s'en rend pas forcément compte tout de suite
-
plus embêtant : dans certains cas (je n'ai pas pu vérifier mais je pense que ça arrive quand on perd la communication client-serveur ou quand le client crash, et donc on n'a pas pu appeler à la méthode
SqlDependency.Stop() correctement), on se retrouve avec des transactions en suspens, ce qui n'est pas bon du tout. Ça a posé tout un tas de problèmes au niveau de la maintenance de la base (backups qui échouent, fichiers de log transactionnels extrêmement volumineux...)
Vu les problèmes recontrés, nous avons préféré faire machine arrière et trouver d'autres solutions (même un simple pooling de base, ça posait moins de problèmes !)
---
J'avais bien pensé à écrire un article dessus à l'époque (vers 2007), mais j'ai préféré m'abstenir.
À mon sens, cet outil n'est pas à mettre entre toutes les mains :
- il est très facile de se retrouver avec des cas à problèmes (mécanisme de notification qui s'arrête subitement, transactions qui restent en suspens suite à un dysfonctionnement logiciel...)
- si on est capable d'implémenter les notifications correctement, alors on est tout aussi capable de trouver d'autres solutions beaucoup plus sures (ex: notifications gérées au niveau du logiciel et non pas par la base elle-même)
Ce qu'il faut retenir : il ne faut pas multiplier les notifications SQL à outrance, car au-delà d'une certaine charge ça devient vite dangereux. Votre DBA vous dira merci.
1 |
0 |