Discussion :

[Batou69]

Bonjour,

J'ai un souci avec un de nos serveurs en production. Il est actuellement en version 11.0.3000.

Nous avons beaucoup de soucis de deadlock sur ce serveur et lors de mes investigations, j'ai active une trace des exceptions. Et j'ai pu constater que le serveur lève beaucoup de 'syntaxe incorrecte vers le mot clef 'UPDATE'.

Nous ne travaillons que en procédure stockées et quelques triggers.
J'ai fait un filtre sur une des connexions qui posait ces problèmes. J'ai donc pu afficher les statements qui sont juste avant et juste après. Mais les deux procédures sont exécutées correctement. Je ne sais pas si j'ai bien affiché tous les évènements.

Ci joint la copie d'écran de la trace...



Comment faire pour trouver d’où vient l'erreur ???

Merci de votre aide !

[rudib]

ajoute les événements SP:StmtStarting et SP:StmtCompleted pour isoler l'instruction où se produit l'exception

[Batou69]

Merci pour votre réponse,

j'ai ajouté les classes que vous m'avez indiqué mais il me semble que mes procédures ne soient pas en cause...

peut être une requete adhoc qui viendrait se faufiler entre ??

[Edit]
non j'ai ajouté les classes :

• SQL : BatchStarting
• SQL : BatchCompleted
• SQL : StmtStarting
• SQL : StmtCompleted

Et pas de requêtes supplémentaires....
[/Edit]

[rudib]

Regarde si c'est le même SPID. Tu as aussi la colonne ClientProcessID qui te donne l'identifiant du processus client pour vérifier qu'il s'agit bien de la même application cliente.

[darkelend]

Tu peux valider la majorité de tes procédures stockées avec cet outil (évites de le tester en prod, utilises plutôt un environnement de test).
Si tu mets hors de cause tes procédures stockées, comme tu le dis dans ton premier message, regardes du coté des triggers.

[Batou69]

Regarde si c'est le même SPID. Tu as aussi la colonne ClientProcessID qui te donne l'identifiant du processus client pour vérifier qu'il s'agit bien de la même application cliente.

Oui c'est bien le même SPID (je filtre dessus en fait) et c'est aussi toujours le même ClientProcessId...

Est il possible de savoir si c'est un trigger qui provoque ces erreurs et si oui comment et lequel ??

[Batou69]

Tu peux valider la majorité de tes procédures stockées avec cet outil (évites de le tester en prod, utilises plutôt un environnement de test).
Si tu mets hors de cause tes procédures stockées, comme tu le dis dans ton premier message, regardes du coté des triggers.

Ok merci je vais regarder la validation des PS avec cet outil... mais sur un serveur de test. bien sûr !!

[rudib]

peut-être y a-t-il dans tes procédures PontClient_Update... une instruction juste avant l'UPDATE qui comporte une erreur. Tu peux poster le code s'il n'y a rien de confidentiel.

[Batou69]

peut-être y a-t-il dans tes procédures PontClient_Update... une instruction juste avant l'UPDATE qui comporte une erreur. Tu peux poster le code s'il n'y a rien de confidentiel.

