MSSQL Tiger Team https://docs.microsoft.com/archive/blogs/sql_server_team/feed.xml This is the official web log for the SQL Server engineering team – we focus on learning customer workloads running on SQL Server, integrating that feedback to enhance the product, and provide guidance on using SQL Server to solve customers' business challenges. Wed, 08 May 2019 22:49:13 GMT en-US hourly 1 We have moved! https://docs.microsoft.com/archive/blogs/sql_server_team/we-have-moved Fri, 29 Mar 2019 11:01:28 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=8205 https://techcommunity.microsoft.com/t5/SQL-Server/bg-p/SQLServer/label-name/SQLServerTiger    ]]> We are moving! https://docs.microsoft.com/archive/blogs/sql_server_team/we-are-moving Mon, 04 Mar 2019 10:22:38 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=8185 SQL Server and Azure SQL Database blogs on the Microsoft TechCommunity website. Once the migration is complete, we will post the new URL along with instructions for how to navigate the new blog and update your RSS feeds. Until then, feel free to keep reading here, but keep in mind that any comments that are added may not make it over to the new blog. You will be able to re-post them there once we are live. Stay tuned and see you on the new site soon!]]> Let’s talk about trace flags https://docs.microsoft.com/archive/blogs/sql_server_team/lets-talk-about-trace-flags Mon, 14 Jan 2019 08:00:53 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=8165 documented, when to use them and when not to is not always clear. The primary reason for this post is to introduce a new article from Microsoft Support that provides guidance on trace flags and other configurations which may help high-end SQL Servers perform better: Recommended updates and configuration options for SQL Server 2017 and 2016 with high-performance workloads https://support.microsoft.com/kb/4465518 The article was published this past fall and is an update of an older article with which you may already be familiar: Recommended updates and configuration options for SQL Server 2012 and SQL Server 2014 with high-performance workloads https://support.microsoft.com/kb/2964518 Microsoft Support has provided these articles to help guide customers toward configuration options that both improve performance, but also help to avoid known issues that present themselves when the server is running on big iron (large memory and many CPUs) and/or is under heavy load. You may be asking yourself, if these trace flags provide a benefit, why aren't they just the default behavior? In a lot of cases, we're asking ourselves the same thing 😊 If you've read both the articles above, you may have noticed that the list of recommended trace flags for SQL Server 2016 and 2017 is much smaller than the list for 2012 and 2014. This is because starting with SQL Server 2016, many of the trace flags that were introduced to solve problems in earlier versions just became the default behavior.

So why do we even have trace flags to begin with?

