Suite au déploiement d'une nouvelle version du trigger after-logon le 25/02, les bases BI en lecture seule sont devenues inaccessibles, rendant les applications BI inopérantes. L'incident a été détecté le 26/02 au matin mais n'a été pris en charge qu'en après-midi en raison d'une équipe en formation. Un correctif a été livré le 26/02 entre 16h30 et 17h00 pour l'ensemble des environnements concernés.

Les applications BI étaient inopérantes pour les clients sur les environnements OMSAAS, les requêtes sur les bases en lecture seule étant impossibles. Le client HM Ramsay a nécessité un correctif spécifique livré séparément. GTI constatée : 2h50, GTR constatée : 3h24.

Remontée client — détection par supervision manuelle (Noëlle) le 26/02 à 09h14, puis escalade progressive via le canal Teams BI/infra.

Causes immédiates : Livraison d'une nouvelle version du trigger after-logon qui ne gérait pas correctement le mode de connexion en lecture seule (read-only).

Causes racines : La gestion des exceptions dans le code du trigger est trop permissive et entraîne des comportements inattendus. Les tests du trigger ne sont pas automatisés et n'incluent pas systématiquement un scénario de connexion sur une base en read-only.

Faits aggravants : Communication tardive sur les problèmes rencontrés lors du merge initial (échec Nexus). L'équipe BDD et le support concerné étaient en formation au moment de la déclaration de l'incident, retardant la prise en charge de près de 3 heures.

Correction du code du trigger after-logon pour permettre le fonctionnement en mode read-only. Livraison du correctif sur l'ensemble des environnements OMSAAS à 16h30, puis correctif spécifique pour l'environnement Ramsay à 17h00.

Ce qui s'est bien passé : Livraison rapide d'un correctif une fois le sujet pris en charge par le pôle BDD (correctif livré en moins de 35 minutes après prise en charge).

Ce qui s'est mal passé : Tests insuffisants avant déploiement — absence de test automatisé sur base en read-only. Remontée du problème uniquement via un message Teams vers le pôle BDD, sans ouverture d'incident formelle. Délai important entre la détection (09h14) et la prise en charge effective (15h56). Il aurait été possible de modifier les paramètres de connexion de la BI pour pointer vers les bases de production comme

Des erreurs internes Oracle (ORA-600) causées par une requête SQL problématique ont provoqué des verrous internes ('library cache lock' et 'cursor pin S wait on X') dans le shared pool de la base de données. Ces verrous ont progressivement bloqué de plus en plus de sessions, rendant l'application HMBloc indisponible. L'incident a été résolu par un redémarrage de l'instance Oracle et des serveurs Tomcat.

Lenteurs applicatives sur HMBloc à partir de 8h55, suivies d'une indisponibilité totale de l'application entre 9h24 et 10h00.

