Votre équipe fait à la main ce que Db2 12 fait tout seul
Votre équipe fait à la main ce que Db2 12 fait tout seul. Et elle ne le sait pas.
Des sauvegardes plus longues que nécessaire, des failovers montés sur un produit qu'IBM ne fait plus évoluer sous Linux, de la maintenance avec arrêt pour des opérations que le moteur gère désormais en ligne. Si votre équipe n'est pas passée à Db2 12, elle travaille plus que nécessaire — et prend peut-être des risques évitables.
IBM a publié Db2 12.1.5 le 9 juin 2026 — le sixième mod pack depuis la sortie de la version 12 en novembre 2024. À chaque publication, l'écart entre la façon dont un DBA exploite son Db2 et ce que le moteur fait déjà tout seul n'a cessé de se creuser. Sans que personne ne prévienne l'équipe.
Ce n'est pas un problème de compétence. Le produit a changé en profondeur et personne n'a mis l'équipe à jour. La 11.5 n'a plus évolué depuis des années, et entre elle et la 12.1 le moteur gère autrement la haute disponibilité, les sauvegardes, la maintenance et même le type de données qu'il peut stocker. Mais personne ne l'a dit à l'équipe.
Cinq situations concrètes où cela se voit. Ce ne sont pas des cas particuliers : c'est le quotidien d'un DBA qui ignore que son Db2 fait déjà ce qu'il continue de faire à la main depuis des années.
Le failover que votre équipe monte sur un produit qu'IBM n'enrichit plus
C'est le cas le plus parlant. Votre équipe configure HADR pour la haute disponibilité. Sous Linux, elle met en place TSAMP (Tivoli System Automation) parce que c'est ce qu'elle connaît. Ça fonctionne. Mais IBM concentre ses nouvelles capacités d'automatisation HADR sur Pacemaker et le positionne comme l'option stratégique pour les nouveaux déploiements Linux. Le gestionnaire de cluster de référence est désormais Pacemaker, open source, standard, plus simple à exploiter.
Sous AIX, TSAMP reste pleinement pris en charge. Mais sous Linux, Pacemaker est la direction qu'indique IBM, et l'automatisation s'améliore à chaque mod pack.
La fenêtre de sauvegarde qui n'a plus besoin d'être aussi large
Avant la version 12, la sauvegarde traitait chaque tablespace avec un seul thread. Sur les bases volumineuses, les fenêtres s'étiraient et le DBA les acceptait comme inévitables. Dans Db2 12, le comportement a changé sur deux fronts concrets :
La maintenance qui arrête le service pour modifier une colonne
Modifier l'échelle d'un DECIMAL ou élargir un SMALLINT en INT sur une table columnaire (BLU) impliquait de recréer la table, migrer les données et vérifier. En pratique, un arrêt programmé. Dans Db2 12.1.4 (mars 2026) et 12.1.5 (juin 2026), plusieurs de ces opérations ne nécessitent plus d'interruption.
L'architecture que votre équipe a écartée avec les critères de 2022
Ce cas rompt un peu le schéma des précédents, mais il est tout aussi pertinent : ce n'est pas quelque chose que Db2 12 fait tout seul, c'est une architecture désormais viable qui ne l'était pas avant. Si quelqu'un dans votre équipe a évalué Db2 pureScale — la haute disponibilité actif-actif d'IBM pour Db2, conceptuellement comparable à Oracle RAC — il l'a probablement écarté à cause des exigences matérielles. C'était un critère valable en 2022. Ça ne l'est plus.
Ce que votre équipe suppose nécessiter une autre base de données
Un besoin de recherche sémantique ou de RAG apparaît. Le réflexe est de supposer qu'il faut une autre base de données : un autre moteur vectoriel, une autre sauvegarde, un autre système de supervision, un autre cycle de vie à maintenir. C'est peut-être le bon choix. Mais il vaut la peine de savoir que Db2 12 stocke et interroge déjà des vecteurs au sein du même moteur :
TO_EMBEDDING y TEXT_GENERATION qui invoquent des modèles watsonx.ai ou OpenAI directement depuis une requête SQL.Ce n'est pas un problème de compétence. C'est un problème d'information.
Les cinq cas ont un point commun : l'équipe ne fait pas les choses mal. Elle les fait comme on le lui a appris. Le problème, c'est que le produit a changé et que personne ne le lui a dit. IBM a publié six mod packs depuis novembre 2024. Les procédures apprises — que ce soit avec la version 10 ou la 11.5 — ne reflètent plus le fonctionnement actuel du moteur.
Et voici l'essentiel : la plupart de ces problèmes ne se résolvent pas en achetant du matériel ni en recrutant. Ils se résolvent en mettant à jour les procédures. Le risque n'est pas de mal exploiter Db2 — c'est de continuer à administrer Db2 12 comme s'il s'agissait de Db2 11.5.
Nous avons construit deux formations propres qui couvrent précisément cette lacune. Ce ne sont pas des cours génériques : ils sont mis à jour pour Db2 12.1.5, dispensés sur AIX et Linux et adaptés au niveau de l'équipe. En présentiel ou à distance, en français, anglais et espagnol.
Questions fréquentes
Pacemaker a-t-il remplacé TSAMP dans Db2 12 ?
Oui, sous Linux. Pacemaker remplace Tivoli System Automation comme gestionnaire de cluster pour HADR. Les procédures de configuration, validation et basculement changent. Sous AIX, TSAMP reste disponible.
Qu'est-ce que Db2 12 automatise par rapport aux versions précédentes ?
Sauvegardes multi-thread sans configuration supplémentaire, maintenance du history file découplée de la sauvegarde, évolution de schéma en ligne sur tables columnaires, purge automatique des archive logs et réorganisation d'index en ligne sans blocage.
Existe-t-il une formation Db2 12 à jour pour AIX et Linux ?
Oui. Chez SIXE, nous proposons deux formations : administration Db2 LUW et déploiement et administration de pureScale. En présentiel ou à distance, en FR/EN/ES.
Db2 pureScale peut-il être déployé dans le cloud ?
Oui, depuis Db2 12. En self-managed sur Azure (RoCE et TCP/IP, BYOL) et sur AWS (Elastic Fabric Adapter). Le matériel dédié on-premises n'est plus requis.
Votre équipe exploite Db2 sans s'être mise à jour sur la v12 ?
Dites-nous quelle version vous utilisez, combien de DBA ont besoin de se former et sur quelle plateforme. Nous vous préparons une proposition sur mesure — programme, format, dates et langue.
