Redémarrage d'un serveur d'applications en mode reprise après incident
Lorsqu'une instance de serveur d'applications avec des transactions actives en cours redémarre suite à une défaillance, le service de transaction utilise les journaux de récupération pour réaliser la procédure de récupération. Ces journaux, entretenus par chaque ressource transactionnelle, sont utilisés toutes les transactions InDoubt et rétablissent la cohérence globale du système.
![[z/OS]](../images/ngzos.gif)
Avant de commencer
En cas de migration d'une version précédente du produit, assurez-vous que le paramètre REC inclus dans l'instruction de procédure JCL du contrôleur contient REC=N ou REC=Y. Si la procédure JCL ne spécifie pas REC=N ou REC=Y, le serveur ne redémarre pas en mode reprise, même si vous spécifiez l'option -recovery.
Si les procédures JCL incluent REC=N, la configuration est automatiquement modifiée en REC=Y si vous spécifiez l'option -recovery lors du redémarrage du serveur. REC=N est automatiquement inclus dans la procédure JCL si vous ne migrez pas à partir d'une version précédente du produit. Voici une exemple de ce pourrait être l'état de votre PROC à jour :
//BBO6ACR PROC PARMS=' ',REC=N,Z=BBO6ACRZ
Pourquoi et quand exécuter cette tâche
- Les ressources transactionnelles effectuent les opérations dans leurs journaux de reprise, puis s'arrêtent. Ceci permet de libérer les verrous de ressource placés par le serveur d'applications avant l'incident.
- Lors de la période de reprise, seules sont disponibles les quelques fonctions de serveur d'applications nécessaires à la reprise transactionnelle.
- Le serveur d'applications n'accepte pas de nouveaux travaux lors du processus de reprise.
- Le serveur d'applications s'arrête à l'issue de la reprise.
Ce processus de reprise commence dès que tous les sous-systèmes nécessaires du serveur d'applications sont disponibles. Si le serveur d'applications n'est pas redémarré en mode reprise, il peut accepter du nouveau travail dès que le serveur est prêt, ce qui peut ne pas être possible avant la fin du processus de reprise.
En principe, ce processus ne pose pas de problème. Cependant, dans certains cas, il peut arriver que les procédures d'exploitation ne soient pas compatibles avec la prise en charge simultanée du travail de reprise et de nouveaux travaux. Par exemple, dans certains environnements de haute disponibilité, la défaillance d'un serveur d'applications entraîne le transfert automatique du travail qu'il était en train de traiter vers un autre serveur d'applications. Ce serveur de secours traite alors exclusivement le travail du serveur d'applications défaillant jusqu'à la fin de la reprise totale sur celui-ci, les deux serveurs d'applications pouvant ensuite être resynchronisés. Dans cette situation, vous pouvez choisir que le serveur d'applications défaillant effectue le processus de reprise transactionnel, puis s'arrête. Vous ne souhaiterez probablement pas que ce serveur d'applications accepte de nouveaux travaux durant la reprise.
Pour éviter l'affectation de nouveau travail à un serveur d'applications en cours de reprise transactionnelle, redémarrez celui-ci en mode reprise.
Lorsque vous redémarrez un serveur d'applications défaillants, l'agent de noeud du noeud sur lequel ce serveur réside doit être préalablement en cours d'exécution.

Si l'entrée d'enregistrement du gestionnaire de ressources a été supprimée des journaux RRS, un démarrage à froid est effectué lors d'un démarrage suivant du serveur d'applications. Toutefois, vous ne pouvez pas effectuer un démarrage à froid avec RRS, si vous démarrez le serveur d'applications en mode reprise.
Dans cette version des services,
vous pouvez effectuer un démarrage à froid du serveur en mode reprise
uniquement sur le système où le serveur est configuré.
Si vous souhaitez redémarrer un serveur d'applications en mode récupération, vous devez appliquer la procédure suivante avant qu'une défaillance ne se produise, puis vous devez redémarrer le serveur d'applications de manière à appliquer les modifications apportées à la configuration :
Procédure
Résultats
![[z/OS]](../images/ngzos.gif)
Que faire ensuite
Configurez la prise en charge haute disponibilité intégrée au sous composant du service de transaction de sorte qu'il récupère les transactions.