Félicitations! Vous venez de mettre en place avec succès Oracle E-Business Suite 12.2! Après des mois de tests et de travail sur les problèmes, tout ton travail acharné a finalement porté fruit. Cependant, maintenant que la base d’utilisateurs générale est dans le système, quelques petits problèmes ont été signalés et votre DBA a trouvé des résultats directs suggérant que quelques correctifs d’application doivent être appliqués.
Mais avant de demander à votre DBA de commencer, vous vous souvenez qu’il vous a parlé de « correctifs en ligne » lors de vos appels hebdomadaires de statut et qu’avec Oracle EBS 12.2, le processus de correctif a changé. Alors, qu’est-ce que ça veut dire? Y a-t-il encore du temps mort? Combien de temps ça va prendre maintenant?
Nouvelle architecture
À partir d’Oracle EBS 12.2, l’ancienne méthode de correctifs n’existe plus. Plutôt que d’arrêter/corriger/redémarrer (et de gérer les temps d’arrêt cumulatifs), Oracle a maintenant offert une fonctionnalité appelée Application DBA Online Patching (ADOP). Oracle y parvient en introduisant des systèmes de fichiers édités dans la version 12.2. Au lieu d’avoir un seul emplacement pour les fichiers applicatifs comme dans les versions précédentes d’EBS, vous avez maintenant deux copies – une qui reste active et une autre qui peut être synchronisée puis corrigée en parallèle. Oracle différencie ces deux systèmes de fichiers en nommant l’un « fs1 » et l’autre « fs2 ».
Le système de fichiers principal est l’endroit où se trouvent tous vos fichiers d’application à l’exécution et est désigné comme système de fichiers RUN. Chaque formulaire ou page web que vous ouvrez viendra d’ici. Le système de fichiers secondaire existe uniquement pour être corrigé (sans incidence sur l’expérience utilisateur frontale) et est désigné comme système de fichiers PATCH. Dès la sortie de la boîte, fs1 est par défaut le système de fichiers RUN et fs2 le système de fichiers PATCH.
Une fois que nous avons terminé d’appliquer les correctifs pendant un cycle ADOP, un court temps d’arrêt est nécessaire pour effectuer un changement entre les deux systèmes de fichiers. Le système de fichiers PATCH qui a été mis à jour avec de nouvelles corrections de bogues deviendra le nouveau système de fichiers RUN et l’ancien système de fichiers RUN sera relégué au système de fichiers PATCH (où il pourra ensuite être synchronisé pour de futurs correctifs). Ainsi, dans l’exemple standard ci-dessus, fs2 devient le système de fichiers RUN et fs1 est maintenant le système de fichiers PATCH. Les deux systèmes de fichiers alternent entre qui est RUN et qui est PATCH après chaque cycle ADOP complété.
Il est aussi important de noter que seules les mises à jour au niveau de l’application peuvent être exploitées avec ADOP. Les correctifs de base de données, malheureusement, nécessiteront toujours des temps d’arrêt puisqu’ils existent en dehors du champ d’application et donc de l’ADOP. Cela dit, pour les plans d’action hybrides comprenant à la fois des correctifs de bases de données et d’applications, l’ordre des opérations peut être manipulé de sorte que la plupart (sinon toutes) des mises à jour d’applications puissent être effectuées lors d’un cycle de correctifs en ligne, la partie base de données étant réservée immédiatement après.
Comprendre les phases d’un cycle ADOP
Comme mentionné précédemment, la simplicité d’arrêter/patcher/redémarrer est complètement oubliée. À la place, il y a un processus plus complexe pour votre DBA, mais une période d’inaccessibilité plus courte pour les utilisateurs finaux, car le système n’est plus en panne pendant la durée des correctifs. En conséquence, les clients devraient connaître un temps de disponibilité global plus élevé avec les correctifs ADOP comparativement à ceux avec les temps d’arrêt. Dans un cycle de patching ADOP, les phases suivantes sont effectuées :
1) Préparer
2) Postuler
3) Finaliser
4) Coupe
5) Nettoyage
Les trois premières phases (et la dernière) se font toutes sans interruption. Ce n’est qu’à la phase de transition que le système s’effondre. Dans les sections ci-dessous, nous en apprendrons un peu plus sur chaque phase, tant pour ceux qui cherchent seulement une compréhension générale que pour ceux qui s’intéressent aux spécificités de chaque phase.
Phase de préparation
Pour une compréhension générale, c’est là que EBS prépare la demande pour le patching. Premièrement, EBS s’assurera qu’il n’y a pas de conflits ni de mauvaises configurations avec l’environnement. Si l’environnement passe tous les contrôles obligatoires, il commencera à synchroniser les deux systèmes de fichiers afin que le système PATCH soit synchronisé avec le système de fichiers RUN actuel. Cela se fait sans temps d’arrêt.
Pour une compréhension plus approfondie, il s’agit sans doute de la phase la plus longue d’un cycle ADOP, car il y a un nombre considérable de choses accomplies :
- Vérifie si la phase de nettoyage a été effectuée lors du dernier cycle ADOP et, sinon, la termine maintenant.
- Vérifie la configuration générale du système pour déterminer si l’environnement est prêt pour un nouveau cycle ADOP.
- Vérifie si le déclencheur de connexion est présent et activé. Si des problèmes sont détectés, il tentera de les corriger automatiquement.
- Vérifie le dictionnaire de données pour détecter toute corruption. Si elle est présente, la corruption devra être résolue avant d’aller de l’avant.
- Vérifie si le vérificateur de niveau de code technologique EBS (ETCC) a été exécuté contre la base de données (sinon, le PREPARE échouera tant qu’il n’a pas été exécuté).
- Vérifie l’enregistrement et la configuration appropriés de tous les nœuds de l’environnement.
- Vérifie si la requête concurrente « Online Patching In Progress » (nom abrégé d’ADZDPATCH) est présente pour bloquer l’exécution de requêtes concurrentes spécifiques. Ce poste restera actif tant que l’édition patch de la base de données existera. Il n’est annulé qu’une fois le changement terminé.
- Synchronise les patchs actuellement sur le FS RUN, mais pas dans le FS PATCH.
- Vérifie si une édition patch existe dans la base de données (et en crée une si elle n’est pas présente).
- Confirme la connectivité de la base de données à l’édition patch.
Phase de candidature
Pour une compréhension générale, c’est lorsque nous appliquons les correctifs et toute autre mise à jour au niveau de l’application à effectuer sur le système de fichiers PATCH.
Pour mieux comprendre, franchement, il n’y a pas grand-chose de plus à ajouter, car cette phase ressemble à l’exécution de l’ancienne commande adpatch dans les versions précédentes d’EBS. Comme avec adpatch, il y a quelques paramètres que vous pouvez utiliser pour obtenir un contrôle plus précis (par exemple, définir « patchtop » pour utiliser un emplacement de mise en page non par défaut ou définir « workers » pour spécifier le nombre de processus parallèles que vous voulez faire fonctionner en même temps). La petite anecdote à ce stade; cependant, est-ce qu’il l’utilise pour appliquer aussi les correctifs FMW et toute autre mise à jour au niveau de l’application au PATCH pendant que vous avez une session ADOP active ouverte. Fais attention cependant et assure-toi de trouver le PATCH fs avant d’appliquer des correctifs FMW ou d’exécuter des commandes. Ces mises à jour seront réfléchies plus tard, après la coupure.
Phase de finalisation
Pour une compréhension générale, cette phase clôture effectivement la phase de patch et prépare l’environnement aux temps d’arrêt.
Pour une compréhension plus approfondie, cette phase prépare l’environnement au plus court temps d’arrêt possible lors de la transition. Cela inclura des tâches telles que la détermination de tout Langage de Définition de Données (DDL) à exécuter, la compilation d’objets invalides et la validation du système avant la période d’arrêt.
Phase de transition
Pour une compréhension générale, c’est la seule phase qui nécessitera des temps d’arrêt pour les clients. Avant ADOP, le temps d’arrêt pour le patching consistait à accumuler le temps d’exécution de chaque patch, plus le temps nécessaire pour arrêter, démarrer et valider les services. Cependant, en tirant parti de l’ADOP dans EBS 12.2, tous nos correctifs sont déjà appliqués au système de fichiers PATCH à ce stade. Donc, tout ce qu’on a à faire lors du Cutover, c’est arrêter les services, alterner les rôles de FS1 et FS2 (concernant lequel est RUN et lequel est PATCH), puis redémarrer les services. Puisqu’il n’y a pas de variables au moment du passage qui influencent le temps d’arrêt (comme le nombre de correctifs ou un gros correctif appliqué), cela aide à assurer une durée de coupure généralement fiable, peu importe le plan d’action, qui varie généralement de 30 à 60 minutes.
Pour une compréhension plus approfondie, le cutover commence par réduire EBS. Une fois hors service, l’édition patch de la base de données deviendra l’édition run et l’ancien PATCH fs deviendra le nouveau RUN fs (avec l’ancien RUN fs qui deviendra le PATCH fs). Une fois basculé, toutes les anciennes sessions RUN fs se termineront et EBS sera redémarré. Cependant, si vous ne voulez pas que vos services soient redémarrés par coupure (par exemple, par exemple si vous devez appliquer des correctifs à la base de données avec des temps d’arrêt après la fin de l’ADOP), vous pouvez choisir de l’exécuter avec le paramètre « mtrestart=no » pour laisser les applications hors service.
Phase de nettoyage
Pour une compréhension générale, cette étape conclut la session ADOP en supprimant toute donnée liée à la session de patch qui n’est plus nécessaire.
Pour une compréhension plus approfondie, un nettoyage doit être effectué pour compléter une session ADOP, mais ce n’est pas obligatoire. C’est parce que, s’il est sauté, le nettoyage sera effectué au début de la prochaine phase de préparation tentée. En conséquence, cela peut allonger le temps nécessaire pour exécuter Prepare, c’est pourquoi il est recommandé de l’exécuter à la fin d’un cycle de patch. Avec le nettoyage, tout objet obsolète et toute donnée liée aux anciennes éditions de votre base de données sera supprimé. Le nettoyage offre aussi quelques modes différents qui peuvent être transmis sous forme de paramètres (par exemple cleanup_mode = plein). Par défaut, le nettoyage fonctionne comme « standard », mais vous pouvez aussi opter pour les modes « rapide » ou « complet », où vous pouvez effectuer un nettoyage minimum ou maximal, respectivement.
Le résultat
Bien qu’il nécessite plus de préparation et un délai global, l’ADOP apporte finalement d’énormes avantages aux utilisateurs finaux en réduisant le temps d’arrêt total nécessaire pour corriger les applications. Les plans d’action longs contre EBS nécessitent maintenant juste un court temps d’arrêt pour rebondir et alterner les systèmes de fichiers. Même des projets aussi importants que des mises à niveau peuvent réduire le temps d’arrêt global en utilisant un cycle ADOP au début des activités de maintenance. Avec une disponibilité maximale essentielle pour les affaires, l’ADOP est un outil essentiel qui offre les avantages des mises à jour de sécurité critiques tout en minimisant le coût pour la productivité de l’entreprise.