Now what should be our choice - a Temporary Table or a Table Variable?

Let us walk through this with an example. Take a scenario where we want to fetch the count of transactions  in a current year for different products on AdventureWorks2012 Database. In addition, we would also like to show the no of transactions for last couple of years.

Query1#Start#:

;With BASE AS
 (
 SELECT ProductID, YEAR(TransactionDate) AS TransCurrYear, COUNT(1) AS NoTrans
 FROM Production.TransactionHistory
 GROUP BY ProductID, YEAR(TransactionDate)
 )
 SELECT CurrYear.ProductID, CurrYear.NoTrans AS CurrTransCnt, PrevYear.NoTrans AS PrevTransCnt, Prev2Year.NoTrans AS Prev2YearCnt
 FROM BASE AS CurrYear
 CROSS APPLY (SELECT *
 FROM BASE PrevYear
 WHERE CurrYear.ProductID = PrevYear.ProductID
 AND CurrYear.TransCurrYear = PrevYear.TransCurrYear - 1 ) AS PrevYear
 OUTER APPLY (SELECT *
 FROM BASE Prev2Year
 WHERE CurrYear.ProductID = Prev2Year.ProductID
 AND CurrYear.TransCurrYear = Prev2Year.TransCurrYear - 2 ) AS Prev2Year

Query1#End#:

Observations from Query 1:

1. There were over 27 scans with logical reads of 1998
2. Although we used a CTE Operation, we could see that similar aggregations are being repeated in the plan.

Let's now use a Temporary Table.

Query2#Start#:

CREATE TABLE #T1
 (ProductID int
 ,TransCurrYear int
 ,NoTrans int
 );
 
 CREATE CLUSTERED INDEX CI_#T1 ON #T1 (TransCurrYear)
 
 INSERT INTO #T1
 SELECT ProductID, YEAR(TransactionDate) AS TransCurrYear, COUNT(1) AS NoTrans
 FROM Production.TransactionHistory
 GROUP BY ProductID, YEAR(TransactionDate)
 ORDER BY YEAR(TransactionDate)
 
 ;With BASE AS
 (
 SELECT * FROM #T1
 )
 SELECT CurrYear.ProductID, CurrYear.NoTrans AS CurrTransCnt, PrevYear.NoTrans AS PrevTransCnt, Prev2Year.NoTrans AS Prev2YearCnt
 FROM BASE AS CurrYear
 CROSS APPLY (SELECT *
 FROM BASE PrevYear
 WHERE CurrYear.ProductID = PrevYear.ProductID
 AND CurrYear.TransCurrYear = PrevYear.TransCurrYear - 1 ) AS PrevYear
 OUTER APPLY (SELECT *
 FROM BASE Prev2Year
 WHERE CurrYear.ProductID = Prev2Year.ProductID
 AND CurrYear.TransCurrYear = Prev2Year.TransCurrYear - 2 ) AS Prev2Year

Query2#End#:

Observations from Query 2:

1. Logical Reads are down when compared to Query1.
2. No Repetition of computation of Aggregated Values.
3. SQL Server uses statistics as can be seen from the properties above which is good when data is more.

Great. Let's now do it with a table variable

Query3#Start#:

DECLARE @T1 AS TABLE
 (ProductID int
 ,TransCurrYear int
 ,NoTrans int
 , INDEX [IX_TransactionYear] CLUSTERED (ProductID,TransCurrYear)
 );
 
 
 INSERT INTO @T1
 SELECT ProductID, YEAR(TransactionDate) AS TransCurrYear, COUNT(1) AS NoTrans
 FROM Production.TransactionHistory
 GROUP BY ProductID, YEAR(TransactionDate)
 ORDER BY YEAR(TransactionDate)
 
 ;With BASE AS
 (
 SELECT * FROM @T1
 )
 SELECT CurrYear.ProductID, CurrYear.NoTrans AS CurrTransCnt, PrevYear.NoTrans AS PrevTransCnt, Prev2Year.NoTrans AS Prev2YearCnt
 FROM BASE AS CurrYear
 CROSS APPLY (SELECT *
 FROM BASE PrevYear
 WHERE CurrYear.ProductID = PrevYear.ProductID
 AND CurrYear.TransCurrYear = PrevYear.TransCurrYear - 1 ) AS PrevYear
 OUTER APPLY (SELECT *
 FROM BASE Prev2Year
 WHERE CurrYear.ProductID = Prev2Year.ProductID
 AND CurrYear.TransCurrYear = Prev2Year.TransCurrYear - 2 ) AS Prev2Year

