[Vxi3] Performances des requetes [Résolu]

[raithfall]

Bonjour bonjour!

Voila, j'ai un souci de performance pour afficher un rapport: l'exécution de ma requête prend environs 3h, apparemment a cause d'un filtre précis puisque le fait de le retirer réduit le temps d'exécution a 2 ou 3 minutes.
La ou je m'interroge vraiment, c'est dans le fait que l'exécution de la requête contenant le filtre, sous SQL developer par exemple, prend environ 3 secondes.

Quelles peuvent être les composants de BO qui vont multiplier a ce point le temps d'exécution?

[Julien59]

Bonjour,

Peux tu nous dire quel est le filtre qui pénalise à ce point ta requête ?

[raithfall]

No problemo:
Il n'est pas forcement facile a comprendre comme ca, demande moi si tu a besoins de précision. Grosso modo, on ne veut selectionner le couple calendrier.jour/calendrier.id_pa_entree que si il ne correspond pas aux 4 critères du where.

Code :

1
2
3
4
5
6
7
8
9
concat(To_CHAR(CALENDRIER.JOUR,'YYYYmmDD'), CALENDRIER.id_pa_entree) NOT IN 
(
      SELECT concat(TO_CHAR(CALENDRIER.JOUR,'YYYYmmDD'), TO_CHAR(CALENDRIER.id_pa_entree))
      FROM CALENDRIER, LOT_METADATA, KEYWORD, LOT 
      WHERE (UPPER(KEYWORD.CODE) = UPPER('Date_Donnees')
      AND TO_CHAR(LOT_METADATA.METAD_DATE,'YYYYmmDD') = TO_CHAR(CALENDRIER.JOUR,'YYYYmmDD')
      AND CALENDRIER.id_pa_entree=LOT.id_pa_entree
      AND LOT_METADATA.ID_LOT=LOT.ID_LOT)
)

Je rectifie ce que j'ai dis lors de mon premier post: Sous sql developer, la requête a beau s'effectuer en 3 seconde, le fait de dérouler toutes les lignes du résultat est long, ca rame lorsqu'on descend la bare de navigation.. Donc c'est lent aussi sous sql, la difference avec webi c'est que sous webi, une fois le rapport affiché, ca ne rame plus...

[Julien59]

Comme je l'ai précisé dans ce post hier, le IN et le NOT IN sont très coûteux.
Tu dis que la requête ne tourne pas du tout sous BO, mais qu'elle tourne parfaitement bien sous SQL Developer ? Combien ta requête retourne-t-elle de lignes ?
N'as-tu pas la possibilité, plutôt que de passer par un NOT IN, de faire un MINUS entre 2 requêtes combinées ?
Il faut savoir que les combinaisons de requêtes sont beaucoup moins coûteuses que les IN et NOT IN.

Par exemple :

Code :

SELECT * FROM Calendar WHERE NOM_JOUR IN ('Jeudi','Vendredi','Samedi')

est beaucoup plus couteux que :

Code :

1
2
3
4
5
SELECT * FROM Calendar WHERE NOM_JOUR = 'Jeudi'
UNION
SELECT * FROM Calendar WHERE NOM_JOUR = 'Vendredi'
UNION
SELECT * FROM Calendar WHERE NOM_JOUR = 'Samedi'

[raithfall]

Pour ce qui est du fait que le requete tourne parfaitement sous SQL developer, je me suis rectifié sur mon poste precedent. Le resultat doit renvoyer plusieurs milliers de lignes, je n'ai pas encore pus tout derouler.

Donc le probleme viendrai du not in? le problème par rapport a ce que tu me propose comme remplacement c'est que plutot que d'avoir des valeures fixes (jeudi vendredi etc...), je dois comparer à des valeures dynamiques, donc susceptibles de changer, et qui sont très nombreuses (plusieurs milliers). Y aurait il une possibilité de contourner le not in dans ce cas précis?

[Julien59]

La solution que je te proposais n'étais pas de faire des Union de requêtes, mais un minus. J'illustrais simplement avec un exemple le fait que le IN est plus coùteux.
En gros, dans ton cas, l'idée serait de faire une combinaison de requête:

Code :

1
2
3
4
5
6
7
8
9
10
11
SELECT
concat(To_CHAR(CALENDRIER.JOUR,'YYYYmmDD'), CALENDRIER.id_pa_entree) 
FROM
CALENDRIER
MINUS
SELECT concat(TO_CHAR(CALENDRIER.JOUR,'YYYYmmDD'), TO_CHAR(CALENDRIER.id_pa_entree))
FROM CALENDRIER, LOT_METADATA, KEYWORD, LOT 
WHERE (UPPER(KEYWORD.CODE) = UPPER('Date_Donnees')
AND TO_CHAR(LOT_METADATA.METAD_DATE,'YYYYmmDD') = TO_CHAR(CALENDRIER.JOUR,'YYYYmmDD')
AND CALENDRIER.id_pa_entree=LOT.id_pa_entree
AND LOT_METADATA.ID_LOT=LOT.ID_LOT)

[raithfall]

waouh effectivement c'est très rapide!
Le problème pour moi c'est que je ne peut pas faire de cette formule un filtre que j'appliquerai au select from calendrier: il va falloir que je crée une nouvelle table et que j'aille piocher mes valeurs dans cette table plutôt que dans ma table calendrier. je me trompe?

Quoi qu'il en soit, merci julien!

[Julien59]

Faire une table dérivée est une solution et la meilleure je dirais.
Si tu veux d'autres méthodes, on doit pouvoir trouver.

N'oublie pas le bouton si ton problème n'en est plus un
Bon courage

[raithfall]

En fait je souhaitais plutôt me contenter de créer un filtre efficace (contrairement à l'ancien) qui me permettrait de ne piocher dans la table calendrier que les valeurs qui m'intéressent, car le rapport a déjà été fait, et donc faire la méthode des tables dérivées me ferait refaire le rapport en profondeur.

Si tu me dis que c'est THE solution alors je me résoudrais à me refaire le rapport, mais si tu vois un moyen de faire passer ca par un filtre, ca m'arrangerai bien la vie!

[Julien59]

Je ne dis pas que c'est THE solution
Je dis que c'est, si on part de zéro, l'une, si ce n'est la meilleure car la plus simple
Par contre, pour contourner le problème, tu peux créer cette table dérivée, et plutôt que de faire pointer tous tes objets dessus, la lier à la table CALENDRIER sur le champ qui va bien.
Ensuite, tu forces l'utilisation de la jointure soit en ajoutant l'objet de ta table dérivé à ta requête, soit en affectant à un objet de ta requête la table dérivée.
De cette façon, tu auras ton filtre sous forme d'une jointure.
Ca devrait le faire

[raithfall]

pfffff! julien tu gères trop!
Grâce a toi, j'ai pas eu besoins de tout me retaper, tu m'a sauvé une journée de boulot, le résultat et efficace et tourne bien, en 5 minutes. Impec!

Merci!