La fonction « Holey Inserts »

Pour optimiser les performances de jobs multiples ajoutant simultanément des enregistrements à un fichier physique, il faut utiliser une description de fichier distincte, en sortie seulement, en précisant qu'il doit utiliser le traitement séquentiel et le blocage en sortie. Le job s'exécutera mieux, mais on rencontrera des goulets d'étranglement dans

le traitement lorsque de nombreux jobs simultanés (de 10 à
100 ou plus) ajoutent des enregistrements au même fichier dans un environnement
de travaux batch multiples. Au-delà d’un certain nombre de jobs, l’utilisation
de la CPU et le débit n’augmentent pas autant que prévu. En fait, à partir d’un
certain seuil, l’utilisation globale de la CPU se stabilise et chaque nouveau
job vient ralentir tous les autres.

Ce ralentissement est du à la sérialisation du traitement SLIC de la base de données
se produisant pendant la construction de l’enregistrement de sortie. Les fonctions
de base de données doivent s’assurer que chaque nouvel enregistrement peut être
ajouté au fichier. Si le blocage en sortie est élevé (comme il le devrait, le
plus près possible de 128 Ko) et si de nombreux jobs ajoutent des enregistrements
en même temps (comme ce devrait être cas), le traitement de validation devient
un goulet d’étranglement.

Heureusement, une fonction de base de données de la V4R4 appelée holey inserts
permet à plusieurs jobs d’ajouter simultanément des enregistrements sans subir
la contention causée par la sérialisation. Le véritable nom de holey inserts est
ENCWT (Enable Concurrent Writes), mais holey inserts (insertions à trous) exprime
mieux la méthodologie de la fonction.

Pour optimiser les traitements d’ajout d’enregistrements à la base de données
en V4R4 ou au delà , il faut faire trois choses suivantes :

1. Appeler un programme base de données OS/400 pour activer les « holey inserts ».
2. Faire un IPL du système activer la fonction.
3. Utiliser une description de fichier distincte, en sortie uniquement, et préciser
SEQONLY *YES et le blocage en sortie.

La séquence d’appel, sur une ligne de commande d’écran passif, pour activer les
holey inserts est CALL QDBENCWT ‘1’ ; pour la désactiver, il faut entrer CALL
QDBENCWT ‘0’. Notons que l’appel de ce programme base de données active les ajouts
simultanés pour tous les fichiers de la base de données du système. Un fichier
physique base de données ne peut bénéficier de l’algorithme des holey inserts
que s’il a été créé avec l’attribut REUSEDLT (Reuse Deleted Records) à *YES, ou
modifié en utilisant CHGPF pour avoir l’attribut REUSEDLT à *YES.

Les holey inserts permettent à plusieurs jobs d’ajouter simultanément des enregistrements
au même fichier base de données, même si un autre job est en train de faire de
même. La base de données calcule le point d’insertion du nouvel enregistrement
pour les jobs suivants et les laisse poursuivre le traitement. Si certains enregistrements
ne satisfont pas aux tests de validation, la base de données ne les acceptera
pas dans le fichier. Elle insèrera alors un enregistrement supprimé (logiquement,
un trou du fichier) à la place de l’enregistrement rejeté, d’où le nom holey inserts.

Grâce aux « holey inserts », plusieurs jobs peuvent utiliser simultanément
la CPU

Si la fonction holey inserts n’est pas activée, aucun enregistrement supprimé
n’est inséré à la place de l’enregistrement rejeté. Les éventuels enregistrements
suivants ajoutés au fichier sont alors remontés d’une position d’enregistrement
dans le fichier. Compte tenu de l’incertitude sur le point d’insertion du début
du prochain job, les jobs suivants ne peuvent procéder à des insertions qu’une
fois que le job en cours a fini de procéder à des ajouts.
Grâce aux holey inserts, plusieurs jobs peuvent utiliser simultanément la CPU.
Cette technique n’améliorera peut-être pas beaucoup les performances sur un système
à une seule CPU, parce que l’opération de validation peut elle-même beaucoup solliciter
la CPU et, par conséquent, il ne restera peut-être pas beaucoup de CPU pour les
autres jobs pendant la validation. En revanche, si on possède un processeur à
n-voies, cette technique permet aux autres jobs concurrents ajoutant des enregistrements
au fichier d’utiliser les autres CPU et de transférer les données dans le fichier
beaucoup plus rapidement.
Si on procède à la journalisation, certains numéros d’ordre (le comptage, par
exemple) des enregistrements du journal risquent d’être modifiés. Cela constitue
un des inconvénients des holey inserts. Cela ne devrait pas poser de problème
avec un logiciel de haute disponibilité.

Caches de journaux batch pour AS/400

