utilisation du merge

Marco a écrit :

bonjour a tous,

j'ai une ptite question .

j'ai un select
from table a
inner join table b

des que je met inner merge join ala place de inner join(normalment cela doit
etre + rapide)
au contraire je perd 10 20s en moyenne.
est ce du a la volumetrie des donnees ou pour une autre raison?

Quel est l'intérêt de demander à un chauffeur de taxi de passer par
Marseille pour aller de Lille à Paris ???

C'est ce que vous êtes en train de faire en imposant à SQL Server une
façon de travailler qui va lui interdire toute optimisation de la jointure !

A +

Merci de votre aide

--
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 ***********************

"SQLpro [MVP]" a écrit :

Marco a écrit :
> bonjour a tous,
>
> j'ai une ptite question .
>
> j'ai un select
> from table a
> inner join table b
>
> des que je met inner merge join ala place de inner join(normalment cela doit
> etre + rapide)
> au contraire je perd 10 20s en moyenne.
> est ce du a la volumetrie des donnees ou pour une autre raison?

Quel est l'intérêt de demander à un chauffeur de taxi de passer par
Marseille pour aller de Lille à Paris ???

C'est ce que vous êtes en train de faire en imposant à SQL Server une
façon de travailler qui va lui interdire toute optimisation de la jointure !

a ce moment la pourquoi permettre a l'utilsiateur de specifier une option si
la meilleure
solution est de le laisser tout gerer tout seul.


je vous dis cela car J'ai 2 exemples qui sont en totale contradiction
select

> from table a
> inner MERGE join table b

Dans un premier cas l'1 est plus rapide et l'autre cas c l'inverse.
Les tables sont differentes mais les champs de jointure sont strictement les
memes(de type int).

quel pourait etre la raison?(cas dans ma situation j'ai pu optimiser le
temps de traitement dans 1 seul cas sur les 2) la typologie des requetes
etant strictement les memes.

Merci pour votre aide

A +

>
> Merci de votre aide

--
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 ***********************

"SQLpro [MVP]" a écrit :

Marco a écrit :
> bonjour a tous,
>
> j'ai une ptite question .
>
> j'ai un select
> from table a
> inner join table b
>
> des que je met inner merge join ala place de inner join(normalment cela doit
> etre + rapide)
> au contraire je perd 10 20s en moyenne.
> est ce du a la volumetrie des donnees ou pour une autre raison?

Quel est l'intérêt de demander à un chauffeur de taxi de passer par
Marseille pour aller de Lille à Paris ???

C'est ce que vous êtes en train de faire en imposant à SQL Server une
façon de travailler qui va lui interdire toute optimisation de la jointure !

j'ai oublie

j'ai fais une jointure sur deux tables lorsque j'utilise le inner join
standard
j'ai des doublons et le resultat affiche un nombres superieur
d'enregistrement par rapport a ma table B,ce qui est impossible
en faisant le inner merge join le pb est regle.

La methode hash join emplye par defaut doit provoque cette erreur de doublon
que le merge join corrige .

C la raison pour laquelle je tente "d'optimiser ems resultats en mettant le
inner merge join

Et encore Merci:)

A +

>
> Merci de votre aide


--
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 ***********************

Pourquoi un MERGE JOIN serait-il normalement plus rapide qu'un LOOP JOIN?
Sur quoi tu te bases pour une telle affirmation?
Normalement cela depend de la volmétrie relative des deux tables

--
Bien Cordialement
Med Bouchenafa


"Marco" wrote:

bonjour a tous,

j'ai une ptite question .

j'ai un select
from table a
inner join table b

des que je met inner merge join ala place de inner join(normalment cela doit
etre + rapide)
au contraire je perd 10 20s en moyenne.
est ce du a la volumetrie des donnees ou pour une autre raison?

Merci de votre aide

Marco a écrit :

"SQLpro [MVP]" a écrit :

Marco a écrit :

bonjour a tous,

j'ai une ptite question .

j'ai un select
from table a
inner join table b

des que je met inner merge join ala place de inner join(normalment cela doit
etre + rapide)
au contraire je perd 10 20s en moyenne.
est ce du a la volumetrie des donnees ou pour une autre raison?

