Using ALTER DATABASE SCOPED CONFIGURATION in SQL Server 2016

On March 7, 2016, Microsoft announced the availability of the RC0 Build of SQL Server 2016. One of the new features in the RC0 Build is Database Scoped Configurations, which gives you the ability to easily make several database-level configuration changes for things that were previously configured at the instance-level.

These include:

    • Setting MAXDOP for an individual database
    • Setting the query optimizer cardinality estimation model for an individual database (independent of the database compatibility level)
    • Enable or disable parameter sniffing for an individual database
    • Enable or disable query optimization hotfixes for an individual database (equivalent to TF 4199)
    • The ability to clear the plan cache for an individual database (without using a DBCC command)

If you are using AlwaysOn Availability Groups, the first four commands can also be used to affect the database-level configuration setting for ALL of the secondary database copies that are in a AG. You can set these values for just the Primary database, set the values in the secondary database(s) to the same value as the Primary database, or set the values in the secondary database(s) to different values from the Primary database.

There is also a new DMV, sys.database_scoped_configurations, which lets you see the configuration values for the current database, including the values for the Primary database and the secondary databases (if that database is part of an AlwaysOn AG). I have examples of these commands in the code in Figure 1.

   1: -- Database scoped T-SQL Commands in SQL Server 2016 RC0

   2: -- Glenn Berry

   3: -- SQLskills.com

   4:  

   5:  

   6:  

   7: -- Get database scoped configuration values for current database 

   8: SELECT configuration_id, name, [value] AS [value_for_primary], value_for_secondary

   9: FROM sys.database_scoped_configurations WITH (NOLOCK) OPTION (RECOMPILE);

  10:  

  11: -- ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)

  12: -- https://msdn.microsoft.com/en-us/library/mt629158.aspx

  13:  

  14: -- The commands for the secondary database affect ALL secondary databases in an AlwaysOn AG

  15:  

  16: USE [CHECKDBTest]

  17: GO

  18:  

  19: -- Enable legacy Cardinality Estimation for Primary database

  20: -- Equivalent to using TF 4136, except this is only for this database

  21: ALTER DATABASE SCOPED CONFIGURATION 

  22: SET LEGACY_CARDINALITY_ESTIMATION = ON;

  23: GO

  24:  

  25: -- Enable legacy Cardinality Estimation for Secondary database

  26: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY 

  27: SET LEGACY_CARDINALITY_ESTIMATION = ON;

  28: GO

  29:  

  30: -- Set legacy Cardinality Estimation for the Secondary database(s) to the same value as the Primary database

  31: -- This is the default setting

  32: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY 

  33: SET LEGACY_CARDINALITY_ESTIMATION = PRIMARY;

  34: GO

  35:  

  36:  

  37:  

  38: -- Disable parameter sniffing for Primary database

  39: ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SNIFFING = OFF;

  40: GO

  41:  

  42: -- Disable parameter sniffing for Secondary database

  43: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY SET PARAMETER_SNIFFING = OFF;

  44: GO

  45:  

  46: -- Set parameter sniffing for the Secondary database(s) to the same value as the Primary database

  47: -- This is the default setting

  48: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY    

  49: SET PARAMETER_SNIFFING = PRIMARY;

  50: GO

  51:  

  52:  

  53:  

  54: -- Enable query optimizer fixes for Primary database

  55: -- Equivalent to using TF 4199, except this is only for this database

  56: ALTER DATABASE SCOPED CONFIGURATION 

  57: SET QUERY_OPTIMIZER_HOTFIXES = ON;

  58: GO

  59:  

  60: -- Enable query optimizer fixes for Secondary database

  61: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY 

  62: SET QUERY_OPTIMIZER_HOTFIXES = ON;

  63: GO

  64:  

  65:  

  66: -- Set MAXDOP for Primary database

  67: ALTER DATABASE SCOPED CONFIGURATION 

  68: SET MAXDOP = 4;

  69: GO

  70:  

  71: -- Set MAXDOP for Secondary database(s)

  72: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY 

  73: SET MAXDOP = 4;

  74: GO

  75:  

  76: -- Set MAXDOP for the Secondary database(s) to the same value as the Primary database

  77: -- This is the default setting

  78: ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY 

  79: SET MAXDOP = PRIMARY; 

  80:  

  81:  

  82: -- Clear plan cache for current database (only possible for Primary database)

  83: ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

  84: GO

Figure 1: Example Database Scoped Configuration Commands in SQL Server 2016

 

 

 