Some trace flags are used to enable enhanced debugging features such as additional logging, memory dumps etc. and are used only when you are working with Microsoft Support to provide additional data for troubleshooting. These trace flags are not ones you want to leave turned on in a production system as they may have a negative impact on your workload. An example of one of these flags would be TF 2551 which is used to trigger a filtered memory dump whenever there is an exception or assertion in the SQL Server process. These trace flags are only used for a short period of time and typically only at the recommendation of Microsoft Support, so they will likely always be around. Other trace flags are used to alter the behavior of the server in other ways, such as to turn a feature ON or OFF or change the way the database engine manages resources. One example of this type of trace flag is 7752 which was introduced as a knob for something that is default behavior in Azure SQL DB. In a SQL Server (on-prem or IaaS) database that is undergoing recovery and has Query Store (QDS) enabled, user queries will be blocked until all the data required for QDS to start is loaded. This ensures QDS doesn't miss any queries that are executed in that database. In some cases, this can take a long time to complete and you'll see sessions with a wait type of QDS_LOADDB until the QDS becomes available. Turning on TF 7752 makes this process asynchronous so that user queries can proceed while the QDS starts. It's not something we want to make the default behavior in general because it means that some query executions won't be captured by QDS, but it's a tradeoff you might be willing to make in order to reduce the time it takes for a database to become available upon restart or failover. This is the sort of trace flag that we are trying to incorporate into the product in some other way, such as to provide a database-scoped configuration. Moving forward, we hope not to introduce any new trace flags like this, and over time the number of flags of this type should approach zero. A subset of the above category is what many folks call the "benchmark specials" – trace flags that alter or disable database engine behavior that is normally desirable, but perhaps not absolutely required if you want lightening fast performance. This would be things like trace flag 661 that disables ghost record cleanup, or one of several flags that disable ring buffers used for monitoring and diagnostic purposes. For the most part, these flags are not ones that you want to run in production because they turn off features that are required for the maintenance and manageability of your server. If you really need lightening fast performance though, and you're willing to make the trade-off of manageability for speed, these are available and documented here. Most of these flags don't make sense to add to the product, but there are a few that have become useful in wider scenarios and are recommended for certain workloads. One flag like this is trace flag 834. This flag turns on large-page memory allocations for the buffer pool, which can be helpful for data warehouse-type workloads. There are some caveats to turning this flag on however, so be sure to review the documentation before considering it. This is one that is also documented in the two KB articles referenced at the top of this blog. The last reason for trace flags is to introduce new behavior or change existing behavior in an in-market release of SQL Server (i.e. a Cumulative Update). We know our customers find that installing updates can be disruptive, and there are many risk-averse customers who are reluctant to apply any non-security updates at all. For the past several versions of SQL Server we have worked hard to make updates as seamless as possible, and this includes keeping any potential behavior changes to a minimum. As Pedro likes to say, "backward compatibility is the unsung hero feature of SQL Server" 😊 To that end, any change we make to an in-market release of SQL Server that has the potential to impact performance or change the behavior of your application, be it an improvement or a bug fix, will be gated by a trace flag (or compatibility level – that's another story). The most common trace flag like this is 4199. This is a very important flag, and one that's going to be around for a while so it's worth talking about in some detail. Fixes to the query optimizer fall under the category of behavior changes that have the potential to impact performance. In many cases, the impact should be positive, but sometimes there are edge cases where they can have a negative impact, so it's not something we want to throw into a cumulative update by default. For this reason, all the fixes that were made to the optimizer between SQL Server 7.0 and SQL Server 2014 were gated by a trace flag. Up until SQL Server 2005 SP3, each one would have to be enabled individually, but in this release, they were rolled up under TF 4199. If you're running one of these versions of SQL Server and you don't have this trace flag turned on, you're missing out on 20 some-odd years of query optimizer fixes that may benefit your workload. Starting with SQL Server 2016, all the fixes from SQL Server 7.0 up to SQL Server 2016 RTM were rolled into the engine by default (when running with 130 compatibility level), but the changes that were released AFTER SQL Server 2016 RTM are still gated by TF 4199. This was also the case with SQL Server 2017 RTM and will continue to be the practice moving forward, all the optimizer fixes will be rolled into the engine at RTM and this becomes the baseline optimizer behavior for that compatibility level (even if you're running on a later version of the database engine). When you have 4199 enabled, all the optimizer fixes available in the current build that are applicable to the current database compatibility level will be enabled. Incidentally, this behavior can also be controlled at the database level using the QUERY_OPTIMIZER_HOTFIXES database scoped configuration option and at the query level using the USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' query hint, although the trace flag is needed if you want to set this at the server level. As you modernize your databases, you should find that the configuration experience for SQL Server gets simpler and more intuitive. While there will likely always be some trace flags, we expect their use to be limited in scope, and any trace flags that are recommended by Microsoft for production use will be thoroughly documented. In the meantime, be sure to reference the articles above any time you build and configure a new SQL Server. We will try to keep these updated whenever new support trends emerge that indicate a trace flag or other configuration setting should be widely recommended for Tier-1 workloads.]]> Replica Failover within the Secondary Availability Group in a Distributed Availability Group https://docs.microsoft.com/archive/blogs/sql_server_team/replica-failover-within-the-secondary-availability-group-in-a-distributed-availability-group Wed, 09 Jan 2019 13:27:38 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7805 distributed availability group (distributed AG) is a special type of availability group that spans two availability groups. This blog will clarify some issues regarding failover in a distributed AG, specifically demonstrates distributed AG resiliency from data loss despite the synchronizing state between the availability groups. A simple distributed AG ‘TIWENDAG’ is created for relevant tests that will be addressed later in this blog. The structure of ‘TIWENDAG’ is illustrated by the following diagram. ‘TIWENAG1’ is the primary AG of distributed AG ‘TIWENDAG’, with ‘TIWENVM1’ as the primary replica and ‘TIWENVM2’ as the secondary replica. ‘TIWENAG2’ is the secondary AG of the distributed AG, with ‘TIWENVM3’ as the primary replica and ‘TIWENVM4’ as the secondary replica. Automatic failover of the two availability groups defined in the distributed AG is supported. For example, if “automatic” is specified for failover mode in availability group TIWENAG1, then automatic failover can occur between TIWENAG1 (primary) and TIWENAG2 (synchronous secondary) in the event that TIWENAG1 goes down. Similarly, in availability group TIWENAG2, in the event TIWENVM3 (primary) goes down, it can automatically failover to TIWENVM4 (synchronous secondary). the primary replica in the AG (no matter whether the AG is part of a distributed AG) will automatically failover to a synchronous secondary replica when the primary replica goes down. If the primary replica on the secondary AG (also known as the “forwarder”) is lost and causes automatic failover to happen or manual failover is performed in the secondary AG in a distributed AG, there will be no data loss if the following conditions are met:
  • The primary replica on the primary AG (which is usually referred to as "global primary") is successfully synchronizing with the forwarder replica in the secondary AG over their database mirroring endpoints.
  • The forwarder replica in the secondary AG is successfully synchronizing with the secondary replica in the secondary AG over their database mirroring endpoints.
Assume that the hardened LSN on the global primary, “TIWENVM1”, is 10:15:1. The secondary replica of the primary AG, “TIWENVM2”, is synchronous, and its hardened LSN is also 10:15:1. For the secondary AG, between the primary AG and the forwarder, synchronization mode is asynchronous, and the hardened LSN of the forwarder, “TIWENVM3”, is 10:12:1. The secondary replica of the secondary AG, “TIWENVM4”, is not yet synchronized and its hardened LSN is 10:10:1. Globally across the two AGs in the distributed AG, replica “TIWENVM4” has the smallest value of hardened LSN, truncation LSN on the global primary won’t go beyond this smallest value. In the event that “TIWENVM3” is lost and “TIWENVM4” becomes the new forwarder, it will be able to synchronize with the primary AG. The reason for this is that when the transaction logs are backed up, only the logs that have been applied to all the replicas in the distributed AG (including the replicas in both AGs) will be truncated. The following table provides an example of how the transaction logs will be truncated in a distributed AG, using the test environment described at the beginning of this post. This scenario can be easily demonstrated. The steps are as following:
  1. Record the current truncation_lsn and last hardened LSN of each replica.
  2. Modify the database. Here an INSERT query is executed 10 times on the “test” database.
  3. Verify that the last hardened LSN of each replica grows by the same number.
  4. Do a transaction logs back up on the “test” database on the global primary.
  5. Verify current truncation_lsn and last hardened LSN .
  6. Suspend data movement on the secondary replica on the secondary AG.
  7. Repeat 2-5.