Query3#End#: 

Observations from Query3:

1. Scan Count and Logical Reads are slightly up.
2. There is no statistics associated with Clustered Key Creation in Table Variable which can be seen from the Estimated Number of Rows Value. This could be bad when data is more.

One reason why the Optimizer could not sniff the "Estimated Number of Rows" is because the entire batch query populates the variable table followed by querying on it. And hence, it is not able to figure out the cardinality. If we add the RECOMPILE Option to the query, SQL Server is able to detect the cardinality like so,

Query4#Start#:

;With BASE AS
 (
 SELECT * FROM @T1
 )
 SELECT CurrYear.ProductID, CurrYear.NoTrans AS CurrTransCnt, PrevYear.NoTrans AS PrevTransCnt, Prev2Year.NoTrans AS Prev2YearCnt
 FROM BASE AS CurrYear
 CROSS APPLY (SELECT *
 FROM BASE PrevYear
 WHERE CurrYear.ProductID = PrevYear.ProductID
 AND CurrYear.TransCurrYear = PrevYear.TransCurrYear - 1 ) AS PrevYear
 OUTER APPLY (SELECT *
 FROM BASE Prev2Year
 WHERE CurrYear.ProductID = Prev2Year.ProductID
 AND CurrYear.TransCurrYear = Prev2Year.TransCurrYear - 2 ) AS Prev2Year
 OPTION (RECOMPILE)

Query4#End#:

One misconception we often hear is that Table Variables are always in memory and it does not incur any disk activity. That was never the case. With larger set of data, there can always be spill over to TempDB.

However, with SQL Server 2014, Table Variables can be defined as a Memory Optimized one by using the option of (MEMORY_OPTIMIZED = TRUE) .

Query5#Start#:

CREATE TYPE [ProductYearlyFigureType] AS TABLE(
 ProductID int NOT NULL
 ,TransCurrYear int NOT NULL
 ,NoTrans int
 , INDEX [IX_TransactionYear] NONCLUSTERED (ProductID,TransCurrYear) 
 )
 WITH ( MEMORY_OPTIMIZED = ON ); 
 
 
 DECLARE @T1 AS [ProductYearlyFigureType];
 
 
 INSERT INTO @T1
 SELECT ProductID, YEAR(TransactionDate) AS TransCurrYear, COUNT(1) AS NoTrans
 FROM Production.TransactionHistory
 GROUP BY ProductID, YEAR(TransactionDate)
 ORDER BY YEAR(TransactionDate)
 
 ;With BASE AS
 (
 SELECT * FROM @T1
 )
 SELECT CurrYear.ProductID, CurrYear.NoTrans AS CurrTransCnt, PrevYear.NoTrans AS PrevTransCnt, Prev2Year.NoTrans AS Prev2YearCnt
 FROM BASE AS CurrYear
 CROSS APPLY (SELECT *
 FROM BASE PrevYear
 WHERE CurrYear.ProductID = PrevYear.ProductID
 AND CurrYear.TransCurrYear = PrevYear.TransCurrYear - 1 ) AS PrevYear
 OUTER APPLY (SELECT *
 FROM BASE Prev2Year
 WHERE CurrYear.ProductID = Prev2Year.ProductID
 AND CurrYear.TransCurrYear = Prev2Year.TransCurrYear - 2 ) AS Prev2Year

Query5#End#:

Observations from Query5:

1. Scan Count and Logical Reads are only to read from base table.
2. There is no Physical IO involved when reading from memory optimized tables.   

Apart from this, there are few other differences between a Table Variable and a Temporary Table

