IBM Db2 DBA & Support
Last reviewed by Tyler Eastridge
AceMQ provides remote and on-call DBA cover for IBM Db2 for Linux, UNIX and Windows (Db2 LUW) 11.5 and 12.1, and a written assessment of whether your databases should stay on Db2 or move to PostgreSQL. AceMQ engineers lead each engagement and partner Db2 specialists do the Db2-specific work, all under one AceMQ contract with a 15-minute emergency response. AceMQ is an independent provider: it is not an IBM partner or reseller, gives no licensing advice and supplies no IBM fixes. Db2 for z/OS is out of scope.
A senior engineer, not an SDR. No sales sequence attached.
Without a full-time Db2 hire or a rushed re-platformFor production incident cover, see AceMQ IBM Db2 24/7 support.
Customers
Partners
The Problem
Eight Db2 problems an AceMQ review starts from, a restore nobody has timed to a standby that keeps falling behind and a move to PostgreSQL that nobody has costed. If one describes your week, that is where the review starts.
The one DBA who knows the Db2 estate is retiring, and nobody else has run a restore and a rollforward
Backup images are taken every night, but archive logs are not shipped anywhere, so point-in-time recovery has never been tried
An HADR standby is falling behind and the log gap alert goes to a mailbox nobody reads
Applications fail with SQL0964C (transaction log full) or SQL0911N lock timeouts at month end
A query regressed after a REORG or a statistics change and nobody can say which plan it used before
Db2 11.5 base support ends on 30 April 2027 and the move to 12.1 has no owner
The IBM renewal is due and leadership wants to know whether every database still needs to be on Db2
Leadership asks whether PostgreSQL could replace Db2 and no one has listed what depends on Db2-only features
A good fit if you run Db2 for Linux, UNIX or Windows in production and need DBA cover that includes nights and holidays, or want a written answer to whether PostgreSQL could replace it.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy IBM Db2.
How it breaks, and the fix
When the primary fails, an HADR standby takes over. If the principal standby has received every log record it is the safe choice; if only an auxiliary standby in SUPERASYNC mode is available, the transactions it never received are lost. The synchronization mode you set months earlier decides how much, and how clients find the new primary decides how long the outage runs.
Primary lost, one standby behind
One primary, a principal standby and an auxiliary standby, reached through a connection pool
The primary serves the application and ships log records to both standbys, which replay them. The log gap on each standby stays small and the HADR state is peer on the principal standby.
The primary fails. Sessions error or hang, the auxiliary standby is behind on logs, and the principal standby holds nearly everything. A takeover on the wrong standby would lose committed work.
The principal standby takes over as the primary and the pool reconnects to it. The old primary is reintegrated as a standby once it is repaired, and the auxiliary standby re-attaches behind the new primary.
The takeover is the easy part. What decides the outcome is set months earlier: the synchronization mode (SYNC, NEARSYNC, ASYNC or SUPERASYNC) against how many lost transactions you can accept, which per IBM's documentation runs from the strongest protection on SYNC, where the log data is guaranteed to be stored at both sites, to the highest risk of loss on SUPERASYNC, where the primary never waits for the standby. Also set earlier: whether a cluster manager automates failover or a person decides, whether you monitor the log gap on each standby, and whether applications handle a reconnect on their own. A takeover rehearsal tests all four.
Our Services
AceMQ runs five Db2 service lines: remote DBA service, performance and capacity reviews, backup, recovery and HADR, fix packs and upgrades, and a fixed-scope health check. Any of them can roll into 24/7 on-call with a 15-minute emergency SLA. The stay-or-move assessment for PostgreSQL sits below.
Day-to-day Db2 administration done remotely by AceMQ and a partner Db2 DBA, from tablespace and user management to scheduled maintenance and on-call.
Recurring review of the SQL that costs the most, the access plans that changed, and the capacity trend, read from the monitoring table functions rather than guessed.
Recovery you have proven, not assumed: backup and log archive policy, timed restore and rollforward tests, standby health and a takeover that someone has rehearsed.
Fix pack planning, and the move between Db2 versions, tested on a copy first with the steps and the way back written down.
The fixed-scope entry engagement: a written report on the state of the estate that your own team can act on, with or without AceMQ afterwards.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ Db2 support gives you an AceMQ engineer and a 15-minute first response when a database is down or failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes still come from IBM: AceMQ does not produce them.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Db2 engagement runs in four stages: a scoping call with a quote within 1 hour, a written estate review, onboarding to cover with runbooks and assigned people, then scheduled remote DBA work with on-call. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: Db2 versions and fix packs, editions, HADR or pureScale, backup and log archiving, how many databases, who is on call today. A quote request is answered within 1 hour.
Scoped per estate
A fixed-scope review of backup and log archiving, a timed restore and rollforward, HADR state, fix pack level against IBM's support dates, configuration and the slowest recurring SQL. Findings are written and ranked by production risk before anything changes.
Scoped per estate
Alert routing, access arrangements you control, runbooks for the failures found in the review, and the AceMQ engineer and partner Db2 DBA assigned to your account.
Ongoing
Remote DBA work on a schedule, on-call response with a 15-minute P1 SLA, and a written review after each fix pack window or incident. If you want the PostgreSQL question answered, the feasibility assessment runs beside this.
A senior engineer, not an SDR. No sales sequence attached.
Stay or move
Moving off Db2 is a project, not a setting. AceMQ covers the database side: assessment, data movement, validation, cutover planning and rollback. Application code changes stay with your developers. This is the order the assessment runs in, and it ends with a recommendation that may be to stay.
Inventory
Every SQL PL routine, trigger and function, plus the features with no one-to-one PostgreSQL equivalent: pureXML columns, materialized query tables, federation nicknames, column-organized tables and temporal tables. Each one needs a decision, not an assumption.
Classify
Schemas, tables, indexes and views usually map cleanly. Routines are rewritten as PL/pgSQL by hand or with a tool and then tested. AWS SCT converts schemas and SQL code objects from Db2 LUW 9.1 to 11.5 to PostgreSQL targets, and AWS does not list 12.1 as a source, so a 12.1 estate needs that checked first.
Movement
A load during a window is simplest. Keeping Db2 live while PostgreSQL catches up needs change capture. Debezium's Db2 connector reads Db2 SQL replication (ASN) change tables, needs an initial snapshot, and its documentation says the replication needs a separate IBM InfoSphere Data Replication licence: check that with IBM before you design around it.
Decide
A rehearsal of the load and the cutover on a copy, a rollback path, and a written recommendation: move now, move in stages, or keep Db2 and put cover and an upgrade plan around it. Some estates should stay.
Typical engagements
Typical Db2 engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Regional Insurer
A typical engagement: AceMQ provides remote and on-call DBA cover for an insurer's IBM Db2 LUW estate and assesses which databases could move to PostgreSQL and which should stay.
PostgreSQL
Debezium
Telecommunications Operator
Remediation of a Grafana deployment that became unusable during incidents, with dashboards timing out exactly when engineers needed them most.
Grafana
Prometheus
KubernetesPostgreSQL
Digital Media Platform
Ongoing support for a Memcached tier prone to thundering-herd database load after node changes and cache expiry cliffs.
Memcached
LinuxPostgreSQLKubernetesSolutions
AceMQ covers IBM Db2 end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed IBM Db2 on your infrastructure and fully managed IBM Db2 on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running IBM Db2 for you.
Compare the four IBM Db2 support tiersSide by side
IBM supplies fix packs and defect fixes under your entitlement; it does not run your databases. AceMQ supplies the engineers who do, alongside IBM, and can assess a move to PostgreSQL for the databases that do not need Db2. A move is a project that Db2 cover has to survive. Each row answers one question about the choice.
| Question | Db2 on IBM support alone | Db2 with AceMQ cover | Move to PostgreSQL |
|---|---|---|---|
| Who answers at 3am? | IBM support under your entitlement. Response targets are in your IBM agreement. | An AceMQ engineer within 15 minutes, 24/7, with your topology and runbooks in front of them. IBM support is still where a defect that needs an IBM fix goes. | Db2 still needs cover until the last application moves. After cutover, a PostgreSQL support route takes over. |
| Who runs the databases day to day? | Your own DBAs. Vendor support answers questions about the product; it does not administer your databases. | AceMQ DBAs remotely, or your team with AceMQ on call. | Your team or a PostgreSQL provider, once the data and the applications have moved. |
| Where do fixes come from? | IBM fix packs and defect fixes, under your entitlement. | IBM, as before. AceMQ plans and applies fix packs and produces none of its own. | The PostgreSQL community releases. No IBM entitlement is involved. |
| What does IBM's calendar say? | Db2 11.5: base support ends on 30 April 2027, extended support runs to 30 April 2031 and is sold by IBM to customers who bought Db2 directly. Db2 12.1: IBM lists base end of support as TBD (IBM, 4 November 2026). | The same IBM dates. AceMQ plans the 11.5 to 12.1 upgrade so the deadline is met on a rehearsed path. | A move is not tied to an IBM date, but the project takes time and Db2 stays in service until it finishes. |
| What does a switch take? | Nothing changes. | A scoping call and a quote. Nothing changes in the databases before the written review. | SQL PL routines rewritten as PL/pgSQL, data types mapped, data moved by offline load or change capture, then validation and a rehearsed cutover. Application code changes are outside what AceMQ does. |
| When does it fit? | You have DBAs in-house and only need IBM's fixes. | You want IBM's fixes and a second team that runs the estate, answers at night and plans the 12.1 upgrade. | The databases use few Db2-only features, the renewal or the skills gap hurts, and you can fund a migration project. |
To see how a move to PostgreSQL is scoped, read PostgreSQL migration services.
One partner, not five
IBM Db2 rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on moving a database to PostgreSQL, plus the AceMQ services around Db2: change data capture, database support and managed operations.
FAQs
Five answers on Db2 from AceMQ: who provides DBA services besides IBM, what AceMQ cannot replace, what the 12.1 upgrade involves, when PostgreSQL makes sense, and what is out of scope.
Still have questions about IBM Db2? Email an Expert
AceMQ supplies remote and on-call DBA cover for IBM Db2 for Linux, UNIX and Windows 11.5 and 12.1. AceMQ engineers lead the engagement and partner Db2 DBAs do the Db2-specific work, all under one AceMQ contract and SLA, with a 15-minute response to a production emergency. It works alongside your IBM support entitlement, which is still where a defect that needs an IBM fix goes.
No. AceMQ is an independent provider, not an IBM partner or reseller. Fix packs and defect fixes come from IBM under your own entitlement, and AceMQ gives no licensing advice. AceMQ supplies the engineers who run, troubleshoot and patch the databases, plan fix packs and upgrades, and prepare the case for IBM with the diagnosis already done.
You install Db2 12.1 as a new copy, then upgrade each instance and each database, after checking the starting version and fix pack against IBM's published upgrade restrictions. AceMQ rehearses the whole sequence on a copy, with a fresh backup and a written way back, before production is touched. Db2 11.5 base support ends on 30 April 2027, which sets the deadline for most estates.
It depends on what the databases use, so the first step is an inventory, not a quote. Schemas and data usually move cleanly. SQL PL routines are rewritten as PL/pgSQL, and features such as pureXML, materialized query tables and federation need a decision each. The assessment ends in a written recommendation, which may be to stay on Db2 with cover and an upgrade plan. Application code changes are outside what AceMQ does.
No. AceMQ covers Db2 for Linux, UNIX and Windows. Db2 for z/OS and Db2 for i, and IBM-hosted Db2 services, are out of scope. If a mainframe Db2 feeds data to systems AceMQ does support, such as Kafka, say so in the scoping call and we will tell you what we can cover around it.
Yes. AceMQ works on IBM Db2 in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your IBM Db2 environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how IBM Db2 is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Db2 estate, tells you what cover fits and whether a PostgreSQL assessment is worth running, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email an IBM Db2 Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