Countdown to DEVintersection/SQLintersection in Orlando

As I have recently posted, I will be presenting three regular sessions and a full-day workshop at the DEVintersection/SQLintersection conference in Orlando, FL on April 16-22, 2016. As the conference get’s closer, I am starting to get more excited about it, reminding me of how I used to feel in my younger days as a developer and DBA. Getting away from work for a few days and being able to focus completely on something you are passionate about, surrounded by many like-minded people has always been a good way to recharge my motivation.

Richard Campbell of DotNetRocks and RunAsRadio has been recording some DEVintersection/SQLintersection “countdown” sessions on Channel 9, and the first five are available from the links below:

Watching short videos like this helps build and maintain the enthusiasm while I wait for the conference! The Doug Seven video is particularly good, prompting me to order an Adafruit Microsoft Internet of Things Pack for Raspberry Pi 2 kit just now…

SQL_Spr16_300x250_v5

You can register for the conference and additional workshops here. If you register by March 21, 2016, you will get (depending on which package you sign up for), your choice of a Microsoft Band 2, a $200.00 hotel gift card, a Microsoft Surface 3, or a Microsoft XBOX One. You can also get a $50.00 discount on your registration if you the use the discount code “BERRY” when you sign up.

 

 

SQL Server 2014 Service Pack 1 CU5 Available

Microsoft has released SQL Server 2014 Service Pack 1 Cumulative Update 5, which is Build 12.0.4439.1. There are 21 hotfixes in the public fix list.

In a very welcome change from the past, Microsoft has greatly streamlined the process for obtaining SQL Server Cumulative Updates. Rather than having to request the CU from a web page, and then wait for Microsoft to send you a download link by email (which, to be fair, usually only took a few minutes), you can now just download the latest Cumulative Update directly from the Microsoft Download Center.

Another, even more welcome move is how Microsoft has changed their guidance and language regarding whether you should install SQL Server Cumulative Updates. Rather than the old, somewhat alarming language, we now have this language:

Only the most recent cumulative update that was released for SQL Server 2014 SP1 is available at the Download Center.

  • Each new Cumulative Update (CU) contains all the fixes that were included with the previous CU for the installed version/Service Pack of SQL Server.
  • Microsoft recommends ongoing, proactive installation of CUs as they become available:
    • SQL Server CUs are certified to the same levels as Service Packs, and should be installed at the same level of confidence.
    • 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.
  • Just as for SQL Server service packs, we recommend that you test CUs before you deploy them to production environments.
  • We recommend that you upgrade your SQL Server installation to the latest SQL Server 2014 service pack.

This is a huge improvement, and I really hope that this new guidance will encourage more people to actually try to stay more up to date with their SQL Server CUs. Having a robust testing, deployment and rollback plan, that you actually use and improve over time as you regularly deploy SQL Server CUs has a lot of benefits for your organization.

SQL Server Diagnostic Information Queries for February 2016

Rather than having a separate blog post for each version, I have just put the links for all six major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set. 

Here are links to the latest versions of these queries for SQL Server 2016, 2014 and 2012:

SQL Server 2016 Diagnostic Information Queries (February 2016)

SQL Server 2016 Blank Results

SQL Server 2014 Diagnostic Information Queries (February 2016)

SQL Server 2014 Blank Results

SQL Server 2012 Diagnostic Information Queries (February 2016)

SQL Server 2012 Blank Results

Here are links to the most recent versions of these scripts for SQL Server 2008 R2 and older:

Since SQL Server 2008 R2 and older are out of Mainstream support from Microsoft (and because fewer of my customers are using these old versions of SQL Server), I am not going to be updating the scripts for these older versions of SQL Server every single month going forward.  I started this policy a while ago, and so far, I have not heard any complaints. I did update these queries slightly in January though.

SQL Server 2008 R2 Diagnostic Information Queries (CY 2016)

SQL Server 2008 R2 Blank Results

SQL Server 2008 Diagnostic Information Queries (CY 2016)

SQL Server 2008 Blank Results

SQL Server 2005 Diagnostic Information Queries (CY 2016)

SQL Server 2005 Blank Results

The basic instructions for using these queries is that you should run each query in the set, one at a time (after reading the directions for that query). It is not really a good idea to simply run the entire batch in one shot, especially the first time you run these queries on a particular server, since some of these queries can take some time to run, depending on your workload and hardware. I also think it is very helpful to run each query, look at the results (and my comments on how to interpret the results) and think about the emerging picture of what is happening on your server as you go through the complete set. I have some comments in the script on how to interpret the results after each query.

