SQL Server Support: 24/7 Emergency Response and Upgrade Planning

• 01

  Emergency Incident Response

  Instance down, failover stuck, the log full, blocking or a restore that will not finish. A senior engineer joins a live bridge within 15 minutes, 24/7, with access to diagnose, not a ticket acknowledgement.

• 02

  Always On and Failover Cluster Support

  Replica modes, quorum, lag against your recovery point objective, listener and connection string behaviour, and login and job synchronisation. We rehearse failover on a non-production copy rather than discovering the gaps during an outage.

• 03

  Performance and Query Store Review

  Wait statistics first, then the queries behind them: regressed plans, parameter sniffing, statistics, parallelism settings, tempdb layout and memory. Fixes are proposed with evidence, not guesses.

• 04

  Backup, Restore and CHECKDB Verification

  The backup chain, the retention against your recovery objectives, restore tests on a scratch server and the date of the last clean DBCC CHECKDB for each database. A backup nobody has restored is a hope, not a plan.

• 05

  Cumulative Update and Security Advisory

  Which cumulative update and security fixes apply to the exact versions you run, a tested rollout order, and the evidence an auditor asks for. For SQL Server 2016, the steps to subscribe to Extended Security Updates.

• 06

  Upgrade Planning

  SQL Server 2016 and 2017 to a supported release: inventory, compatibility level and Query Store testing, a rollback plan and a cutover window. Microsoft's own migration guidance is the reference, and we test it against your workload.

• One SLA, One Escalation Path

  AceMQ holds the contract and the 15-minute response, and brings in partner SQL Server specialists as the problem needs them. You are never handed between companies in the middle of an incident.

• No Help-Desk Layer

  You reach a senior engineer directly by phone, email or Slack. No agent collecting details to relay, and no approval step between you and someone who can read a wait-statistics snapshot and act on it.

• The Application Is in Scope

  Many SQL Server incidents start in what the application does: transactions held open across a call, chatty connections, parameterised queries with skewed data. We look at the database and the workload that drives it.

• Honest About What We Cannot Patch

  SQL Server is Microsoft's. We do not offer patched builds, and we say so. Extended Security Updates come from Microsoft; we plan the route, test it and support the instance around it.

Source: Microsoft Learn lifecycle pages for each version, and Microsoft's Extended Security Updates article, checked 31 October 2026. Microsoft stamps each end date 06:59:59 on the following day; this table shows the calendar day in Redmond. Microsoft lists SQL Server 2016 Extended Security Updates in three annual periods, 15 July 2026 to 13 July 2027, to 18 July 2028 and to 17 July 2029.

• Dozens of sessions are waiting and the application times out

  A blocking chain: find the head blocker with sys.dm_exec_requests (blocking_session_id) and sys.dm_tran_locks, then see what its open transaction is doing. Usually it is a transaction held open across a slow call, an unindexed update or an escalated lock, not the SQL Server itself. Usual fix: shorter transactions, an index, or row-versioning isolation, after the head blocker is dealt with.

• Error 9002: the transaction log is full

  Query log_reuse_wait_desc in sys.databases. LOG_BACKUP means log backups are not running in the full recovery model. ACTIVE_TRANSACTION means a long-running or deferred transaction. AVAILABILITY_REPLICA means a secondary has not applied the log yet. Shrinking the file before the wait reason is fixed only repeats the problem. Usual fix: fix the wait reason, take the log backup, then size the log properly.

• A query that was fast is now slow after an upgrade, a patch or a compatibility level change

  Query Store, where the previous plan is still on record: compare plans for the query and look at runtime statistics around the change. A regression can be forced back to the last good plan as a stopgap while the cause (statistics, a changed estimate, parameter sniffing) is found. Usual fix: plan forcing as a stopgap, then the statistics, index or query fix.

• An availability group database shows NOT SYNCHRONIZING or the send and redo queues keep growing

  sys.dm_hadr_database_replica_states for the synchronization state, queue sizes and last_commit_time of every secondary. A suspended database on a secondary delays log truncation on the primary, so the log can fill while you look at the replica. Network, redo thread blocking and disk latency on the secondary are the usual causes. Usual fix: resume or reseed the secondary, and fix the network, disk or blocking cause.

• Failover happened, but the application cannot connect or jobs and logins are missing

  Whether the application connects through the availability group listener, and whether the connection string sets MultiSubnetFailover for a multi-subnet listener. Microsoft notes that, except for contained databases, logins and jobs on the former primary must be recreated on the new one, so we compare them across every replica. Usual fix: listener and connection string changes, plus login and job synchronisation.

