SELECT TOP 1000 col1 
FROM tbl1
OPTION (QUERYTRACEON 4138);

SELECT TOP 1000 col1 
FROM tbl1
OPTION (USE HINT('DISABLE_OPTIMIZER_ROWGOAL'));

1. You have upgraded your SQL Server from 2014 to SQL Server 2017, and upgraded your database compatibility level to the native 140.
2. You notice all your workload runs better on CE140, apart from this one specific query that has regressed.
3. And because you haven’t run the recommended upgrade process, you don’t have a previously known-good plan in Query Store, and Automatic Tuning cannot kick in and help.

1. Whenever you submit a query to SQL Server, if it includes a JOIN and/or WHERE clause, that constitutes a row filtering pattern known as a predicate.
2. The query optimizer can use that to estimate how to best retrieve only the intended rows, after that predicate has been applied, this surfaces in the query plan as the Estimated Number of Rows.
3. When that estimated plan is executed, and you look at the actual execution plan, this surfaces as the Actual Number of Rows. Usually, a big difference between Estimated and Actual number of rows indicates a misestimation that may need to be addressed to improve performance: maybe you don’t have the right indexes in place?

The good!

CREATE NONCLUSTERED INDEX [IX_ModifiedDate_OrderQty] ON [Sales].[SalesOrderDetailBulk] ([ModifiedDate] ASC)
INCLUDE ([ProductID],[OrderQty]) 
GO

SELECT [ProductID]
FROM [Sales].[SalesOrderDetailBulk]
WHERE [ModifiedDate] BETWEEN '2011-01-01' AND '2012-01-01'
AND [OrderQty] = 2
GO

The better!

The Best!

CREATE NONCLUSTERED INDEX [IX_ModifiedDate_OrderQty] ON [Sales].[SalesOrderDetailBulk] ([ModifiedDate] ASC)
INCLUDE ([ProductID],[OrderQty]) 
WHERE [OrderQty] = 2
GO

In conclusion…

So, what's next?

Anything else?

-- Create UDF
CREATE FUNCTION ufn_CategorizePrice(@Price money)
RETURNS NVARCHAR(50)
AS
BEGIN
    DECLARE @PriceCategory NVARCHAR(50)

    IF @Price < 100 SELECT @PriceCategory = 'Cheap'
    IF @Price BETWEEN 101 and 500 SELECT @PriceCategory =  'Mid Price'
    IF @Price BETWEEN 501 and 1000 SELECT @PriceCategory =  'Expensive'
    IF @Price > 1001 SELECT @PriceCategory =  'Unaffordable'
    RETURN @PriceCategory 
END
GO

-- Execute
SELECT dbo.ufn_CategorizePrice(UnitPrice), 
    SalesOrderID, SalesOrderDetailID, CarrierTrackingNumber, 
    OrderQty, ProductID, SpecialOfferID, UnitPrice, UnitPriceDiscount, 
    LineTotal, rowguid, ModifiedDate 
FROM Sales.SalesOrderDetail
GO

So what is row goal?

How is row goal used?

• A hash join is usually a good choice for joining larger inputs. Although it has a higher initial cost, because it has to build a hash table before any rows can be returned, once built, the hash join is generally cheaper.
• But if the two join inputs are sorted on their join column (for example, if they were obtained by scanning sorted indexes), a merge join is the fastest join operation and can be chosen instead.

Example of row goal benefits

SELECT TOP (100) *
FROM Sales.SalesOrderHeaderBulk AS s 
    INNER JOIN Sales.SalesOrderDetailBulk AS d ON s.SalesOrderID = d.SalesOrderID
WHERE s.TotalDue > 1000
OPTION (RECOMPILE);
GO

SELECT TOP (100) *
FROM Sales.SalesOrderHeaderBulk AS s 
    INNER JOIN Sales.SalesOrderDetailBulk AS d ON s.SalesOrderID = d.SalesOrderID
WHERE s.TotalDue > 1000
OPTION (RECOMPILE, USE HINT('DISABLE_OPTIMIZER_ROWGOAL'));
GO

Example of row goal that we can improve upon

SELECT TOP 250 *
FROM Production.TransactionHistory H
INNER JOIN Production.Product P ON  H.ProductID = P.ProductID
OPTION (RECOMPILE)
GO