The following screenshots record a complete repro of the scenario.  
Step1 -
DMVs used in this step: USE test SELECT COUNT(*) AS '# of transaction logs' FROM fn_dblog(null, null) SELECT database_id,        group_id,        replica_id,        is_local,        is_primary_replica,        truncation_lsn,        last_hardened_lsn FROM sys.dm_hadr_database_replica_states WHERE database_id=6 AND is_local=1 SELECT replica_id, replica_server_name FROM sys.availability_replicas WHERE replica_id=       (SELECT replica_id FROM sys.dm_hadr_database_replica_states WHERE database_id=6 AND is_local=1) SELECT COUNT(*) AS '# of entries in testt1 table' FROM testt1 Results from the four replicas : Primary replica on primary AG (global primary): Secondary replica on primary AG: Primary replica on secondary AG (forwarder): Secondary replica on secondary AG: If all the replicas are synchronized, all the replicas should have the same number of transaction logs as well as the same truncation_lsn as in the test environment shown in the screenshots above.
Step 2 -
Execute an INSERT clause 10 times. INSERT INTO testt1 (NAME, ID) VALUES ('John Smith', 1) GO
Step 3 -
Primary replica on primary AG (global primary): Secondary replica on primary AG: Primary replica on secondary AG (forwarder): Secondary replica on secondary AG: The size of transaction logs grows due to the INSERT executions. The increase of entries in the ‘test’ database also reflects that 10 rows are inserted into the table.

Step 4 -
Perform a transaction log backup on the global primary.  
Step 5 -
Primary replica on primary AG (global primary): Secondary replica on primary AG: Primary replica on secondary AG (forwarder): Secondary replica on secondary AG: Truncation_lsn of each replica should grow to the current lsn, and the number of transaction logs should shrink by the same size as the t-logs have been truncated.  
Step 6 -
Suspend data movement of ‘test’ database on the secondary replica on the secondary AG.  
Step 7 -
After repeating step 2 and 3, we can see that except for the secondary replica on the secondary AG (TIWENVM4), the ‘test’ database on all other three replicas are modified again and another 10 entries are inserted into the table. The database on secondary replica on the secondary AG is not updated because the data movement has been suspended. Primary replica on primary AG (global primary): Secondary replica on primary AG: Primary replica on secondary AG (forwarder): Secondary replica on secondary AG: The results from repeating step 4 and 5 are shown below. Primary replica on primary AG (global primary): Secondary replica on primary AG: Primary replica on secondary AG (forwarder): Secondary replica on secondary AG: Note that the newly generated transaction logs were truncated on the secondary replica on the primary AG, but the truncation_lsn of the primary replica on the primary didn’t change after 10 new rows were inserted into the database and executing transaction logs back up. As mentioned earlier, this is because the secondary replica on the secondary AG of the distributed AG (TIWENVM4) is not yet synchronized and thus has not successfully applied the new transaction logs generated by the INSERT queries. The global primary of a distributed AG only truncates logs to the least LSN among all the replicas in the distributed AG. This logic guarantees that there’ll be no data loss when the forwarder got lost even when the secondary replica on the secondary AG has not fully synchronized with the forwarder, as long as the global primary is in a healthy state and can communicate with the secondary replica on the secondary AG properly. To simulate the scenario mentioned above, we shut down the network of the primary replica on the secondary AG (TIWENVM3) so that it becomes unavailable before we resume the data movement on the secondary replica on the secondary AG (TIWENVM4). After the data movement of ‘test’ database on TIWENVM4 is resumed, the secondary AG (TIWENAG2) is now in a resolving state because the current primary replica on TIWENAG2, TIWENVM3, fails to be connected. To fix this issue, a failover needs to be performed. Under the scenario when in the secondary AG of a distributed AG, the forwarder is not available, the only failover option to the secondary replica of the secondary AG is FORCE_FAILOVER_ALLOW_DATA_LOSS. ALTER AVAILABILITY GROUP TIWENAG2 FORCE_FAILOVER_ALLOW_DATA_LOSS After performing failover with FORCE_FAILOVER_ALLOW_DATA_LOSS on the secondary replica on the secondary AG (TIWENVM4), the database is synced even though the previous forwarder is currently unavailable, as the global primary keeps track of the unsynchronized part of transaction logs of the secondary replica on the secondary AG. In this scenario, though the only failover option is FORCE_FAILOVER_ALLOW_DATA_LOSS, there’s no data loss during the failover. One thing worth notice is that after FORCE_FAILOVER_ALLOW_DATA_LOSS and the previous primary replica (in this case, TIWENVM3) is brought back, data movement will not resume automatically and needs to be resumed manually. This behavior is by design and not limited to the distributed AG scenario but applies whenever failover with FORCE_FAILOVER_ALLOW_DATA_LOSS is performed. This is because there might be difference and even conflicts between the previous primary replica and the new primary replica, and user needs to manually choose which version to keep. After resuming data movement on TIWENVM3, all replicas on the distributed AG are synchronized and the transaction logs get truncated to the same point. Primary replica on primary AG (global primary): Secondary replica on primary AG: (New) Secondary replica on secondary AG (former forwarder): (New) Primary replica on secondary AG (new forwarder): It needs to be clarified that though under this scenario, FORCE_FAILOVER_ALLOW_DATA_LOSS in the secondary AG doesn’t cause data loss, it’s not guaranteed that there’ll be no data loss when using this option to perform failover in a distributed AG. For example, if the primary AG is lost, there might be data loss when a force failover is performed in the secondary AG. This behavior is expected, and the cases that might cause data loss are not limited to this example.]]> SQL Server 2017 on Linux: Support for third-party AD providers https://docs.microsoft.com/archive/blogs/sql_server_team/sql-server-2017-on-linux-support-for-third-party-ad-providers Mon, 26 Nov 2018 09:30:44 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7745 https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-third-party-providers?view=sql-server-2017. This functionality was made available in SQL Server 2017 CU10 first. But it is highly recommended to use it with SQL Server 2017 CU12 onwards.   Additionally, if your domain controller supports LDAPS, you can force all connections from SQL Server to the domain controllers to be over LDAPS. To check your client can contact the domain controller over ldaps, run the following bash command, “ldapsearch -H ldaps://contoso.com:3269”. To set SQL Server to only use LDAPS, run the following:
  • sudo mssql-conf set network.disablesssd true
  • sudo mssql-conf set network.forceldaps true
  • systemctl restart mssql-server
