SQL Server 2014 SP3 CU4: What You Need to Know

SQL Server 2014 SP3 CU4 (Cumulative Update 4 for Service Pack 3) is a critical patch release from Microsoft that addresses multiple stability, security, and correctness issues in SQL Server 2014. If you're still running SQL Server 2014 in production, this update should be on your patching schedule immediately. SQL Server 2014 entered Extended Support in July 2019, which means Microsoft no longer ships new features or general fixes. What you do get are security patches and targeted cumulative updates, and every one of them matters more than it did during mainstream support.

Extended Support environments carry a different risk profile. You're running older software that's no longer being actively improved, only patched when something breaks badly enough to warrant it. That makes each cumulative update more significant, not less. Skipping patches on an Extended Support product is how organisations end up with preventable outages and security exposures.

What Does SQL Server 2014 SP3 CU4 Fix?

SP3 CU4 addresses a focused set of issues that have real operational impact. These aren't minor edge cases. Several of them affect core SQL Server functionality in ways that can cause data integrity problems or unexpected downtime.

The key fixes included in this cumulative update are:

  • SQL Agent jobs failing due to blocking in SSISDB. If you're running SSIS packages via SQL Agent jobs and experiencing intermittent failures, this fix is directly relevant. Blocking in the SSISDB catalogue can cause jobs to hang or fail without a clear error, which makes troubleshooting frustrating and time-consuming.
  • Extended Events causing unexpected SQL Server shutdowns. An event session misconfiguration or a specific trace scenario could trigger a crash. That's a hard stop on your instance, not a graceful failure. This fix eliminates that risk.
  • Filtered index corruption. This is a serious one. Corrupted indexes can produce incorrect query results silently, meaning your application returns wrong data without throwing an error. Any bug in this category warrants immediate attention.
  • Incorrect query results on columnstore indexes. Similar to the filtered index issue, wrong results from columnstore queries are particularly dangerous because columnstore is often used for reporting and analytics workloads where users may not immediately notice subtle data discrepancies.
  • Australia timezone data correction in the Tz database. This one gets a mention because it directly affects Australian SQL Server environments. Australia's timezone rules have changed over the years, and when the Tz database that SQL Server relies on contains incorrect timezone data, date and time calculations can produce wrong results. For any system that stores, converts, or reports on datetime values with Australian timezone context, this fix has practical consequences.

The full list of fixes is documented in the Microsoft Knowledge Base article for this update. It's worth reading through the complete list rather than relying on summaries, because some fixes are specific to particular configurations or features that may apply to your environment.

Why Timezone Accuracy Matters for Australian SQL Server Environments

The Australia timezone fix deserves a bit more explanation because it's easy to dismiss as a niche concern. It isn't.

SQL Server uses the Windows timezone database (derived from the IANA Tz database) to handle timezone conversions. Functions like AT TIME ZONE, SWITCHOFFSET, and various datetime calculations depend on this data being accurate. If the underlying timezone rules are wrong, the calculations are wrong, and the errors can be subtle enough to go unnoticed for months.

Australian timezone rules are genuinely complicated. Different states observe different offsets. Some states observe daylight saving time and some don't. The transition dates have changed historically. Lord Howe Island has a 30-minute daylight saving offset that's unusual by global standards. When Microsoft updates the Tz database to reflect current rules, that update needs to flow through to SQL Server via patches like SP3 CU4.

If you're running financial systems, scheduling applications, or any reporting that crosses Australian timezone boundaries, running outdated timezone data is a real risk. The fix in SP3 CU4 brings the timezone data current and eliminates that exposure.

How to Apply SQL Server 2014 SP3 CU4

Applying a cumulative update to SQL Server 2014 follows the same process as any SQL Server patch. Here's the standard approach:

  1. Download the update from the Microsoft Knowledge Base article: KB article for SQL Server 2014 SP3 CU4.
  2. Check your current patch level by running the following query against your instance:
SELECT @@VERSION;

This returns the full version string including the build number. SQL Server 2014 SP3 is build 12.0.6024.0. SP3 CU4 brings the build to 12.0.6329.1. If you're below that, you need this update.

  1. Back up all databases before applying any patch. This is non-negotiable. A cumulative update modifies system databases and binaries, and while rollbacks are rarely needed, you want that option available.
  2. Schedule a maintenance window. SQL Server services will restart during the update. Plan for 15 to 30 minutes of downtime depending on your environment.
  3. Apply the update by running the downloaded installer with elevated privileges. The installer will detect your SQL Server instance and apply the patch.
  4. Verify the build number post-installation by running SELECT @@VERSION again and confirming the build matches 12.0.6329.1.
  5. Test critical functionality after the update, particularly any workflows involving SSIS, Extended Events sessions, columnstore indexes, or timezone-dependent queries.

If you're running SQL Server 2014 in an Always On Availability Group, apply the update to secondary replicas first, fail over, then patch the former primary. This minimises downtime and gives you a fallback if something unexpected occurs.

Should You Still Be Running SQL Server 2014?

This is worth addressing directly. SQL Server 2014 reached end of Extended Support on 9 July 2024. That means Microsoft is no longer releasing security patches for it. If you're reading this article and you're still on SQL Server 2014, you're running an unsupported product with no further security fixes coming.

SP3 CU4 was released before end of support and remains a valid patch to have installed. But the more important conversation is about your upgrade path. SQL Server 2019 and SQL Server 2022 are both in mainstream support, offer significant performance improvements, and have a much longer support runway ahead of them.

Staying on SQL Server 2014 past its end-of-support date creates compliance risk, security exposure, and increasingly limits your ability to take advantage of modern tooling and integrations. If budget or complexity has been the barrier, that's a conversation worth having now rather than after an incident forces the issue.

Key Takeaways

  • SQL Server 2014 SP3 CU4 (build 12.0.6329.1) addresses critical bugs including SSISDB blocking, Extended Events crashes, filtered index corruption, and incorrect columnstore query results.
  • The timezone fix in this update is directly relevant to Australian SQL Server environments and affects any system using AT TIME ZONE or other datetime conversion functions with Australian timezone context.
  • SQL Server 2014 reached end of Extended Support on 9 July 2024. If you're still running it, upgrade planning should be a priority.
  • Always verify your build number with SELECT @@VERSION before and after patching to confirm the update applied correctly.
  • Cumulative updates on Extended Support products carry more weight than during mainstream support. Each one addresses issues that won't be fixed any other way.

If you're managing SQL Server 2014 environments and need help with patching, upgrade planning, or ongoing maintenance, DBA Services provides managed SQL Server support for Australian organisations. A health check is a practical starting point to understand your current patch status, identify risk areas, and build a clear path forward. Get in touch to find out how we can help.