probleme de performance sur execution de requete avec sp_executesq
2 réponses
Silvere
Nous avons un important problème de performance avec une requete un peu
complexe.
La requete s'execute en approximativement 7 seconde à travers Query Analyer
(ce qui serait OK pour nous), mais prends beaucoups plus de temps avec
ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés
augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres.
Si on remplace les paramètres directement dans la requête, elle prend 11
secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes
paramétrées) pour executer la requête depuis Query Analyser, la requête met
de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps
d'éxécution. Nous désirons utiliser des requêtes paramétré (conception,
maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index n'a
aucune suggestion d'optimisation).
Le plan d'éxécution de la requête est correcte.
Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation
de sp_executesql ?)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romelard Fabrice [MVP]
Bonjour,
L'usage de requette paramétrée dans ADO.NET est fortement déconseillée. En effet, vous évitez tous les bénéfices de la puissance de SQL Server par ce passage.
Il est fortement conseillé de passer par une procédure stockée qui sera optimisée lors de sa premiere exécution.
-- Cordialement.
Romelard Fabrice [MVP]
"Silvere" a écrit dans le message de news:
Nous avons un important problème de performance avec une requete un peu complexe. La requete s'execute en approximativement 7 seconde à travers Query Analyer (ce qui serait OK pour nous), mais prends beaucoups plus de temps avec ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres. Si on remplace les paramètres directement dans la requête, elle prend 11 secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes paramétrées) pour executer la requête depuis Query Analyser, la requête met de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps d'éxécution. Nous désirons utiliser des requêtes paramétré (conception, maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index n'a aucune suggestion d'optimisation). Le plan d'éxécution de la requête est correcte. Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation de sp_executesql ?)
Bonjour,
L'usage de requette paramétrée dans ADO.NET est fortement déconseillée.
En effet, vous évitez tous les bénéfices de la puissance de SQL Server par
ce passage.
Il est fortement conseillé de passer par une procédure stockée qui sera
optimisée lors de sa premiere exécution.
--
Cordialement.
Romelard Fabrice [MVP]
"Silvere" <Silvere@discussions.microsoft.com> a écrit dans le message de
news: B916B32D-242F-4EEA-B27B-87F90A09D34B@microsoft.com...
Nous avons un important problème de performance avec une requete un peu
complexe.
La requete s'execute en approximativement 7 seconde à travers Query
Analyer
(ce qui serait OK pour nous), mais prends beaucoups plus de temps avec
ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés
augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres.
Si on remplace les paramètres directement dans la requête, elle prend 11
secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes
paramétrées) pour executer la requête depuis Query Analyser, la requête
met
de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps
d'éxécution. Nous désirons utiliser des requêtes paramétré (conception,
maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index
n'a
aucune suggestion d'optimisation).
Le plan d'éxécution de la requête est correcte.
Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation
de sp_executesql ?)
L'usage de requette paramétrée dans ADO.NET est fortement déconseillée. En effet, vous évitez tous les bénéfices de la puissance de SQL Server par ce passage.
Il est fortement conseillé de passer par une procédure stockée qui sera optimisée lors de sa premiere exécution.
-- Cordialement.
Romelard Fabrice [MVP]
"Silvere" a écrit dans le message de news:
Nous avons un important problème de performance avec une requete un peu complexe. La requete s'execute en approximativement 7 seconde à travers Query Analyer (ce qui serait OK pour nous), mais prends beaucoups plus de temps avec ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres. Si on remplace les paramètres directement dans la requête, elle prend 11 secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes paramétrées) pour executer la requête depuis Query Analyser, la requête met de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps d'éxécution. Nous désirons utiliser des requêtes paramétré (conception, maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index n'a aucune suggestion d'optimisation). Le plan d'éxécution de la requête est correcte. Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation de sp_executesql ?)
Med Bouchenafa
ADO.NET genere effectivement un sp_executesql pour toute commande de type Text La première fois que ta commande est lancée, SQL compile un plan qu'il réutilise pour tous les appels suivants Il est fort possible que le plan initial est mauvais pour les appels suivants. Pour tester, vide ton cache et regarde s'il y a amelioration
Un autre truc que j'ai rencontré une fois est que j'ai remarqué que sp_executesql utilisait des NVARCHAR là où j'avais des VARCHAR Regarde si tu n'as pas quelque chose de similaire
-- Bien cordialement Med Bouchenafa
"Silvere" a écrit dans le message de news:
Nous avons un important problème de performance avec une requete un peu complexe. La requete s'execute en approximativement 7 seconde à travers Query Analyer (ce qui serait OK pour nous), mais prends beaucoups plus de temps avec ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres. Si on remplace les paramètres directement dans la requête, elle prend 11 secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes paramétrées) pour executer la requête depuis Query Analyser, la requête met de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps d'éxécution. Nous désirons utiliser des requêtes paramétré (conception, maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index n'a aucune suggestion d'optimisation). Le plan d'éxécution de la requête est correcte. Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation de sp_executesql ?)
ADO.NET genere effectivement un sp_executesql pour toute commande de type
Text
La première fois que ta commande est lancée, SQL compile un plan qu'il
réutilise pour tous les appels suivants
Il est fort possible que le plan initial est mauvais pour les appels
suivants.
Pour tester, vide ton cache et regarde s'il y a amelioration
Un autre truc que j'ai rencontré une fois est que j'ai remarqué que
sp_executesql utilisait des NVARCHAR là où j'avais des VARCHAR
Regarde si tu n'as pas quelque chose de similaire
--
Bien cordialement
Med Bouchenafa
"Silvere" <Silvere@discussions.microsoft.com> a écrit dans le message de
news: B916B32D-242F-4EEA-B27B-87F90A09D34B@microsoft.com...
Nous avons un important problème de performance avec une requete un peu
complexe.
La requete s'execute en approximativement 7 seconde à travers Query
Analyer
(ce qui serait OK pour nous), mais prends beaucoups plus de temps avec
ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés
augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres.
Si on remplace les paramètres directement dans la requête, elle prend 11
secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes
paramétrées) pour executer la requête depuis Query Analyser, la requête
met
de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps
d'éxécution. Nous désirons utiliser des requêtes paramétré (conception,
maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index
n'a
aucune suggestion d'optimisation).
Le plan d'éxécution de la requête est correcte.
Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation
de sp_executesql ?)
ADO.NET genere effectivement un sp_executesql pour toute commande de type Text La première fois que ta commande est lancée, SQL compile un plan qu'il réutilise pour tous les appels suivants Il est fort possible que le plan initial est mauvais pour les appels suivants. Pour tester, vide ton cache et regarde s'il y a amelioration
Un autre truc que j'ai rencontré une fois est que j'ai remarqué que sp_executesql utilisait des NVARCHAR là où j'avais des VARCHAR Regarde si tu n'as pas quelque chose de similaire
-- Bien cordialement Med Bouchenafa
"Silvere" a écrit dans le message de news:
Nous avons un important problème de performance avec une requete un peu complexe. La requete s'execute en approximativement 7 seconde à travers Query Analyer (ce qui serait OK pour nous), mais prends beaucoups plus de temps avec ADO.NET : timeout après 30 secondes. Idem pour 240 secondes aprés augmentation du paramètre timeout.
La requêtre ADO est paramétré, utilisant 4 paramètres. Si on remplace les paramètres directement dans la requête, elle prend 11 secondes avec ADO.NET.
Si on utilise sp_executesql (utilisé par ADO.NET pour les requêtes paramétrées) pour executer la requête depuis Query Analyser, la requête met de nouveaus beaucoups de temps pour s'executer (plus de 4 minutes).
La commande ADO.NET utilisée est ExecuteReader
Il semble que sp_executesql est responsable de l'accroissement du temps d'éxécution. Nous désirons utiliser des requêtes paramétré (conception, maintenance, ...).
Le problème ne semble pas venir de mauvais index (l'optimisateur d'index n'a aucune suggestion d'optimisation). Le plan d'éxécution de la requête est correcte. Nous n'avons toutefois pas de plan d'éxécution à travers sp_executesql
Est-il possible de résoudre le problème ou de le contourner (désactivation de sp_executesql ?)