Tejas Shah - Senior Program Manager Dylan Gray - Senior Software Engineer]]> Failover Detection Utility - Availability Group Failover Analysis Made Easy https://docs.microsoft.com/archive/blogs/sql_server_team/failover-detection-utility-availability-group-failover-analysis-made-easy Mon, 19 Nov 2018 12:25:01 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7725 Failover Detection Utility The failover detection utility can be downloaded here. The download consists of the following files.
  1. FailoverDetector.exe – The Failover analysis utility.
  2. Configuration.json – The configuration file for the failover analysis utility. The file consists of the following fields. { "Data Source Path": "F:\\DataLocation\\Data", "Health Level": 3, "Instances": [ "Replica1", "Replica2", "Replica3" ] } Data Source Path – Location for the Logs from the different replicas in the Availability Group. Health Level – The failover policy level configured for the availability group. More information on the different failover conditions can be found here. Instance – The list of replicas in the availability groups.
  3. Supporting DLL’s – Supporting DLLs for the Failover analysis utility.
  4. Data and Reports Folders – The Data and Analysis reports folders.
Preparing for Failover Analysis with the Failover Detection Utility The first step in using the utility is to configure the configuration.json file to include the location of the data files and the details of the availability group for which analysis is being done. For a correct analysis, all replicas in the availability groups needs to be listed in the configuration file. The next step is to capture the various logs from each of the replicas and add those under the data folder. The following files are required for the analysis.
  • SQL error logs
  • Always On Availability Groups Extended Event Logs
  • System Health Extended Event Logs
  • System log
  • Windows cluster log
The first three categories of logs can be found in the LOG folder of the SQL instance installation path. For example, if you have a SQL Server 2017 instance named "SQL17RTM01" and If the installation path is on C drive, you will find the above three categories of logs under "C:\Program Files\Microsoft SQL Server\MSSQL14.SQL17RTM01\MSSQL\Log", and copy all AlwaysOn XEvent, System Health XEvent and SQL ERRORLOG files. The last two categories of logs can be found. You can use commands mentioned below to collect these logs.

Get-ClusterLog -Node $server.ComputerNamePhysicalNetBIOS -Destination $server.ErrorLogPath

Get-Eventlog -ComputerName $server.ComputerNamePhysicalNetBIOS -LogName System | Export-CSV -Path $SystemLogExportPath

Organizing the files The log files collected in the previous step should be placed in a folder with correct subfolder structure. This folder should be the folder path specified in the "Data Source Path" section of the configuration file "Configuration.json". The following is an example of the subfolder structure, assuming there are two replicas (instances) in the AG. One is "Replica1" and another one is "Replica2".

¦ +---Data

¦ ¦

¦ ¦

¦ +---Replica1

¦ ¦ AlwaysOn_health_0_131532583880140000.xel

¦ ¦ AlwaysOn_health_0_131532634780070000.xel

¦ ¦ AlwaysOn_health_0_131532680183890000.xel

¦ ¦ AlwaysOn_health_0_131532701164380000.xel

¦ ¦ ERRORLOG

¦ ¦ ERRORLOG.1

¦ ¦ ERRORLOG.2

¦ ¦ ERRORLOG.3

¦ ¦ SQLDUMPER_ERRORLOG.log

¦ ¦ system_health_0_131532583879830000.xel

