Tu equipo resuelve a mano lo que Db2 12 hace solo. Y ni lo sabe.
Backups que tardan más de lo necesario, failovers montados con un producto que IBM ya no evoluciona en Linux, mantenimiento con parada para operaciones que el motor ya hace en caliente. Si tu equipo no se ha actualizado a Db2 12, está trabajando de más — y puede que asumiendo riesgos que ya no tiene por qué asumir.
IBM publicó Db2 12.1.5 el 9 de junio de 2026 — el sexto mod pack desde que la versión 12 salió en noviembre de 2024. Con cada uno, la diferencia entre cómo opera un DBA y lo que el motor ya hace por su cuenta no ha parado de crecer. Y nadie les ha avisado.
No es un problema de incompetencia. Es que el producto ha cambiado por debajo y nadie ha puesto al día al equipo. La 11.5 lleva años sin novedades, y entre ella y la 12.1 el motor gestiona de otra manera la alta disponibilidad, los backups, el mantenimiento e incluso el tipo de datos que puede almacenar. Pero al equipo nadie se lo ha contado.
Cinco situaciones concretas donde se nota. No son excepciones: son el día a día de un DBA que no sabe que su Db2 ya resuelve lo que él lleva años haciendo a mano.
El failover que tu equipo monta sobre un producto al que IBM ya no añade automatización
Este es el caso más claro. Tu equipo configura HADR para alta disponibilidad. En Linux, monta TSAMP (Tivoli System Automation) porque es lo que aprendió. Funciona. Pero IBM concentra las nuevas capacidades de automatización de HADR sobre Pacemaker y lo posiciona como la opción estratégica para los nuevos despliegues en Linux. El gestor de clúster de referencia ahora es Pacemaker, open source, estándar, más sencillo de operar.
En AIX, TSAMP sigue plenamente vigente. Pero en Linux, Pacemaker es la dirección que marca IBM, y la automatización mejora con cada mod pack.
La ventana de backup que ya no necesita ser tan grande
Antes de la versión 12, el backup procesaba cada tablespace con un solo hilo. En bases grandes, las ventanas se estiraban y el DBA las asumía como inevitables. En Db2 12, el comportamiento ha cambiado en dos frentes concretos:
El mantenimiento que para el servicio para cambiar una columna
Cambiar la escala de un DECIMAL o ampliar un SMALLINT a INT en una tabla columnar (BLU) implicaba recrear la tabla, migrar datos y verificar. En la práctica, una parada programada. En Db2 12.1.4 (marzo 2026) y 12.1.5 (junio 2026), varias de estas operaciones ya no requieren interrupción.
La arquitectura que tu equipo descartó con criterios de 2022
Este caso rompe un poco el patrón de los anteriores, pero es igual de relevante: no es algo que Db2 12 haga solo, es una arquitectura que ahora es viable y antes no. Si alguien en tu equipo evaluó Db2 pureScale — la alta disponibilidad activo-activo de IBM para Db2, conceptualmente comparable a Oracle RAC — probablemente lo descartó por los requisitos de hardware. Era un criterio válido en 2022. Ya no lo es.
Lo que tu equipo asume que necesita otra base de datos
Llega un requisito de búsqueda semántica o RAG. El reflejo es asumir que hace falta otra base de datos: otro motor vectorial, otro backup, otro sistema de monitorización, otro ciclo de vida que mantener. Puede que sea lo correcto. Pero conviene saber que Db2 12 ya guarda y consulta vectores dentro del mismo motor:
TO_EMBEDDING y TEXT_GENERATION que invocan modelos de watsonx.ai u OpenAI directamente desde una consulta SQL.No es un problema de competencia. Es un problema de información.
Los cinco casos tienen algo en común: el equipo no hace las cosas mal. Las hace como le enseñaron. El problema es que el producto ha cambiado y nadie se lo ha dicho. IBM ha publicado seis mod packs desde noviembre de 2024. Los procedimientos que el equipo aprendió — da igual si fue con la versión 10 o con la 11.5 — no reflejan cómo funciona el motor hoy.
Y aquí está lo importante: la mayoría de estos problemas no se resuelven comprando hardware ni añadiendo personal. Se resuelven actualizando procedimientos. El riesgo no es ejecutar mal Db2 — es seguir administrando Db2 12 como si fuera Db2 11.5.
Hemos construido dos formaciones propias que cubren exactamente esa laguna. No son cursos genéricos: están actualizados a Db2 12.1.5, se imparten sobre AIX y Linux, y se adaptan al nivel del equipo. Presencial o remoto, en español, inglés y francés.
Preguntas frecuentes
¿Pacemaker ha sustituido a TSAMP en Db2 12?
Sí, en Linux. Pacemaker reemplaza a Tivoli System Automation como gestor de clúster para HADR. Los procedimientos de configuración, validación y failover cambian. En AIX, TSAMP sigue disponible.
¿Qué hace Db2 12 de forma automática que antes era manual?
Backups multihilo sin configuración adicional, mantenimiento del history file desacoplado del backup, evolución de esquema online en tablas columnares, purgado automático de archive logs y reorg de índices online sin bloqueo.
¿Existe formación actualizada de Db2 12 para AIX y Linux?
Sí. En SIXE ofrecemos dos cursos propios: administración de Db2 LUW (sustituye al CL2X3G) y despliegue y administración de pureScale (sustituye al CL801G). Presencial o remoto, en ES/EN/FR.
¿Db2 pureScale se puede desplegar en nube?
Sí, desde Db2 12. Self-managed en Azure (RoCE y TCP/IP, BYOL) y en AWS (con Elastic Fabric Adapter). Ya no requiere hardware dedicado on-premises.
¿Tu equipo opera Db2 sin haberse puesto al día con la v12?
Cuéntanos qué versión tenéis, cuántos DBAs necesitan formarse y en qué plataforma. Te preparamos una propuesta a medida — temario, formato, fechas e idioma.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