1. Scope of a Table Variable is only within the batch that declared it whereas Temporary Tables are visible within a session.
2. Creation of too many Temporary Tables may result in contention of the SGAM Pages.
3. In events of rollback, data  processing in table variables (within the transaction) are not rolled back or destroyed unlike the temporary tables.

Hope this helps to de-mystify the difference between the two. Thanks

The query optimizer is likely to choose a per-row plan when no of records to be deleted are low in number. If you closely look in a per-row plan, SQL Server uses the Clustered Index Key to fetch the keys to be updated on the non-clustered indexes.

During operations involving large deletes, we would usually see SQL Optimizer choosing a per-Index Plan. For non-clustered indexes, Table Spools are created including attributes which are part of the key and sorted based on the respective index.

For the purpose of this demonstration, I shall create a table and populate it like so,

I create few non-clustered indexes on the above table

Now, lets go execute the delete statements. In our scenario, Query1 shall delete a single row whereas Query2 will delete large number of rows.

If we have the execution plan turned on, we shall observe similar to below. For Query1, we shall see that the same operator performs the updation operation on all indexes.

For Query2, we can observe that SQL Server created separate spools for all non-clustered indexes which were again sorted based on how the index keys are arranged.

There is an undocumented trace flag 8790 which may be invoked to force a per-index plan.You can validate that when no of records to be deleted are low, using this trace flag in fact deteriorates the performance. It is important to note that both maintenance plans may be used in the same query.

1. Request for a Read Access with permissions to access the DMVs on Production.
2. Request for a Production Backup and restore it on a different environment to analyze.
3. Run Extended Events / SQL Profiler on the Production Databases.

These methods work and are quite fruitful too. But they can sometimes be time consuming (specially if we end up asking for a backup of the database) or could be less flexible to test out new things (if we want to create a new index) . Are there any quick ways? Sure is.

One of the very interesting yet a less known feature SQL Server offers is that you can script out all the necessary metadata, statistics that a SQL Optimizer uses (to optimize a query) , and load it in another server to do the analysis. Some benefits are :

1. The DBA is happy that you will not run excess load on production servers to tune the queries
2. There is no need to copy backup of huge databases across networks from production to test environments, thereby saving valuable time.
3. There is no need to figure out as big a disk space on your local environment as it is in Production.
4. In event of databases having sensitive information, there is no compromise as there is no movement or copying of data to another environment.
5. New indexes created on the shell database also have their statistics updated as per the stats available on other indexes in the table.

Just to note that this is absolutely not a panacea for creating an environment for doing all forms of performance tuning. It serves a purpose where we want to tune queries based on the statistics currently available on Production. 

Let's see how this can be done.

Step - 1 : Right Click on the Database , go to Tasks -> Generate Scripts

Step - 2 : On the Generate and Publish Script Window, select the objects you want to script out.

Step - 3 : On the Set Scripting Options Tab of the Window, provide a location to where the file can be generated and then  click on the Advanced Button 

Step - 4 : On the Advanced Scripting Objects, change the default values of the given properties to values mentioned below

Once Done, click on Finish to generate the script. This script may now be used to re-create the objects on a different environment.

Since I am performing the activities on the same machine, I have edited the script to change the database name from AdventureWorks2012 to AdventureWorks2012Shell.

Now, assuming a query (like the one below) is causing some performance challenge on production.  This can now be run on this newly created database for analysis. One can observe that although there are no records returned, it uses the statistics from our source Database (Look at the Estimated Number of Rows Property), like so.

Now as part of the analysis, we would like to validate if creating a new index will help remove the clustered index scan. Let's go create one on column ModifiedDate.

Running the same query again, shows that the SQL Optimizer chose to use the newly created index. This way, we can validate usage of new indexes based on the statistics on our Production Server.

Thanks 

We shall use the AdventureWorks2012 Database for demonstrating this. I will create a new table TransactionHistory2 for this.

Query1:

I will now add more rows to the table and follow it up by creating a Clustered and a non-Clustered Index on it

Query2:

Query3:

As part of the demonstration, I will  query for TransactionID,TransactionDate,TransactionType from  table TransactionHistory2 by filtering on the attribute TransactionID.