SELECT TOP 250 *
FROM Production.TransactionHistory H
INNER JOIN Production.Product P ON  H.ProductID = P.ProductID
OPTION (RECOMPILE, USE HINT('DISABLE_OPTIMIZER_ROWGOAL'))
GO

1. Create a new table with a UNIQUEIDENTIFIER column or IDENTITY as primary key. Both inherently unique by design.

   IF NOT EXISTS (SELECT [object_id] FROM sys.objects (NOLOCK) WHERE [object_id] = OBJECT_ID(N'[CustomersTableGuid]') AND [type] IN (N'U'))
   CREATE TABLE CustomersTableGuid
   (
       ID UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID() PRIMARY KEY,
       FirstName VARCHAR(50),
       LastName VARCHAR(50)
   )
   GO
   
   IF NOT EXISTS (SELECT [object_id] FROM sys.objects (NOLOCK) WHERE [object_id] = OBJECT_ID(N'[CustomersTableIdent]') AND [type] IN (N'U'))
   CREATE TABLE CustomersTableIdent
   (
       ID int IDENTITY(1,1) NOT NULL PRIMARY KEY,
       FirstName VARCHAR(50),
       LastName VARCHAR(50)
   )
   GO

2. Insert 1 million records.

   SET NOCOUNT ON;
   DECLARE @i INT = 0
   WHILE (@i <= 1000000)
   BEGIN
       INSERT INTO CustomersTableGuid (FirstName, LastName)
       VALUES ('FirstName' + CAST(@i AS VARCHAR),'LastName' + CAST(@i AS VARCHAR))
   
       INSERT INTO CustomersTableIdent (FirstName, LastName)
       VALUES ('FirstName' + CAST(@i AS VARCHAR),'LastName' + CAST(@i AS VARCHAR))
       
       SET @i +=1
   END
   GO

3. And let's update the statistics with a FULLSCAN.

   UPDATE STATISTICS CustomersTableGuid WITH FULLSCAN
   GO
   UPDATE STATISTICS CustomersTableIdent WITH FULLSCAN
   GO

4. Now, let’s find stats info:
   1. Verifying sampled rows and steps, we have 3 steps for each statistic, with 100% row sampling (rows = rows_sampled).

      SELECT OBJECT_NAME(stat.[object_id]) AS [TableName], sp.stats_id, name, 
          last_updated, rows, rows_sampled, steps, unfiltered_rows, modification_counter   
      FROM sys.stats AS stat   
      CROSS APPLY sys.dm_db_stats_properties(stat.[object_id], stat.stats_id) AS sp  
      WHERE stat.[object_id] = OBJECT_ID('CustomersTableGuid')
          OR stat.[object_id] = OBJECT_ID('CustomersTableIdent');
      GO

      
   2. Looking at the histograms for ID column, we see the 3 steps for each statistic. SQL Server will compact multiple histogram steps into as few steps as possible, without losing histogram quality. As expected, the fullscan is a perfect distribution, and so it can be compacted into just 3 steps.

      SELECT OBJECT_NAME(stat.[object_id]) AS [TableName], stat.name, sh.stats_id, 
          sh.range_high_key, sh.range_rows, sh.equal_rows
      FROM sys.stats AS stat
      INNER JOIN sys.stats_columns AS sc 
          ON stat.stats_id = sc.stats_id AND stat.[object_id] = sc.[object_id]
      INNER JOIN sys.all_columns AS ac 
          ON ac.column_id = sc.column_id AND ac.[object_id] = sc.[object_id]
      CROSS APPLY sys.dm_db_stats_histogram(stat.[object_id], stat.stats_id) AS sh
      WHERE (stat.[object_id] = OBJECT_ID('CustomersTableGuid') 
          OR stat.[object_id] = OBJECT_ID('CustomersTableIdent'))
          AND ac.name = 'ID';
      GO

      Let’s take the histogram steps on ID for the CustomersTableIdent table:
      • 1st step with value 1;
      • 2nd step with 999,998 rows with no repeats (the density is 1);
      • 3rd step with the last row at 1,000,001.
