La préparation de la phase d'adoption est la première phase du cycle de correctifs en ligne dans R12.2. Adop effectue de nombreuses actions dans la phase.Voici la séquence d'activités
1.Vérifie s'il faut effectuer un nettoyage, qui sera nécessaire si l'utilisateur n'a pas réussi à invoquer le nettoyage après la phase de basculement d'un précédent cycle de correctifs en ligne .
2.Valide la configuration du système pour s'assurer que le système est prêt à démarrer un cycle de correctifs en ligne.
3.Vérifie si la base de données est prête pour les correctifs en ligne :
a) Vérifie si l'utilisateur de la base de données est activé pour l'édition. Si ce n'est pas le cas, adop se termine immédiatement avec une erreur.
b) Vérifie si le service de correctif a été créé. adop nécessite qu'un service de base de données spécial existe dans le but de se connecter à l'édition de correctif. Ce service est créé automatiquement, mais sa pérennité est validée à chaque préparation.
c) Vérifie si le déclencheur de connexion existe et est activé. Si le déclencheur de connexion est manquant ou si le service de correctif n'a pas été créé, adop essaiera automatiquement de résoudre le problème afin qu'il puisse continuer. S'il ne peut pas le faire, il se terminera avec un message d'erreur.
d) Vérifie l'intégrité du dictionnaire de données de la base de données. Si une corruption est détectée, adopte une sortie avec un errorease 12.2.
e) Vérifie que le vérificateur de niveau de code de la technologie E-Business Suite (ETCC) a été exécuté pour vérifier que tous les correctifs requis ont été appliqués à la base de données.
4.Vérifie la configuration du système sur chaque nœud de niveau d'application. Un certain nombre de paramètres critiques sont validés pour garantir que chaque nœud de niveau d'application est correctement enregistré, configuré et prêt pour l'application de correctifs.
Vérifie le système de fichiers à l'aide du script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Ce script vérifie l'espace du système de fichiers, les connexions à la base de données, les mots de passe Apps/System/Weblogic, la validation du fichier de contexte, etc. Ce rapport est créé dans $APPL_TOP/admin/$TWO_TASK/out.
5. Vérifie l'existence de la "correction en ligne en cours" (ADZDPATCH) programme simultané. Ce programme empêche le démarrage de certains programmes concurrents prédéfinis et, en tant que tel, doit être actif pendant qu'un cycle de correctifs est en cours (c'est-à-dire tant qu'une édition de correctifs de base de données existe).
Le déroulement du processus est
a.Si l'exécution du programme ADZDPATCH n'a pas encore été demandée, une demande est soumise. S'il n'existe pas, l'erreur ci-dessous est signalée
ERREUR à la ligne 1 :
ORA-20008 :Aucun gestionnaire simultané n'est défini pour exécuter un programme simultané
ADZDPATCH
b.Le statut d'ADZDPATCH est déterminé. S'il est en attente, il attend peut-être la fin d'un programme incompatible. Une fois l'incompatibilité résolue, son statut passera à running et permettra à la phase de préparation de se poursuivre. Un message à cet effet est affiché à l'utilisateur.
c.L'étape suivante dépend de l'exécution ou non des gestionnaires de concurrents :
i.Si les gestionnaires simultanés sont tous arrêtés, la phase de préparation se poursuit, ADZDPATCH passant à l'état En attente (avec la priorité la plus élevée) jusqu'au démarrage des gestionnaires.
ii.Si les gestionnaires simultanés sont partiellement opérationnels, mais qu'il si aucun gestionnaire défini ne peut exécuter ADZDPATCH, la phase de préparation se terminera avec une erreur.
iii.Si les gestionnaires simultanés sont actifs et qu'il y en a un défini qui peut exécuter ADZDPATCH, le traitement se bouclera jusqu'à ce qu'ADZDPATCH change le statut de en attente d'exécution. La phase de préparation se poursuit ensuite.
ADZDPATCH est annulé lorsque la phase de basculement est terminée.
Si vous souhaitez qu'un programme personnalisé ne s'exécute pas dans le cycle de correctifs, vous devrez le rendre incompatible avec ce programme ont été appliqués au run APPL_TOP, mais pas au patch APPL_TOP. Le script dépend du référentiel adop pour les correctifs qui ont été appliqués sur l'exécution APPL_TOP mais pas le correctif APPL_TOP.
Identifiez les correctifs qui ont été appliqués à l'exécution APPL_TOP et appliquez-les au correctif APPL_TOP. Les étapes suivantes sont effectuées automatiquement :
a.Les correctifs qui doivent être appliqués au correctif APPL_TOP sont identifiés à partir de la base de données.
b.Les correctifs fusionnés sont appliqués par l'utilitaire adop.
L'utilitaire adop identifie les correctifs delta à appliquer, et les applique silencieusement au patch actuel APPL_TOP. Comme cette procédure ne nécessite que l'application de correctifs delta, elle prend moins de temps
Dans certaines circonstances, la méthode de synchronisation de style delta (incrémentielle) peut échouer lors de l'application d'une série de correctifs à l'édition de correctifs. Cela peut se produire si le cycle de correctifs précédent incluait des correctifs qui ne s'appliquaient pas correctement et qu'il était suivi de correctifs ultérieurs qui corrigeaient le problème.
Le paramètre skipsyncerror vous permet de spécifier que vous vous attendez à ce que toutes les erreurs de synchronisation dans la phase de préparation soient corrigées automatiquement lors de la synchronisation qui a lieu avec les correctifs suivants.
Si la valeur du paramètre est passée à 'yes', le premier correctif à synchroniser sera effectué avec le drapeau 'autoskip' activé.
Important :il est de votre responsabilité de vérifier les fichiers journaux et de corriger les éventuelles erreurs dans la phase d'application suivante, ou pour confirmer que la synchronisation avec les correctifs suivants a résolu le problème.
Un exemple d'utilisation de ce paramètre serait le suivant.
a.Vous exécutez adop phase=prepare.
b.La phase échoue avec une erreur lors de la tentative de synchronisation des systèmes de fichiers run et patch. Autrement dit, la tentative de synchronisation d'un correctif échoue, mais on sait qu'un correctif ultérieur corrigera le problème.
c.Vous examinez les fichiers journaux et concluez que les erreurs de synchronisation seront corrigées automatiquement lors de la synchronisation qui prend place avec les correctifs suivants.
d.Vous exécutez la commande adop phase=prepare skipsyncerror=yes pour redémarrer la phase de préparation. Cette fois, l'application du correctif qui a échoué lors de la préparation précédente sera réessayée avec l'indicateur "autoskip" défini.
Synchronisation des personnalisations
La méthode de synchronisation du système de fichiers de style delta (incrémentielle) par défaut gère les correctifs officiels mais ne synchronisera aucune personnalisation appliquée manuellement. Voici des exemples d'actions de correction qui ne sont pas synchronisées par défaut :
Compiler des JSP définis par l'utilisateur
Copie de certaines bibliothèques tierces
Copier et compiler des programmes concurrents définis par l'utilisateur
Copie et génération de formulaires définis par l'utilisateur
Pour inclure des actions de correction personnalisées dans la synchronisation du système de fichiers par défaut, vous devez inclure les commandes requises dans le pilote de synchronisation personnalisé, $APPL_TOP_NE/ad/custom/adop_sync.drv . Vous ajouterez vos personnalisations à la section suivante du fichier :
#Begin Customization
…
#End Customization
Toutes les actions définies dans ce fichier seront effectuées par adop automatiquement lors de la phase de préparation. Sachez qu'il existe deux catégories de commandes personnalisées dans adop_sync.drv :celles qui ne sont exécutées qu'une seule fois et celles qui sont exécutées à chaque synchronisation du système de fichiers (pendant la phase de préparation de l'adop).
Important :Le fichier adop_sync. drv n'est actuellement réinitialisé à son fichier de modèle à aucun moment. Par conséquent, après le basculement (et avant la prochaine phase de préparation), vous devez examiner le contenu de adop_sync.drv et vous assurer que les exigences de vos commandes personnalisées continuent d'être respectées.
7.Vérifie l'existence d'un correctif dans la base de données édition, et en crée une s'il n'en trouve pas.
a)Une édition de correctif est créée dans la base de données.
b)Tous les objets de code de l'édition de correctif commencent par des pointeurs vers des objets de code dans l'édition d'exécution. Les objets de code dans l'édition du correctif commencent par des « objets stub » légers qui pointent vers les définitions d'objet réelles, héritées des éditions précédentes. Les objets stub consomment un minimum d'espace, de sorte que l'édition de correctif de base de données est initialement de très petite taille.
c) Lorsque des correctifs sont appliqués à l'édition de correctif, les objets de code sont actualisés (une nouvelle définition est créée) dans cette édition.
8.Appelle à nouveau le script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl pour confirmer que la connexion de la base de données à l'édition du correctif fonctionne.
Articles connexes
Adop expliqué dans R12.2
Résumé du cycle de correctifs en ligne R12.2
