Améliorations concernant la disponibilité et la reprise

deux phases. Le commit en deux phases est mis en oeuvre sur l’iSeries dans son support de Distributed Unit of Work DRDA (Distributed Relational Database Architecture). Distributed Unit of Work DRDA a été supporté sur l’AS/400 pendant plusieurs années, mais uniquement sur des connexions SNA. La V5R1 supporte désormais Distributed Unit of Work DRDA sur une connexion TCP/IP.

La V5R1 procure aussi des améliorations de journalisation qui augmentent la disponibilité et le potentiel de reprise des données de gestion de l’iSeries. L’ajout le plus important est l’option Journal Minimal Data.

A l’heure actuelle, si une application modifie une ligne dans la table de base de données, le gestionnaire de la base de données doit déposer une copie de toute la ligne dans le journal, afin de posséder les données nécessaires pour revenir en arrière et inverser les modifications de l’application. La totalité de la ligne est copiée dans le journal même si une seule de ses colonnes a changé. Ainsi, si l’application met à  jour une colonne code produit de quatre octets, DB2 copie toute la ligne (200 octets, par exemple) dans le journal.

L’option Journal Minimal data permet d’ordonner à  DB2 de ne copier dans le journal que les données de la ligne réellement modifiée. Des entrées de journal plus petites réduiront le rythme de croissance des récepteurs de journaux et diminueront la fréquence de permutation de ces récepteurs. En outre, une entrée plus petite signifie qu’il faut moins d’opérations d’I/O pour écrire l’entrée du journal sur disque. Qui plus est, l’empreinte mémoire principale totale rétrécira probablement, ce qui ne pourra qu’améliorer les performances des autres applications s’exécutant de manière simultanée. Une session de traitement de transactions de gestion dans le lab s’est exécutée de 3 à  4 % plus vite avec l’option Journal Minimal data, et la taille moyenne des entrées de journal a été réduite de presque 50 %.

On active l’option Journal Minimal data en spécifiant le nouveau paramètre MINENTDTA sur les commandes CL ChgJrn (Change Journal) et CtrJrn (Create Journal). On ne peut spécifier Journal Minimal data que pour des zones de fichiers (tables) et de données. Une fois que l’on a activé Journal Minimal data, DB2 ne copie dans l’entrée du journal que les octets d’une ligne réellement modifiés. Si des voies d’accès sur les mêmes tables font l’objet d’une journalisation (explicitement ou via SMAPP), les colonnes clé (key columns) peuvent être incluses même si elles n’ont pas été modifiées.

Quand on utilise un journal à  des fins de contrôle (audit), il vaut mieux ne pas utiliser cette option Minimal. Quelqu’un, par exemple, souhaite voir toutes les modifications réelles apportées à  la colonne Salaire dans un fichier de base de données. Dans un tel cas, les données ne sont pas lisibles quand l’entrée est affichée parce que DB2 utilise un algorithme « hash » pour minimiser les données. L’entrée du journal indique encore quand la mise à  jour s’est produite et qui l’a effectuée, mais on ne peut pas voir la modification des données proprement dite.

Il existe un autre moyen d’améliorer les performances de journalisation dans la V5R1 : la PRPQ Batch Journal Caching (5799-BJC). Cette PRPQ existait déjà  dans les releases V4R4 et V4R5. BJC (Batch Journal Caching) peut améliorer nettement les performances d’environnements batch pratiquant la journalisation. Il modifie la manipulation des écritures sur disque, de manière à  obtenir des performances maximales pour les opérations de base de données journalisées. En cachant les écritures de journalisation en mémoire principale, Batch Journal Caching peut réduire l’impact de la journalisation sur l’exécution (runtime) batch en éliminant le délai pendant lequel chaque entrée du journal est écrite sur disque.

Cette PRPQ est une solution idéale pour les clients travaillant en batch qui utilisent la journalisation pour répliquer sur un système de sauvegarde, les modifications apportées à  la base de données. Certains tests de performances conduits dans le lab ont révélé une amélioration de 700 %. La PRPQ Batch Journal Caching est proposée pour un essai de 60 jours et donc on peut évaluer ses mérites avant l’achat. Pour plus d’informations sur cette PRPQ, voir l’article « La PRPQ Batch Journal Caching améliore les performances de la journalisation » (NEWSMAGAZINE, avril 2001).

La journalisation de l’OS/400 est également améliorée dans la V5R1, avec des possibilités de journalisation complète pour les zones de données, les files d’attente de données et les objets IFS. Egalement, les modifications de base de données au niveau objet (instructions SQL Create ou Alter, par exemple) sont également désormais enregistrées dans le journal. Dans les releases antérieures, les modifications au niveau objet n’étaient journalisées que dans le journal d’audit, et pas dans le journal normal. En raison de cette déficience, c’est vous qui étiez chargé de fusionner les deux journaux. De plus, bon nombre de ces mêmes changements au niveau objet ne pouvaient être appliqués automatiquement avec les commandes ApyJrnChg. Une nouvelle PRPQ (5799-AJC) de base de données gratuite fournit la commande CL ApyJrnChgX capable de reproduire automatiquement les entrées du journal associées aux modifications au niveau objet de la base de données ainsi que les entrées du journal classiques.