You need to click on the top left square of the results grid in SQL Server Management Studio (SSMS) to select all of the results, and then right-click and select “Copy with Headers” to copy all of the results, including the column headers to the Windows clipboard. Then you paste the results into the matching tab in the blank results spreadsheet.

About half of the queries are instance specific and about half are database specific, so you will want to make sure you are connected to a database that you are concerned about instead of the master system database. Running the database-specific queries while being connected to the master database is a very common mistake that I see people making when they run these queries.

Note: These queries are stored on Dropbox. I occasionally get reports that the links to the queries and blank results spreadsheets do not work, which is most likely because Dropbox is blocked wherever people are trying to connect.

I also occasionally get reports that some of the queries simply don’t work. This usually turns out to be an issue where people have some of their user databases in 80 compatibility mode, which breaks many DMV queries, or that someone is running an incorrect version of the script for their version of SQL Server.

It is very important that you are running the correct version of the script that matches the major version of SQL Server that you are running. There is an initial query in each script that tries to confirm that you are using the correct version of the script for your version of SQL Server. If you are not using the correct version of these queries for your version of SQL Server, some of the queries are not going to work correctly.

If you want to understand how to better run and interpret these queries, you should consider listening to my three latest Pluralsight courses, which are SQL Server 2014 DMV Diagnostic Queries – Part 1SQL Server 2014 DMV Diagnostic Queries – Part 2 and SQL Server 2014 DMV Diagnostic Queries – Part 3. All three of these courses are pretty short and to the point, at 67, 77, and 68 minutes respectively. Listening to these three courses is really the best way to thank me for maintaining and improving these scripts…

You can also come listen to me discuss these queries in great detail, over the course of over three hours by coming to SQLintersection Spring 2016 – Orlando, FL – April 16-22, 2016, which will be a lot of fun!

Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks

Recommended Intel Xeon E5-2600 v4 Processors for SQL Server

Updated March 31, 2016: Today, Intel has released the fourth generation, 14nm Xeon E5-2600 v4 processor family, code-named “Broadwell-EP”. This is a Tick release from Intel, taking the existing Haswell microarchitecture, and shrinking it from 22nm to 14nm. This new family of processors has more physical cores, a larger total shared L3 cache size, and support for up to DDR4-2400 memory. There will doubtless be a few other minor improvements, as part of the Tick release.

These processors are socket compatible with the current Intel Xeon E5-2600 v3 family, “Haswell-EP”, so they should just need an updated BIOS to work in existing model servers that currently support Haswell-EP. What that means for most people is that existing model servers from your server vendor of choice will be able to use these new processors as soon as they are available, meaning less delay to market.

From the official Intel ARK database, I have put together a list of what I think are the best models at each core count for SQL Server usage.

 

Model Cores Base Clock Speed Turbo Clock Speed L3 Cache
Xeon E5-2637 v4 4 3.5 GHz 3.7 GHz 15 MB
Xeon E5-2643 v4 6 3.4 GHz 3.7 GHz 20 MB
Xeon E5-2667 v4 8 3.2 GHz 3.6 GHz 25 MB
Xeon E5-2640 v4 10 2.4 GHz 3.4 GHz 25 MB
Xeon E5-2687W v4 12 3.0 GHz 3.5 GHz 30 MB
Xeon E5-2690 v4 14 2.6 GHz 3.5 GHz 35 MB
Xeon E5-2697A v4 16 2.6 GHz 3.6 GHz 40 MB
Xeon E5-2697 v4 18 2.3 GHz 3.6 GHz 45 MB
Xeon E5-2698 v4 20 2.2 GHz 3.6 GHz 50 MB
Xeon E5-2699 v4 22 2.2 GHz 3.6 GHz 55 MB

Table 1: Recommended Intel Xeon E5-2600 v4 Family Processors for SQL Server

Notice the dramatic drop in base clock speeds as you go with higher core count models than the eight core Xeon E5-2667 v4 model. Also notice the amount of L3 cache per core decreasing with the higher core count models. It is not clear whether the Xeon E5-2687W v4 (which is meant for workstation use) will be available for server from the major vendors or not. The previous E5-2687 v3 was available, just requiring higher wattage power supplies.

What this means is that most people are going to be much better off from a pure performance perspective with the eight core or lower core count models. They will have much better single-threaded processor performance and much lower SQL Server 2014/2016 licensing costs. The downside is less total CPU capacity, meaning less scalability, as long as you don’t run into storage or memory bottlenecks before you run into CPU bottlenecks.