¦ ¦ system_health_0_131532634779760000.xel

¦ ¦ system_health_0_131532680183430000.xel

¦ ¦ system_health_0_131532701164070000.xel

¦ ¦ Replica1_system.log

¦ ¦ Replica1_cluster.log

¦ ¦

¦ +---Replica2

¦ AlwaysOn_health_0_131532571347210000.xel

¦ AlwaysOn_health_0_131532578226200000.xel

¦ AlwaysOn_health_0_131532586348180000.xel

¦ AlwaysOn_health_0_131532725682240000.xel

¦ ERRORLOG

¦ ERRORLOG.1

¦ ERRORLOG.2

¦ ERRORLOG.3

¦ ERRORLOG.4

¦ ERRORLOG.5

¦ ERRORLOG.6

¦ system_health_0_131532571346430000.xel

¦ system_health_0_131532578225950000.xel

¦ system_health_0_131532586347860000.xel

¦ system_health_0_131532725681930000.xel

¦ Replica2_system.csv

¦ Replica2_cluster.log

Executing the Utility The FailoverDetection.exe can be executed with the following flags (or default mode without any flags) Default Mode (No execution flags defined) - In the default mode, where no parameters are passed to the utility, the analysis tool will load the configuration file, copy log data from data source path to local workspace data folder, examine the files with the configuration settings, perform the analysis, and write the analysis result to a JSON report file. User should make sure the execution credential running tool has access to share folder defined in Configuration.json. When tool runs into access denial issues or the directory does not exist, the tool will exit with proper error message. After the tool copies the log files to the local tool directory, it scans the local data folder and compare with the AG configuration in Configuration.json. If it finds log data is not complete, the tool will show which files are missing. The tool will also alert the user that the failover root cause might not be properly identified due to missing files. If analysis is successful, the utility persists the analysis result report as JSON file in Result directory. Analysis result will NOT be presented on the console, unless the "--Show" parameter is specified. --Analyze - When "--Analyze" is specified as a parameter, the utility will load configuration file without copying log data. It assumes the log files have already been copied over. It does everything as default mode except copying log data. This option is useful if you already have the data in the local tool execution subdirectories and want to rerun the analysis. --Show -The utility after analyzing log data will display the results in the command console. Additionally, the results will be persisted to a JSON file in the results folder. Currently supported failover root causes The tool in current form can analyze and report failover reason if a failover is due to the following causes. Planned Failovers
  • Stopping SQL service: Admin or other process gracefully shuts down SQL Server hosting the AG primary. In this case, if automatic failover is enabled, Windows notifies WSFC to initiate a failover and picks one secondary as new primary.
  • Shutting down Windows Server: The Windows Server which hosts the SQL Server that has the primary replica is shut down or restarted. In this case, if automatic failover is enabled, Windows notifies WSFC to initiate a failover and picks one secondary as new primary.
  • Manual failover: An administrator performs a manual failover through Management Studio or through a direct Transact-SQL statement "ALTER AVAILABILITY GROUP <AG name> FAILOVER" or "ALTER AVAILABILITY GROUP <AG name> FAILOVER WITH DATA_LOSS" on the secondary replica that will become the primary replica.
SQL Service Internal Health Issue
  • Too many memory dumps generated on the SQL Server hosting the primary replica: There are more than 100 SQL Server dumps on the primary replica since the last SQL Server restart, and there is at least one dump in the last 10 seconds. In this case, sp_server_diagnostics running in SQL Server determines that SQL Server system component is in error state and notifies failover WSFC to initiate a failover.
  • Memory scribbler: SQL Server has a write access violation and the write address is more than 64KB. If there are more than three such memory corruptions since SQL Server was started, sp_server_diagnostics running in SQL Server determines that SQL Server system component is in error state and notifies failover WSFC to initiate a failover.
  • Sick Spinlock: After an access violation, a spinlock is marked as sick if it backs off more than three times, which is the threshold. In this case, sp_server_diagnostics running in SQL Server determines that SQL Server system component is in error state and notifies failover WSFC to initiate a failover.
  • Out of Memory: If no memory has been freed in 2 minutes, sp_server_diagnostics running in SQL Server determines that SQL Server system component is in error state and notifies failover WSFC to initiate a failover.
  • Unresolved deadlock: If sp_server_diagnostics detects unresolved deadlock from query processing component, it determines that SQL Server system component is in error state and notifies failover WSFC to initiate a failover.
  • Deadlocked scheduler: If sp_server_diagnostics detects deadlocked schedulers from query processing component, it determines that SQL Server system component is in error state and notifies failover WSFC to initiate a failover.
