vendredi 26 mai 2006

Performance DB2 sur une table de 100 millions de lignes

Bonjour,

Voici une nouvelle question posée sur le forum DB2 en français :
http://db2usa2.free.fr/forums/viewtopic.php?id=256

Nous avons un traitement un peu long qui parcours comme point de départ une table de 100 millions de lignes.Il existe un index(cluster) sur COL1 + COL2 qui est partitionné en 10 partitions d'après le premier caractère de COL1 (valeurs de 0 à 9).Le curseur ressemble un peu au suivant:

SELECT COL1, COL2, COL4, ......., COL25
FROM TABLE
WHERE COL1 BETWEEN :Hostvar1 AND :Hostvar2
AND ( (COL4 = '03' AND COL7 = '01' )
OR (COL4 = '06' AND COL7 = '05' )
OR (COL4 = '06' AND COL7 = '07' )
OR (COL4 = '10' AND COL7 = '05' ) );


Ce curseur avait été imaginé pour ne traiter qu'une plage de partitions: si Hostvar1 = '0000000000' et Hostvar2 = '0999999999' on ne lis que la première partition. Ces 2 parametres sont lus dans un fichier par le programme batch: c'est surtout pour passer plusieurs batchs en parallèleL'embêtant c'est que DB2 utilise l'index (avec MatchCol = 1) alors qu'il serait préférable qu'il fasse un accès avec PAGE_RANGE = Y.L'optimizer ne sachant pas la valeur des Hostvar, vous me répondrez que c'est le moins qu'il puisse faire.Mais j'aimerais bien éviter l'utilisation de l'index avec lequel on ne peu pas espérer plus qu'un indexscan trop couteux et inutile.Cependant je me demande si vous avez des solutions à proposer pour faire du Page_Range avec des paramètres en entrée.

Personnellement je vois deux solutions: utiliser un ordre dynamique ou bien écrire 10 SQL (un par partition) qui seraient exécutés sous condition....

Merci d'avoir lu ce post jusqu'au bout !
Merci d'avance pour vos réponses ou vos questions,
Etienne Salvadori


Amicalement,

DB2usa.