Le 11 mai 2026, la base de données Oracle P05OM s'est arrêtée suite à la corruption d'un bloc d'entête de fichier, elle-même conséquence d'un incident électrique survenu le 4 mai ayant affecté le stockage SAN. Une bascule sur l'infrastructure de secours a été réalisée mais la machine de secours, mal paramétrée, n'était pas en mesure d'absorber la charge de production, provoquant un second arrêt de service et allongeant significativement la durée d'interruption.

Interruption totale de l'accès à l'application sur une période de 2h19, avec 1h58 d'interruption effective répartie en trois plages : 12h12-12h52 (40 min), 13h05-13h35 (30 min) et 13h43-14h31 (48 min). Les utilisateurs n'ont pas pu accéder à l'application durant ces fenêtres.

Aucun antécédent connu de corruption de bloc en production.

Alerte de supervision de type "Impossible de se connecter à l'application".

Causes immédiates : Arrêt non planifié de l'instance Oracle P05OM suite à la détection d'un bloc corrompu sur une entête de fichier (datafile omsaas2_datlob1.910), rendant tout redémarrage impossible sans intervention manuelle (ORA-63999 : media failure).

Causes racines : La corruption de blocs trouve son origine dans la combinaison de deux facteurs : l'incident électrique du 4 mai ayant provoqué l'arrêt brutal d'un switch FC du SAN STDN, et un problème de configuration de zoning au niveau du SAN pour certains serveurs dont P05OM. Les corruptions initiales (blocs d'index) ont été partiellement traitées mais la corruption s'est propagée jusqu'à un bloc d'entête de fichier, provoquant l'arrêt définitif de l'instance. La fonctionnalité de réparation automatique Oracle EE (via la standby) n'a pas fonctionné, et la limite de rétention des archive logs à 3 jours a em

Faits aggravants : 1. La fonctionnalité de réparation automatique Oracle Enterprise Edition à partir de la base standby n'a pas fonctionné, empêchant une auto-correction transparente. 2. La configuration du serveur de secours n'était pas conforme à celle de la production : SGA configurée à 40 Go au lieu de 160 Go, et HugePages non activées ou mal configurées. Ces écarts ont provoqué un second arrêt de service après

Bascule en failover sur la base Oracle de secours. Reparamétrage de la SGA (40 Go → 160 Go). Identification et correction de la configuration HugePages non conforme (correction via Puppet + redémarrage serveur). Redémarrage manuel des services de connexion applicatifs. Vérification de la disponibilité de l'application et des SCLites.

Ce qui s'est bien passé : La décision de basculer sur l'infrastructure de secours a été prise rapidement et efficacement. La procédure de failover elle-même s'est déroulée correctement (bascule terminée en moins de 3 minutes). Les communications vers le client ont été régulières tout au long de l'incident.

Ce qui s'est mal passé : Le serveur secondaire n'était pas prêt à accueillir une charge de production : SGA insuffisante (40 Go au lieu de 160 Go) et HugePages non configurées conformément à la production. Ces écarts de configuration, qui auraient dû être détectés et corrigés en amont, ont provoqué un second arrêt de service et considérablement allongé la durée d'interruption. Par ailleurs, la limite de rétention des arch

Chanceux : La corruption n'a affecté qu'une seule base (P05OM) parmi l'ensemble des bases hébergées sur STDN, malgré l'ampleur de l'incident électrique. La base de secours (standby) était à jour et disponible, ce qui a permis un failover possible. Si la corruption avait également touché la standby, aucun bascu

Le 04/05/2026, une maintenance électrique réalisée par Digital Realty sur le PDU B2.01 du datacenter FR.PAR5 a provoqué un pic de consommation entraînant la disjonction du PDU10 et du PDU09B. Cette coupure électrique de quelques secondes a mis hors ligne plusieurs composants critiques de l'armoire R54B3, engendrant des ralentissements généralisés et des corruptions MySQL sur les plateformes Tamm.

