Oracle accorde maintenant à ses partenaires la possibilité de réaliser sur ses « Engineered Systems » (Exadata, Exalogic, ODA, SuperCluster, …) les opérations d’installation de configuration et de patching, à condition d’avoir suivi un cycle précis de formations et de certifications. En tant que partenaire privilégié, nous avons suivi ce programme et nos clients peuvent nous faire confiance pour réaliser ce type de prestations, comme par exemple le passage trimestriel des patchs de l’éditeur sur l’ensemble d’une infrastructure Exadata. Dernièrement, le service BPCE-IT, service technique de l’informatique du groupe Banque Populaire – Caisse d’Epargne, nous a permis d’organiser la première campagne de ce type sur leurs configurations. Voici donc, à titre de partage d’expérience, un résumé de ce que nous avons vécu et les points importants à connaitre.

1) Configurations et mode d’application des patchs
Nous avions deux typologies à traiter :
D’une part, 1/4 d’Exadata X5-2 avec disques Haute-Capacité dédié à l’homologation des applications. Cette machine n’est pas critique mais son indisponibilité met au chômage technique plusieurs équipes. Le choix a été fait de réaliser l’opération de nuit en mode arrêt complet des applications.
D’autre part, deux autres 1/4 Exadata X5-2 avec chacun 3 Cellules disques Haute-Capacité et 6 Cellules supplémentaires Extrême-Performance. Chaque Exadata est dans un immeuble différent. Les bases de données hébergées sont reparties sur les deux sites et protégées par Data Guard (base de données de secours sur l’autre site). Ces machines hébergent des applications critiques. Nous avons décidé d’utiliser la méthode « Physical Standby First » dont les fondamentaux sont décrits dans la note MOS Oracle Patch Assurance – Data Guard Standby-First Patch Apply (Doc ID 1265700.1). Ceci permet de limiter l’indisponibilité des applications à seulement deux courtes périodes correspondant au changement de rôle (switchover Data Guard) avec le protocole suivant :
a) Passage de toutes les bases des applications sur un seule site (devenant site principal) première interruption liée au « switchover », mais uniquement pour les bases qui avaient au départ le rôle secours (STANDBY) sur ce site
b) Arrêt de toutes les instances du site de secours et patch de ce site. Cette opération peut se faire pendant les heures ouvrées puisque les applications sont toujours disponibles sur l’autre site
c) Changement de rôle pour les sites, les bases deviennent principales sur le site qui a été patché, seconde interruption applicative liée à cette bascule.
d) Arrêt de toutes les instances sur le nouveau site de secours et patch de ce site.
e) Relance de toutes les instances. Finalisation du passage des patchs (évolution du dictionnaire) sur les bases de données ayant le rôle principal (PRIMARY), via le script catbundle.sql (version 11.2 et inférieur) ou l’exécutable datapatch (à partir des versions 12.1)
f) Retour à une situation nominale où les bases applicatives sont réparties en mode principal sur les deux sites, d’où une dernière interruption applicative uniquement pour les bases nécessitant un déplacement.
On le voit, la configuration du client, l’architecture, la présence d’un PCA et/ou d’un PRA influencent grandement la méthode d’application des patchs.
A noter que le mode rolling over, qui permet en patchant un des serveurs de base de données puis l’autre, de limiter encore plus les arrêts, n’a pas été choisi car le mode de protection des disques groupes ASM n’étaient pas suffisants pour sécuriser l’opération (mirroring simple et non triple).
L’autre élément ayant une influence sur la méthodologie finale est le type des patchs à appliquer, ce que nous déterminons et analysons dans l’étape suivante.

2) La préparation
Tout commence par l’accès à la note MOS Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1), informations mises à jour régulièrement, c’est en la lisant que vous pourrez déterminer :
– les dernières versions disponibles
– les matrices de compatibilité entre les versions
– les pointeurs vers les distributions
– les dernières alertes et points d’attention
De là, vous en déduirez et choisirez les cibles à atteindre pour les composants de vos machines :
– PDU (alimentation)
– Switch Cisco (réseau d’administration)
– Switches Infiniband
– Serveurs des cellules de stockage
– Serveurs des bases de données
– Oracle Grid Infrastructure
– Oracle Database (patches pour les versions 11.2 et 12.1)
Une fois les choix actés par tous, il faut télécharger les distributions correspondantes depuis les sites d’Oracle et se créer un dépôt sur chacun des serveurs de bases de données.
L’ensemble pour avril 2016 comprenant les fichiers pour toute la pile faisait 5 Go.
En plus de cela, il faut récupérer les dernières versions d’OPATCH (patch 6880880 ), d’exacheck à partir de la note MOS Oracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1) et de l’outil dbnodeupdate.sh (patch 16486998).
On ne peut s’affranchir de la lecture de tous les README des patchs que l’on souhaite appliquer, c’est très important pour établir les détails de votre procédure et s’éviter des problèmes, car on y trouve :
– le mode d’application
– le mode de retour-arrière
– les pré-requis
– les derniers points d’attention connus
– et surtout l’indication en tout début du fichier de la propriété « This patch is Data Guard Standby First Installable »