If your workload can be split across multiple, two-socket database servers, you would be much better off with two or even three database servers, with lower core count, “frequency-optimized” processors (especially the Xeon E5-2643 v4 and the Xeon E5-2667 v4) rather than a single two-socket database server with a much higher core count processor model.

For example, two Dell PowerEdge R730 servers with the eight-core Xeon E5-2667 v4 would be far superior to one Dell PowerEdge R730 server with the sixteen-core Xeon E5-2683 v4 processor. You would have much faster processor cores, more total L3 cache, twice the memory capacity, and twice the number of PCIe 3.0 slots, for the same SQL Server 2014/2016 licensing cost. The cost of the extra server would be pretty negligible compared to the total cost of the hardware and SQL Server licenses. You could probably even go down to the six core Xeon E5-2643 v4 in each of the two servers, dropping your total SQL Server 2014/2016 licensing costs by over $50K.

SQLintersection Spring 2016 – Orlando, FL – April 16-22, 2016

I’ll be presenting multiple sessions at the SQLintersection Spring 2016 conference in Orlando, FL on April 16-22, 2016. This conference has an exclusive slate of top-tier speakers, with great content, and a nice, intimate atmosphere that lets attendees get more personal interaction with the speakers compared to most other SQL Server conferences.

Here are the sessions that I will be presenting:

Workshop Session

Analyzing and Improving I/O Subsystem Performance  (All day workshop on Monday, April 18, 2016)

SQL Server is often I/O bound, but proving it to your storage or SAN administrator can be challenging! You will learn about the different types of storage that are available for SQL Server, and how to decide what type of storage to use for different SQL Server workload and file types. You will also learn useful tips and techniques for configuring your storage for the best performance and reliability for your workload. There will be extensive coverage on how to use disk benchmark tools like CrystalDiskMark 5.0 and Microsoft DiskSpd, so you can confidently understand the performance that your I/O subsystem can deliver. We’ll also cover methods to effectively measure and monitor your storage performance from an OS and SQL Server perspective so that you will have valuable information and evidence available the next time you have to discuss I/O performance with your storage administrator. You will also learn a number of valuable OS and SQL Server configuration settings that will help you get the best I/O performance possible from your storage subsystem.

 

Regular Sessions

Dr. DMV’s Troubleshooting Toolkit – Part 1

Dynamic Management Views and functions allow you to easily see exactly what is happening inside your SQL Server instances and databases with a high level of detail. You can discover your top wait types, most CPU intensive stored procedures, find missing indexes, and identify unused indexes, to name just a few examples. This session presents, demonstrates and explains a complete set of diagnostic DMV queries that you can easily use to detect and diagnose configuration and performance issues in your SQL Server instances and databases.

Dr. DMV’s Troubleshooting Toolkit – Part 2

A continuation of the first session!
Dynamic Management Views and functions allow you to easily see exactly what is happening inside your SQL Server instances and databases with a high level of detail. You can discover your top wait types, most CPU intensive stored procedures, find missing indexes, and identify unused indexes, to name just a few examples. This session presents, demonstrates and explains a complete set of diagnostic DMV queries that you can easily use to detect and diagnose configuration and performance issues in your SQL Server instances and databases.

Scaling SQL Server

SQL Server implementations can quickly evolve and become more complex, forcing DBAs and developers to think about how they can scale their solution quickly and effectively. Scaling up is relatively easy (but can be expensive), while scaling out requires significant engineering time and effort. If you suggest hardware upgrades you may be accused of simply “throwing hardware at the problem”, and if you try to scale out, you may be thwarted by a lack of development resources or 3rd party software restrictions. As your database server nears its load capacity, what can you do? This session gives you concrete, practical advice on how to deal with this situation. Starting with your present workload, configuration and hardware, we will explore how to find and alleviate bottlenecks, whether they are workload related, configuration related, or hardware related. Next, we will cover how you can decide whether you should scale up or scale out your data tier. Once that decision is made, you will learn how to scale up properly, with nearly zero down-time. If you decide to scale out, you will learn about practical, production-ready techniques such as vertical partitioning, horizontal partitioning, and data dependent routing. We will also cover how to use middle-tier caching and other application techniques to increase your overall scalability.

 

