Un système IBM Maximo sous pression de données
SUEZ SA, acteur mondial de la gestion de l’eau et de l’environnement, s’appuie sur IBM Maximo pour piloter l’ensemble de ses interventions terrain dans le cadre du projet IPOP. Avec des années d’exploitation, les tables actives de la base de données ont accumulé des millions d’ordres de travail au statut « Archivée ».
Cette surcharge progressive dégradait les temps de réponse des recherches, alourdissait les requêtes opérationnelles et faisait peser un risque croissant sur la stabilité du système. Il devenait impératif d’agir — sans sacrifier l’accès aux données historiques.
Le défi : archiver sans interrompre, sans perdre
Déplacer automatiquement les interventions clôturées vers des tables d’archive dédiées, tout en maintenant la continuité de service et l’intégrité des données historiques.
- Volume important de données réparties sur 6 tables liées (
WORKORDER,WOSTATUS,LABTRANS…) - Continuité de service absolue — aucune interruption réseau admissible
- Zéro dégradation des performances Maximo en production
- Traçabilité complète et gouvernance des opérations d’archivage
Choix de la solution : comparatif des trois approches
Sinorfi a analysé trois architectures d’archivage disponibles dans l’écosystème IBM Maximo avant de recommander la solution optimale.
| Critère | Solution 1 — Java natif | Solution 2 — Java + SQL | Solution 3 — Job SQL autonome |
|---|---|---|---|
| Performance | Lenteur sur grands volumes | Exécution correcte mais limitée | ✓ Exécution hors JVM Maximo — optimale sur tout volume |
| Coupure réseau | Traitement interrompu | Traitement interrompu | ✓ Aucun impact — le Job SQL continue indépendamment |
| Ressources Maximo | Forte consommation Java | Forte utilisation système | ✓ Aucune allocation depuis Maximo |
| Impact applicatif | Risque de plantage | Ralentissement possible | ✓ Aucun impact direct sur Maximo |
| Stabilité | Moins fiable | Risques de surcharge | ✓ Très fiable — traitement SQL autonome |
Architecture : une solution découplée de Maximo, pilotée par Job SQL
La solution repose sur un filegroup SQL Server dédié à l’archivage, séparant physiquement les données historiques des données actives. Ce découplage garantit qu’aucune opération d’archivage ne consomme les ressources de l’application Maximo.
Une tâche périodique Maximo (INSTANCE) déclenche le Job SQL selon le planning défini. Le Job orchestre ensuite le cycle complet de manière autonome : copie vers les tables d’archive, suppression dans les tables actives, et journalisation des traitements.
Les tables d’archive miroir sont synchronisées en temps réel avec la structure des tables principales. Tout attribut ajouté ultérieurement ne nécessite qu’une mise à jour ciblée, garantissant l’évolutivité du dispositif.
Stack technique : IBM Maximo · SQL Server Job · Tâche périodique · Filegroup dédié · Tables miroir
Deux modes d’archivage adaptés à chaque besoin
- 01 — Mode Isolé · Archivage unitaireTraitement d’un ordre de travail individuel avec l’ensemble de ses sous-objets liés (statuts, main d’œuvre, adresses…). Idéal pour les régularisations ciblées et la vérification d’un cas précis avant un archivage en masse.
- 02 — Mode Lot (Batch) · Archivage en masseTraitement groupé d’un ensemble d’interventions selon des critères configurables (statut, date, groupe). Conçu pour les purges planifiées à grande échelle, maximisant l’efficacité des opérations de maintenance.
Une interface de pilotage intégrée dans IBM Maximo
Sinorfi a développé et intégré nativement dans Maximo une application Configuration d’archivage, accessible aux administrateurs MAXADMIN, couvrant l’ensemble du cycle de vie.
- ConfigurationParamétrage des tables principales, tables d’archive, groupes d’archivage, conditions d’exécution (Isolé / Lot) et tables filles associées.
- PlanificationProgrammation des instances de traitement avec choix de la méthode, de la fréquence et du groupe cible. Visualisation du planning actif.
- HistoriqueSuivi complet des opérations : statut d’exécution, date, table concernée, groupe, méthode utilisée et messages d’erreur détaillés.
- StatistiquesVisualisation de l’évolution du volume archivé par table et par année, permettant de piloter la capacité et d’anticiper les besoins futurs.
- EscaladeMécanisme de remontée des anomalies de traitement pour alerter les équipes techniques en cas d’échec d’un Job SQL.
- Liste des archivesConsultation centralisée de l’ensemble des archives disponibles, avec filtres par objet, période et groupe pour retrouver rapidement les données historiques.
Résultats : des bénéfices concrets et mesurables
- Base de données active allégée — Les tables opérationnelles Maximo ne contiennent plus que les données vivantes. Les recherches et rapports sont sensiblement accélérés, avec une réduction directe de la charge sur le moteur SQL Server.
- Continuité totale de service — Grâce à l’architecture Job SQL autonome, les opérations d’archivage n’impactent jamais les utilisateurs Maximo. Aucun ralentissement ni interruption applicative n’a été constaté en production.
- Accès préservé aux données historiques — Les tables d’archive dédiées maintiennent l’intégralité des données passées, consultables à tout moment depuis l’interface Maximo sans délai de reconstruction.
- Gouvernance et traçabilité complètes — Chaque opération est journalisée : date, table, groupe, méthode, statut. Les équipes SUEZ disposent d’une visibilité totale sur l’historique des archivages.
- Solution évolutive et autonome — L’architecture modulaire permet d’étendre l’archivage à de nouveaux objets Maximo sans refonte. Les administrateurs pilotent l’ensemble depuis l’interface native, sans dépendance à Sinorfi pour les opérations courantes.
