Introduction

Au sein d'Epsilon Composite, DataExchanger (ou simplement nommé DEX) est un progiciel utilisé afin de réguler les flux et les données d'autres serveurs et services.  Il permet de contrôler les échanges et interfacer les différentes sources de données et applications. Il est principalement utilisé afin de gérer l'interconnexion et la translation des données entre Cimag et Sage X3. DEX possède son propre serveur. Généralement, peu de maintenance est requise. Il arrive cependant de devoir gérer des pannes ou des bugs. 

Problème rencontré

Le serveur DEX transmet un message d'erreur et un fichier de log, par mail, en continue.

En parallèle, les opérateurs de production signalaient des ralentissements et même des arrêts des fonctionnalités de DEX ; pour eux, cela se manifestait par le fait qu'ils ne pouvaient plus imprimer les étiquettes qui doivent être collées sur le produit (à différentes étapes de la production).

Après analyse de ce message, le problème fut ciblé : la base de données "DEX_DEV" est pleine. Pourtant cette BDD était configurée pour "grandir automatiquement", par blocs de 64Mo. Cependant, en accédant à la base de donnée, j'ai constaté qu'elle n'avait que 0.2Mo d'espace disponible.

Après des recherches plus approfondie, je me suis aperçue que la base dépendait d'une 'structure' de taille supérieure qui est limitée à 10Go maximum, étant une base SQLEXPRESS (limite fixée par Microsoft). Cette base ayant atteint son maximum de capacité, "DEV_DEX" ne pouvait plus grandir.

Actions

Arrêt des services d'ordonnancement sur le serveur DEX

Le but était d'arrêter de ne plus permettre à la production de mener certaines activités, comme l'impression d'étiquettes. Si les opérateurs ne peuvent plus imprimer, il n'y a plus de requêtes émises vers DEX et donc plus de traitement en lecture/écriture sur la BDD pour ne pas le saturer. 

Le but était double puisque cela à également permis d'arrêter de générer des logs qui continuaient de flood les boîtes mails des différents comptes du SI et qui pouvaient donc nuire à la détection d'autres problèmes potentiels.

Nettoyage de la BDD

Pour rétablir les services au plus vite, et donc reprendre la production, il était important de libérer de la place sur la BDD.

Habituellement, cette tâche se fait en fond ; tous les jours, à midi, DEX purge les flux de plus de 15 jours. Cependant, l'entreprise a récemment augmenté la cadence de production et ce paramétrage n'est visiblement plus suffisant.

Une purge manuelle était donc nécessaire pour libérer "instantanément" du stockage. Cette purge a ciblée une période plus courte de 10 jours. Cela a permis de libérer environ 5Go de stockage, et donc de laisser DEX_DEV fonctionner à nouveau normalement.

Rapport aux équipes

Un mail a informé les équipes de production que le service était de nouveau opérationnel. Un autre a été fait pour l'équipe SI afin de rendre compte du processus de solutionement mais également des actions à mener sur le long terme, afin de prévenir la situation de se reproduire : 

1. Afin de limiter les problèmes à l'avenir, le paramétrage de la purge automatique a été modifier pour supprimer les flux datant d'il y a 10 jours ou plus, contre 15 précédemment. Ceci est amené à évoluer à nouveau, puisque l'entreprise va passer sur un cycle de production en 24/7 dans les prochains mois.
2. Il faut analyser si des "points de reprise" sont utilisés au sein d'Epsilon. Ils permettent de reprendre un flux stoppé à partir d’une sauvegarde faite à un instant T. Or, ces sauvegardes entraînent l'utilisation d'une partie du stockage étant donné que le checkpoint retient le flux antérieur non complet. Il y a donc besoin de déterminer si l'entreprise en utilise et, le cas échéant, de réduire leur nombre si possible
3. La BDD est actuellement un base "SQL express" ce qui bride le stockage à 10Go. Upgrade vers une license classique permettrait de limiter la taille de la BDD à celle du disque présent sur le serveur.