You can register for the conference and additional workshops here. If you register by March 1, 2016, you will get (depending on which package you sign up for), your choice of a Microsoft Band 2, a $200.00 hotel gift card, a Microsoft Surface 3, or a Microsoft XBOX One. You can also get a $50.00 discount on your registration if the use the discount code “Berry” when you sign up.

I think this will be a very useful and fun conference, and I hope to see you there!

SQL Server Diagnostic Information Queries Detailed–Recap

Over the course of the month of January 2016, I wrote a series of daily blog posts that went through each of the 70 queries in the January 2016 version of my SQL Server 2016 Diagnostic Information Queries, with documentation of the various views and functions behind each query, along with what I hope is some useful information about how to interpret the results of each query.

Below are links to each of the daily blog posts for this series, along with a list of the queries that were covered that day:

SQL Server Diagnostic Information Queries Detailed, Day 1

Version Info, Core Counts

SQL Server Diagnostic Information Queries Detailed, Day 2

Server Properties, Configuration Values

SQL Server Diagnostic Information Queries Detailed, Day 3

Global Trace Flags, Process Memory

SQL Server Diagnostic Information Queries Detailed, Day 4

SQL Server Services Info, SQL Server Agent Jobs

SQL Server Diagnostic Information Queries Detailed, Day 5

SQL Server Agent Alerts, Windows Info

SQL Server Diagnostic Information Queries Detailed, Day 6

SQL Server NUMA Info, System Memory

SQL Server Diagnostic Information Queries Detailed, Day 7

SQL Server Error Log, Cluster Node Properties, AlwaysOn AG Cluster

SQL Server Diagnostic Information Queries Detailed, Day 8

Hardware Info, System Manufacturer, Processor Description

SQL Server Diagnostic Information Queries Detailed, Day 9

BPW Configuration, BPE Usage

SQL Server Diagnostic Information Queries Detailed, Day 10

Memory Dump Info, Database Filenames and Paths

SQL Server Diagnostic Information Queries Detailed, Day 11

Volume Info, Drive-Level Latency, IO Stalls by File, IO Warnings

SQL Server Diagnostic Information Queries Detailed, Day 12

Database Properties, Missing Indexes All Databases, VLF Counts

SQL Server Diagnostic Information Queries Detailed, Day 13

CPU Usage by Database, IO Usage by Database, Total Buffer Usage by Database

SQL Server Diagnostic Information Queries Detailed, Day 14

Top Waits, Connection Counts by IP Address

SQL Server Diagnostic Information Queries Detailed, Day 15

Avg Task Counts, Detect Blocking

SQL Server Diagnostic Information Queries Detailed, Day 16

CPU Utilization History, Top Worker Time Queries

SQL Server Diagnostic Information Queries Detailed, Day 17

PLE by NUMA Node, Memory Grants Pending,

SQL Server Diagnostic Information Queries Detailed, Day 18

Memory Clerk Usage, Ad hoc Queries, Top Logical Reads Queries

SQL Server Diagnostic Information Queries Detailed, Day 19

File Sizes and Space, IO Stats by File

SQL Server Diagnostic Information Queries Detailed, Day 20

Query Execution Counts, SP Execution Counts

SQL Server Diagnostic Information Queries Detailed, Day 21

SP Avg Elapsed Time, SP Worker Time

SQL Server Diagnostic Information Queries Detailed, Day 22

SP Logical Reads, SP Physical Reads

SQL Server Diagnostic Information Queries Detailed, Day 23

SP Logical Writes, Top IO Statements

SQL Server Diagnostic Information Queries Detailed, Day 24

Bad NC Indexes, Missing Indexes, Missing Index Warnings

SQL Server Diagnostic Information Queries Detailed, Day 25

Buffer Usage, Table Sizes

SQL Server Diagnostic Information Queries Detailed, Day 26

Table Properties, Statistics Update

SQL Server Diagnostic Information Queries Detailed, Day 27

Volatile Indexes, Index Fragmentation

SQL Server Diagnostic Information Queries Detailed, Day 28

Overall Index Usage – Reads, Overall Index Usage – Writes

SQL Server Diagnostic Information Queries Detailed, Day 29

XTP Index Usage, Lock Waits

SQL Server Diagnostic Information Queries Detailed, Day 30

UDF Statistics, QueryStore Options

SQL Server Diagnostic Information Queries Detailed, Day 31

High Aggregate Duration Queries, Recent Full Backups

 

These three Pluralsight Courses go into even more detail about how to run these queries and interpret the results.

SQL Server 2014 DMV Diagnostic Queries – Part 1

SQL Server 2014 DMV Diagnostic Queries – Part 2

