Impossibilité de lancer des requêtes sur les bases BI en lecture seule

Application(s) BI inopérantes

Remontée client

Causes immédiates : Livraison d’une nouvelle version du trigger after-logon La gestion des exceptions dans le code 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 test sur une base en read-only Communication tardive sur les problèmes rencontrés

• Correction code

Ce qui s'est bien passé : Livraison rapide d’un correctif une fois le sujet pris en charge côté pôle Tests insuffisants Remontée du problème (”juste” un teams vers le pôle DB). Il aurait été possible de modifier les paramètres de connexion de la BI pour faire pointer vers les bases de production

Résumé de l’incident

Nombre de clients impactés, produits impactés, features impactées, impact en cash

Quelle est la récurrence du problème? Lien vers les Post Mortems similaires

Comment l’incident a t’il été détecté?

Causes immédiates : Quelle est la cause immédiate Quelles sont les causes racines qui ont amener à la cause immédiate? Y a t’il eu des faits aggravants

Comment l’incident a été résolu Fermé/RCA/Récurrent/Prevention/Exécuté/Récurrence Possible 1 →Poor, 2→ Partiel, 3→ Nominal

Erreurs internes ORA-600 déclenchées par un code SQL problématique, ces erreurs ont entrainé des verrous internes bloquants ('library cache lock' et 'cursor pin S wait on X’) dans la zone mémoire ‘shared pool’; bloquant au fur et à mesure de plus en plus de sessions et empêchant l’application de fonctionner.

Lenteurs depuis 8h55, puis indisponibilité de l’application HMBloc entre 9h24 et 10h

Première fois avec ces symptomes (ORA-600 puis blocage)

Supervision zabbix

Causes immédiates : Verrous internes Quelles sont les causes racines qui ont amener à la cause immédiate? Problème avec une requête en particulier générant des erreurs internes : Errors in file /logs/diag/rdbms/p01am/P01AM/trace/P01AM_ora_28276.trc  (incident=1328391): ORA-00600: code d'erreur interne, arguments : [KGL-heap-size-exceeded], [0x0FF341658], [0], [524288008], [], [], [], [], [], [], [], [] Incident details in: /logs/diag/rdbms/p01am/P01AM/incident/incdir_1328391/P01AM_ora_28276_i1328391.trc Use ADRCI

Redémarrage de l’instance oracle et redémarrage des serveurs tomcat

Ce qui s'est bien passé : Détection du problème de saturation des logs pendant la nuit Alerte déclenchée par la supervision sur le nombre de sessions actives Erreur ORA-600 / saturation des logs non traité Nécessité de redémarrer les serveurs tomcat post-redémarrage de la base (nombre de connexions max trop important par seveur) Requête problématique déjà identifiée mais correctif pas déployé

Le 12 février, le service d'accueil d'un client a été totalement indisponible pendant 2h30, empêchant la prise en charge de 166 patients et impactant 27 utilisateurs.

C’est la première fois que nous sommes confrontés à ce problème

Causes immédiates : Les logs pour : - 1 seul utilisateur - 1 accueil patient Deux enregistrements coexistaient en base, pour le code fonctionnel 'R' : La requête applicative ne filtrait pas les enregistrements supprimés. La logique attendait un résultat unique — elle en a reçu deux, déclenchant une exception bloquante. La règle métier "ne pas tenir compte des enregistrements supprimés" était bien appliquée à l'écriture (création d'un code), mais pas à la lecture (récupération d'un code). Cette asymétrie est la sou

L'incident a été résolu en renommant le code supprimé de 'R' en 'R1' via l'interface One Manager, éliminant ainsi le doublon. Note : Cette résolution est un contournement ponctuel, pas un correctif pérenne. Le problème de fond (absence de filtre sur les suppressions logiques) reste présent dans le code. Fermé/RCA/Récurrent/Prevention/Exécuté/Récurrence Possible 1 →Poor, 2→ Partiel, 3→ Nominal

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 alors qu’elle ne savait pas que l’incident était un SEV-1 En cas de doublon, aucun message clair n'est affic

8 Infras non à jour le Lundi 9/02 matin. SAAS4 SAAS7 SAASDOMTOM 0044000 TORCY 0763002 Mutualité de la loire 0771000 SAINT PRIEST 1518000 RENNES 1529000 MARTINIQUE SAINT PAUL 0263 Les traitements BI se sont effectués plus tardivement qu’habituellement. Aucune action manuelle n’a été nécessaire côté BI. Les stats se sont mis à jour progressivement dans la journée. Hostnames machine sur lesquels le problème a été rencontré: qvw1-pbs1, qvw1-pbs2, qvw1-qms.

Nombre de clients impactés, produits impactés, features impactées, impact en cash

Quelle est la récurrence du problème? 1ère fois que l’on rencontre (ou qu’on se rend compte de) ce problème.

Comment l’incident a t’il été détecté? Vérification de Noëlle quotidienne.

Causes immédiates : Quelle est la cause immédiate: ? Quelles sont les causes racines qui ont amener à la cause immédiate? Y a t’il eu des faits aggravants

Comment l’incident a été résolu L’incident s’est résolu tout seul. Aucune action n’a été nécessaire. Fermé/RCA/Récurrent/Prevention/Exécuté/Récurrence Possible 1 →Poor, 2→ Partiel, 3→ Nominal