Discussion :

[Marie22000]

Bonjour,

Nous rencontrons un problème dans l'exécution en batch d'une requête SQL qui s'exécute parfaitement en interactif.
Nos recherches nous ont permis de mettre en évidence une différence de schéma entre l'exécution interactive et batch, dans cette dernière, l'optimiseur utilise un fichier index différent qui est un fichier de l'applicatif que nous utilisons (movex) et que nous ne pouvons donc pas modifier/supprimer.

Nous avons testé l'exécution du SQL à partir d'une bibliothèque de travail préalablement alimentée par une copie des fichiers d'origine.
Quand il n'y a ni index ni logique, le traitement se déroule correctement et se termine en quelques minutes.
Si nous ajoutons un fichier index semblable à celui de Movex, le traitement ne se termine pas (Kill au bout de 45mn) et consomme énormément de cpu, bien que nous ne voyons aucune trace d'avancement (enregistrements fichiers) dans les logs du travail.

Conclusion, nous souhaiterions pouvoir exécuter dans l'environnement de production cette requête en s'appuyant sur un schéma qui n'utiliserait pas l'index de Movex.
Cela est-il possible ?

Marie

[punkoff]

Conclusion, nous souhaiterions pouvoir exécuter dans l'environnement de production cette requête en s'appuyant sur un schéma qui n'utiliserait pas l'index de Movex.

Vous pouvez, avant de lancer votre batch, drop des indexs et les re-créer ensuite à la fin du traitement.

Mais au vu des symptômes, ne serai-t-il pas mieux de chercher la cause du 1er problème ?

edit: sinon pourriez-vous préciser quelle version de DB2 vous utilisez ?

[Marie22000]

Bonjour et merci por votre réponse mais je ne peux pas pas faire de DROP su ces index, ils sont utilisés par notre applicatif principal.
Nous sommes en version V5R4M0.

[punkoff]

Bonjour,

Le problème étant que l'optimiseur va essayer d'utiliser ces indexs par défaut, car selon lui ca sera la meilleur solution.

Il me semble que vous pourriez contourner ceci en mettant des droits spécifiques sur vos indexs afin que le pgm batch ne puisse les utiliser (à confirmer mais il me semble avoir déjà vu ce cas lors de nos test).

sinon, pourriez-vous développer ce point car je ne comprend pas bien :

Nous rencontrons un problème dans l'exécution en batch d'une requête SQL qui s'exécute parfaitement en interactif.
Nos recherches nous ont permis de mettre en évidence une différence de schéma entre l'exécution interactive et batch, dans cette dernière, l'optimiseur utilise un fichier index différent qui est un fichier de l'applicatif que nous utilisons (movex) et que nous ne pouvons donc pas modifier/supprimer.

Votre batch n'utilise pas les mêmes tables sql pour travailler ?
Avez-vous bien vérifié les bibliothèques utilisées par votre pgm batch ? (par exemple une table serai dupliquée dans QGPL et votre jobd aurai QGPL en 1er ? ou QTEMP ou ..)

[Marie22000]

Oui, c'est bien ça, l'optimiseur semble ne pas utiliser les mêmes index en batch et en intéractif.
J'ai vérifié, ces tables n'existent que dans les bibliothèques de production.
Merci.
Marie

[punkoff]

Outre le fait d'interdire l'acces à l'index via des droits d'exclusion spécifique, peut être une autre piste pour vous.

Une différence entre les exécutions entre interactif / batch qui peut amener a l'utilisation de schéma différent des requêtes SQL :
Par défaut (si vous n'avez pas changé le QAQQINI / implanté de close OPTIMIZE FOR / FETCH FIRST) l'optimiseur va créé un plan "optimisé" pour ramener les 10 (ou 20 je ne sais plus) 1ere row au plus vite en exécution interactive alors qu'en exécution de type batch il va tenté de ramener au plus vite la totalité des enregistrements.

=> Ceci change souvent les plan d'exécutions.

Pourriez-vous voir si en rajoutant une close OPTIMIZE FOR 10 ROWS ONLY dans votre pgm batch si le plan créé est le même que lorsque vous lancez la requête de manière interactive ?

Malheureusement si cela fonctionne ca ne vous garantira pas un fonctionnement permanent car l'optimiseur pourra décider, pour une raison X d'utiliser l'index qui pose problème de nouveau.


Autre piste aussi pour la non utilisation d'un même index, ce serai une différence entre vos 2 requête SQL entre batch / interactif, que ce soit au niveau de la close SELECT ou WHERE ou voir des jointure. Les 2 requêtes sont-elles identiques ?

J'ai noté que vous n'étiez qu'"en" V5R4M0, n'y aurai-t-il pas des PTF qui pourrai régler ce problème ? (contactez IBM ?)

[belha]

Il s'agit de bugs corrigés par des PTFs (entièrement ?), c'est donc la première chose à faire mettre à jour les PTFs.
En attendant, vous pouvez forcer l'optimiseur à faire du séquentiel en imposant un 'ORDER BY' qui va bien.
Mettez votre requête pour voir.

[Marie22000]

Merci pour vos réponses et désolée de ne pas vous avoir répondu plus tôt.

Nous avons programmé la mise à jour des PTFs pour le week end prochain (le 05 septembre), nous verrons donc les nouveaux résultats la semaine prochaine.

à bientôt.

[frfancha]

Bonjour Marie,

1) Tu peux afficher le "mauvais" chemin d'exécution dans Visual Explain à partir de run sql script ou du plan cache, c'est en général éclairant de voir pourquoi cela prend si longtemps.

2) En V5R4, tu peux forcer l'utilisation de CQE en ajoutant
"where 'A' = upper('A')"
à ton query. CQE est un peu "bête" par rapport à SQE, il prend simplement le chemin décrit par les joins sans aucun raccourcis... mais au moins il ne s'emmèle pas les pinceaux dans ce qu'il croit être plus rapide comme SQE le fait visiblement ici.
Si tu obtiens une exécution "normale" en CQE et très lente en SQE, tu peux envoyer la trace à IBM et tu recevras rapidemment une PTF, si elle n'existe pas déjà.

3) en V6R1 ce sera beaucoup plus difficile de forcer CQE, mais SQE est plus malin qu'en V5R4 et depuis que nous sommes en V6R1 nous n'avons eu qu'à nous féliciter d'avoir fait la migration (et nous utilisons énormément SQL). Je croise les doigts pour que cela continue.

Fred

[K2R400]

Il me semble que vous pourriez contourner ceci en mettant des droits spécifiques sur vos indexs afin que le pgm batch ne puisse les utiliser (à confirmer mais il me semble avoir déjà vu ce cas lors de nos test).

L'optimiseur ne tient pas compte des droits sur les index.
Un utilisateur ne possédant pas les droits sur un index (de type radix ou vecteur) n'empêche pas l'optimiseur de s'appuyer dessus (si ce dernier estime qu'il obtiendra de meilleurs temps).

[K2R400]

Marie,

Comme le conseille fred, il faut récupérer l'explain de la requête.
Ainsi on saura exactement ce qu'il se passe.