SQL Server 2014 DMV Diagnostic Queries – Part 3

SQL Server Diagnostic Information Queries Detailed, Day 31

For Day 31 of this series, we start out with Query #69, which is High Aggregate Duration Queries. This query retrieves information from the sys.query_store_query_text query store catalog view, the sys.query_store_query query store catalog view, the sys.query_store_plan query store catalog view, the sys.query_store_runtime_stats query store catalog view, and the sys.query_store_runtime_stats_interval query store catalog view about the highest aggregate duration queries in the current database over the past hour. Query #69 is shown in Figure 1.

   1: -- Get highest aggregate duration queries over last hour (Query 69) (High Aggregate Duration Queries)

   2: WITH AggregatedDurationLastHour

   3: AS

   4: (SELECT q.query_id, SUM(count_executions * avg_duration) AS total_duration,

   5:    COUNT (distinct p.plan_id) AS number_of_plans

   6:    FROM sys.query_store_query_text AS qt WITH (NOLOCK)

   7:    INNER JOIN sys.query_store_query AS q WITH (NOLOCK)

   8:    ON qt.query_text_id = q.query_text_id

   9:    INNER JOIN sys.query_store_plan AS p WITH (NOLOCK)

  10:    ON q.query_id = p.query_id

  11:    INNER JOIN sys.query_store_runtime_stats AS rs WITH (NOLOCK)

  12:    ON rs.plan_id = p.plan_id

  13:    INNER JOIN sys.query_store_runtime_stats_interval AS rsi WITH (NOLOCK)

  14:    ON rsi.runtime_stats_interval_id = rs.runtime_stats_interval_id

  15:    WHERE rsi.start_time >= DATEADD(hour, -1, GETUTCDATE()) 

  16:    AND rs.execution_type_desc = N'Regular'

  17:    GROUP BY q.query_id),

  18: OrderedDuration AS

  19: (SELECT query_id, total_duration, number_of_plans, 

  20:  ROW_NUMBER () OVER (ORDER BY total_duration DESC, query_id) AS RN

  21:  FROM AggregatedDurationLastHour)

  22: SELECT OBJECT_NAME(q.object_id) AS [Containing Object], qt.query_sql_text, 

  23: od.total_duration AS [Total Duration (microsecs)], 

  24: od.number_of_plans AS [Plan Count],

  25: p.is_forced_plan, p.is_parallel_plan, p.is_trivial_plan,

  26: q.query_parameterization_type_desc, p.[compatibility_level],

  27: p.last_compile_start_time, q.last_execution_time,

  28: CONVERT(xml, p.query_plan) AS query_plan_xml 

  29: FROM OrderedDuration AS od 

  30: INNER JOIN sys.query_store_query AS q WITH (NOLOCK)

  31: ON q.query_id  = od.query_id

  32: INNER JOIN sys.query_store_query_text AS qt WITH (NOLOCK)

  33: ON q.query_text_id = qt.query_text_id

  34: INNER JOIN sys.query_store_plan AS p WITH (NOLOCK)

  35: ON q.query_id = p.query_id

  36: WHERE od.RN <= 50 

  37: ORDER BY total_duration DESC OPTION (RECOMPILE);

  38:  

  39: -- New for SQL Server 2016

  40: -- Requires that QueryStore is enabled for this database

Figure 1: Query #69 High Aggregate Duration Queries

If you are using the QueryStore feature in SQL Server 2016, (meaning that you have enabled it for the current database), then you can either use the built in functionality in SSMS, or use queries like this to examine the data that it collects and exposes. Personally, I like to be able to write custom queries like this to analyze the information.

This query lets you identify which queries in the current database have the highest aggregate duration over the past hour. This lets you find queries that might benefit from your query and index tuning efforts, especially ones that may show a noticeable benefit from any improvements.

 

