Comparaison des performances entre fichiers définis par DDS et fichiers définis par SQL

Le point où se produit la validation des données constitue une différence majeure entre une table SQL (c’est-à-dire, définie avec une instruction Create Table) et un fichier physique créé avec DDS. Pour un fichier physique DDS, les données sont validées au fur et à mesure qu’elles sont lues. Pour SQL, les données sont validées au moment où elles sont écrites. La figure 1 montre cette comparaison.

Ce changement a deux répercussions importantes sur les entrées/sorties de la base de données. En premier lieu, il assure l’intégrité des données numériques (packées ou zonées) entrées dans la base de données. Ceux d’entre nous qui ont fait leurs classes sur cette plate-forme l’ont souvent appris à leurs dépens : en recevant de nombreux messages d’exception « decimal data error » dans nos programmes applicatifs. Que ceux d’entre vous qui n’ont pas été confrontés à ce problème effectuent simplement le test suivant.

Commencez par créer un objet fichier physique qui n’est pas décrit en externe, comme suit :

CRTPF FILE (TESTDATA) RCDLEN(80)

Une fois l’objet fichier créé, entrez-y des données alphanumériques quelconques, comme ‘dan123ouch’.

Ensuite, créez un objet fichier physique DDS décrit en externe, nommé DDS_FILE, en utilisant la définition et la commande suivantes :

A R DDS_FILER
A FIELD1
9P 0
CRTPF FILE(DDS_FILE)

Exécutez la commande copy file suivante pour copier les données alphanumériques dans l’objet fichier physique :

CPYF FROMFILE(*CURLIB/TESTDATA)
TOFILE(*CURLIB/DDS_FILEPF) MBROPT
(*ADD) FMTOPT(*NOCHK)

Les messages suivants devraient apparaître dans le journal :

Data from file TESTDATA truncated to 5 characters.
1 records copied from member TESTDATA.

Le journal des jobs indique que les données ont été insérées dans la base de données. En utilisant la commande DSPPFM (Display Physical File Member) (figure 2), on voit que les données non valides existent pourtant dans l’objet fichier physique.

Ensuite créez une table SQL identique au fichier physique DDS créé précédemment, comme suit :

CREATE TABLE DDL_TABLE ( FIELD1 DECIMAL(9,0) NOT NULL DEFAULT 0 );

Procédez à la même opération copy file, mais en changeant le paramètre TOFILE pour utiliser la nouvelle table SQL, comme suit :

CPYF FROMFILE(*CURLIB/TESTDATA)
TOFILE(*CURLIB/DDL_TABLE)
MBROPT(*ADD) FMTOPT(*NOCHK)

Le journal des jobs devrait maintenant présenter les messages suivants :

Data from file TESTDATA truncated to 5 characters.
Data mapping error on member DDL_TABLE.
Data mapping error on member DDL_TABLE.
C
Cancel reply received for message CPF5029.
Error writing to member DDL_TABLE in file DDL_TABLE.
0 records copied to DDL_TABLE.

Outre une meilleure intégrité des données, le changement du mode de validation des données améliorera les performances pour de nombreux clients iSeries/i5 parce que la plupart des applications tournant sur la plate-forme iSeries/i5 effectuent bien plus d’opérations de lecture que d’écriture. En moyenne, j’ai constaté un rapport de 25 à 1 environ.

Outre une meilleure intégrité des données, le changement du mode de validation des données améliorera les performances pour de nombreux clients iSeries/i5 parce que la plupart des applications tournant sur la plate-forme iSeries/i5 effectuent bien plus d’opérations de lecture que d’écriture. En moyenne, j’ai constaté un rapport de 25 à 1 environ.

Pour mettre en évidence l’avantage des fichiers physiques créés par DDL par rapport à ceux créés par DDS, j’ai écrit un programme RPG simple qui effectue des opérations indexées (keyed) aléatoires sur une table d’environ 600 000 lignes.

La figure 4 montre un fragment de code du programme, nommé DB2RE_ RPG2. Le programme simule une application qui se positionne sur une entrée clé spécifique puis lit les 10 premières entrées correspondantes, pour éventuellement remplir une page de sous-fichier.