5. Now let's update the statistics with a smaller sample (try whatever value you want), and look at the stats info. SQL Server pulls pages worth of data, then extrapolates that to a full distribution. So, as expected, the sampled distribution is only approximate, and being an extrapolation, this is why we see frequencies that are close to 1, but not exactly 1.

   UPDATE STATISTICS CustomersTableGuid WITH SAMPLE 90 PERCENT
   GO
   UPDATE STATISTICS CustomersTableIdent WITH SAMPLE 90 PERCENT
   GO

   

So why split?

1. Parallelism use is intrinsically a benefit for costly queries, bound by the Cost Threshold for Parallelism and Max Degree of Parallelism server configurations among other considerations. See the Query Processing Guide for more in-depth information on how SQL Server implements parallelism. Also refer to Craig Freedman’s blog series on the topic.
2. Waits are a normal part of the waits and queues model, allowing SQL Server to concurrently execute many more requests than there are schedulers available. See more about waits and queues here,

What is what going forward?

• This is the actionable wait. If contention on this wait type becomes a problem for most of your workload, consider for example:
  • Lowering the Max Degree of Parallelism, which can be done at the server or query level;
  • Changing the default Cost Threshold for Parallelism based on observed query cost for your entire workload;
  • Or better yet, by improving cardinality estimations if actual rows are very different from estimations. See this previous blog post on how to use the new SSMS Plan Analysis feature to get insights into cardinality estimation differences. Improving estimations can include actions such as updating or adding statistics, revising the underlying index design (consider leveraging the Database Tuning Advisor for this), or even hinting the Query Optimizer in edge cases.

• This is a wait type that is a normal part of parallel query execution, and cannot be directly influenced by changing the above mentioned configurations. This is why I called it "negligible" above.

Where can I see how this affects my SQL Servers?

Practical example

SELECT *
FROM Sales.SalesOrderDetail SOD
INNER JOIN Production.Product P ON SOD.ProductID = P.ProductID
WHERE SalesOrderDetailID > 10
ORDER BY Style

SELECT *
FROM Sales.SalesOrderDetail SOD
INNER JOIN Production.Product P ON SOD.ProductID = P.ProductID
WHERE SalesOrderDetailID > 10
ORDER BY Style
OPTION (MAXDOP 4)

 

If you follow this blog, you have seen that in the past few releases we have continuously included a number of diagnostic improvements to Showplan. You can read about some of them here.

Looking at the actual execution plan is one of the most used performance troubleshooting techniques. Having information on elapsed CPU time and overall execution time, together with session wait information in an actual execution plan allows a DBA to use showplan to troubleshoot issues away from the server, and be able to correlate and compare different types of waits that result from query or schema changes.

A few months ago we had introduced exposed in SSMS some of the per-operator statistics, such as CPU and elapsed time per thread. More recently, we have introduced overall query CPU and elapsed time tracking for statistics showplan xml (both in ms). These can be found in the root node of an actual plan. Available using the latest versions of SSMS v17, when used with SQL Server 2012 SP4, SQL Server 2016 SP1 and SQL Server 2017. For SQL Server 2014 it will become available in a future Service Pack. 

And also included the top 10 waits that the execution was waiting on (includes WaitType, WaitTimeMs and WaitCount), based on sys.dm_exec_session_wait_stats. Most common sleep and idle waits are filtered out from the actual plan, so that it becomes easier to really see the relevance of non-idle waits for query performance.

This allows a user to correlate waits with overall times, and be more precise in what to look for to improve query performance. For example, in the picture below, I can correlate the overall elapsed time with the top waits, see that CXPACKET were the most prevalent, that this query is running with DOP 12, and choose to reduce DOP as a way to address this (among other actions possible).

Available using the latest versions of SSMS v17, when used with SQL Server 2016 SP1 and SQL Server 2017. Note that CXPACKET wait will be available in showplan with SQL Server 2017 CU3 and 2016 SP2.

One other information you can now find in showplan is trace flags. This is relevant to understand what trace flags are active during compilation, and which one (if any) actually influence compilation. Below we can see trace flags 2371, 7412 and 9481 were active during compilation (IsCompileTime = True), but 23714 and 7412 did not influence the Query Optimizer (IsCompileTime = False). You can see more information on these trace flags and others in https://aka.ms/traceflags.

These can be found in the root node of even an estimated plan, given this is a compile time ionformation. Available using the latest versions of SSMS v17, when used with SQL Server 2012 SP4, SQL Server 2016 SP1 and SQL Server 2017. For SQL Server 2014 it will become available in a future Service Pack.

