Your team is doing manually what Db2 12 already handles
Your team is doing manually what Db2 12 already handles. And they don't know it.
Backups that take longer than they should, failovers built on a product IBM no longer develops for Linux, downtime for operations the engine now handles online. If your team hasn't updated to Db2 12, they're doing more work than they need to — and possibly taking on risks they no longer have to.
IBM released Db2 12.1.5 on 9 June 2026 — the sixth mod pack since version 12 shipped in November 2024. With each one, the gap between how a DBA operates and what the engine already does on its own has kept growing. And nobody told the team.
It's not a competence problem. The product has changed underneath and nobody has brought the team up to speed. Version 11.5 has had no new features for years, and between it and 12.1 the engine handles high availability, backups, maintenance and even the types of data it can store in fundamentally different ways. But nobody told the team.
Five concrete situations where it shows. These aren't edge cases — they're the daily reality of a DBA who doesn't know their Db2 already handles what they've been doing by hand for years.
The failover your team builds on a product IBM no longer extends
This is the clearest case. Your team configures HADR for high availability. On Linux, they set up TSAMP (Tivoli System Automation) because that's what they learned. It works. But IBM is focusing its new HADR automation on Pacemaker and positions it as the strategic option for new Linux deployments. The reference cluster manager is now Pacemaker, open source, standard, simpler to operate.
On AIX, TSAMP remains fully supported. But on Linux, Pacemaker is the direction IBM is signalling, and the automation improves with every mod pack.
The backup window that no longer needs to be this wide
Before version 12, backups processed each tablespace with a single thread. On large databases, backup windows stretched and the DBA accepted them as inevitable. In Db2 12, the behaviour has changed on two specific fronts:
The maintenance that takes the service down to change a column
Changing the scale of a DECIMAL or widening a SMALLINT to INT on a columnar (BLU) table meant recreating the table, migrating data and verifying. In practice, scheduled downtime. In Db2 12.1.4 (March 2026) and 12.1.5 (June 2026), several of these operations no longer require an outage.
The architecture your team ruled out with 2022 criteria
This case breaks the pattern of the previous ones, but it's just as relevant: it isn't something Db2 12 does on its own, it's an architecture that is now viable and wasn't before. If anyone on your team evaluated Db2 pureScale — IBM's active-active high availability for Db2, conceptually comparable to Oracle RAC — they probably ruled it out over the hardware requirements. That was a valid criterion in 2022. It no longer is.
What your team assumes needs another database
A semantic search or RAG requirement comes up. The instinct is to assume you need another database: another vector engine, another backup, another monitoring system, another lifecycle to maintain. It may well be the right call. But it's worth knowing that Db2 12 already stores and queries vectors inside the same engine:
TO_EMBEDDING y TEXT_GENERATION that invoke watsonx.ai or OpenAI models directly from a SQL query.It's not a competence problem. It's an information problem.
All five cases share the same root cause: the team isn't doing things wrong. They're doing them as they were taught. The problem is that the product has changed and nobody told them. IBM has shipped six mod packs since November 2024. The procedures the team learned — whether on version 10 or 11.5 — no longer reflect how the engine works today.
And here's what matters: most of these problems aren't solved by buying hardware or adding headcount. They're solved by updating procedures. The risk isn't running Db2 badly — it's running Db2 12 as if it were Db2 11.5.
We've built two in-house courses that cover exactly this gap. They're not generic: they're updated to Db2 12.1.5, delivered on AIX and Linux, and tailored to the team's level. On-site or remote, in English, Spanish and French.
FAQ
Has Pacemaker replaced TSAMP in Db2 12?
Yes, on Linux. Pacemaker replaces Tivoli System Automation as the cluster manager for HADR. Configuration, validation and failover procedures change. On AIX, TSAMP remains available.
What does Db2 12 automate that used to be manual?
Multi-threaded backups with no extra configuration, history file maintenance decoupled from backup execution, online schema evolution on columnar tables, automatic archive log pruning and online index reorg without blocking.
Is there up-to-date Db2 12 training for AIX and Linux?
Yes. At SIXE we offer two in-house courses: Db2 LUW administration and pureScale deployment and administration. On-site or remote, in EN/ES/FR.
Can Db2 pureScale be deployed in the cloud?
Yes, since Db2 12. Self-managed on Azure (RoCE and TCP/IP, BYOL) and on AWS (with Elastic Fabric Adapter). Dedicated on-premises hardware is no longer required.
Is your team running Db2 without having caught up with v12?
Tell us which version you're on, how many DBAs need training and on which platform. We'll put together a tailored proposal — syllabus, format, dates and language.