System Wide Issues
  • Unexpected crash: SQL Server service was shut down unexpectedly. Resources host service (rhs.exe) does not detect lease check from SQL Server about availability group lease. This results an AG lease timeout signal to WSFC and WSFC will initiate a failover.
  • Long dump: SQL Server is creating a dump file. During the process, threads handling the AG lease are frozen and which may result in a lease timeout. This results an AG lease timeout signal to WSFC and WSFC will initiate a failover if automatic failover is enabled.
  • Quorum loss: AG resource is brought offline because quorum is lost. This could be because of a plethora of issues, which would need to be determined by a closure examination of the cluster logs.
  • Network interface failure: Network interface used to communicate between cluster nodes fails. Primary and secondary replicas cannot communicate. WSFC will initiate quorum vote and determine a new primary to fail over to.
  • Cluster disk failure: Network interface used to communicate between cluster nodes has failed, resulting in a communication loss between the cluster nodes. Cluster will initiate quorum vote and determine a new primary failover to.
  • Cluster Service paused: Cluster service on primary was paused, resulting in primary unable to communicate with other nodes in the cluster. Cluster will initiate quorum vote and determine a new primary to fail over to.
  • Node offline: When primary node is frozen or loses power, WSFC loses connection from and to the primary. Failover cluster decide to initiate failover and pick a primary from other possible nodes.
  • High CPU utilization: System wide performance issue causes SQL Server service to be unable to respond to AG lease handler. For example, it is possible that some process on the node is consuming 100% CPU and hence the lease renewal threads cannot execute. This is a best effort estimation based on the inputs from the Cluster logs.
  • High I/O: System wide performance issue causes SQL Server service to be unable to respond to AG lease handler. For example, it is possible that some process on the node is throttling the disks on the system and as such the lease renewal cannot be completed. This is again a best effort estimate based on the inputs from the cluster logs.
The Failover Detection utility can be used to analyze SQL Server 2012, 2014, 2016 and 2017 Availability groups, provided the servers are on the latest service packs and cumulative updates. Update 11/21 A few users have reported the following error while using the utility. We are looking into this and will post an update shortly. “An unhandled exception of type ‘System.BadImageFormatException’ occurred in FailoverDetector.exe Could not load file or assembly ‘Microsoft.SqlServer.XEvent.Linq, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. An attempt was made to load a program with an incorrect format.” Update 11/27 New updated binaries for the Failover Detector Utility have been uploaded to GitHub. Before running the utility, please install the "Microsoft Visual C++ Redistributable for Visual Studio 2017" from here. On the download page, scroll down to the "Other Tools and Frameworks" section to download the redistributable (x64 version). You may encounter the "Strong name validation failed" error while using the utility. To resolve the error use sn.exe (available in the zip file) to disable strong name validation. To disable strong name use the following command sn.exe -Vr <<path to the DLLs>>   Sourabh Agarwal
Senior PM, SQL Server Tiger Team
Twitter | LinkedIn
Follow us on Twitter: @mssqltiger | Team Blog: Aka.ms/sqlserverteam]]> String or Binary data would be truncated: replacing the infamous error 8152 https://docs.microsoft.com/archive/blogs/sql_server_team/string-or-binary-data-would-be-truncated-replacing-the-infamous-error-8152 Wed, 24 Oct 2018 12:30:00 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7695 Big Data Clusters, data virtualization, support for UTF-8, and Intelligent Query Processing were highlights. But we have also previewed work being done to address the infamous error message “String or binary data would be truncated”. This error condition may happen for example when you implement an ETL between a source and a destination that does not have matching data types and/or length. In this context, the message "String or binary data would be truncated" is one of the most time-consuming troubleshooting processes to engage in, especially in large datasets. You probably know about and voted for this feedback item before. Let’s see an example of what happens when you insert data into a column whose size is not big enough to store it: 
USE [AdventureWorks2016CTP3]
GO
DROP TABLE IF EXISTS [Sales].[SalesOrderHeaderTest]
GO
CREATE TABLE [Sales].[SalesOrderHeaderTest](
    [SalesOrderID] [INT] NOT NULL,
    [CustomerID] [INT] NOT NULL,
    [CreditCardApprovalCode] [nvarchar](13) NULL
)
GO