Quel est l'intérêt de demander à un chauffeur de taxi de passer par
Marseille pour aller de Lille à Paris ???

C'est ce que vous êtes en train de faire en imposant à SQL Server une
façon de travailler qui va lui interdire toute optimisation de la jointure !

a ce moment la pourquoi permettre a l'utilsiateur de specifier une option si
la meilleure
solution est de le laisser tout gerer tout seul.

Ce sont des paramétrage d'option très avancés pour les utilisateurs
maitrisant le fonctionnement interne de SQL Server et ayant l'habitude
de pratiquer l'audit de leurs bases.

Si cela vous intéresse je vous invite à venir vous former à
l'optimisation des bases de données MS SQL Server chez Learning Tree ou
Orsys par exemple :
http://www.learningtree.fr/courses/fr535.htm
http://www.orsys.fr/pdfCours/SQO.pdf

je vous dis cela car J'ai 2 exemples qui sont en totale contradiction
select

from table a
inner MERGE join table b

Dans un premier cas l'1 est plus rapide et l'autre cas c l'inverse.
Les tables sont differentes mais les champs de jointure sont strictement les
memes(de type int).

quel pourait etre la raison?(cas dans ma situation j'ai pu optimiser le
temps de traitement dans 1 seul cas sur les 2) la typologie des requetes
etant strictement les memes.

L'optimiseur est là pour choisir au cas par cas en fonction des valeurs
de paramètre ce qui est à priori (c'est à dire avant exécution) la
meilleure solution.

Cepandant la meilleure solution nécessite d'être estimée par rapport aux
statistiques calculées sur les index.
Ce sui suppose que vous faîtes le ménage régulièrement dans vos table
notament en matière de fragmentation de données et d'index.

Optimisez donc la structure de vos données, SQL server fera le reste !

A +

Merci pour votre aide

A +

Merci de votre aide

--
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 ***********************

--
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 ***********************

Marco a écrit :

"SQLpro [MVP]" a écrit :

Marco a écrit :

bonjour a tous,

j'ai une ptite question .

j'ai un select
from table a
inner join table b

des que je met inner merge join ala place de inner join(normalment cela doit
etre + rapide)
au contraire je perd 10 20s en moyenne.
est ce du a la volumetrie des donnees ou pour une autre raison?

Quel est l'intérêt de demander à un chauffeur de taxi de passer par
Marseille pour aller de Lille à Paris ???

C'est ce que vous êtes en train de faire en imposant à SQL Server une
façon de travailler qui va lui interdire toute optimisation de la jointure !

j'ai oublie

j'ai fais une jointure sur deux tables lorsque j'utilise le inner join
standard
j'ai des doublons et le resultat affiche un nombres superieur
d'enregistrement par rapport a ma table B,ce qui est impossible
en faisant le inner merge join le pb est regle.

La methode hash join emplye par defaut doit provoque cette erreur de doublon
que le merge join corrige .

C la raison pour laquelle je tente "d'optimiser ems resultats en mettant le
inner merge join

Encore une foi il n'y a pas de logique à imposer une façon de faire au
moteur relationnel sans avoir mesuré les conséquences....

Et encore Merci:)

A +

Merci de votre aide

--
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 ***********************

--
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 ***********************

"Med Bouchenafa" a écrit :

Pourquoi un MERGE JOIN serait-il normalement plus rapide qu'un LOOP JOIN?
Sur quoi tu te bases pour une telle affirmation?
Normalement cela depend de la volmétrie relative des deux tables

salut,
je me suis base sur ma propre requete que j'ai execute deux sur deux tables
a chaque fois differentes.
Cepedant ce sont des bases volumineuses.
ce qui m'intrigue c pkoi d'un cote c'est + plus rapide que l'autre cas
surtotu qu'elels ont els meme critere,champ en int pas d'index.
je pensais a la volumetrie des donnees.

Petite question dans quel cas on doit priviligiez plus une methode d'une
autre?
ou bine est ce qu'il fo tout simplement ke je teste chaqe methode ?

Merci pour ta reponse

--
Bien Cordialement
Med Bouchenafa


"Marco" wrote:

> bonjour a tous,
>
> j'ai une ptite question .
>
> j'ai un select
> from table a
> inner join table b
>
> des que je met inner merge join ala place de inner join(normalment cela doit
> etre + rapide)
> au contraire je perd 10 20s en moyenne.
> est ce du a la volumetrie des donnees ou pour une autre raison?
>
> Merci de votre aide

Marco a écrit :

"Med Bouchenafa" a écrit :

Pourquoi un MERGE JOIN serait-il normalement plus rapide qu'un LOOP JOIN?
Sur quoi tu te bases pour une telle affirmation?
Normalement cela depend de la volmétrie relative des deux tables

salut,
je me suis base sur ma propre requete que j'ai execute deux sur deux tables
a chaque fois differentes.
Cepedant ce sont des bases volumineuses.
ce qui m'intrigue c pkoi d'un cote c'est + plus rapide que l'autre cas
surtotu qu'elels ont els meme critere,champ en int pas d'index.
je pensais a la volumetrie des donnees.

Petite question dans quel cas on doit priviligiez plus une methode d'une
autre?
ou bine est ce qu'il fo tout simplement ke je teste chaqe methode ?

encore une fois il n'est pas possible de répondre à votre question de
manière tranchée.

Comprenez que derrière l'écriture de votre requête (sans aucun tag
spécifique) l'optimiseur SQL de SQL Server va choisir parmi des milliers
d'algorithme la bonne façon de faire.
Pour mesurer chacun de ces alogorithmes il va scruter les statistiques
posées sur les index et décider tout seule de la façon dont il va
implémenter sa stratégie de jointure. C'est le "plan de requête".

Bien entendu si pour une même requête les conditions changent (par
exemple la recherche des factures du 1/1/2000 au 31/12/2005 au lieu du
1/1/2006 au 31/01/2006) alors le plan de requête ne sera pas forcément
le même.
La question est : êtes vous capable de faire mieux que l'optimiseur de
SQL server en essayant toutes les stratégies de jointures sans même
exécuter les requêtes ?

Encore une fois formez vous ! Cela sera bénéfique si vous voulez vous
amusez à contraindre l'optimiseur SQL Server...

A +

Merci pour ta reponse

--
Bien Cordialement
Med Bouchenafa


"Marco" wrote:

bonjour a tous,

j'ai une ptite question .

j'ai un select
from table a
inner join table b

des que je met inner merge join ala place de inner join(normalment cela doit
etre + rapide)
au contraire je perd 10 20s en moyenne.
est ce du a la volumetrie des donnees ou pour une autre raison?

Merci de votre aide

--
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 ***********************

Effectivement la volumétrie est importante
en gros, le LOOP fait du n1 * n2 alors que le MERGE du n1+n2
n1 et n2 étant le nombre d'enregistrements respectifs des deux tables
--
Bien Cordialement
Med Bouchenafa


"Marco" wrote:

"Med Bouchenafa" a écrit :

> Pourquoi un MERGE JOIN serait-il normalement plus rapide qu'un LOOP JOIN?
> Sur quoi tu te bases pour une telle affirmation?
> Normalement cela depend de la volmétrie relative des deux tables
>

salut,
je me suis base sur ma propre requete que j'ai execute deux sur deux tables
a chaque fois differentes.
Cepedant ce sont des bases volumineuses.
ce qui m'intrigue c pkoi d'un cote c'est + plus rapide que l'autre cas
surtotu qu'elels ont els meme critere,champ en int pas d'index.
je pensais a la volumetrie des donnees.

Petite question dans quel cas on doit priviligiez plus une methode d'une
autre?
ou bine est ce qu'il fo tout simplement ke je teste chaqe methode ?

Merci pour ta reponse

> --
> Bien Cordialement
> Med Bouchenafa
>
>
> "Marco" wrote:
>
> > bonjour a tous,
> >
> > j'ai une ptite question .
> >
> > j'ai un select
> > from table a
> > inner join table b
> >
> > des que je met inner merge join ala place de inner join(normalment cela doit
> > etre + rapide)
> > au contraire je perd 10 20s en moyenne.
> > est ce du a la volumetrie des donnees ou pour une autre raison?
> >
> > Merci de votre aide