• PAGELATCH waits on tempdb at peak load

  Allocation contention on a few system pages. We compare the number and size of tempdb data files, which should be equal, against the core count, and look at what is creating and dropping temporary objects at that rate. Modern versions create several files at setup, but older installs are often left at one. Usual fix: equally sized tempdb files, and the workload that hammers them.

• DBCC CHECKDB reports corruption, or a restore fails partway through the chain

  Which pages are damaged, when the last clean CHECKDB and backup were, and whether the log chain is unbroken. We do not reach for REPAIR_ALLOW_DATA_LOSS first. Restoring from the last good chain to a scratch server shows what a recovery really takes. Usual fix: restore from a clean chain, then find the storage or memory cause.

• CPU is pegged and CXPACKET or CXCONSUMER waits dominate

  Cost threshold for parallelism (the default is 5, which Microsoft calls a starting point) and MAXDOP against the core count, then the top CPU queries in Query Store. Too many small queries going parallel is a common cause, as are missing indexes and stale statistics. Usual fix: parallelism settings and the worst queries, before any cores are added.

Something not on the list? Tell us what is breaking and a senior engineer will take it. SQL Server DBA services

• Upgrade, the durable answer

  Move to SQL Server 2022 or 2025, or to Azure SQL Managed Instance. Test the application at the new compatibility level with Query Store open so a regressed plan is visible, and keep a rollback path until the new version has run a full business cycle.

• Extended Security Updates through Azure Arc

  Microsoft's article says ESUs for SQL Server 2016 are available when an instance is connected to Azure Arc, with Software Assurance on an Enterprise Agreement, Enterprise Agreement Subscription, Server and Cloud Enrollment or Enrollment for Education Solutions, or with pay-as-you-go billing without Software Assurance. Azure bills hourly, and the subscription ends when you upgrade.

• ESUs on SQL Server on Azure VMs

  Instances on Azure virtual machines subscribe through the SQL IaaS Agent extension. Microsoft states that SQL Server 2016, unlike 2014, does not get free ESUs by moving to an Azure VM, so this is a subscription too.

• What an ESU is not

  ESUs cover vulnerabilities Microsoft rates Critical, with no regular schedule, and no new features or fixes you asked for. They do not include support for the underlying SQL Server version. Microsoft advises installing and validating the latest cumulative update when you subscribe, not when the first ESU ships.

Dates, options and a checklist for this week are in the full guide. SQL Server 2016 end of life

Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount. Request a quote

• Tier 1

  SQL Server 24/7 Support & Incident Management

  You run it, we back you up

  • 15-minute P1 response, 24/7, by phone, email or Slack
  • Senior engineers, no first-line triage layer
  • Written root-cause analysis after every P1

  Best for: Teams that run SQL Server themselves and need senior cover when production misbehaves at 3am.

  SQL Server 24/7 Support Quote
• Tier 2

  SQL Server 24/7 Support with Proactive Monitoring

  You run it, we watch it with you

  • Scheduled reviews of backups, restores and DBCC CHECKDB history
  • Availability group lag, quorum and failover rehearsals
  • Cumulative update and security advisory for your exact versions

  Best for: Teams that want the failed restore or the lagging replica found in a review, not in an outage.

  SQL Server Proactive Monitoring Quote
• Tier 3

  Managed SQL Server on Your Infrastructure

  We run it in your cloud or data centre

  • AceMQ holds the pager for your SQL Server instances
  • Cumulative updates and upgrades staged and tested first
  • Runs on Windows Server or Linux, virtual or bare metal, in your AWS or Azure account

  Best for: Estates that must keep SQL Server inside their own boundary and want someone else to run it.

  Managed SQL Server Quote
• Tier 4

  Fully Managed SQL Server on AceMQ Infrastructure

  We host it and run it, as a service

  • Hosted and operated by AceMQ
  • Backups, restore tests and high availability included
  • Cumulative updates and upgrades run for you

  Best for: Teams that want SQL Server without a DBA rota or the infrastructure underneath it.

  Fully Managed SQL Server Quote

Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.

• ConsultingSQL Server consulting and services
• Managed servicesManaged SQL Server services
• LifecycleEnd-of-life software support
• Enterprise supportOpen source support across your whole stack
• GuideSQL Server guide