Une base Oracle bloquée en plein jour férié : que faire ?

Nous sommes lundi matin. C’est un jour férié. L’application informatique principale  d’un groupement hospitalier se bloque. Pourquoi ? Comment la remettre en service ? Comment éviter une telle situation à l’avenir ?

Depuis les années 2000, les hôpitaux et les cliniques se sont dotés de systèmes d’information pertinents pour gérer le dossier patient et les processus de soins. Ces établissements de soins se sont équipés de solutions efficaces telles que celles édités par la société McKesson / CrossWay. Au niveau logiciel Oracle l’Editeur McKesson a souscrit  un contrat de support Digora.

Comme dans tout SI, un  incident de production matériel, logiciel ou réseau peut survenir avec les conséquences que l’on imagine sur le fonctionnement de l’établissement de soins…

Dans le cas qui nous intéresse, le client n’a pas de contrat d’assistance concernant le suivi de ses bases Oracle, ni auprès de son éditeur, ni auprès de Digora,  ni auprès de toute autre source d’assistance. En effet, l’acquisition d’un logiciel auprès d’un éditeur n’apporte pas de façon automatique le suivi de l’exploitation des bases et serveurs utilisés…

Pourquoi ce plantage

Oracle est une base de données extrêmement fiable. Mais si les valeurs maximum d’extension automatique définis pour les tablespaces d’une base sont atteints, la base se bloque… Lors de l’installation, l’éditeur paramètre la taille future de la base de façon confortable en fonction de différents critères. Puis il appartient au client de suivre l’évolution de sa base et d’anticiper en ajustant la croissance potentielle. Le client peut aussi déléguer ce suivi…

Donc, en la circonstance toute modification dans la base est devenue impossible par manque d’espace. Un mode dégradé est mis en place : crayon et papier !!!

D’autres causes de pannes plus graves peuvent aussi se produire, telles qu’une panne serveur, une panne de baie disque ou un sinistre, qui ne sont pas prévisibles. De ce fait, de nombreux clients Oracle mettent en place des solutions de type DataGuard.

Comment remettre l'application en service ?

La remise en service d’une application bloquée dans un tel contexte durant un jour férié ressemble à une course d’obstacles.

Voici le détail des étapes  :

• les utilisateurs de l’établissement de soins contactent l’astreinte informatique
• l’astreinte informatique essaye de résoudre le problème (ce qui n’a pas été le cas ici) ou escalade auprès de son responsable (nommé le client ci-dessous)
• le client essaye de résoudre le problème ou tente de contacter un autre employé du service qui aurait les compétences :  sans succès
• le client décide de se tourner vers DIGORA qui connait un peu son site; DIGORA n’a jamais été sollicité pour une mission préventive sur les bases Oracle et l’offre de contrat de supervision de DIGORA n’a pas été adoptée par ce groupe d’établissements
• le client contacte son commercial DIGORA (qui décroche par chance : nous sommes un jour férié)
• le commercial DIGORA contacte son responsable DIGORA (qui décroche par chance)
• le responsable DIGORA demande au service astreinte de DIGORA de dépanner le client bien qu’il n’ait pas de contrat
• l’astreinte DIGORA contacte le client pour obtenir plus de détails (contexte, nom du serveur Oracle, nom de la base, mots de passe, moyen de se connecter à la base à distance, etc…)
• l’astreinte DIGORA configure le VPN
• l’astreinte DIGORA pose le diagnostic  (manque d’espace) et élimine le problème
• l’application est à nouveau en service

Comment éviter une telle situation à l'avenir ?

Cette situation partiellement bloquante en production (le groupe hospitalier a fonctionné en mode dégradé sur papier pendant la matinée) aurait pu être détectée avec une console du supervision et un suivi de la base Oracle au quotidien.

En effet superviser les applications et ses systèmes sous-jacents permet d’intervenir de façon préventive dans plus de 80 % des cas.

Les problèmes potentiels sont détectés de façon anticipée permettant aux experts des domaines systèmes / bases de données ou applications d’intervenir de manière préventive.

Après étude, le retour sur investissement (ROI)  montre que 2 incidents mineurs équivalents rentabilisent déjà la mise en place d’un service supervision (indisponibilité utilisateur, opérations de rétablissement (plusieurs heures), désorganisation du service…).

Notre client a opté pour superviser l’ensemble des systèmes de production (7 applications majeures).

Comme l’on fait beaucoup de nos clients, vous pouvez demander à DIGORA de superviser vos applications de Production. Contactez-nous.

Voir aussi nos solutions de Services Managés.