Discussion :

[Deallyra]

Bonsoir,

J'aurais voulu savoir s'il était possible de savoir le temps que mettait une requête à se faire sous Oracle.

En fait, j'aimerai faire des tests me permettant de savoir si une requête est plus rapide qu'une autre.

J'ai les deux requêtes suivantes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
SELECT nome, embauche
FROM li.employes
WHERE salaire = (
			SELECT salaire 
			FROM li.employes 
			WHERE noe = '&1'
			) 
AND indem NOT IN (
			SELECT indem 
			FROM li.employes 
			WHERE noe = '&1'
			 );

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT NOME, EMBAUCHE
FROM li.employes a
WHERE SALAIRE = ( 
				SELECT SALAIRE 
				FROM li.employes b 
				WHERE NOE = &1 
				AND a.INDEM <> b.INDEM 
			);

J'aimerai savoir laquelle de ces deux requêtes est là plus rapide.

Dans quel cas ? (Est ce qu'à partir d'un certain nombre d'enregistrements, une requête est préférable à l'autre? )

Merci à vous :3

[derise]

Bonsoir
Pour le temps d'execution, hormis la mesure empirique je ne vois pas
Sinon le plan d'execution me semble une bonne méthode pour comparer deux requetes, plan d'execution qui met en valeur le cout en accès. Valeur qui permet d'approcher le temps d'execution prévisionnelle de la requete.
Pas mieux pour le moment désolé

[Alain Defrance]

Bonjour,

Pour ma part je dirais la seconde.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SELECT nome, embauche
FROM li.employes
WHERE salaire = (
			SELECT salaire 
			FROM li.employes 
			WHERE noe = '&1'
			) 
AND indem NOT IN (
			SELECT indem 
			FROM li.employes 
			WHERE noe = '&1'
			 );

Ici le SGBD est obligé d'effectuer 3 sélections, et soustraire un ensemble a un autre.

Code :

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

1
2
3
4
5
6
7
8
SELECT NOME, EMBAUCHE
FROM li.employes a
WHERE SALAIRE = ( 
				SELECT SALAIRE 
				FROM li.employes b 
				WHERE NOE = &1 
				AND a.INDEM <> b.INDEM 
			);

Ici le SGBD effectue toujours 3 sélections, mais c'est tout.
Je dirais donc que l'écart entre les deux requêtes aurait tendance à s'accentuer, je ne suis cependant pas expert Oracle et je peux me tromper.

Concernant le plan d'exécution, ce n'est pas ce qui prend le plus de ressource, puisqu'il est calculé puis mis en cache. Avec une utilisation intelligente du SGBD, le cache sera utilisé la fois suivante.

[Deallyra]

Le problème de la seconde est qu'il s'agit d'une requête corrélée...

J'ai peur qu'avec un nombre d'enregistrement important, elle ne tienne plus la route.

Apparemment avec "Set Timing On;" je devrai pouvoir lui demander de m'afficher le temps mit pour l'exécution de la requête...

Je vous tiens au courant

[Alain Defrance]

Le problème de la seconde est qu'il s'agit d'une requête corrélée...

Ah oui en effet j'avais pas fait attention , le nombre de requête sera donc proportionnel au nombre de tuple présent dans table employees dans la requête 2.
Jai tendance à éviter au maximum ce type de requête plutôt lourde pour la db.

Peut-être qu'avec un extrait du MLD et ce que tu cherche à faire on aurait un avis plus critique, tu as ça sous la main ?

pour calculer le temps d'exécution je pense que cette discussion t'aidera.

[Deallyra]

Hum.

Un extrait du MLD je veux bien mais pour ce qu'il servira...
(en fait, je n'arrive pas à travailler avec les MLD... Si j'ai un MLD, je dois en faire un MCD pour le comprendre dans son ensemble :3 )

Heu... J'ai déjà fait le MCD... Ce sera déjà ça... Et je vais tenter de générer automatiquement le MLD ^^
Pas envie de perdre du temps avec le MLD :s