INSERT INTO [Sales].[SalesOrderHeaderTest]
SELECT [SalesOrderID], [CustomerID], [CreditCardApprovalCode]
FROM [Sales].[SalesOrderHeader]
GO
You receive following error message, which admittedly is not very helpful: 
Msg 8152, Level 16, State 30, Line 13
String or binary data would be truncated.
The statement has been terminated.
We heard that. Which is why SQL Server 2019 introduces a new message, with additional context information. For the same operation, the new error message outputs the following: 
Msg 2628, Level 16, State 1, Line 14
String or binary data would be truncated in table 'AdventureWorks2016CTP3.Sales.SalesOrderHeaderTest', column 'CreditCardApprovalCode'. Truncated value: '1231736Vi8604'.
The statement has been terminated.
Ok, the new error message provides more context, and now I have the resulting truncated value (not the source value). This is simplifying the troubleshooting process, because now I know the truncated value starts with ‘1231736Vi8604' – that’s 13 characters. And so I can go back to my data source, and locate the source record and its length: 
SELECT [SalesOrderID], [CustomerID], [CreditCardApprovalCode], LEN([CreditCardApprovalCode])
FROM [Sales].[SalesOrderHeader]
WHERE CreditCardApprovalCode LIKE '1231736Vi8604%'
image It’s 14 characters, and in my table definition I have a NVARCHAR(13). Well, I know what I need to do: change my table data type length. This new message is also backported to SQL Server 2017 CU12 (and in an upcoming SQL Server 2016 SP2 CU), but not by default. You need to enable trace flag 460 to replace message ID 8152 with 2628, either at the session or server level. Note that for now, even in SQL Server 2019 CTP 2.0 the same trace flag 460 needs to be enabled. In a future SQL Server 2019 release, message 2628 will replace message 8152 by default. Is there a limit to how much of my truncated string this error can return? Let’s run a small test inserting a 123 character string into a VARCHAR(120): 
CREATE TABLE myTable (myString VARCHAR(120));
GO
INSERT INTO myTable
VALUES ('Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.')
GO
Although my string gets truncated at 120 characters, the offending value that is shown is truncated to the first 100 characters: 
Msg 2628, Level 16, State 1, Line 30
String or binary data would be truncated in table 'AdventureWorks2016CTP3.dbo.myTable', column 'myString'. Truncated value: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore '.
Still plenty to find offending values in most data sources. Pedro Lopes (@SQLPedro) – Senior Program Manager]]> SQL Server 2019 CTP 2.0 New Features – Columnstore support for sp_estimate_data_compression_savings https://docs.microsoft.com/archive/blogs/sql_server_team/sql-server-2019-ctp-2-0-new-features-columnstore-support-for-sp_estimate_data_compression_savings Mon, 22 Oct 2018 08:00:42 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7715 sp_estimate_data_compression_savings stored procedure to add support for both columnstore and columnstore archive compression. This stored procedure has been around since SQL Server 2008 and is handy when you are evaluating whether to compress tables and indexes. The procedure takes five parameters: schema_name, object_name, index_id, partition_number and data_compression. Prior to SQL Server 2019, the data_compression parameter could be 'ROW', 'PAGE' or 'NONE' only. In SQL Server 2019 CTP 2.0, we added two new options here: 'COLUMNSTORE' and 'COLUMNSTORE_ARCHIVE'. With rowstore tables and indexes, the way you apply compression is to rebuild the object using the desired compression state. Here's an example that will rebuild a heap table with row compression: ALTER TABLE Production.TransactionHistory REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = ROW); GO Compression ratios are heavily dependent on the type of data that's being stored in the table, so the only good way to estimate compression space savings is to actually compress a sampling of the data and see what the result is. The way sp_estimate_data_compression_savings works for rowstore compression types is to take a sampling of pages from the source object (up to 5,000 pages) and create a sample object in tempdb that mimics the source object. The sample object is then rebuilt using the desired compression state. An estimated compression ratio is calculated by comparing the original sample object size with the compressed sample object size. This ratio is then used to project the estimated size of the entire source object if the desired compression setting is applied. Keep in mind this can also be used to estimate the size of an object if compression is removed by supplying a data_compression parameter value of 'NONE' for a source object that already has compression applied. For columnstore compression, you don't really "enable" it, you create a new columnstore index that leverages either standard columnstore or columnstore archive compression. Because of this, the logic of sp_estimate_data_compression_savings when using one of the columnstore options is different than when using one of the rowstore options. When you use a data_compression parameter value of 'COLUMNSTORE' or 'COLUMNSTORE_ARCHIVE' for a rowstore source object, we're not comparing the same rowstore object with different compression states, we're comparing the rowstore object to an equivalent columnstore object. The process is roughly the same: sample pages and create a sample object in tempdb that mimics the source object, build an equivalent columnstore index using the same data, compare the size of the source object with the size of the columnstore index to estimate the compression ratio. So, what do we consider an "equivalent" columnstore object? We had to make some assumptions here to come up with a suitable columnstore reference object based on the source object. The following table illustrates the different reference object types we use to calculate the compression ratio. These apply to both 'COLUMNSTORE' and 'COLUMNSTORE_ARCHIVE' data_compression options:
Source Object Reference Object
Heap Clustered columnstore index
Clustered index Clustered columnstore index
Non-clustered index Non-clustered columnstore index (including the key columns and any included columns of the provided non-clustered index, as well as the partition column of the table, if any)
Non-clustered columnstore index Non-clustered columnstore index (including the same columns as the provided non-clustered columnstore index)
Clustered columnstore index Clustered columnstore index
  You can also estimate in the other direction from columnstore to rowstore compression states. These apply to all the rowstore options, 'ROW', 'PAGE' and 'NONE':  