Ralentissements sur toutes les applications de 12h15 à 12h35. Indisponibilité de P03TM de 12h23 à 13h58 (VM Share KO), de P01TM et P05TM de 12h23 à 12h50 (corruption MySQL / apaches KO). Indisponibilité de HM sur P07HM, P09HM et P17HM entre 12h15 et 12h20. Indisponibilité de OM sur omsaas2 de 12h28 à 12h30 et sur omsaas4/7/cXXX de 12h15 à 12h24. Le lendemain, nouvelles interruptions de service sur P01TM et P05TM dues aux corruptions MyISAM, nécessitant 2 jours de travail de décorruption par 2 architectes et un administrateur infra.

Incident similaire survenu une fois par an par le passé, généralement lors d'une maintenance datacenter. N'avait plus été observé depuis plusieurs années.

Détection par la supervision applicative et Oracle (ralentissements applicatifs et base de données).

Causes immédiates : La remise sous tension par Digital Realty sur le PDU B2.01 (FR.PAR5) a provoqué un pic de consommation à 19,5 A sur la voie B, entraînant la disjonction du disjoncteur interne du PDU10, coupant une partie des blocs prise voie B. Les deux voies électriques ont été indisponibles quelques secondes, provoquant la perte de plusieurs équipements de l'armoire R54B3 : un nœud SVC, un switch FC (euw1fr01-swfc06), 5 hyperviseurs ESXi, un optics, un serial console switch et un leaf (nx-leaf3-stdn). Le master Palo Alto a également redémarré.

Causes racines : Lors de l'intervention planifiée de Digital Realty sur le PDU B2.01, la remise sous tension a généré un appel de courant trop important (19,5 A) sur la voie B, déclenchant le disjoncteur interne du PDU. L'absence de protection ou de limitation du pic de courant lors de la remise sous tension est la cause racine de la coupure.

Faits aggravants : 1. Le moteur de stockage MyISAM utilisé par Tamm n'est pas résilient aux arrêts brutaux (crash), ce qui a entraîné des corruptions MySQL sur P01TM et P05TM, prolongeant l'impact au lendemain et nécessitant 2 jours de travail de remédiation. 2. La VM Share nécessaire aux applications Tamm est hébergée sur une seule VM sans redondance, ce qui a directement causé l'indisponibilité de P03TM. 3. Lors d

Relance des VMs indisponibles après rétablissement de l'alimentation électrique. Réparation des corruptions MySQL (mysqlcheck) sur P01TM et P05TM, avec isolation de MySQL2 le temps d'une passe extensive de vérification. Ouverture d'un case auprès de Digital Realty (CS4499545) le lendemain à 14h19 ; disjoncteur réarmé et redondance électrique restaurée à 15h15.

Ce qui s'est bien passé : Le lendemain, lors d'une autre maintenance programmée sur la même baie, deux serveurs ont été arrêtés préalablement de manière contrôlée. L'impact a été limité à un seul accès autonome client (ticket 2375), démontrant l'efficacité d'une préparation anticipée.

Ce qui s'est mal passé : 1. Les tables MySQL de Tamm sous moteur MyISAM ont été corrompues lors de l'arrêt brutal des ESXi, causant une indisponibilité prolongée pour la quasi-totalité des utilisateurs Tamm. 2. La tentative de réparation des tables MySQL2 de P05TM le lendemain a entraîné la réplication des instructions REPAIR vers MySQL1 (serveur d'écriture), déclenchant une réparation sur des tables saines et provoquant

Chanceux : Les serveurs MySQL d'écriture principaux de Tamm (P01TM, P03TM, P05TM) n'ont pas été arrêtés lors de l'incident initial, évitant ainsi une corruption des données à la source. Si ces serveurs avaient été coupés, la durée de l'interruption de service et l'effort de remédiation auraient été considérabl