Un chemin d’accès plus large

fichiers. Depuis la V4R2, un chemin d’accès créé via SQL, que ce soit un index ou une contrainte, a une taille de page logique de 64 K. Un fichier logique indexé DDS créera, en moyenne, un chemin d’accès de 8 K, jusqu’à une taille maximale de 32 K.

Ce changement est dû en partie à un usage intensif de l’index associé aux opérations SQL. Par exemple, une implémentation SQL d’une instruction SQL unique pourrait aboutir à une sonde d’index (comme un SETLL en RPG) suivie de plusieurs opérations de balayage d’index (similaires à un RPG READE).br>
La figure 10 montre la différence entre cette instruction SQL

SELECT COUNT(*) FROM PART_DIM
WHERE PART LIKE ‘B%’
OR PART LIKE ‘C%’

utilisant un fichier logique indexé par rapport à un index SQL. Dans les deux tests, l’accès par index seulement a été utilisé pour l’application de l’instruction SQL.

Vous vous demandez peut-être, « Si le chemin d’accès à 64 K aide SQL à effectuer les sondes et les balayages d’index, est-ce que ce même chemin d’accès ne serait pas bénéfique pour mes opérations indexées HLL ? » La réponse est positive et elle se présente sous la forme d’un chemin d’accès partagé.

La figure 11 présente un environnement iSeries mêlant des applications SQL et DDS. Chaque application HLL utilise un chemin d’accès différent pour diverses raisons. Par exemple, le chemin d’accès rouge est très ancien et n’a pas nécessité de recréation depuis quelques temps. Le chemin d’accès jaune sur la droite utilise la logique select/omit, et le chemin d’accès jaune sur la gauche a été créé avant l’index SQL.

Essentiellement, l’application SQL a le droit d’emprunter la voie rapide parce qu’elle peut contenir deux passagers ou plus (ensembles de données). Les applications HLL utilisent les voies plus lentes parce qu’elles contiennent un passager (un enregistrement). Mais, dans la réalité, l’application HLL la plus critique peut effectuer des dizaines, voire des centaines, d’accès aux enregistrements pour exécuter une transaction. En fait, c’est généralement ces transactions massives qui accaparent 80 % ou plus des ressources informatiques (CPU et I/O) d’une entreprise. Ajoutons à cela le fait que, parmi les centaines ou les milliers de programmes applicatifs qui existent dans la logithèque d’une entreprise, il se peut qu’une poignée seulement représente la majorité du temps de CPU et d’I/O.

Pour que les applications HLL puissent utiliser le chemin d’accès à 64 K, nous devons tirer parti du support de partage de chemin d’accès intégré de l’OS/400 (i5/OS). Ce support n’est pas nouveau. Déjà sur le S/38, il fallait spécifier le mot-clé de niveau de fichier REFACCPTH dans votre source DDS pour le fichier logique indexé que vous alliez créer. Ceux d’entre nous qui connaissaient ce mot-clé s’en servaient pour alléger la maintenance des chemins d’accès.

De nos jours, c’est le système d’exploitation qui effectue implicitement le partage des chemins. Malgré cela, les règles suivantes sont importantes :

• Un index SQL ne partagera pas le chemin d’accès d’un fichier logique indexé DDS.
• Un fichier logique indexé DDS partagera un chemin d’accès créé via SQL.
• Un fichier logique indexé DDS partagera un chemin d’accès si les clés sont un sous-ensemble des champs clés dans le chemin d’accès existant et dans le même ordre. Ainsi, LF1 avec les clés K1 et K2 partagera un chemin d’accès qui est indexé sur K1, K2 et K3.
• Un index SQL partagera un autre chemin d’accès créé par SQL uniquement si les colonnes clés correspondent exactement et dans le même ordre.
• Un fichier logique multiformaté DDS ne partagera pas les chemins d’accès existants.
• Un fichier logique join DDS peut partager les chemins d’accès existants.
• Le mot-clé de niveau de fichier DYNSLT peut être utilisé pour faire partager un chemin d’accès existant à des fichiers logiques DDS contenant des critères select/omit.

Il résulte de ces règles que si nous ajoutons le mot-clé DYNSLT au source DDS représentant le second fichier logique, puis si nous recréons nos fichiers logiques dans l’ordre décroissant des colonnes les plus indexées aux colonnes les moins indexées, nous devrions nous retrouver avec un chemin d’accès partagé, comme dans la figure 12.

J’ai construit un index SQL sur la table ORD_HST avec la même colonne clé que le fichier logique indexé OrderHstL2 (le fichier utilisé dans mes programmes RPG). J’ai ensuite recréé OrderHstL2 sur la table ORD_HST.

Les écrans iSeries Navigator des figures 13A et 13B montrent les deux fichiers logiques. On voit la différence de taille de page logique : 8 192 contre 65 536. C’est le signe que le fichier logique index sur la droite partage un chemin d’accès à 64 K créé par SQL.

J’ai réexécuté les mêmes tests que précédemment, en utilisant maintenant le fichier logique avec le chemin d’accès à 64 K. On peut voir les résultats dans les graphiques de la figure 14.

D’après les données, l’utilisation du chemin d’accès à 64 K a réduit la durée globale pendant les tests Read et Update. Le test Insert a duré plus longtemps que le test précédent en utilisant un chemin d’accès à 8 K sur une table DDL mais moins longtemps qu’en utilisant le chemin d’accès de même taille sur un fichier physique créé par DDS.