Discussion :

[Flo2]

Bonjour,

je dois faire des requêtes sur une base DB2 sur zOs.
Comme c'est une base de production, je n'ai pas les autorisations pour ajouter des index par exemple.

J'ai 2 tables (jai modifié les noms pour que ce soit lisible ) de 300 000 lignes (donc pas grosses...)

tableA
cle
champ_dec DECIMAL(11)

tableB
cle
champ_char CHAR(11)

Il n'y a pas d'index sur champ_char

Je dois récupérer tous les enregistrements de tableA dont le champ_dec ne correspond à aucun champ_char dnas tableB.
En fait champ_dec est un entier (oui je sais )

J'ai donc écrit la requête suivante :

select tableA.cle
from tableA
where subtr(ltrim(char(tableA.champ_dec)),1,11)
not in
(
select tableB.champ_char
from tableB
)
;


Comme ça prenait des heures (littéralement), j'ai réécrit comme j'aurais fait sous Oracle, avec une jointure externe:

select tableA.cle
from
tableA
left outer join
tableB
on
substr(ltrim(char(tableA.champ_dec)),1,11)=tableB.champ_char
where tableB.champ_char is null
;

Le temps de réponse est toujours aussi déplorable, je n'arrive pas au bout en une heure. Mes collègues me disent que c'est toujours comme ça lorsqu'il y a une conversion de type. Il est vrai que j'ai écrit une requête similaire (tables de même taille, pas d'index utilisable) mais sans conversion, et ça n'a pris que quelques minutes.

Auriez-vous des idées? Car là je sèche complétement, même après avoir parcouru la doc et des forums, je n'ai rien trouvé... Je suis à court d'idées.

Merci

PS : je ne peux pas convertir dans l'autre sens, il y a apparemment des valeurs de champ_char qui ne sont pas numériques...

[philouf0183]

N'étant pas un spécialise de DB2, j'ai tout de même une idée qui serait intéressante à tester.

L'idée est de faire une table temporaire avec ton champ modifié substr(ltrim(char(tableA.champ_dec)),1,11) puis de faire la jointure entre cette table temporaire et la table nommée tableB.

C'est pas dit que tu gagnes réellement du temps, mais parfois, il est pratique de décomposer en plusieurs sous-problèmes, notamment en optimisation de requête.

[Flo2]

Hélas, on n'a pas le droit de créer de table, même temporaire... Sinon j'aurais bien essayé...

[philouf0183]

Si tu as "le droit" de faire des procédures stockées, tu peux bien évidemment passer par ce principe.

En revanche, si tu n'as toujours pas la possibilité de faire, ça, j'ai bien peur que tu ne puisses pas faire grand chose pour améliorer les perf'

[jab]

Ce n'est pas grand chose mais enleve le ltrim il ne sert à rien puisque tu fait un substr après.

[Luc Orient]

Il serait judicieux d'avoir le chemin d'accès choisi par DB2 (fonction EXPLAIN en DB2 for z/OS) ...

[Peut-êtreUneRéponse]

De toute manière avec une build-in fonction dans la WHERE condition cela sera peu performant

[polux]

Salut
Quel est le nombre de valeur possible de champ_dec et de champ_char
A+

[Mercure]

Que donne cette requête ?

Code :

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

1
2
3
4
5
SELECT tableA.cle
FROM tableA 
LEFT OUTER JOIN tableB 
ON char(tableA.champ_dec) = tableB.champ_char
WHERE tableB.champ_char IS NULL

On peut éviter je pense l'imbrication des 3 fonctions substr, ltrim (inutile) et char et ne conserver que cette dernière.

Cependant, dans tous les cas, on ne coupera pas à l'overhead dû à la conversion de type.

[jab]

Tu peux aussi essayer avec les fonctions Cast ou digit. Il se peut qu'elles soient plus performantes.

[Luc Orient]

Que donne cette requête ?

Code :

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

1
2
3
4
5
SELECT tableA.cle
FROM tableA 
LEFT OUTER JOIN tableB 
ON char(tableA.champ_dec) = tableB.champ_char
WHERE tableB.champ_char IS NULL

On peut éviter je pense l'imbrication des 3 fonctions substr, ltrim (inutile) et char et ne conserver que cette dernière.

Cependant, dans tous les cas, on ne coupera pas à l'overhead dû à la conversion de type.

Attention à la fonction CHAR avec DB2 for z/OS ... elle donne, en plus des chiffres présents dans la colonne à convertir, un caractère à gauche pour le signe et un caractère à droite pour la virgule ...

A mon humble avis ce n'est pas un problème de fonctions scalaires mais bien d'indexation.
En effet, si l'optimiseur de DB2 peut partir sur un TS SCAN pour la première table (la A), il risque aussi de partir en TS SCAN sur la seconde (la B) puisqu'il semble ne pas y avoir d'index sur B.champ_char. C'est à dire que pour chaque ligne de la table A on va balayer toutes les lignes de la table B.
Mais bon, ce n'est qu'une supposition et c'est pourquoi j'aurais bien aimé voir le résultat de la fonction EXPLAIN de la requête ...

[Mercure]

Moi aussi, j'aimerais bien voir ce résultat...