The machine I am using for the demonstration is a 64 bit OS with an Windows 8.1 Enterprise with 16 GB RAM. Also find below the CPU Configuration.

My first goal is to ensure that the queries that I picked up for my demonstration run with parallelism. The property Cost threshold for Parallelism on my SQL Instance is set to 5. I executed the below code changing the value of the predicate TransactionID such that the Estimated Subtree Cost for the query goes over 5. Note that the mentioned properties are of the SELECT operator.

Query4:

Now, with a value greater than 166000 (I have selected  a much higher number) , I go fetch the data ordering first by the TransactionDate in Ascending Order followed by Descending Order. 

Query5: 

And as expected, SQL Server scans the data in parallel. Lets do the same again but changing the direction of the ordering.

Query6:

SQL Server now choses a Clustered Scan but does not process the descending order clause with a parallel scan even while the Estimated Subtree Cost is over 17%. That’s because, currently a BACKWARD scan is not possible with parallelism. It is good to be aware of such implications while designing indexes. If the requirement is to fetch data from tables in a descending order, it may be more performant to create an index in descending order. Similarly, if the data needed is ordered by multiple attributes, both in opposite direction of ordering , it will be prudent to store the data within the index in that fashion (column1, column2 desc ) else there will be an explicit sorting of data, which is quite avoidable in such cases.

Thanks for reading!!

There are multiple ways how SQL Server accesses data from the tables. To illustrate the point I make, I shall query a heap and a clustered tables in AdventureWorksDW2012 in a few different ways

The clustered table taken for the example is FactInternetSales which has a Clustered Index on attributes SalesOrderNumber and SalesOrderLineNumber. 

I shall create a heap table , like so

To draw a comparative analysis between the two tables, I have dropped all non-clustered indexes from table FactInternetSales. In addition, I have turned on the Actual Execution Plan and STATISTICS IO , TIME to understand the execution pattern for the below queries.

Query 1 : Execute the Query on the Heap Table

Query 2: Execute the below query on the clustered Table without an Order By Clause

Query 3: Execute the below query on the clustered Table with an Order By Clause

Let's us list the differences between the above 3 queries -

1. Query1 as expected was a Table Scan with Ordered Property Value as "False". Logical Reads measure 1313. CPU Time = 350 ms
2. Query2 was a Clustered Index Scan with Ordered Property Value as "False". Logical Reads measure 2062. CPU Time = 364 ms
3. Query3 was a Clustered Index Scan with Ordered Property Value as "True" and a new Property Scan Direction as "FORWARD". Logical Reads measure 2061. CPU Time = 393 ms

These above differences may be summarized into the following buckets,  like so

1. Logical Reads Measure
2. CPU Time
3. Ordered Property

Logical Reads Measure

If we can use the DBCC IND command to get the number of data pages for both the tables , it will explain the difference in Logical measure between the Clustered Table and the Heap table. In this case, the clustered index is fragmented which means more IO as compared to that of the Heap Table. To understand more around the DBCC IND command, there is an excellent post by Paul Randal which can be referred from here.

 CPU Time

In the event of a fragmented index (FactInternetSales Clustered Index is fragmented) , An Unordered Scan (Query2) may consume (not necessarily though!!) lesser resource (IO or/and CPU time) than an Ordered Scan (Query3).

Ordered Property

In Query2, SQL Server did an Unordered Clustered Scan while Query3 was an Ordered Scan. Both were full scans as expected. The first query however, had no requirement for an ordered set.  SQL Server uses different algorithms to fetch the data - 

1. For Query2, SQL Server reads the IAM Pages to fetch the list of pages which holds the data. Refer the sys.system_internal_allocation_units table to know more. This type of scan is called the allocation order scan (or a Unordered Clustered Scan) and it will not ensure the order of the dataset as per the clustered key.
2. Where as in Query3, when we exclusively asked SQL Server to fetch the data in an ordered fashion, it scans through the binary tree of the Clustered Index. 

 I do hope you find this useful. Thanks for reading. Do share your views/learnings on this.