Columnstore Indexes part 86 (“New Trace Flags in SQL Server 2016”)

Continuation from the previous 85 parts, the whole series can be found at http://www.nikoport.com/columnstore/

With the release of SQL Server 2016, a great number of new functionalities with specific internal structures and own behaviours were created ( Columnstore Indexes part 60 (“3 More Batch Mode Improvements in SQL Server 2016”) , Columnstore Indexes part 60 (“3 More Batch Mode Improvements in SQL Server 2016”) , Columnstore Indexes part 65 (“Clustered Columnstore Improvements in SQL Server 2016”) , Columnstore Indexes part 72 (“InMemory Operational Analytics”) ) so that there is a customer need to execute a good control under some certain circumstances.

2 years ago I have blogged about available Trace Flags & Query Rules for the Columnstore Indexes in SQL Server 2014 , and now it is the time to revisit this topic and show what new Trace Flags are available in SQL Server 2016, and this article focuses on this topic.

Batch Sort

The possibility of having your data sorted with the help of the Batch Execution Mode was introduced in SQL Server and some of the key improvements for the SQL Server 2016, such asWindow Functions depend on the velocity of execution of the Sort iterator

The vast majority of the time, it works fine, but some rare times it can bring you into some serious trouble.

For that purpose, the documented (I call it documented, since it is mentioned in the KB 3172787 ) Trace Flag was introduced to allow to disable the Batch Execution Mode for the iterator.

This trace flag works as a Configuration Parameter, as a Global Trace Flag, Session Trace Flag or even QueryTraceOn option).

I will use the free ContosoRetailDW database (it is so easy to play) and run the standard script for restoring a copy of it from C:\Install\, upgrading it’s compatibility level to 130 (batch mode improvements require it) and then dropping the primary clustered key from the FactOnlineSales table and create a Clustered Columnstore Index on it:

USE master; alterdatabaseContosoRetailDW setSINGLE_USERWITHROLLBACKIMMEDIATE; RESTOREDATABASE [ContosoRetailDW] FROMDISK = N'C:\Install\ContosoRetailDW.bak' WITHFILE = 1, MOVE N'ContosoRetailDW2.0' TO N'C:\Data\ContosoRetailDW.mdf', MOVE N'ContosoRetailDW2.0_log' TO N'C:\Data\ContosoRetailDW.ldf', NOUNLOAD,STATS = 5; alterdatabaseContosoRetailDW setMULTI_USER; GO Use ContosoRetailDW; GO ALTERDATABASE [ContosoRetailDW] SETCOMPATIBILITY_LEVEL = 130 GO ALTERDATABASE [ContosoRetailDW] MODIFYFILE ( NAME = N'ContosoRetailDW2.0', SIZE = 2000000KB , FILEGROWTH = 128000KB ) GO ALTERDATABASE [ContosoRetailDW] MODIFYFILE ( NAME = N'ContosoRetailDW2.0_log', SIZE = 400000KB , FILEGROWTH = 256000KB ) GO ALTERTABLEdbo.[FactOnlineSales] DROPCONSTRAINT [PK_FactOnlineSales_SalesKey]; createclusteredcolumnstoreIndexPK_FactOnlineSales ondbo.FactOnlineSales;

Let’s run the following test query against our Clustered Columnstore table, it should give us in the execution plan a Sort Iterator which will function in the Batch Execution Mode:

declare @loadDateas DateTime; select @loadDate = sales.loadDate fromdbo.FactOnlineSalessales innerjoindbo.DimPromotionprom onsales.PromotionKey = prom.PromotionKey whereprom.DiscountPercent = 0 orderbysales.LoadDate;

The 3rd from the left, the Sort Iterator is there, running in the Batch Execution Mode and occupying estimated 34% of the resources. It took just 171ms on my virtual machine.

Now, let’s us enable the Trace Flag 9347 and see if it shall bring the expected impact to the Batch Sort iterator (notice that if you are running on the RTM version of SQL Server, you will face a bug that was fixed in the Cumulative Update 1, which is already available):

declare @loadDateas DateTime; select @loadDate = sales.loadDate fromdbo.FactOnlineSalessales innerjoindbo.DimPromotionprom onsales.PromotionKey = prom.PromotionKey whereprom.DiscountPercent = 0 orderbysales.LoadDate option( querytraceon 9347);

Occupying estimated 84%! of the resources, the very same query runs over 15 times slower 2731 ms , all because of the Sort Iterator being executed in the Row Execution Mode. What makes the performance suffer more is that the Sort Iterator does not get enough memory through the memory grant and that is why it is spilling on the disk.

Top N Sort

The Top N Sort iterator does sort like the above mentioned Sort iterator, with the difference that it passes only top N rows after sorting. There are different optimisations to the used algorithm that make this iterator functioning differently from the Sort iterator.

Given it is a different functionality and a different iterator, SQL Server 2016 has a separate Trace Flag that will allow you to disable the Batch Mode on it the Trace Flag 9349 . It is important to have it separate from the complete Sort Iterator, since a number of times one can catch both operators and having a possibility to shut down just a Top N Sort can be advantageous.

Let’s run a SELECT TOP X query, selecting 100.000 rows from the results of our previous query:

declare @loadDateas DateTime; selecttop 100000 @loadDate = sales.loadDate fromdbo.FactOnlineSalessales innerjoindbo.DimPromotionprom onsales.PromotionKey = prom.PromotionKey whereprom.DiscountPercent = 0 orderbysales.LoadDate;

As you can see on the image above, the execution plan presents TOP N Sort Iterator functioning in the Batch Execution Mode, taking 101ms in total execution time on my VM, while occupying estimated 53% of the execution plan resources.

Let’s execute the same query this time with the help of the Trace Flag 9349, thus preventing the TOP N Sort Iterator from running in the Batch Execution Mode:

declare @loadDateas DateTime; selecttop 100000 @loadDate = sales.loadDate fromdbo.FactOnlineSalessales innerjoindbo.DimPromotionprom onsales.PromotionKey = prom.PromotionKey whereprom.DiscountPercent = 0 orderbysales.LoadDate option(querytraceon 9349);

This time the query took good 1820ms , over 18 times slower then the query with Sort Iterator using the Bat