Pedro Lopes (@sqlpto) – Senior Program Manager

When SQL Server creates or updates statistics and a sampling rate is not manually specified, SQL Server calculates a default sampling rate. Depending on the real distribution of data in the underlying table, the default sampling rate may not accurately represent the data distribution and then cause degradation of query plan efficiency.

To improve this scenario, a database administrator can choose to manually update statistics with a specific sampling rate that can better represent the distribution of data. However, a subsequent automatic update statistics operation will reset back to the default sampling rate, possibly reintroducing degradation of query plan efficiency.

With the most recent SQL Server 2016 SP1 CU4, we released an enhancement for the CREATE and UPDATE STATISTICS command – the ability to persist sampling rates between updates with a PERSIST_SAMPLE_PERCENT keyword.

Let’s use an example. I’m using the following query:

SELECT [SalesOrderID],[ShipDate],[DueDate],[OrderDate]
FROM [Sales].[SalesOrderHeaderBulk]
WHERE OrderDate BETWEEN '8/30/2012 00:00:00.000' AND '9/30/2012 00:00:00.000' 
GO

Looking at the actual plan, we see a skew between estimated and actual rows in the scan over the orders table:

Let’s check stats on this table then. I’m searching for stats on table orders with column col2 (part of the join argument):

SELECT ss.stats_id, ss.name, filter_definition, last_updated, rows, 
    rows_sampled, steps, unfiltered_rows, modification_counter, persisted_sample_percent,
    (rows_sampled * 100)/rows AS sample_percent
FROM sys.stats ss
INNER JOIN sys.stats_columns sc 
    ON ss.stats_id = sc.stats_id AND ss.object_id = sc.object_id
INNER JOIN sys.all_columns ac 
    ON ac.column_id = sc.column_id AND ac.object_id = sc.object_id
CROSS APPLY sys.dm_db_stats_properties(ss.object_id, ss.stats_id) shr
WHERE ss.[object_id] = OBJECT_ID('[Sales].[SalesOrderHeaderBulk]') 
    AND ac.name = 'OrderDate';

We see a statistic for the index used above, with a sampling rate of 6 percent. Let’s say I really need to improve estimations, and that having a higher sampling rate could just do that.

So I’ll just update this statistic, and while I could try to find a better (and higher) sampling rate, for this demo I’ll just update with full scan:

UPDATE STATISTICS [Sales].[SalesOrderHeaderBulk] [IX_OrderDate] WITH FULLSCAN

Let’s see the estimations now:

Great, so what happens when auto update statistics is triggered? Or I have some stats maintenance job that does not explicitly sets the sampling rate?

UPDATE STATISTICS [Sales].[SalesOrderHeaderBulk] [IX_OrderDate]

It’s back at default sampling (in this case 6 percent).

I really want to always update this statistic with 100 percent sampling rate, so I can now use the following PERSIST_SAMPLE_PERCENT keyword:

UPDATE STATISTICS [Sales].[SalesOrderHeaderBulk] [IX_OrderDate] 
WITH FULLSCAN, PERSIST_SAMPLE_PERCENT = ON

Notice the new persisted_sample_percent column is now showing 100 percent (because sI used FULLSCAN). Both DBCC SHOW_STATISTICS and sys.dm_db_stats_properties have this new column.

What happens when auto update statistics is triggered or my stats are manually updated again?

UPDATE STATISTICS [Sales].[SalesOrderHeaderBulk] [IX_OrderDate]

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

My choice for sampling percentage is now persisted. It will remain persisted until I set this option to OFF. When set to OFF (which is the default), the statistics sampling percentage will get reset to default sampling in subsequent updates that do not explicitly specify a sampling percentage.

Note that if a manual update statistics is executed with a different sampling percentage, but not using PERSIST_SAMPLE_PERCENT keyword to set it as the new persisted value, the previously set fixed sampling will still be in effect for subsequent auto update statistics, or any other manual update that does not set a specific sampling rate.

UPDATE STATISTICS [Sales].[SalesOrderHeaderBulk] [IX_OrderDate] WITH SAMPLE 90 PERCENT

Pedro Lopes (@sqlpto) – Senior Program Manager