Bonjour,
J'ai une requête du type select * sur une table, qui s'execute sur une
configuraion bipro. Si le laisse le parametrage par défaut (execution sur 2
proc) elle me prend deux fois plus de temps que si je la force à s'éxécuter
sur un processeur (Number of processor to use for parallel execution plan)
Une idée ?
Cordialement.
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
Med Bouchenafa
Une requete multi processeurs a un cout supplementaire qui peut expliquer cette difference. Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que la requete fait plus de 5 secondes Cela est parametrable par l'option "cost threshold for parallelism" Faut voir si cette option n'a pas ete touchee Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est pourquoi le hint MAXDOP existe
-- Bien cordialement Med Bouchenafa
"nono" wrote in message news:
Bonjour, J'ai une requête du type select * sur une table, qui s'execute sur une configuraion bipro. Si le laisse le parametrage par défaut (execution sur 2 proc) elle me prend deux fois plus de temps que si je la force à s'éxécuter sur un processeur (Number of processor to use for parallel execution plan) Une idée ? Cordialement.
Une requete multi processeurs a un cout supplementaire qui peut expliquer
cette difference.
Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que
la requete fait plus de 5 secondes
Cela est parametrable par l'option "cost threshold for parallelism"
Faut voir si cette option n'a pas ete touchee
Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est
pourquoi le hint MAXDOP existe
--
Bien cordialement
Med Bouchenafa
"nono" <nono@discussions.microsoft.com> wrote in message
news:7EAE2D34-18BC-4FC0-A024-06743218FA47@microsoft.com...
Bonjour,
J'ai une requête du type select * sur une table, qui s'execute sur une
configuraion bipro. Si le laisse le parametrage par défaut (execution sur
2
proc) elle me prend deux fois plus de temps que si je la force à
s'éxécuter
sur un processeur (Number of processor to use for parallel execution
plan)
Une idée ?
Cordialement.
Une requete multi processeurs a un cout supplementaire qui peut expliquer cette difference. Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que la requete fait plus de 5 secondes Cela est parametrable par l'option "cost threshold for parallelism" Faut voir si cette option n'a pas ete touchee Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est pourquoi le hint MAXDOP existe
-- Bien cordialement Med Bouchenafa
"nono" wrote in message news:
Bonjour, J'ai une requête du type select * sur une table, qui s'execute sur une configuraion bipro. Si le laisse le parametrage par défaut (execution sur 2 proc) elle me prend deux fois plus de temps que si je la force à s'éxécuter sur un processeur (Number of processor to use for parallel execution plan) Une idée ? Cordialement.
GNocent
Vérifies également que tes statistiques sur cette table sont à jour (cf. update statistics) car cela peut également influer sur les choix de l'optimizer ...
Guillaume.
"Med Bouchenafa" a écrit :
Une requete multi processeurs a un cout supplementaire qui peut expliquer cette difference. Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que la requete fait plus de 5 secondes Cela est parametrable par l'option "cost threshold for parallelism" Faut voir si cette option n'a pas ete touchee Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est pourquoi le hint MAXDOP existe
-- Bien cordialement Med Bouchenafa
"nono" wrote in message news: > Bonjour, > J'ai une requête du type select * sur une table, qui s'execute sur une > configuraion bipro. Si le laisse le parametrage par défaut (execution sur > 2 > proc) elle me prend deux fois plus de temps que si je la force à > s'éxécuter > sur un processeur (Number of processor to use for parallel execution > plan) > Une idée ? > Cordialement.
Vérifies également que tes statistiques sur cette table sont à jour (cf.
update statistics) car cela peut également influer sur les choix de
l'optimizer ...
Guillaume.
"Med Bouchenafa" a écrit :
Une requete multi processeurs a un cout supplementaire qui peut expliquer
cette difference.
Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que
la requete fait plus de 5 secondes
Cela est parametrable par l'option "cost threshold for parallelism"
Faut voir si cette option n'a pas ete touchee
Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est
pourquoi le hint MAXDOP existe
--
Bien cordialement
Med Bouchenafa
"nono" <nono@discussions.microsoft.com> wrote in message
news:7EAE2D34-18BC-4FC0-A024-06743218FA47@microsoft.com...
> Bonjour,
> J'ai une requête du type select * sur une table, qui s'execute sur une
> configuraion bipro. Si le laisse le parametrage par défaut (execution sur
> 2
> proc) elle me prend deux fois plus de temps que si je la force à
> s'éxécuter
> sur un processeur (Number of processor to use for parallel execution
> plan)
> Une idée ?
> Cordialement.
Vérifies également que tes statistiques sur cette table sont à jour (cf. update statistics) car cela peut également influer sur les choix de l'optimizer ...
Guillaume.
"Med Bouchenafa" a écrit :
Une requete multi processeurs a un cout supplementaire qui peut expliquer cette difference. Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que la requete fait plus de 5 secondes Cela est parametrable par l'option "cost threshold for parallelism" Faut voir si cette option n'a pas ete touchee Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est pourquoi le hint MAXDOP existe
-- Bien cordialement Med Bouchenafa
"nono" wrote in message news: > Bonjour, > J'ai une requête du type select * sur une table, qui s'execute sur une > configuraion bipro. Si le laisse le parametrage par défaut (execution sur > 2 > proc) elle me prend deux fois plus de temps que si je la force à > s'éxécuter > sur un processeur (Number of processor to use for parallel execution > plan) > Une idée ? > Cordialement.
Fred BROUARD
Pour compléter la réponse de Med, lorsqu'une requête est couteuse ses processus peuvent être déchargés et chargés plusieurs fois, induisant un temps de recalcul du contexte. Ceci peut être évité en passant en mode fibre qui évite le changement de contexte. Cepandant cette manip est rarement gagnante en bi pro.
A +
Med Bouchenafa a écrit:
Une requete multi processeurs a un cout supplementaire qui peut expliquer cette difference. Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que la requete fait plus de 5 secondes Cela est parametrable par l'option "cost threshold for parallelism" Faut voir si cette option n'a pas ete touchee Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est pourquoi le hint MAXDOP existe
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Pour compléter la réponse de Med, lorsqu'une requête est couteuse ses processus
peuvent être déchargés et chargés plusieurs fois, induisant un temps de recalcul
du contexte. Ceci peut être évité en passant en mode fibre qui évite le
changement de contexte.
Cepandant cette manip est rarement gagnante en bi pro.
A +
Med Bouchenafa a écrit:
Une requete multi processeurs a un cout supplementaire qui peut expliquer
cette difference.
Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que
la requete fait plus de 5 secondes
Cela est parametrable par l'option "cost threshold for parallelism"
Faut voir si cette option n'a pas ete touchee
Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est
pourquoi le hint MAXDOP existe
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Pour compléter la réponse de Med, lorsqu'une requête est couteuse ses processus peuvent être déchargés et chargés plusieurs fois, induisant un temps de recalcul du contexte. Ceci peut être évité en passant en mode fibre qui évite le changement de contexte. Cepandant cette manip est rarement gagnante en bi pro.
A +
Med Bouchenafa a écrit:
Une requete multi processeurs a un cout supplementaire qui peut expliquer cette difference. Par defaut, SQL Server decide d'utiliser le parallelisme lorqu'il juge que la requete fait plus de 5 secondes Cela est parametrable par l'option "cost threshold for parallelism" Faut voir si cette option n'a pas ete touchee Des fois, l'optimiseur est impuissant a bien evaluer la requete et c'est pourquoi le hint MAXDOP existe
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