Query #70 is Recent Full Backups. This query retrieves information from the dbo.backupset table in the msdb system database about the most recent Full database backups for the current database. Query #70 is shown in Figure 2.

   1: -- Look at recent Full backups for the current database (Query 70) (Recent Full Backups)

   2: SELECT TOP (30) bs.machine_name, bs.server_name, bs.database_name AS [Database Name], bs.recovery_model,

   3: CONVERT (BIGINT, bs.backup_size / 1048576 ) AS [Uncompressed Backup Size (MB)],

   4: CONVERT (BIGINT, bs.compressed_backup_size / 1048576 ) AS [Compressed Backup Size (MB)],

   5: CONVERT (NUMERIC (20,2), (CONVERT (FLOAT, bs.backup_size) /

   6: CONVERT (FLOAT, bs.compressed_backup_size))) AS [Compression Ratio], bs.has_backup_checksums, bs.is_copy_only, bs.encryptor_type,

   7: DATEDIFF (SECOND, bs.backup_start_date, bs.backup_finish_date) AS [Backup Elapsed Time (sec)],

   8: bs.backup_finish_date AS [Backup Finish Date]

   9: FROM msdb.dbo.backupset AS bs WITH (NOLOCK)

  10: WHERE bs.database_name = DB_NAME(DB_ID())

  11: AND bs.[type] = 'D' -- Change to L if you want Log backups

  12: ORDER BY bs.backup_finish_date DESC OPTION (RECOMPILE);

  13:  

  14: -- Are your backup sizes and times changing over time?

  15: -- Are you using backup compression?

  16: -- Have you done any backup tuning with striped backups, or changing the parameters of the backup command?

Figure 2: Query #70 Recent Full Backups

This query gives you some useful statistics and properties about your most recent Full database backups for the current database. It shows you the uncompressed size of the backup, along with the compressed size and the compression ratio, if any. It also lets you know if the backup is using checksums, whether it is a copy-only backup, and whether it is using native backup encryption, which was a new feature in SQL Server 2014. Finally, it shows you when each backup finished and how long it took to complete.

Keeping an eye on the size and elapsed time for your database backups is always a good idea. As your database gets larger, you may have to make changes to how and when you do your backups or to the underlying resources at location to where they are going to make sure that they are finishing in a reliable and timely manner.

These three Pluralsight Courses go into even more detail about how to run these queries and interpret the results.

SQL Server 2014 DMV Diagnostic Queries – Part 1

SQL Server 2014 DMV Diagnostic Queries – Part 2

SQL Server 2014 DMV Diagnostic Queries – Part 3

We have finally made it to the end of this series!  I’ll be putting up a recap post for the entire series, with links to each post.

SQL Server Diagnostic Information Queries Detailed, Day 30

For Day 30 of this series, we start out with Query #67, which is UDF Statistics. This query retrieves information from the sys.dm_exec_function_stats dynamic management view about aggregate runtime metrics for user-defined functions in the current database, ordered by object name. Query #67 is shown in Figure 1.

   1: -- Look at UDF execution statistics (Query 67) (UDF Statistics)

   2: SELECT OBJECT_NAME(object_id) AS [Function Name], execution_count,

   3:    total_elapsed_time/1000 AS [time_milliseconds], fs.[type_desc]

   4: FROM sys.dm_exec_function_stats AS fs WITH (NOLOCK) 

   5: WHERE database_id = DB_ID()

   6: ORDER BY OBJECT_NAME(object_id) OPTION (RECOMPILE);

   7:  

   8: -- New for SQL Server 2016

   9: -- Helps you investigate UDF performance issues

Figure 1: Query #67 UDF Statistics

One fairly well-known, long-running issue with SQL Server is how often you see performance problems with scalar, user-defined functions (UDFs). As a DBA, I always tried to avoid having my developers ever find out that scalar UDFs even existed, but they sometimes discovered them on their own, unfortunately. One big problem with scalar UDFs is that their actual cost does not show up when you look at the execution plan or statistics IO output for the query or stored procedure that called them.

In the past, you needed to use tools like SQL Profiler or Extended Events to see what was going on when you had scalar UDF usage. In SQL Server 2016, you will be able to use this new DMV and this query to have some visibility about what your UDFs are doing. As far as mitigation goes, doing things like converting a scalar UDF to a table UDF that just returns just one column and one row, or converting it to a stored procedure are often pretty effective and easy to do.

 

Query #68 is QueryStore Options. This query retrieves information from the sys.database_query_store_options dynamic management view about the current QueryStore options for the current database. Query #68 is shown in Figure 2.

   1: -- Get QueryStore Options for this database (Query 68) (QueryStore Options)

   2: SELECT actual_state, actual_state_desc, readonly_reason, 

   3:        current_storage_size_mb, max_storage_size_mb

   4: FROM sys.database_query_store_options WITH (NOLOCK)

   5: OPTION (RECOMPILE);

   6:  

   7: -- New for SQL Server 2016

   8: -- Requires that QueryStore is enabled for this database

Figure 2: Query #68 QueryStore Options