J’ai ensuite appelé ce programme 802 fois en utilisant des numéros d’articles (parts) aléatoires. J’ai exécuté le test plusieurs fois, en purgeant les objets base de données de la mémoire avant chaque passage. Puis j’ai répété l’opération après avoir réagencé le OrderHst DDS PF en une table SQL nommée Ord_Hst. Après avoir chargé la table, j’ai créé le fichier logique OrderHstL2 sur la nouvelle table SQL. Notons au passage que ma table SQL a un nom différent du DDS PF.

Le graphique de la figure 5 montre le résultat des tests. La barre bleue représente le temps que l’instruction Set Cursor MI a passé à attendre la fin de l’exécution d’une requête work. C’est une attente de type B. (Pour en savoir plus sur le temps d’attente, attendez le nouveau IBM Redbook IBM iDoctor for iSeries Job Watcher: Advanced Performance Tool.) Le nombre d’opérations d’I/O synchrones (c’est-à-dire, celles qui amènent des données du stockage auxiliaire en mémoire) est presque identique entre les sessions DDS et DDL (7 027 par rapport à 7 018, respectivement). Les données provenant des tables DDL sont arrivées environ 11 secondes plus vite. Soit une durée inférieure de 43 %.

J’ai apporté de légères modifications au programme RPG pour effectuer quelque mise à jour. Le fragment de code de la figure 6 représente le nouveau programme DB2RE_RPG3.

J’ai ensuite testé le nouveau programme de la même manière, en accédant aléatoirement au fichier logique indexé. En outre, j’ai effectué une seconde batterie de tests en forçant tous les changements sur disque (FRCRATIO = 1). Le graphique de la figure 7 en montre les résultats.

On le voit, le fait de forcer les changements sur disque alourdit la tâche. Deux raisons à cela : le plus grand nombre d’opérations d’I/O disque synchrones (à la fois DDS et DDL) et la validation supplémentaire inhérente aux tables DDL. Je rencontre souvent cette utilisation de FRCRATIO avec les bases de données héritées. Généralement, je recommande de mettre (ou de laisser) FRCRATIO sur *NONE (par défaut) et d’utiliser la journalisation pour la protection des données. Pour plus d’informations sur les techniques aptes à protéger vos données, consultez l’IBM Redbook Striving for Optimal Journal Performance on DB2 Universal Database for iSeries.

J’ai été étonné par la réduction de la durée dans cette comparaison des opérations de mise à jour. Il s’avère qu’il existe une autre amélioration de performance dite support d’écriture simultanée (concurrent write support).

Le support d’écriture simultanée existe pour les fichiers physiques qui sont créés avec le paramètre REUSEDLT réglé sur *YES. C’est l’état par défaut généré par une instruction SQL CREATE TABLE. L’état par défaut pour la commande CRTPF (Create Physical File) est *NO. Le support d’écriture simultanée est le comportement normal pour la V5R3 (i5/OS). J’ai effectué le test sur un système V5R2 où ce support avait été activé via l’API QDBENCWT. (Pour en savoir plus sur ce support, voir l’IBM Redbook Striving for Optimal Journal Performance on DB2 Universal Database for iSeries.

J’ai créé une autre variante de mon programme RPG pour tester les insertions vis-à-vis de fichiers physiques créés par DDS ou DDL. J’ai créé une variante DDL et DDS d’un objet nommé OrderWrk. C’est un fichier physique non indexé.

La figure 8 montre la nouvelle variante du programme. J’ai testé ce dernier en utilisant la même méthodologie pour le programme de mise à jour, avec et sans le paramètre FRCRATIO. Le graphique de la figure 9 montre les résultats de ces tests. J’ai utilisé le paramètre SEQONLY(*NO) de la commande OVRDBF (Override with Database File) pour désactiver le blocage. Malgré les mérites du blocage en matière d’amélioration de performance, de nombreuses entreprises que je fréquente n’en tirent pas tout le parti possible, intentionnellement ou non. Là encore, nous voyons l’avantage d’utiliser une base de données DDL avec le support d’écriture simultanée activé. La surcharge qui s’ajoute à la validation des données sur les insertions n’entre pas en ligne de compte.