Pb de volume (Zos 390) [Résolu]

[mainframe]

Bonjour !
En quelques mots : je dois faire un curseur sur une table pour màj de lignes, (plusieurs centaine de milliers de ligne, et oui on est en mainframe !) cette table est cluster (plus de 200 partitions) sur une primary key de 2 colonnes. Quand on lit suivant l'index cluster pas de pb de temps, or on me demande de gérer une clé de reprise (du genre fait moi un commit tous les 5000 lignes) qui, elle est sur un index différent (autre colonne). Mais là, la requête explose au niveau du temps (pourtant requête simple sur une table, sans jointure ,avec prédicats sargeable). Ouvrir le curseur WITH HOLD mais si l'on plante il faut tout recommencer, avec les pb de contention la journée, le job ne peut passer qu'en batch de nuit ... Je pense que pour améliorer le coût, il faut forcer DB2 à faire un MERGE SCAN càd trier sur les 2 index séparés (normallement c'est fait puisque ce sont des index) et ensuite faire l'intersection.
Comment modifier ma requête pour cela ou si autre solution (bienvenue) ?
Requête de départ en rouge le prédicat qui pose pb

Index cluster colonne :a et b
Index secondaire colonne : c

SELECT d,e,f FROM TABLE
WHERE a = : x
AND b = :y
AND c >= :z

[Luc Orient]

Envoyé par mainframe

...
En quelques mots : je dois faire un curseur sur une table pour màj de lignes, (plusieurs centaine de milliers de ligne, et oui on est en mainframe !) cette table est cluster (plus de 200 partitions) sur une primary key de 2 colonnes.

Attention à ne pas confondre l'index primaire et l'index cluster.
Ce sont deux choses bien différentes ...

Quand on lit suivant l'index cluster pas de pb de temps, or on me demande de gérer une clé de reprise (du genre fait moi un commit tous les 5000 lignes) qui, elle est sur un index différent (autre colonne). Mais là, la requête explose au niveau du temps (pourtant requête simple sur une table, sans jointure ,avec prédicats sargeable). Ouvrir le curseur WITH HOLD mais si l'on plante il faut tout recommencer, avec les pb de contention la journée, le job ne peut passer qu'en batch de nuit ... Je pense que pour améliorer le coût, il faut forcer DB2 à faire un MERGE SCAN càd trier sur les 2 index séparés (normallement c'est fait puisque ce sont des index) et ensuite faire l'intersection.

MERGE SCAN c'est dans le cas d'une jointure, je pense que vous devez parler de MULTIPLE INDEX SCAN ...

Comment modifier ma requête pour cela ou si autre solution (bienvenue) ?
Requête de départ en rouge le prédicat qui pose pb

Index cluster colonne :a et b
Index secondaire colonne : c

SELECT d,e,f FROM TABLE
WHERE a = : x
AND b = :y
AND c >= :z

Si vous êtes à envisager une stratégie de reprise (ce qui est bien en soit ...) ça veut dire qu'il faut parcourir les données à traiter de manière ordonnée (sinon ça ne marche pas ...)
Donc pour moi, il faut une clause ORDER BY.
De plus, si la colonne c pose problème car elle est indexée, alors je ferais la distinction entre le curseur normal, soit :

Code :

1
2
3
4
5
 
SELECT d,e,f FROM TABLE 
WHERE a = : x  
AND b = :y
ORDER BY c

et le curseur de reprise, soit :

Code :

1
2
3
4
5
SELECT d,e,f FROM TABLE 
WHERE a = : x  
AND b = :y
AND c >= :z
ORDER BY c

Dans le premier cas, on passera bien par l'index CLUSTER mais on aura un tri supplémentaire (attention quand même au nombre de lignes triées ...)
Dans le second cas on risque de passer par l'index sur la colonne c, mais outre que ce cas devrait être très rare (on est pas toujours en reprise sinon il y a un autre problème ...) on peut estimer qu'on a déjà traité une partie des données.
Voilà quelques pistes de réflexion ...

[mainframe]

Bon j'en ai discuté avec un support DB2 à ma boîte, et on est tombé d'accord sur cette solution :

SELECT d,e,f FROM TABLE
WHERE a = : x
AND b = :y
ORDER BY c

On tri pour gérer la reprise mais pas prise en compte dans le curseur, (donc plus de AND c >= :z )
mais positionnement dans le programme par lecture séquentielle du curseur jusqu'à la dernière clé sauvegardée.