SMAPP

dans le menu de commande EDTRCYAP (Edit Recovery Access Path)), et SMAPP fera
le nécessaire pour que les chemins d’accès appropriés de la base de données soient
journalisés en conséquence.

Quand on active SMAPP, le temps de reprise de la base de données est calculé périodiquement
pour les applications qui s’exécutent. Si on dépasse la valeur de reprise visée,
SMAPP ajoute des chemins d’accès à  ceux qu’il est en train de journaliser. Si
on collecte des données de Performance Monitor ou de Collection Services, on peut
voir les temps de reprise estimés et le nombre de chemins d’accès gérés par le
système (journalisés) dans la section Journaling du Component Report du Performance
Tool.

L’utilisation de SMAPP peut entraîner deux types de ralentissement du
débit de l’application

L’utilisation de SMAPP peut entraîner deux types de ralentissement du débit de
l’application. Dans le premier cas, les chemins d’accès sont journalisés dans
l’ASP système (qui peut être protégé par RAID) plutôt que dans un ASP distinct
(qui est mirroré). C’est le cas si le fichier physique sous-jacent au chemin d’accès
n’est pas en train d’être journalisé. Par défaut, SMAPP met le récepteur de journal
dans l’ASP système. Cependant, si le fichier physique sous-jacent est journalisé
explicitement, les enregistrements du journal du chemin d’accès de SMAPP iront
dans le même récepteur de journal utilisé par la journalisation du fichier physique.

Notons qu’on contrôle si le fichier physique est journalisé et où se trouve le
récepteur de journal. Si l’on souhaite confier à  SMAPP le soin d’activer et de
désactiver automatiquement la journalisation des chemins d’accès et si l’on veut
optimiser les performances d’écriture du journal des chemins d’accès, il faut
envisager de journaliser le fichier physique dans un récepteur de journal situé
dans un ASP mirroré distinct. L’autre possibilité consiste à  prendre les choses
en main à  la place de SMAPP et à  journaliser explicitement les chemins d’accès
les plus grands (et les plus coûteux à  reconstruire) dans le récepteur de journal
dans l’ASP journal mirroré.
L’autre type de ralentissement est associé à  la purge de grandes quantités d’enregistrements
base de données de fichiers physiques et logiques de la mémoire centrale. Les
fonctions système monitorent le nombre de pages modifiées en mémoire, et le système
commence à  les écrire sur disque dès qu’un certain seuil est atteint. On a ainsi
constaté, à  l’occasion de tests clients, une dégradation du débit batch de l’ordre
de 60 à  70 %.

Plusieurs facteurs peuvent entraîner ce genre de situation. Ainsi, si on travaille
longtemps dans un très grand pool mémoire, on risque davantage d’atteindre le
seuil que si on travaille dans un pool plus petit. On n’accumulera pas autant
de pages modifiées parce que les fonctions d’allocation de la mémoire  » volent
 » les pages pour des demandes mémoire concernant d’autres données. De plus, si
les jobs ne tournent pas pendant longtemps, se terminent et ferment les fichiers,
les pages modifiées ne s’attardent plus en mémoire centrale : elles sont écrites
quand on ferme le fichier.
Quand on utilise SMAPP, qu’on journalise le fichier physique sous-jacent et qu’on
utilise un ASP distinct pour les récepteurs de journaux, il faut également employer
le paramètre CHGJRN RCVSIZOPT(*RMVINTENT) pour optimiser les performances. Ce
paramètre met en place une  » bifurcation  » et dirige les entrées du journal SMAPP
onéreuses (inutiles pour la reprise de la base de données) vers un jeu de lecteurs
de disques distinct (encore dans l’ASP du journal séparé). Les fonctions de journalisation
du système divisent l’utilisation des lecteurs de disques du journal et mettent
de côté un jeu de bras de disque distincts pour les récepteurs de journaux qui
recevront les entrées SMAPP.