Deux usines bloquées par un problème… déroutant sur une base Oracle

Il est minuit. Plus aucune connexion n’est possible sur une base Oracle stratégique. Ce blocage provoque la paralysie de deux usines fonctionnant en 24h/24 (merci à l’approche Flux Tendu…).

Les nouvelles approches de Production en flux tendu permettent une réduction drastique des stocks. Mais cette approche risque de causer un arrêt des lignes de Production. Et les dépendances entre usines ne font qu’aggraver la situation.

Evidemment, pour des raisons déontologiques rigoureuses, l’identité des usines concernées reste confidentielle  !

Le constat du problème

Sur l’usine n° 1, les applications ne peuvent plus se connecter à la base. Les administrateurs du site ne trouvent aucune explication. Un redémarrage de la base et même du serveur ne permettent pas un retour au fonctionnement de l’application.

L’usine n’a pas souscrit de contrat d’assistance 24h/24 pour prendre en charge ce type de problèmes.

La production de l’usine n° 1 ne part plus vers l’usine n° 2, qui est bloquée à son tour très rapidement.

Une perte financière très importante sera constatée, ainsi que l’obligation de rendre des comptes sur les responsabilités engagées.

Un dépannage provisoire

Un redémarrage a été possible au bout d’environ 8h d’arrêt en exportant la base de Production et en la rechargeant sur un autre serveur. Cette solution ne pouvait être que provisoire et n’expliquait pas l’origine du problème.

Pourquoi ce plantage

DIGORA a été sollicité le lendemain pour diagnostiquer ce problème. Ayant passé une nuit blanche, les informaticiens du site ont souhaité dormir le matin. Un consultant expert de DIGORA est donc intervenu le lendemain après-midi.

Un examen du serveur incriminé a conduit  aux constatations  suivantes :

• Le Listener Oracle (programme Oracle recevant les demandes de connexion et les associant aux bases d’un serveur) ne veut plus jouer son rôle
• Le fichier Log du Listener (listener.log) a atteint la taille astronomique de 32 Go !!!
• Lorsque le suivi des connexions dans le fichier Log du Listener est activé, aucune connexion n’est plus possible si le fichier a atteint sa taille limite
•  Il faut lancer les actions suivantes :
  
  • arrêter le Listener
  • effacer le fichier listener.log
  • éventuellement désactiver l’écriture des logs de connexion dans le fichier listener.log, ou à défaut effectuer un contrôle régulier de la taille de ce fichier (ou une remise à zéro périodique et automatique)
  • redémarrer le Listener

Comment éviter une telle situation à l'avenir ?

Une autre solution pourrait être la mise en oeuvre d’un PRA à condition que le PRA ne soit pas basé sur un Mirroring des disques du serveur Principal.

D’une façon générale, la meilleure garantie pour un client consiste à mettre en œuvre un système de supervision global (matériel, logiciel, réseau…). C’est le cas  de plus de 120 clients de Digora.

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.

Comme l’ont 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.