Discussion :

[ruru9]

Bonjour à tous,

J'ai écrit une requête contenant une sous requête imbriquée. La sous requête est donc évaluée dans son ensemble pour chacune des lignes de la principale avec à chaque fois 4 tests fait sur différents critères.

C'est donc assez lourd. Néanmoins, je trouve que les temps de réponse sont acceptables avec des volumes de données plutôt faibles. Pour 10 000 lignes j'ai un temps de réponse à 10min. Ce temps de réponse semble d'ailleurs linéaire puisque avec 1 000 lignes, c'est 1 min.

Mais le problème vient sur des volumes plus gros. Je n'ai pas essayé de lancer sur une période plus grande concernant 100 000 lignes. Ca devrait faire 100min en tps de réponse! Et 1 000 min à 1M de lignes!! Je voudrais éviter de lancer l script au serveur à 18h et le laisser travailler toute la nuit.
J'ai aucune connaissance dans tout ce qui est optimisation des Rq/Tps de réponses. Ma question est donc, est t'il possible de faire en sorte que l'exécution se fasse par étape, par exemple mois après mois???
Sachant que je voudrais le résultat de ma requête dans une table unique et non dans 12 différentes si une exécution mois par mois était possible.

Merci d'avance pour votre aide.

[al1_24]

Difficile de répondre dans le vide... Pourrais-tu nous présenter ta requête ?

[mnitu]

...
J'ai aucune connaissance dans tout ce qui est optimisation des Rq/Tps de réponses. ...

Cela se voit! 10 minutes pour une requête qui travaille sur 10 000 lignes avec Oracle ? Vous devez faire quelque chose de profondément erroné.

[ruru9]

Cela se voit!

Euh oui m'enfin je ne parle pas d'une requête qui retournerait juste les 10 000 occurrences d'une table.
Quand je lance 10 000 lignes, lors de l'exécution c'est en fait pour chaque ligne un comparaison sur 3 critères (et non pas 4) comme dit dans mon post précédent, ce qui fait du 10 000² * 3 , soit 300*10^6 comparaisons.

Encore une fois, je n'ai les compétences pour juger si c'est long ou pas, je pensais que ça restait correct mais apparemment c'est pas le cas. Peut être qu'un expert arrive à faire exécuter au serveur ces 300*10^6 comparaisons en moins de 4 secondes?? Mais je suis quand même sceptique.

[Waldar]

Ça dépend du test réalisé (s'il est en local où si vous faites des appels à d'autres serveur, ce n'est pas la même histoire), mais actuellement vos performances sont nulles.
Pouvez-vous publier votre code afin qu'on jette un œil ?

[ruru9]

Je reviens vers vous avec le code que j'ai écris. J'ai les champs suivants :

- CLE : clé primaire de l'événement
- ID_TYPE_EVENEMENT : la catégorie
- DH_DEBUT : Date Heure de début
- DH FIN : Date Heure de fin

L’idée est de dénombrer pour chaque évènement avec combien d’autre(s) évènement(s) il se chevauche d’au moins 1 seconde.

C’est cette table retournée que j’ai aliasé en E3 pour faire un comptage en fonction de la valeur correspondant au nombre d’événements.
En tout cas, le nombre de contrôles effectués pour chaque occurrence de la requête principale ne semble pas avoir d’influence puisque si j’exécute avec un seul contrôle le temps est le même.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
SELECT SIMULT, count(CLE)  FROM
 
(SELECT
  E1.CLE,
  E1.ID_TYPE_EVENEMENT,
(SELECT
Count(E2.CLE)
FROM 
  TABLE _EVENEMENT E2
WHERE
E2.ID_TYPE_EVENEMENT IN (‘A’) AND E1.CLE <> E2.CLE
 
and
 
((E1.DH_DEBUT > E2.DH_DEBUT and E1.DH_DEBUT<E2.DH_FIN) 
or
(E1.DH_DEBUT<E2.DH_DEBUT and E1.DH_FIN > E2. DH_FIN)
or
(E1. DH_FIN < E2. DH_FIN and E1. DH_FIN>E2. DH_DEBUT)
 
)
 
and
 
 to_char(E2.DH_DEBUT,'YYYYMM') = 201501
) as SIMULT
 
FROM
  TABLE _EVENEMENT E1
 
WHERE
E1.ID_TYPE_EVENEMENT IN (‘A’) and to_char(E1.DH_DEBUT,'YYYYMM') = 201501
) E3
 
GROUP BY 
 
SIMULT

[aieeeuuuuu]

Encore une fois, je n'ai les compétences pour juger si c'est long ou pas, je pensais que ça restait correct mais apparemment c'est pas le cas. Peut être qu'un expert arrive à faire exécuter au serveur ces 300*10^6 comparaisons en moins de 4 secondes?? Mais je suis quand même sceptique.

L'idée de l'optimisation d'un requête ne consiste pas à faire un maximum de calcul en un minimum de temps, mais de réduire le nombre de calculs nécessaires afin de prendre moins de temps.

Dans votre requête, la sous requete corrélée n'est certainement pas une bonne idée.

Que donne ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
SELECT 
		SIMULT
	,	count(CLE)  
FROM(
	SELECT
		E1.CLE,
		E1.ID_TYPE_EVENEMENT,
		COUNT(*) as SIMULT
 
	FROM  TABLE_EVENEMENT E1
	INNER JOIN TABLE_EVENEMENT E2
		ON E1.CLE <> E2.CLE
		AND E2.ID_TYPE_EVENEMENT IN ('A') 
		AND E2.DH_DEBUT >= TO_DATE('201501','YYYYMM')
		AND E2.DH_DEBUT < TO_DATE('201502','YYYYMM')
		and (
				(E1.DH_DEBUT > E2.DH_DEBUT and E1.DH_DEBUT<E2.DH_FIN) 
				or(E1.DH_DEBUT<E2.DH_DEBUT and E1.DH_FIN > E2. DH_FIN)
				or(E1. DH_FIN < E2. DH_FIN and E1. DH_FIN>E2. DH_DEBUT)
			)
	WHERE	E1.ID_TYPE_EVENEMENT IN ('A') 
		AND E1.DH_DEBUT >= TO_DATE('201501','YYYYMM')
		AND E1.DH_DEBUT < TO_DATE('201502','YYYYMM')
	GROUP BY 
			E1.CLE,
			E1.ID_TYPE_EVENEMENT
) E3 
GROUP BY SIMULT

[ruru9]

Merci pour votre réponse. Effectivement le temps de réponse est divisé par 10 en faisant cette autojointure. J'ai l'impression que l'emploi de sous requêtes corrélées est un pis aller, à déconseiller.