par Larry Youngren
La fonction « Batch Journal Caching (caches de journaux batch) pour AS/400 »
est fournie par la PRPQ 5799-BJC de la base de données, disponible depuis
juillet 2000 pour les V4R4 et V4R5 de l’OS/400.
Les caches de journaux batch peuvent améliorer nettement les performances
des environnements batch utilisant la journalisation. Ils modifient la gestion
des écritures sur disque pour accéder à un maximum de performances des opérations
base de données journalisées. En mettant en cache de mémoire centrale les
écritures du journal, le « Batch Journal Caching » peut réduire l’impact de
la journalisation sur un traitement batch, en éliminant le retard qu’entraîne
l’écriture de chaque entrée de journal sur disque. Cette PRPQ est une solution
idéale pour des utilisateurs travaillant en batch et utilisant la journalisation
dans le cadre d’une solution haute disponibilité pour répliquer les modifications
d’une base de données sur un système de backup.

Bien que la PRPQ soit principalement destinée à des jobs batch, certaines
applications interactives peuvent également en bénéficier, en particulier
les applications qui effectuent de nombreuses opérations de mise à jour/ajout/suppression
base de données. Les applications utilisant le contrôle de validation sont
celles qui en bénéficieront le moins parce que le contrôle de validation
fait déjà lui-même un peu de mise en cache des journaux.
Avec une journalisation normale, non mise en cache, dans un environnement
batch, chaque enregistrement base de données que le job batch met à jour,
ajoute ou supprime entraîne la construction d’une nouvelle entrée de journal
en mémoire centrale. Le job batch attend ensuite que chaque nouvelle entrée
de journal soit écrite sur disque pour assurer la reprise. Il s’ensuit un
grand nombre d’écritures synchrones sur disque.

La PRPQ Batch Journal Caching permet de mettre en oeuvre sélectivement une
nouvelle variante de mise en cache du journal. Les entrées de journal et
les enregistrements base de données correspondants sont tous deux mis en
cache en mémoire centrale, retardant ainsi l’écriture des entrées de journal
sur disque jusqu’à ce qu’une écriture disque efficace puisse être planifiée.
Ce mécanisme permet à la plupart des opérations base de données d’éviter
d’attendre l’écriture synchrone des entrées de journal sur disque. Le cache
de mémoire centrale peut contenir 128 Ko, donc un grand nombre d’entrées
journalisées peut être mis en cache avant qu’il ne s’ensuive une écriture
synchrone sur disque.
La PRPQ Batch Journal Caching permet d’éviter les inconvénients (travail,
difficultés et coûts) associés aux modifications applicatives (comme rajouter
un contrôle de validation) pour améliorer les performances dans des environnements
batch. Ce peut être aussi une solution idéale pour un système de sauvegarde
ciblé dans un contexte de haute disponibilité où l’on emploie un job d’application
en boucle, qui réapplique les opérations base de données à une réplique
des fichiers base de données d’origine.

Pour avoir des performances de journalisation optimales, il faut prendre
en compte de nombreux facteurs matériels et logiciels en plus de l’utilisation
de la PRPQ Batch Journal Caching : nombre et type d’unités et de contrôleurs
disques, quantité de cache d’écriture, positionnement des récepteurs de
journaux dans les ASP utilisateurs, et modifications des applications.

Difficultés techniques
Pour utiliser la PRPQ Batch Journal Caching, il faut être soit en V4R4 avec
les PTF MF24293, MF24626, MF25019 et SF63186, soit en V4R5 avec les PTF
MF24863, MF24866, MF24870, MF25022 et SF63192. Notons que ce type de journalisation
est différent de la journalisation traditionnelle et peut affecter la reprise
des fichiers base de données associés. Comme les entrées de journal sont
temporairement mises en cache en mémoire centrale, certaines modifications
récentes de la base de données qui sont encore en cache et pas encore écrites
sur disque, risquent de ne pas atteindre celui-ci dans le cas, peu probable,
d’une défaillance système suffisamment grave pour altérer le contenu de
la mémoire centrale.

De plus, ce type de journalisation risque de ne pas convenir à des applications
interactives où
§ la reprise sur un seul système (plutôt que la réplication sur systèmes
dupliqués) est la principale raison d’utiliser la journalisation
§ il est inacceptable de perdre même une modification base de données récente
dans le cas, peu probable, d’une défaillance système affectant le contenu
de la mémoire centrale.

La PRPQ Batch Journal Caching est surtout intéressante quand on utilise
la journalisation pour activer la réplication de bases de données sur un
second système (pour des applications de haute disponibilité ou de business
intelligence, par exemple) avec une forte charge de travail, comme un traitement
batch ou un lourd travail interactif avec des applications qui n’emploient
pas universellement le contrôle de validation.

On peut aussi mettre en oeuvre la PRPQ de manière sélective pour optimiser
les performances d’exécution de charges de travail batch nocturnes, puis
la désactiver chaque matin pour optimiser la faculté de reprise pendant
l’exécution d’applications interactives. L’avantage est double : on accélère
certains jobs batch nocturnes tout en conservant une excellente reprise
pour le travail interactif de jour.

Larry Yougren travaille chez IBM à Rochester

Pour beaucoup d’utilisateurs AS/400, une bonne sauvegarde du système repose
sur la journalisation de la base de données