Résultats des accès SQL par ordre d’arrivée

ont dépassé
les débits comparables (185.000 et 150.000, respectivement) obtenus en utilisant
un SetObjAcc … Pool(*Job) puis en traitant le fichier en mémoire. Bien que le
RPG affiche un avantage relatif d’environ 17 % par rapport à  SQL, les deux approches
fournissent des débits tellement élevés que, dans la pratique, la différence peut
sembler négligeable. En effet, la lecture d’un fichier de plusieurs millions d’enregistrements
durerait à  peine de 50 secondes de plus avec SQL qu’avec RPG.

Dans une grande variété de tests Fetch multiligne SQL, en utilisant les deux pools
de mémoire *Calc et *Fixed et en paramétrant OvrDbf de nombreuses manières différentes,
j’ai constaté que la taille de transfert restait aux alentours de 112 Ko, qui
est proche du maximum de 128 Ko pour DB2 UDB. Les performances ont augmenté rapidement
lorsque la taille de Fetch est passée de une à  11 lignes (figure 4a), puis elle
s’est stabilisée et enfin a décliné légèrement avec des tailles de Fetch supérieures
à  176.

On voit en figure 4b qu’un Fetch monoligne est bien plus lent qu’un Fetch multiligne,
indépendamment de la valeur de SeqOnly. (Rappelons que le paramètre SeqOnly affecte
le Fetch monoligne mais pas le Fetch multiligne.) Les résultats présentés ici
concernent des pools de mémoire *Calc, mais les mêmes relations de performances
sont apparues avec des pools *Fixed (bien que tous les tests se soient exécutés
plus lentement dans des pools *Fixed). Dans tous les cas, la taille de transfert
de Fetch monoligne a été d’environ 112 Ko, la même que pour des tests Fetch multiligne.
Le Fetch multiligne est plus rapide parce qu’il demande moins d’itérations que
l’instruction Fetch pour extraire le même nombre de lignes et le temps d’exécution
de SQL utilise une technique légèrement plus efficace pour placer les données
dans des variables hôtes pour un Fetch multiligne.

Ces résultats nous inspirent deux recommandations élémentaires pour l’accès par
ordre d’arrivée SQL le plus performant :

· Utiliser une instruction Fetch multiligne extrayant au moins 32 Ko.

· Inutile d’utiliser un OvrDbf avec un paramètre NbrRcds ou SeqOnly lorsqu’on
utilise un Fetch multiligne.

Bien qu’une taille de Fetch de 32 Ko fournisse probablement des performances quasi-optimales,
pour obtenir le maximum de rapidité, effectuez vos propres essais en faisant varier
la taille de Fetch par incréments de 32 Ko. Pour calculer le nombre de lignes
à  définir sur l’instruction Fetch, divisez 32.768 (ou un multiple de ce nombre)
par la taille de la ligne extraite et arrondissez. Si le résultat est inférieur
à  deux, utilisez 2. Avec un Fetch monoligne, on pourra améliorer les performances
en définissant une valeur de SeqOnly équivalente à  un bloc de 32 Ko, en utilisant
le calcul précédent.