Pas de problème : voici deux des procédures qui posent problème (il semble y en avoir plein d'autres)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
CREATE PROCEDURE [dbo].[PontClient_UpdateStatusMorTrans]
AS
	UPDATE
		[dbo].[MOR_TRANS]
	SET
		STATUS = 2,
		DATE_TRAITEMENT = GETDATE()
	FROM
		[TracePrep].[UP] UP
	JOIN
		[TracePrep].[UP_DOCUMENT] UPD
	ON
		UPD.NO_UP = UP.NO_UP
	WHERE
		UP.CODE_UP = ID_CARTON
		AND UPD.NOM_FICHIER = FICHIER_ETIQUETTE
		AND STATUS = 1
GO

et la deuxième :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
CREATE PROCEDURE [dbo].[PontClient_UpdateStatusRestantMorTrans]
AS
	UPDATE
		[dbo].[MOR_TRANS]
	SET
		STATUS = 2,
		DATE_TRAITEMENT = GETDATE(),
		CODE_ERREUR = EPC.NO_ERREUR,
		MESSAGE_ERREUR = EPC.LIBELLE
	FROM
		[dbo].[ERREUR_PONT_CLIENT] EPC
	WHERE
		STATUS = 1
		AND EPC.CODE_ERREUR = 'INCONNU'
		AND DATE_CREATION < DATEADD( SECOND, -60, GETDATE() ) 
GO

Après vérification, il n'y a pas de trigger sur la table dbo.MOR_TRANS
Donc je suis sec...

J'ai pas encore passé l'outil de validation cependant....

[rudib]

Bon, ça a l'air pas mal, des UPDATE tout simples. S'il d'agissait de triggers, tu les verrais dans les SP:StmtStarting et SP:StmtCompleted ...

Il manque peut-être des infos ici. Peux-tu ajouter les événements :
RPC:Starting
RPC:Completed

et dans T-SQL:
SQL:StmtStarting
SQL:StmtCompleted

[Batou69]

Il manque peut-être des infos ici. Peux-tu ajouter les événements :
RPC:Starting
RPC:Completed

Ok c'est fait dans le screen shot suivant

et dans T-SQL:
SQL:StmtStarting
SQL:StmtCompleted

Ceux la ils y sont déja....

J'ai une remarque plus générale : je sais que nos appels de procédure stoquées ne sont pas parfiatement conformes aux best practices de Microsoft. (vous le verrez dans l'appel de RPC). J'ai l'impression que mon erreur est liée à cela aussi. Tous nos appels provoquent des cachemiss (deux en général) mais sans que je puisse expliquer pourquoi non plus. Ce point ne vous parait il lié à mon problème actuel ?

[rudib]

C'est bien possible. Votre appel RPC fait un sp_cursoropen, et un des messages qui vous est renvoyé est qu'il ne peut pas le passer en curseur et qu'il exécute directement.

Ça peut s'expliquer : sp_cursoropen essaie de créer un curseur sur une prcédure d'UPDATE qui ne retourne pas de données, donc pas possible de créer un curseur. http://technet.microsoft.com/fr-fr/l...ql.100%29.aspx

Comment se fait-il que vous fassiez un sp_cursoropen ? Qu'est-ce que vous utilisez en bibliothèque client ? Avec quels paramètres ?

[Batou69]

Comment se fait-il que vous fassiez un sp_cursoropen ? Qu'est-ce que vous utilisez en bibliothèque client ? Avec quels paramètres ?

Alors c'est un problème de très longue date avec nos applications car nous utilisons depuis des lustres la même DLL standard tout le temps.
Nous développons en Qt 4 avec une connexion ODBC. La chaine de connexion utilisée est du style :

Code :

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

DRIVER={SQL Server native client 10.0};server=<ip add>;database=<mabase>;Uid=<username>;Pwd=<passw>;App=<appplicationname>

Cependant, lorsque j'ai commencé a regarder ces problèmes, j'ai noté que le driver ODBC réagit différemment selon le texte que l'on utilise pour l'appel de la SP. (selon que l'on utilise exec, execute ou rien du tout !!)

Nous ne préparons pas les requetes (j'ai cru comprendre que notre problème vient en partie de là). A la place on execute le statement :

Code :

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

execute <NomSP> <params>

Ce qui est étonnant c'est qu'il ne me semble pas avoir ce genre de problèmes pour d'autres applications sur le même site avec la même méthode d'appel....

[SQLpro]

À mon avis, vous utilisez un objet de code côté client qui est fait pour de la lecture alors que vous lancez des procédures.
Certains langage client assez bas de gamme n'offre pas de différenciation entre un objet de lecture et une mise à jour, obligeant le serveur SQL à récupérer systématiquement dans un curseur le résultat de la commande... qui ne vient jamais dans une mise à jour !

Revoyez votre code client. Remplacez si possible votre objet client, par un autre plus adéquat. Sinon, changez de langage !

A +

[Batou69]

À mon avis, vous utilisez un objet de code côté client qui est fait pour de la lecture alors que vous lancez des procédures.
Certains langage client assez bas de gamme n'offre pas de différenciation entre un objet de lecture et une mise à jour, obligeant le serveur SQL à récupérer systématiquement dans un curseur le résultat de la commande... qui ne vient jamais dans une mise à jour !

Revoyez votre code client. Remplacez si possible votre objet client, par un autre plus adéquat. Sinon, changez de langage !
A +

Ok merci beaucoup, je vais regarder pour changer notre façon d'invoquer les procédures.