Discussion :

[loggti]

Bonjour à tous !

on me rapporte un message d'erreur sur un serveur SQL 2000 que je n'ai jamais rencontré jusqu'à maintenant :

Intra query parallelism caused your server command to deadlock.

est-ce quelque chose rencontré par certains d'entre vous ?
j'ai fait quelques recherches, mais à priori, les moyens de contournement demandent la modification au niveau du serveur en lui même, et pas uniquement sur la base, ça me gêne un peu.

Quelq'un aurait une idée ?

Merci d'avance.
Jo

[rudib]

Bonjour,

As-tu des processeurs en hyperthreading ?
Si tu ne veux pas modifier la configuration du "maximum degree of parralelism" du serveur, ce qui serait pourtant probablement la meilleure solution, tu peux changer seulement la requête qui te pose problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT ...
FROM...
...
OPTION (MAXDOP 1)

[loggti]

j'avoue que je suis un peu néophyte sur ces notions !

As-tu des processeurs en hyperthreading ? --> comment puis je le savoir ?

pour toi la meilleure solution consisterait à modifier la configuration du "maximum degree of parralelism" du serveur ? On peut le faire par procédure Stockée ?

ce qui me paraît étonnant, c'est que de mon côté, sur mon portable, je n'ai jamais rencontré de soucis, et que le client a ce message sur son serveur !


Cordialement,

Jo

[rudib]

Bien sûr que tu n'as pas la même réaction sur ton protable que sur son serveur : le parrallélisme est dépendant du nombre de processeurs...

Pour tester les CPU et savoir s'ils sont en hyperthreading, essaie cet outil :
http://www.cpuid.com/cpuz.php

Sinon, pour savoir si tu dois désactiver le parallélisme, il faut savoit le nombre de processeurs physiques et le nombre de processeurs logiques

[loggti]

merci beaucoup pour tes réponses, mais j'ai bien l'impression que ça dépasse mes compétences ... Oups !!

Je vais d'abord essayer l'ordre SQL que tu m'as donné Option (maxdop 1) pour un dépannage rapide !
Dans un second temps, je passerai du temps à essayer de réécrire la requête, parce que j'ai l'impression que je vais me noyer dans ces notions de parallélisme et d'hyperthreading !

En fait le problème vient aussi du fait que le serveur en question n'est ne m'est pas dédié, je ne voudrais pas faire des modifications qui pourraient avoir des conséquences non maitrisées dans d'autres applis !

[SQLpro]

Est-ce que cette requête utilise des fonctions (UDF) qui font appel aux mêmes tables ?

A +

[loggti]

non pas d'UDF.
en fait la requête portait sur une vue, laquelle vue était composée de deux requêtes reliées par un UNION.

Il y avait aussi pas mal de CASE, qui je crois sont assez gourmands !

J'ai réécrit un peu la vue, notamment pour supprimer les CASE de la requête. A priori c'est mieux, le message d'erreur a disparu pour le moment.

Si jamais il apparaît de nouveau, je tenterai l'option OPTION (MAXDOP 1)

Petite question, positionner des index sur les tables utilisées par la vue a t-il un intérêt ou bien faut il mieux envisager de créer des index sur la vue ?

Je crois que positionner des index sur une vue comprenant un UNION est impossible d'ailleurs !

[SQLpro]

Petite question, positionner des index sur les tables utilisées par la vue a t-il un intérêt ou bien faut il mieux envisager de créer des index sur la vue ?

C'est plus qu'essentiel : c'est indispensable !

A +