This article describes Cumulative Update package 15 (CU15) for SQL Server 2017. This update contains fixes that were released after the initial release of SQL Server 2017 and updates the SQL Server and Analysis services components to the following builds:
|Component||Build version||File version|
This article also provides important information about the following situations:
- Pacemaker: A behavioral change is made in distributions that use the latest available version of Pacemaker. Mitigations methods are provided.
- Query Store: You must run this script if you use Query Store and you have previously installed SQL Server 2017 Cumulative Update 2 (CU2).
- Availability Group preferred replica backups: An error occurs if you use sys.fn_hadr_backup_is_preferred_replica to determine the preferred Availability Group replica for backup jobs.
- Analysis Services CU build version: Beginning in SQL Server 2017, the Analysis Services build version number and SQL Server Database Engine build version number do not match. For more information, see Verify Analysis Services cumulative update build version.
Cumulative updates (CU) are now available at the Microsoft Download Center.
Only the most recent CU that was released for SQL Server 2017 is available at the Download Center.
CU packages for Linux are available at https://packages.microsoft.com/.
- Each new CU contains all the fixes that were included with the previous CU for the installed version of SQL Server.
- SQL Server CUs are certified to the same levels as Service Packs, and should be installed at the same level of confidence.
- Microsoft recommends ongoing, proactive installation of CUs as they become available according to these guidelines:
- Historical data shows that a significant number of support cases involve an issue that has already been addressed in a released CU.
- CUs may contain added value over and above hotfixes. This includes supportability, manageability, and reliability updates.
- We recommend that you test CUs before you deploy them to production environments.
How to obtain this cumulative update package for Windows
The following update is available from the Microsoft Download Center:
If the download page does not appear, contact Microsoft Customer Service and Support to obtain the cumulative update package.
- After future cumulative updates are released for SQL Server 2017, this and all previous CUs can be downloaded from the Microsoft Update Catalog. However, we recommend that you always install the latest cumulative update that is available.
How to obtain this cumulative update package for Linux
Additional hotfixes that are included in this cumulative update package
Notes for this update
Hybrid environments deployment
- SQL Server failover cluster rolling update and service pack process
Note If you do not want to use the rolling update process, follow these steps to apply an update:
- Install the update on the passive node.
- Install the update on the active node (requires a service restart).
- Upgrade and update of availability group servers that use minimal downtime and data loss
Note If you enabled AlwaysOn with SSISDB catalog, see the information about SSIS with AlwaysOn for more information about how to apply an update in these environments.
- How to apply a hotfix for SQL Server in a transactional replication and database mirroring topology
- How to apply a hotfix for SQL Server in a replication topology
- How to install service packs and hotfixes on an instance of SQL Server that is configured to use database mirroring
- Overview of SQL Server Servicing Installation
Cumulative update package information
PrerequisitesTo apply this cumulative update package, you must be running SQL Server 2017.
Restart informationYou may have to restart the computer after you apply this cumulative update package.
Registry informationTo use one of the hotfixes in this package, you do not have to make any changes to the registry.
All distributions (including RHEL 7.3 and 7.4) that use the latest available Pacemaker package 1.1.18-11.el7 introduce a behavior change for the start-failure-is-fatal cluster setting when its value is false. This change affects the failover workflow. If a primary replica experiences an outage, the cluster is expected to failover to one of the available secondary replicas. Instead, users will notice that the cluster keeps trying to start the failed primary replica. If that primary never comes online (because of a permanent outage), the cluster never fails over to another available secondary replica.
This issue affects all SQL Server versions, regardless of the cumulative update version that they are on.
To mitigate the issue, use either of the following methods.
Follow these steps:
- Remove the start-failure-is-fatal override from the existing cluster.
# RHEL, Ubuntu pcs property unset start-failure-is-fatal # or pcs property set start-failure-is-fatal=true # SLES crm configure property start-failure-is-fatal=true
- Decrease the cluster-recheck-interval value.
# RHEL, Ubuntu pcs property set cluster-recheck-interval=<Xmin> # SLES crm configure property cluster-recheck-interval=<Xmin>
- Add the failure-timeout meta property to each AG resource.
# RHEL, Ubuntu pcs resource update ag1 meta failure-timeout=60s # SLES crm configure edit ag1 # In the text editor, add `meta failure-timeout=60s` after any `param`s and before any `op`s
Note In this code, substitute the value for <Xmin> as appropriate. If a replica goes down, the cluster tries to restart the replica at an interval that is bound by the failure-timeout value and the cluster-recheck-interval value. For example, if failure-timeout is set to 60 seconds and cluster-recheck-interval is set to 120 seconds, the restart is tried at an interval that is greater than 60 seconds but less than 120 seconds. We recommend that you set failure-timeout to 60s and cluster-recheck-interval to a value that is greater than 60 seconds. Setting cluster-recheck-interval to a small value is not recommended. For more information, refer to the Pacemaker documentation or consult the system provider.
Revert to Pacemaker version 1.1.16.
Query Store notice
If you use the Query Store feature, and you have previously installed Cumulative Update 2 (CU2) (14.0.3008.27), the following requirement applies to you:
After you install Cumulative Update 3 (CU3) (14.0.3015.40) or a later CU, you must immediately run the following script to delete all plans that were collected by Query Store while CU2 was installed:
SET NOCOUNT ON;DROP TABLE IF EXISTS #tmpUserDBs;SELECT [database_id], 0 AS [IsDone]INTO #tmpUserDBsFROM master.sys.databasesWHERE [database_id] > 4 AND [state] = 0 -- must be ONLINE AND is_read_only = 0 -- cannot be READ_ONLY AND [database_id] NOT IN (SELECT dr.database_id FROM sys.dm_hadr_database_replica_states dr -- Except all local Always On secondary replicas INNER JOIN sys.dm_hadr_availability_replica_states rs ON dr.group_id = rs.group_id INNER JOIN sys.databases d ON dr.database_id = d.database_id WHERE rs.role = 2 -- Is Secondary AND dr.is_local = 1 AND rs.is_local = 1)DECLARE @userDB sysname;WHILE (SELECT COUNT([database_id]) FROM #tmpUserDBs WHERE [IsDone] = 0) > 0BEGIN SELECT TOP 1 @userDB = DB_NAME([database_id]) FROM #tmpUserDBs WHERE [IsDone] = 0 -- PRINT 'Working on database ' + @userDB EXEC ('USE [' + @userDB + '];DECLARE @clearPlan bigint, @clearQry bigint;IF EXISTS (SELECT [actual_state] FROM sys.database_query_store_options WHERE [actual_state] IN (1,2))BEGIN IF EXISTS (SELECT plan_id FROM sys.query_store_plan WHERE engine_version = ''14.0.3008.27'') BEGIN DROP TABLE IF EXISTS #tmpclearPlans; SELECT plan_id, query_id, 0 AS [IsDone] INTO #tmpclearPlans FROM sys.query_store_plan WHERE engine_version = ''14.0.3008.27'' WHILE (SELECT COUNT(plan_id) FROM #tmpclearPlans WHERE [IsDone] = 0) > 0 BEGIN SELECT TOP 1 @clearPlan = plan_id, @clearQry = query_id FROM #tmpclearPlans WHERE [IsDone] = 0 EXECUTE sys.sp_query_store_unforce_plan @clearQry, @clearPlan; EXECUTE sys.sp_query_store_remove_plan @clearPlan; UPDATE #tmpclearPlans SET [IsDone] = 1 WHERE plan_id = @clearPlan AND query_id = @clearQry END; PRINT ''- Cleared possibly affected plans in database [' + @userDB + ']'' END ELSE BEGIN PRINT ''- No affected plans in database [' + @userDB + ']'' ENDENDELSEBEGIN PRINT ''- Query Store not enabled in database [' + @userDB + ']''END') UPDATE #tmpUserDBs SET [IsDone] = 1 WHERE [database_id] = DB_ID(@userDB)END
Availability Group preferred replica backups
Consider the following scenario:
- You are running an Availability Group on a Windows Server failover cluster.
- You are using the sys.fn_hadr_backup_is_preferred_replica function within your backup jobs to determine whether to run a backup on the current replica.
In this scenario, the function call fails and generates the following error message:
Msg 41070, Level 16, State 1, Line 1
Configuration data for the availability group with Windows Server Failover Clustering (WSFC) resource ID '<resource ID>' is not found in the WSFC data store. The availability group may have been dropped, or a previous CREATE AVAILABILITY GROUP or DROP AVAILABILITY GROUP operation has failed. Please use DROP AVAILABILITY GROUP command to clean up previously failed operations before retrying the current operation.
This issue does not affect the backup itself. Therefore, you can work around this issue by removing the call to sys.fn_hadr_backup_is_preferred_replica.
If you have to back up only on the preferred replica, we recommended that you do not apply Cumulative Update 15. This issue will be fixed in a future release.
- Announcing updates to the SQL Server Incremental Servicing Model (ISM)
- SQL Server Service Packs are discontinued starting from SQL Server 2017
- The script to determine which version and edition of SQL Server Database Engine is running
- The Incremental Servicing Model for SQL Server to deliver hotfixes for reported problems
- Naming schema for Microsoft SQL Server software update packages
- Description of the standard terminology that is used to describe Microsoft software updates