Discussion :

[Pierre Quefer]

Bonjour,

J'avais il y a peu soumis un problème d'utilisation de l'ordre LIKE dans
des requêtes SQL à travers RPG ILE.

voir intitulé discussion problème de LIKE + param dans un query

Aujourd'hui, j'ai un autre souci

lorsque je lance une requête SQL toute simple à travers RPG ILE
les temps de réponses sont pratiquement immédiats.

Il suffit de rajouter une instruction ORDER BY et le temps de
réponse devient plus long.

Vous me direz que c'est normal

Manque de bol, en enlevant ORDER BY et en travaillant avec
un logique dont l'index est la zone mentionnée dans ORDER BY,
le SQL s'en fout et ne fait aucun tri.

La question est:

y-a-t' il un moyen d'optimiser les temps de réponses en maintenant
l'instruction ORDER BY ?


Merci

[Pierre Quefer]

petite précision importante que j'ai oublié.

Lorsque je sors la requête SQL avec ORDER BY du RPG ILE
et que je l'exécute sur STRSQL, le temps de réponse est
à nouveau instantané.

[Mercure]

Manque de bol, en enlevant ORDER BY et en travaillant avec un logique dont l'index est la zone mentionnée dans ORDER BY, le SQL s'en fout et ne fait aucun tri.

Normal aussi ! Ne jamais utiliser de logiques sur les instructions SQL. Toujours utiliser le physique ou, mieux encore, les tables créées par SQL.

y-a-t' il un moyen d'optimiser les temps de réponses en maintenant l'instruction ORDER BY

Ne jamais préjuger que SQL utilisera tel ou tel chemin d'accés correspondant à des critères du WHERE, de l'ORDER BY, etc, mais préférer de loin faire un passage de la requête toujours sur le physique ou la table pour aller voir ensuite sous iSeries Navigator>Bases de données>Advised Index quel est le chemin d'accés dont SQL a eu besoin et recommande de construire.

Sous écran vert, on peut aussi se mettre sous debug ( STRDBG "brut" sans autres paramètres ) puis exécuter la requête SELECT sous STRSQL. Ensuite, analyser la log du job interactif et y repérer les messages SQLnnnn où SQL signale qu'il a du créer un index pour accomplir la requête dans des conditions optimisées. Contruire alors l'index en conséquence.

Voir aussi
OnDemand Index Advice for DB2 for i
et
Simplify DB2 for i5/OS index advice

[Pierre Quefer]

Merci beaucoup Philippe,

Effectivement, en utilisant le nom des tables de physiques, cela va
plus vite, sauf peut-être à la première requête.
Mais c'est certainement parce qu'il construit alors ses index en
fonctions des zones de la table, car ensuite peu importe la zone
de la table utilisée pour le tri, cela va plus vite.
Et de toute façon, derrière la première requête en vient en général
une autre...

[Mercure]

Je tiens les infos générales qui suivent de Birgitta Hauser, un "Gourou" SQL sur DB2 System i.

Comment fonctionne SQL

La première fois qu'une instruction SQL est exécutée, le processus complet d'optimisation est mis en oeuvre, c'est à dire

• récriture du SELECT
• contrôle des index
• création du plan d'accés
• création de l'ODP (Open Data Path)

A la fin de ce premier passage, le curseur (l'ODP) est fermé par le système.

Au deuxième passage de cette même instruction, le plan d'accés est validé et l'ODP réouvert.

A partir du troisième passage, l'ODP reste ouvert et seules les données qui y sont contenues sont réactualisées.

Il faut bien avoir en mémoire que le processus complet d'optimisation prend beaucoup de temps et est donc très coûteux.