Autocorrection (2)

la durée maximum de la phase de
reprise de la voie d’accès d’un redémarrage
système (IPL). Pour parvenir à 
cette détermination, le moteur de base
de données supervise en permanence
l’activité de changement de tous les
index du système. Il protège les
index fortement actifs non encore
journalisés et dont la taille est suffisante
pour justifier l’overhead de temps d’exécution supplémentaire en
commençant la journalisation pour
leur compte. Au lieu de laisser à 
quelqu’un le soin de démarrer la journalisation,
le système protège « automatiquement
» les voies d’accès vulnérables.

La journalisation est la principale
méthode pour assurer sur l’iSeries une
reprise de base de données sûre et rapide
après un crash du système.
L’iSeries offre une autre fonction autocurative,
les récepteurs de journaux
gérés par le système, pour éviter les délais
de traitement de base de données
et réduire les exigences administratives
de la journalisation.

Le récepteur de journaux est l’objet
qui stocke les changements de base
de données journalisés. Au fil du temps
et au fur et à  mesure qu’on apporte des
changements aux données, la taille de
l’objet récepteur de journaux augmente.
Quand on est près de la taille
maximale, les administrateurs doivent
attacher un nouvel objet récepteur au
journal. faute de quoi, une erreur
« hard » stoppera net le traitement de la
base de données. L’option récepteur
journal géré par le système (MNGRCVR
(*SYSTEM) sur les commandes CRTJRN
(Create Journal) et CHGJRN
(Change Journal) empêche cette erreur
hard en attachant automatiquement
un nouveau récepteur de journaux
dès que le récepteur existant
approche de la limite de taille maximale.
Les administrateurs n’ont plus à 
intervenir pour contrôler la taille du récepteur
ou pour attacher un nouveau
récepteur de journaux: le système s’en
charge.