( je n'arrive pas à générer un MLD textuel...)

-> MCD

[Alain Defrance]

J'aurais arrangé le MCD différemment mais mon windesign refuse de se lancer .

Concernant tes requêtes, pourquoi ne pas passer par des tables temporaires ?
Ça t'éviterais deux exécutions de requêtes au lieu d'une, toujours ça de gagné

[Deallyra]

Table temporaire -> Vue ?

Sinon, le modèle relationnel que j'ai eu... Ben c'est pas moi l'auteur ^^'
Donc pour ce qui est de le faire différemment... C'est sûr u_u

[Alain Defrance]

non non, table temporaire

[skuatamad]

Conecernant ta 1ere requête je pense que tu devrais choisir entre =/<> et IN/NOT IN.

Sinon concernant ta requête corrélée, vu que tu testes l'existance je l'aurais écrite comme ça :

Code :

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

1
2
3
4
5
6
7
8
SELECT NOME, EMBAUCHE
FROM li.employes a
WHERE EXISTS (SELECT 1
	      FROM li.employes b
	      WHERE b.NOE = &1
	      AND b.salaire=a.salaire
              AND b.INDEM <> a.INDEM
              );

Personnelement, j'aime bien les requêtes corrêlées qui peuvent apportées des gains significatifs en terme de perfs.
Mais sinon tu peux toujours passer par une sous requête :

Code :

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

1
2
3
select a.nome,a.embauche
from employe a
JOIN (select salaire,indem from employes where noe=&1) b on (a.salaire=b.salaire and a.indem<>b.indem)

[lallio]

Bonjour,

Effectivement, pour comparer deux requetes, rien de mieux que de les executer de voir... (SET TIMING ON). En revanche attention au fait que les données une fois en cache peuvent fausser le résultat.

sinon SET AUTOTRACE ON, qui en plus de plan d'execution donne également des statistiques en termes d'accès mémoire et disque, cet qui permet de comparer plus facilement.
J'ai fait un petit post sur le sujet:http://www.lao-dba.com/article-23772890.html

Attention également à la "fausse idée" qu'une requete avec le plus petit cost sera la plus rapide...

[Deallyra]

Conecernant ta 1ere requête je pense que tu devrais choisir entre =/<> et IN/NOT IN.

Pas d'accord ^^

= ou <> permet de comparer deux opérandes.

IN ou NOT IN permet de comparer une opérande à une liste potentiellement pourvue d'un unique élément.

Attention également à la "fausse idée" qu'une requete avec le plus petit cost sera la plus rapide...

Hum. Merci pour cette précision, je n'y avais pas réfléchi même si je le savais xD

[mnitu]

Bonsoir,

J'aurais voulu savoir s'il était possible de savoir le temps que mettait une requête à se faire sous Oracle.

En fait, j'aimerai faire des tests me permettant de savoir si une requête est plus rapide qu'une autre.
...

Cherchez runstats_pkg sur le site AskTom. Pour la source téléchargez ToolsIuse.

[derise]

Bonjour, [...]
Attention également à la "fausse idée" qu'une requete avec le plus petit cost sera la plus rapide...

Comment est ce le cost et le temps d'execution pourrait être dissocié ?
A priori à temps d'accès constant en moyenne, un cost plus élevé induit plus d'accès donc prend plus de temps ? ou bien est ce que quelque chose m'a échappé.
Via l'utilisation du cache

D'avance merci

[mnitu]

Comment est ce le cost et le temps d'execution pourrait être dissocié ?
A priori à temps d'accès constant en moyenne, un cost plus élevé induit plus d'accès donc prend plus de temps ? ou bien est ce que quelque chose m'a échappé.
Via l'utilisation du cache

D'avance merci

Le coût est une estimation! Quand votre banquier vous promet de rendement allant jusqu’au 10 % sur un placement risqué il n’est pas garanti que vous allez toucher ces 10%. Il se peut qu’au bout de la ligne vous allez perdre de l’argent. C’est pareil avec le calcul du coût, si l’optimiseur se trompe le temps d’exécution sera en réalité plus long.

[derise]

De ma courte expérience j'ai appris que la manipulation des statistiques sur la base impactait les performances des requetes. Je n'ai pas vraiment compris comment mais bon j'ai compris qu'il valait mieux laisser un vrai DBA s'en occuper.

Si je comprends bien l'optimiseur peut se tromper. L'examen du plan d'exécution (sur lequel mon n+1 jure par dessus tout) peut donc s'avérer trompeur, de fait est ce que deux requetes ayant le meme plan d'execution peuvent avoir un comportement différent si elles sont lancées dans des environnements différents ? (typiquement de la recette a la prod)

[mnitu]

De ma courte expérience j'ai appris que la manipulation des statistiques sur la base impactait les performances des requetes.
...

Vrai en ce qui concerne l'optimiseur basé sur le coût.

Je n'ai pas vraiment compris comment mais bon j'ai compris qu'il valait mieux laisser un vrai DBA s'en occuper.
...

Il n'est pas possible d'optimiser ses requêtes sans comprendre comment ça marche. Pire encore le DBA ne peut rien face aus mauvais algorithmes.

Si je comprends bien l'optimiseur peut se tromper. L'examen du plan d'exécution (sur lequel mon n+1 jure par dessus tout) peut donc s'avérer trompeur, de fait est ce que deux requetes ayant le meme plan d'execution peuvent avoir un comportement différent si elles sont lancées dans des environnements différents ? (typiquement de la recette a la prod)

L'optimiseur utilise les informations concernant les statistiques des segments (tables, indexes, etc.) et les statistiques système plus des algorithmes issues de la théorie des probabilités pour élaborer son meilleur plan d'exécution. Si les statistiques sont incorrectes ou si la distribution des valeurs ne cadre pas avec les prémisses des algorithmes son meilleur plan d'exécution peut être sous optimale. Cella ne signifie pas que le plan d'exécution sur lequel ton n+1 jure n'est pas vrai mais que ce n'est pas tout simplement optimal.
Dans ces conditions il est clair qu'une même requête peut avoir deux plans d'exécutions différents si les environnements sont différents. Contrairement à l'optimiseur en mode règle pour lequel le plan d'exécution était stable, de par sa nature l'optimiseur basée sur le coût ne peut pas garantir la stabilité de son plan, sauf les cases ou les statistiques sont imposées par l'utilisateur et non pas calculées.