Source Object Reference Object
Clustered columnstore index Heap
Non-clustered columnstore index Non-clustered index (including the columns contained in the non-clustered columnstore index as key columns, and the partition column of the table, if any, as an included column)
  If you use the 'COLUMNSTORE' or 'COLUMNSTORE_ARCHIVE' options for an existing columnstore source object, the procedure works the same as before, it will create a sample columnstore index and rebuild that index with the desired compression state. Nothing comes for free of course, and while data compression can save a lot of space and therefore a lot of I/O (both logical and physical), the trade off is generally more CPU to compress and decompress the data. In some cases, it may cause performance issues, particularly for data that is heavily updated. This is doubly so for columnstore. These indexes are designed for mostly read data, and heavy updates against columnstores make the structures much less efficient. Leveraging sp_estimate_data_compression_savings along with careful analysis of your workload patterns can help you make the right index and compression choices for your data and application.]]> SQL Server 2019 CTP 2.0 New Features – Introducing the Page Cracker (AKA sys.dm_db_page_info)! https://docs.microsoft.com/archive/blogs/sql_server_team/sql-server-2019-ctp-2-0-new-features-introducing-the-page-cracker-aka-sys-dm_db_page_info Tue, 16 Oct 2018 08:00:45 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7665 Big Data Clusters, data virtualization and Intelligent Query Processing among others, but I wanted to take some time on the blog to dig a little deeper into a few of the improvements we're working on in the storage engine. The first feature is one which I'm particularly excited about – the new sys.dm_db_page_info dynamic management function! The primary use case we had in mind when developing this function was troubleshooting page-related waits. Some of the key performance scenarios that require page details to diagnose are tempdb contention, last page insert contention (also see this blog article for code samples) and page-level blocking. All of these scenarios present as either PAGELATCH or lock wait types in sys.dm_exec_query_stats with a page identifier (db_id:file_id:page_id) in the wait_resource column. In order to gain any insight into the problem, you have to know more details about what that page is. Is it a data page, an index page or something else? If it's a data or index page, which object does it belong to? Prior to SQL Server 2019 CTP 2.0, the only way to gain any of this insight was to use the lightly documented command DBCC PAGE. Unfortunately, if you're using some sort of monitoring tool or script to gather data about waits and blocking, there's no good way to include this DBCC PAGE call in those scripts. Not to mention it requires sysadmin privileges. Enter sys.dm_db_page_info. The sys.dm_db_page_info function takes 4 parameters: database ID, file ID, page ID and mode ('LIMITED' or 'DETAILED'). It returns a table with a single row that contains the header information from the page, including things like object_id, index_id and partition_id. As a standalone function, this provides a documented and fully supported way to retrieve this information without the need for a DBCC command. The real benefit however is the ability to JOIN this function with other DMVs such as sys.dm_exec_requests or sys.sysprocesses to gather this information automatically when there is any sort of page-related contention. If you're familiar with these views you know that the wait_resource column can contain all sorts of different resources, so it's not in the right format to facilitate a direct join to sys.dm_db_page_info. To support this use case, we had to add another column to these views called page_resource. Whenever the wait_resource column contains a page resource, the page_resource column will be populated with an 8-byte hexadecimal value. The page ID is the first four bytes, followed by 2 bytes for the file ID and then 2 bytes for the database ID. For example: 0x4801000001000500 translates to page 5:1:328. Don't worry, you don't have to write T-SQL to do this translation yourself, we've created a new companion function called sys.fn_PageResCracker that will do this translation for you. Here's a sample script of how you can use these two new functions to help troubleshoot page-related waits: SELECT page_info.* FROM sys.dm_exec_requests AS d CROSS APPLY sys.fn_PageResCracker(d.page_resource) AS r CROSS APPLY sys.dm_db_page_info(r.db_id, r.file_id, r.page_id, 1) AS page_info Now that you know the primary use case, let's discuss some limitations. First, this is not a full replacement for DBCC PAGE. DBCC PAGE gives you the entire contents of the page, including header information as well as all the data and the slot array. It can also interpret all this information for you and return it in a user-friendly manner. There are still use cases for this, but they are primarily for things like deep troubleshooting, data corruption analysis and recovery, or simply to illustrate SQL Server concepts such as how indexes are structured. I fully expect to continue to see DBCC PAGE used for demos and illustration purposes, but hopefully its production use can be limited to only those scenarios that absolutely require it. Another limitation is that we currently only support joins to sys.dm_exec_requests and sys.sysprocesses. We hope to expand this list in the future and are open to suggestions for where you would like to see the page_resource column added. One additional view we have in mind is sys.dm_os_waiting_tasks, but since this view stores wait resource information differently than sys.dm_exec_requests, it requires a little more work. Please feel free to comment here or send us feedback at https://aka.ms/sqlfeedback to let us know how you'd like to use this function in the future.]]> SQL Server 2019 Preview https://docs.microsoft.com/archive/blogs/sql_server_team/sql-server-2019-preview Wed, 26 Sep 2018 12:06:48 GMT https://blogs.msdn.microsoft.com/sql_server_team/?p=7655 Earlier this week, we announced SQL Server 2019 Public Preview at Microsoft Ignite. All the features that you see in the “What’s New” page are new capabilities that shipped with the CTP 2.0 release. Some of the key changes that people normally wouldn’t associate with SQL Server was the introduction of big data clusters which combines Apache Spark and Hadoop into a single data platform called SQL Server. Now you have the ability to combine the power of Spark with SQL Server over your relational and non-relation data sitting in SQL Server, HDFS and other systems like Oracle, Teradata, CosmosDB, etc. This is an amazing way to celebrate the 25th anniversary of SQL Server. Not only do we have new capabilities around performance, availability and security for mission critical environments along with capability to leverage hardware innovations like persistent memory and enclaves. But wait that’s not it! We also added Hadoop, ApacheSpark, Kubernetes and Java as native capabilities to our database engine!!! Happy Birthday SQL Server!!!

Release announcement for SQL Server 2019 preview

A detailed introduction to SQL Server big data clusters

General Availability of Azure Data Studio

SQL Server 2019 preview and Containers

Detailed blog post on database engine enhancements for SQL Server 2019 preview

Please stay tuned to the SQL Server blog to know more about the new capabilities and enhancements that will ship in subsequent CTP releases.

Below are the videos from the SQL Server 2019 public preview sessions at Ignite.

]]>