QueryStore is one of the more exciting new features in SQL Server 2016. It gives you a lot of visibility about what is happening with your query plans in a particular database over time. You also get the ability to force the query optimizer to use a particular “good” query plan. This should make it much easier to troubleshoot and correct plan regression issues. So far, Microsoft has not announced whether this is an Enterprise Edition–only feature or not. Before you can use QueryStore, you have to enable it for the database that you are concerned with.

 

These three Pluralsight Courses go into even more detail about how to run these queries and interpret the results.

SQL Server 2014 DMV Diagnostic Queries – Part 1

SQL Server 2014 DMV Diagnostic Queries – Part 2

SQL Server 2014 DMV Diagnostic Queries – Part 3

SQL Server Diagnostic Information Queries Detailed, Day 29

For Day 29 of this series, we start out with Query #65, which is XTP Index Usage. This query retrieves information from the sys.dm_db_xtp_index_stats dynamic management view and the sys.indexes object catalog view about the overall in-memory OLTP index usage in the current database, ordered by object name. Query #65 is shown in Figure 1.

   1: -- Get in-memory OLTP index usage (Query 65) (XTP Index Usage)

   2: SELECT OBJECT_NAME(i.[object_id]) AS [Object Name], i.index_id, i.name, i.type_desc,

   3:        xis.scans_started, xis.scans_retries, xis.rows_touched, xis.rows_returned 

   4: FROM sys.dm_db_xtp_index_stats AS xis WITH (NOLOCK)

   5: INNER JOIN sys.indexes AS i WITH (NOLOCK)

   6: ON i.[object_id] = xis.[object_id] 

   7: AND i.index_id = xis.index_id 

   8: ORDER BY OBJECT_NAME(i.[object_id]) OPTION (RECOMPILE);

   9:  

  10: -- This gives you some index usage statistics for in-memory OLTP

  11: -- Returns no data if you are not using in-memory OLTP

Figure 1: Query #65 XTP Index Usage

If you are using in-memory OLTP (aka Hekaton), then this query will show how your in-memory OLTP indexes are being used. Perhaps because this is an Enterprise-only feature and perhaps because it has some limitations in SQL Server 2014, I have not seen this feature being used that much out in the field yet. I think the adoption rate will improve with SQL Server 2016.

 

Query #66 is Lock Waits. This query retrieves information from the sys.dm_db_index_operational_stats dynamic management function, the sys.objects object catalog view, and the sys.indexes object catalog view about the cumulative lock waits in the current database. Query #66 is shown in Figure 2.

   1: -- Get lock waits for current database (Query 66) (Lock Waits)

   2: SELECT o.name AS [table_name], i.name AS [index_name], ios.index_id, ios.partition_number,

   3:         SUM(ios.row_lock_wait_count) AS [total_row_lock_waits], 

   4:         SUM(ios.row_lock_wait_in_ms) AS [total_row_lock_wait_in_ms],

   5:         SUM(ios.page_lock_wait_count) AS [total_page_lock_waits],

   6:         SUM(ios.page_lock_wait_in_ms) AS [total_page_lock_wait_in_ms],

   7:         SUM(ios.page_lock_wait_in_ms)+ SUM(row_lock_wait_in_ms) AS [total_lock_wait_in_ms]

   8: FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) AS ios

   9: INNER JOIN sys.objects AS o WITH (NOLOCK)

  10: ON ios.[object_id] = o.[object_id]

  11: INNER JOIN sys.indexes AS i WITH (NOLOCK)

  12: ON ios.[object_id] = i.[object_id] 

  13: AND ios.index_id = i.index_id

  14: WHERE o.[object_id] > 100

  15: GROUP BY o.name, i.name, ios.index_id, ios.partition_number

  16: HAVING SUM(ios.page_lock_wait_in_ms)+ SUM(row_lock_wait_in_ms) > 0

  17: ORDER BY total_lock_wait_in_ms DESC OPTION (RECOMPILE);

  18:  

  19: -- This query is helpful for troubleshooting blocking and deadlocking issues

Figure 2: Query #66 Lock Waits

If you are seeing symptoms of locking/blocking/deadlocks (such as high average task counts or actual deadlock errors), then this query can show which tables and indexes are seeing the most lock waits, which can often help you troubleshoot and resolve your blocking issues.

These three Pluralsight Courses go into even more detail about how to run these queries and interpret the results.

SQL Server 2014 DMV Diagnostic Queries – Part 1

SQL Server 2014 DMV Diagnostic Queries – Part 2

SQL Server 2014 DMV Diagnostic Queries – Part 3