Première occurrence avec ces symptômes (ORA-600 suivi d'un blocage général des sessions).

Détection via la supervision Zabbix, notamment sur le nombre de sessions actives. Une alerte sur le remplissage du volume /logs avait également été déclenchée la nuit précédente mais n'avait pas été prise en charge.

Causes immédiates : Verrous internes Oracle de type 'library cache lock' et 'cursor pin S wait on X' dans le shared pool, bloquant progressivement toutes les sessions applicatives.

Causes racines : Une requête SQL spécifique (SELECT * FROM ... impliquant plusieurs jointures sur les tables HMBloc) génère des erreurs internes ORA-00600 avec l'argument [KGL-heap-size-exceeded], provoquant un dépassement de la taille du heap du Library Cache (512 000K détectés, seuil à 51 200K). Cette requête avait déjà été identifiée comme problématique et un correctif (réécriture) avait été livré, mais n'était pas déployé sur ce client en raison de son processus de montée de version.

Faits aggravants : L'alerte de supervision sur la saturation du volume /logs générée la nuit (liée aux traces ORA-600) n'a pas été prise en charge, retardant la détection et la résolution d'environ 10 minutes. Par ailleurs, le redémarrage de l'instance Oracle seul n'a pas suffi : le nombre de connexions Tomcat résiduel était trop important, nécessitant un redémarrage complémentaire des serveurs Tomcat.

Redémarrage de l'instance Oracle (base P01AM) suivi du redémarrage des serveurs Tomcat pour purger les connexions résiduelles et rétablir un état stable.

Ce qui s'est bien passé : La supervision Zabbix a correctement détecté et alerté sur le nombre de sessions actives anormales. L'alerte sur le remplissage de /logs avait également été déclenchée dès la nuit précédente.

Ce qui s'est mal passé : L'alerte ORA-600 / saturation des logs de la nuit n'a pas été traitée, aggravant la situation le lendemain matin. Le correctif de la requête SQL problématique, pourtant déjà identifiée et livrée, n'avait pas été déployé sur ce client. Le redémarrage Oracle seul s'est avéré insuffisant, nécessitant également un redémarrage Tomcat en raison d'un nombre de connexions max trop important par serveur.

Le 12 février, une duplication de code fonctionnel 'R' dans le catalogue de priorités a provoqué une indisponibilité totale du service d'accueil pendant 2h30. La requête applicative ne filtrant pas les enregistrements supprimés, elle a reçu deux résultats au lieu d'un et a déclenché une exception bloquante. L'incident a impacté 27 utilisateurs et empêché la prise en charge de 166 patients.

Le service d'accueil patient d'un client a été totalement indisponible pendant 2h30, empêchant la prise en charge de 166 patients. 27 utilisateurs ont été bloqués dans leur activité. Aucune alerte automatique n'a été déclenchée, le client ayant lui-même servi de système de détection.

Première occurrence de ce problème.

Aucune alerte automatique ne s'est déclenchée. La détection a reposé entièrement sur les utilisateurs : 24 minutes se sont écoulées entre la première erreur bloquante et l'appel au support, puis 25 minutes supplémentaires avant la prise en charge effective.

Causes immédiates : Deux enregistrements coexistaient en base pour le code fonctionnel 'R' (un actif, un supprimé logiquement). La requête applicative ne filtrait pas les enregistrements supprimés et attendait un résultat unique — elle en a reçu deux, déclenchant une exception bloquante.

Causes racines : La règle métier 'ne pas tenir compte des enregistrements supprimés' était appliquée à l'écriture (création d'un code) mais pas à la lecture (récupération d'un code). Cette asymétrie entre les opérations de lecture et d'écriture est la cause racine de l'incident.

Faits aggravants : 1. Absence d'alerting automatique : aucune alerte déclenchée sur les premières erreurs bloquantes, le client a servi de monitoring. 2. Utilisation d'un compte partagé (adm2) : traçabilité impossible, on ne sait pas pourquoi ni dans quel contexte la création du code a été effectuée. 3. Absence de validation à la création : le système a permis la création d'un code 'R' actif sans avertir qu'un code

L'incident a été résolu en renommant le code supprimé de 'R' en 'R1' via l'interface One Manager, éliminant ainsi le doublon. Cette résolution est un contournement ponctuel : le problème de fond (absence de filtre sur les suppressions logiques côté lecture) reste présent dans le code et nécessite un correctif pérenne.

Ce qui s'est bien passé : Une fois l'escalade effectuée, la collaboration entre le support et l'équipe de développement a été efficace : le correctif a été livré en 1h20 sans information supplémentaire à aller chercher. Les membres de l'équipe de développement se sont mobilisés rapidement dès réception de l'escalade, même sans savoir qu'il s'agissait d'un SEV-1.

Ce qui s'est mal passé : 1. Aucun message d'erreur clair affiché à l'utilisateur en cas de doublon : l'application plante sans indication exploitable, compliquant le diagnostic et aggravant l'impact perçu. 2. Détection trop tardive : 50 minutes perdues au total entre la première erreur et la prise en charge, sans aucune alerte automatique. 3. Sévérité mal évaluée dès le départ : l'incident bloquait complètement une foncti

Chanceux : 1. L'incident s'est produit en journée avec l'équipe disponible. La nuit ou un week-end, le temps de résolution aurait été bien supérieur. 2. Un seul client était concerné. Si ce bug avait touché plusieurs clients simultanément, la résolution manuelle aurait été bien plus complexe.

Dans la nuit du 9 février, les traitements BI ne se sont pas lancés sur 8 infrastructures (SAAS4, SAAS7, SAASDOMTOM et 5 sites clients). Les traitements se sont effectués plus tardivement qu'habituellement, sans nécessiter d'intervention manuelle. La situation est revenue à la normale progressivement dans la journée.

8 infrastructures non à jour au matin du 9 février : SAAS4, SAAS7, SAASDOMTOM, TORCY (0044000), Mutualité de la Loire (0763002), SAINT PRIEST (0771000), RENNES (1518000), MARTINIQUE SAINT PAUL (1529000). Les statistiques BI n'étaient pas disponibles en début de journée pour les clients concernés, avec une mise à jour progressive dans la journée. Aucun impact financier direct mentionné.

1ère occurrence connue de ce problème.

Détection via la vérification quotidienne manuelle effectuée par Noëlle, signalée dans le canal Teams à 12h07 le 9 février.

L'incident s'est résolu de lui-même, sans nécessiter d'action manuelle. Les traitements BI se sont exécutés avec retard et les statistiques se sont mises à jour progressivement dans la journée. Une investigation Infra a été lancée sur les machines qvw1-pbs1, qvw1-pbs2 et qvw1-qms pour identifier la cause racine.