Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 :
Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette
requete comporte plusieurs jointures. Puis nous l'avons enregistrée en tant
que procédure stockée. Hors lorsque nous testons la procédure via l'analyseur
de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute
dans l'analyseur de requètes le requete elle même en déclarnt au préalable
les parametres, elle s'execute quasi immédiatement.
Pourquoi une procedure stockée est elle plus lente qu'un requete ?
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
Philippe T [MS]
Bonjour,
Une recompilation de la procédure et une mise à jour des statistiques est peut être nécessaire ?
---------------------------------------------------------------------- Philippe TROTIN - Microsoft Service France
"olivier" wrote in message news:
Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 : Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette requete comporte plusieurs jointures. Puis nous l'avons enregistrée en tant que procédure stockée. Hors lorsque nous testons la procédure via l'analyseur de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute dans l'analyseur de requètes le requete elle même en déclarnt au préalable les parametres, elle s'execute quasi immédiatement. Pourquoi une procedure stockée est elle plus lente qu'un requete ?
Bonjour,
Une recompilation de la procédure et une mise à jour des statistiques est
peut être nécessaire ?
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"olivier" <olivier@discussions.microsoft.com> wrote in message
news:E1EFBB77-B8E7-4460-B719-0A9387BC8264@microsoft.com...
Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 :
Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette
requete comporte plusieurs jointures. Puis nous l'avons enregistrée en
tant
que procédure stockée. Hors lorsque nous testons la procédure via
l'analyseur
de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute
dans l'analyseur de requètes le requete elle même en déclarnt au préalable
les parametres, elle s'execute quasi immédiatement.
Pourquoi une procedure stockée est elle plus lente qu'un requete ?
Une recompilation de la procédure et une mise à jour des statistiques est peut être nécessaire ?
---------------------------------------------------------------------- Philippe TROTIN - Microsoft Service France
"olivier" wrote in message news:
Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 : Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette requete comporte plusieurs jointures. Puis nous l'avons enregistrée en tant que procédure stockée. Hors lorsque nous testons la procédure via l'analyseur de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute dans l'analyseur de requètes le requete elle même en déclarnt au préalable les parametres, elle s'execute quasi immédiatement. Pourquoi une procedure stockée est elle plus lente qu'un requete ?
BVesan
Bonjour, Si la procédure comporte une unique requête et que l'instance de base de données n'est pas chargée, le problème réside dans une différence de plan d'accès. Le plan d'accès de la requête lancée seule est calculé à la volée, en tenant compte des valeurs des variables. Celui de la procédure stockée est a priori pré calculé à la compilation , donc sans que l'optimiseur ait connaissance de la valeur des paramètres.
Une solution consisterait donc à créer la procédure en utilisant l'option WITH RECOMPILE (recompilation avant chaque exécution).
Benjamin
Bonjour,
Si la procédure comporte une unique requête et que l'instance de base de
données n'est pas chargée, le problème réside dans une différence de plan
d'accès.
Le plan d'accès de la requête lancée seule est calculé à la volée, en
tenant compte des valeurs des variables.
Celui de la procédure stockée est a priori pré calculé à la compilation ,
donc sans que l'optimiseur ait connaissance de la valeur des paramètres.
Une solution consisterait donc à créer la procédure en utilisant l'option
WITH RECOMPILE (recompilation avant chaque exécution).
Bonjour, Si la procédure comporte une unique requête et que l'instance de base de données n'est pas chargée, le problème réside dans une différence de plan d'accès. Le plan d'accès de la requête lancée seule est calculé à la volée, en tenant compte des valeurs des variables. Celui de la procédure stockée est a priori pré calculé à la compilation , donc sans que l'optimiseur ait connaissance de la valeur des paramètres.
Une solution consisterait donc à créer la procédure en utilisant l'option WITH RECOMPILE (recompilation avant chaque exécution).
Benjamin
lionelp
Bonjour,
L'exécution de la requête et de la procédure stoqkée précédées de dbcc freeproccache et set statistics profile on permettront certainement: de comprendre qu'il y a des plans différents de vérifier que dans un cas comme dans l'autre les statistiques estimées et réalisées sont identiques sinon proches.
Il faut comprendre que : lors de l'exécution d'une requête paramétrée l'optimiseur utilise les statistiques généréles (entête de show_statistics) lors de l'exécution d'un procédure stockée, à la première compilation, il y a du "parameter sniffing", i.e. remplacement des paramètres par les valeurs, et dans ce cas l'optimiseur utilise les statistiques détaillées (histogram steps du show_statistics). La recompilation n'est pas systématique.
D'où des différences potentielles de temps d'exécution.
Cordialement, Lionelp
Cordialement, LionelP
"olivier" a écrit :
Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 : Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette requete comporte plusieurs jointures. Puis nous l'avons enregistrée en tant que procédure stockée. Hors lorsque nous testons la procédure via l'analyseur de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute dans l'analyseur de requètes le requete elle même en déclarnt au préalable les parametres, elle s'execute quasi immédiatement. Pourquoi une procedure stockée est elle plus lente qu'un requete ?
Bonjour,
L'exécution de la requête et de la procédure stoqkée précédées de dbcc
freeproccache et set statistics profile on permettront certainement:
de comprendre qu'il y a des plans différents
de vérifier que dans un cas comme dans l'autre les statistiques estimées et
réalisées sont identiques sinon proches.
Il faut comprendre que :
lors de l'exécution d'une requête paramétrée l'optimiseur utilise les
statistiques généréles (entête de show_statistics)
lors de l'exécution d'un procédure stockée, à la première compilation, il y
a du "parameter sniffing", i.e. remplacement des paramètres par les valeurs,
et dans ce cas l'optimiseur utilise les statistiques détaillées (histogram
steps du show_statistics). La recompilation n'est pas systématique.
D'où des différences potentielles de temps d'exécution.
Cordialement,
Lionelp
Cordialement,
LionelP
"olivier" a écrit :
Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 :
Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette
requete comporte plusieurs jointures. Puis nous l'avons enregistrée en tant
que procédure stockée. Hors lorsque nous testons la procédure via l'analyseur
de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute
dans l'analyseur de requètes le requete elle même en déclarnt au préalable
les parametres, elle s'execute quasi immédiatement.
Pourquoi une procedure stockée est elle plus lente qu'un requete ?
L'exécution de la requête et de la procédure stoqkée précédées de dbcc freeproccache et set statistics profile on permettront certainement: de comprendre qu'il y a des plans différents de vérifier que dans un cas comme dans l'autre les statistiques estimées et réalisées sont identiques sinon proches.
Il faut comprendre que : lors de l'exécution d'une requête paramétrée l'optimiseur utilise les statistiques généréles (entête de show_statistics) lors de l'exécution d'un procédure stockée, à la première compilation, il y a du "parameter sniffing", i.e. remplacement des paramètres par les valeurs, et dans ce cas l'optimiseur utilise les statistiques détaillées (histogram steps du show_statistics). La recompilation n'est pas systématique.
D'où des différences potentielles de temps d'exécution.
Cordialement, Lionelp
Cordialement, LionelP
"olivier" a écrit :
Nous sommes confronté à un curieux probleme sous SQL 2000 SP4 : Nous avons créé un requete à laquelle 3 parametres typé sont passés, cette requete comporte plusieurs jointures. Puis nous l'avons enregistrée en tant que procédure stockée. Hors lorsque nous testons la procédure via l'analyseur de requètes elle met 7 à 8 secondes à s'ecxécuter alors que si on execute dans l'analyseur de requètes le requete elle même en déclarnt au préalable les parametres, elle s'execute quasi immédiatement. Pourquoi une procedure stockée est elle plus lente qu'un requete ?
