> Tech > La journalisation au service des performances

La journalisation au service des performances

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Pour beaucoup d'utilisateurs AS/400, une bonne sauvegarde du système repose sur la journalisation de la base de données. Bien configurées, les fonctions de journalisation du système fournissent des informations à  haute disponibilité fiables et des performances optimales.
Le contenu de la base de données est écrit dans un récepteur de

La journalisation au service des performances

journal. Les fonctions
de journalisation du système  » disséminent  » un récepteur de journal sur de nombreux
bras de disque. Le système bloque et écrit des données dans le récepteur du journal
par une méthode circulaire ( » round bin « ) ; chaque enregistrement des données
du journal est écrit sur un bras du disque différent de ceux qui ont été utilisés
pour les enregistrements du récepteur du journal précédent. Si les récepteurs
de journaux se trouvent dans leur propre ASP (Auxiliary Storage Pool) disque,
et si un seul récepteur de journal est actif à  un moment donné, cette approche
élimine tout risque de contention de bras quand de multiples écritures simultanées
dans le journal se produisent.

Les étapes permettant d’obtenir des performances optimales de la journalisation
sont les suivantes :

1. Placer les récepteurs de journaux dans leur propre AS.
2. N’avoir qu’un récepteur de journal actif sur l’ASP à  un moment donné.
3. Utiliser le mode miroir plutôt que le RAID pour protéger les unités ASP du
journal.

Quand un récepteur de journal est le seul objet actif dans un ASP distinct, la
contention des bras de disque est minimale. Le plus souvent, le bras de disque
n’a pas à  être déplacé au début d’une opération d’I/O ; il peut être déplacé quand
un cylindre est plein. En revanche, si de multiples récepteurs de journaux actifs
se trouvent dans un ASP ou si le récepteur du journal est dans l’ASP système en
même temps que des fichiers base de données de production, le risque de contention
de bras est élevé. Chaque écriture dans le journal demandera probablement un mouvement
de bras (une recherche, par exemple) avant de s’effectuer.
Si les récepteurs de journaux se trouvent dans un ASP protégé par RAID, chaque
écriture dans le journal doit exécuter quatre opérations d’I/O disque pour effectuer
la fonction RAID. Pour chaque écriture en provenance de la CPU, il y a deux lectures
et deux écritures au niveau unité et IOP. Si les opérations d’écriture sont nombreuses
(dans un environnement batch, par exemple), le temps d’exécution risque d’augmenter
sensiblement.

Sur une unité protégée par RAID, les données existent à  l’extérieur (s’étendant
vers l’intérieur) et les pistes RAID se trouvent à  l’intérieur (s’étendant vers
l’extérieur). Donc, si on écrit l’enregistrement du journal sur une unité protégée
par RAID, celle-ci doit rechercher vers le bord extérieur, effectuer l’I/O, puis
rechercher vers le bord intérieur pour lire l’information RAID. De quoi ralentir
considérablement une unité réceptrice de journal performante.
Bien que la plupart des opérations d’écriture dans une base de données et autres
soient asynchrones, les opérations d’écriture du récepteur du journal base de
données sont généralement synchrones pour le job émetteur. Par conséquent, le
job est obligé d’attendre (dans les fonctions d’écriture I/O disque du système)
que l’I/O (écriture) soit terminée avant de poursuivre le traitement. Les écritures
dans le journal peuvent être rendues asynchrones si le job utilise le contrôle
de validation.
Quand le contrôle de validation s’exerce, les fonctions d’écriture du journal
de base de données savent que l’intégrité du fichier n’est requise que dans certaines
limites et pas à  chaque opération de mise à  jour/ajout/suppression d’enregistrement.
C’est pourquoi les écritures dans le journal base de données sont planifiées de
manière asynchrone. Quand l’une des limites est atteinte, les fonctions de la
base de données s’assurent que tout I/O du fichier base de données en suspens
est terminé avant de poursuivre.

Des tests en labo démontrent qu’en utilisant le contrôle de validation et la journalisation,
on obtient des performances presque égales à  la non-utilisation de la journalisation
de la base de données. Si on utilise la journalisation mais pas le contrôle de
validation, un job peut être de trois à  quatre fois plus lent que quand on n’utilise
pas du tout la journalisation.
 » Mais je devrais donc modifier mon code !  » me direz-vous. C’est vrai, mais le
coût de ces modifications est minime par rapport au gain en performances. Dans
le programme CL qui appelle le programme batch, il faut préciser les fichiers
qui utilisent le contrôle de validation et les ouvrir. Il faut démarrer un cycle
de validation dans le programme CL avant d’appeler le programme batch. Dans le(s)
programme(s) applicatif(s), il faut modifier la description du fichier pour indiquer
que le contrôle de validation est utilisé. Quand le programme revient au programme
CL, il faut mettre fin au cycle de validation pour forcer l’exécution de tout
éventuel I/O de fichier en suspens.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010