3) Validation et tests préalables
Avant toute campagne, il faut vérifier si les configurations sont saines, pour cela les tests les plus complets sont réalisés par l’outil « exacheck »; il donne un score de bonne santé sur 100 qui doit être le plus haut possible, il permet surtout de détecter tout problème dans la configuration que votre supervision n’aurait pas vue (comme un câble mal connecté sur le switch infiniband ou un écart de configuration entre vos serveurs).
Il faut cependant faire la part des choses avec les résultats de cet outil et ne prendre en compte que les éléments de type « FAILED » les plus significatifs (atteindre un score de 100/100 est irréaliste).
Les autres vérifications à passer sont relatives aux différents composants :
#patchmgr -ibswitch_precheck, pour les switchs infiniband
#patchmgr -patch_check_prereq, pour les serveurs de stockage
#dbnodeupdate –sh –v, pour les mises à jour OS des serveurs de données
$opatch prereq CheckConflictAgainstOHWithDetail, pour chacun des patchs des produits Oracle, Grid Infrastructure et base de données.

4) Les pré-requis
Pour qu’une campagne se déroule sereinement, il faut établir et vérifier une liste de pré-requis, ceci seront a minima :
– la présence des distributions sur tous les serveurs de base de données
– la validité des mots de passe pour la connexion sur les serveurs
– la présence des fichiers liste des catégories de serveur (pour les commandes groupées de type dcli)
– un fichier de réponses générique pour opatch
– la compatibilité avec vos outils (netbackup , zabbix , etc…)

5) Rédaction du plan
Pendant cette phase, vous établirez au format qui vous convient le mieux le plan détaillé des opérations, avec la liste et le résultat attendu pour chaque étape, un chronographe et les procédures de retour-arrière.
A titre indicatif, les étapes 2 à 5 nous ont pris 7 jours pleins pendant lesquels nous avons réalisé pour tous nos environnements :
– analyse du Quaterly Full Stack Download Patch
– étude des README
– détermination des Pré-requis
– planification et rédaction de la procédure complète
– pré-check des environnements
– compatibilité des patchs

6) Application des patchs sur l’environnement d’homologation
Durée totale de l’opération, sans compter le temps pour arrêter correctement les applicatifs : 12h00.
Soit une nuit de travail commençant à 17h00 et se terminant le lendemain matin à 5h00.
Deux heures prises pour l’ouverture et le traitement d’un SR de priorité 1 au support Oracle, cela suite à un non-redémarrage de la couche cluster après le passage des patchs Grid Infrastructure.
La durée sans anomalie est elle de 10 heures.
Ce qui comprend le passage du script catbundle.sql sur les bases en version 11g (2 minutes par base) et l’exécution de datapatch pour les bases en version 12c (5 minutes par base).
7) Application des patchs sur le site devenu de secours
Durée totale, hors bascule des applications : 9 heures
Pas d’interruption des applications pendant l’application des patchs sur le site de secours.
Durée de la synchronisation des bases de secours une fois l’opération terminée : 1 minute
8) Application des patchs sur le second site
Durée totale, hors bascule applicative : 10 heures
Pas d’interruption des applications pendant l’application des patchs sur ce site.
Passage du script catbundle.sql sur les bases 11g pour la finalisation dans le même temps que sur la plateforme d’homologation (2 minutes par base)
Exécution de datapatch, des difficultés suite à une configuration DNS introduisant trop de délai, ce qui nous a contraint à utiliser le mode « force ».

9) Quelques leçons apprises
– Décaler d’un trimestre la campagne par rapport à la date de sortie des patchs pour avoir du recul et profiter de l’expérience de tous. Nous avions décidé de réaliser cette campagne dès parution des patchs d’avril alors que dans le même temps les patchs de janvier étaient passé par Oracle chez nos autres clients.
– Libérer complètement les interlocuteurs pendant la phase de préparation. Cette phase est minutieuse et cruciale pour la suite, toutes les personnes impliquées doivent être dédiées entièrement à cette tâche.
– L’outil « oplan » fourni par Oracle est peu utile, il permet seulement de valider les étapes pour les mises à jour de la Grid Infrastructure et des ORACLE_HOME pour la base de données, mais ne prend pas en compte la mise à jour des autres composants ni le fait d’être dans une configuration Data Guard.
– Traiter les anomalies critiques relevées par « exacheck » en amont de la campagne. Faire un exacheck régulièrement avant de démarrer les opérations de patch pour ne pas que cela impacte le planning.
– Le traitement d’une SR de type P1 par le support Oracle s’est bien déroulée malgré l’heure de la demande. Éviter cependant le travail en heures non ouvrées pour limiter les risques et les contraintes.
– Valider l’état complet de la configuration après les opérations Data Guard de basculement (switchover), les rôles associés à certaines bases n’étaient pas toujours cohérents dans le registre du cluster et certains ont nécessité des corrections manuelles avant le démarrage correct des instances.
– Le traitement de la bascule des applications est à améliorer et à industrialiser. Beaucoup d’opérations manuelles, nécessité de faire un arrêt-relance, d’où une durée d’une heure à chaque bascule.

Au bilan, satisfaction globale de tous les acteurs, le planning prévisionnel a été respecté, indisponibilité minimale des systèmes, pas d’impact sur le comportement des applications. Une collaboration efficace et plaisante avec tous les membres de l’équipe. Merci à BPCE-IT de leur confiance et de nous permettre de communiquer sur le sujet.
Prêt pour de nouvelles campagnes avec nous ?