Top 5 T-SQL Improvements in SQL Server 2014

Editor's Notes

• #8: Standard Edition too Change tracking and change data captureAll transactions with change tracking are fully durable. A transaction has the change tracking property if it does any write operations to tables that are enabled for either change tracking or change data capture (CDC). Crash recovery Consistency is guaranteed, but some changes from delayed durable transactions that have committed may be lost. Cross-database and DTC If a transaction is cross-database or distributed, if is fully durable, regardless of any database or transaction commit setting. Always On Availability Groups and MirroringDelayed durable transactions do not guarantee any durability on either the primary or any of the secondaries. In addition, they do not guarantee any knowledge about the transaction at the secondary. After commit, control is returned to the client before any acknowledgement is received from any synchronous secondary. Failover clusteringSome delayed durable transaction writes might be lost. Transaction ReplicationDelayed durable transactions do not guarantee their replication. Transactions are only replicated after they have been made durable. Log shippingOnly transactions that have been made durable are included in the log that is shipped. Log BackupOnly transactions that have been made durable are included in the backup.
• #11: When you say to the DBAs it’s slow here is what they see.
• #12: Wouldn’t it be interesting if… 60 KB buffer -> flush Sp_flush_log Durable transaction – MSDTC or Cross database
• #19: How many of you have heard about this improvement? What is – QE assignes costs to each plan and the one with lowest cost is choosen. Those costs are actually how many rows are we going to be proceeded for each operator and that’s the work of the cardinality estimator Talk about the problem – slow queries in general
• #20: Under estimation – disk spills, serial plans, bad indexes chosen or join orders Over estimation – more memory assigned, parallel plan and not serial So, what is a cardinality estimator? A cardinality estimator is the component of the query processor whose job is to estimate the number of rows returned by relational operations in a query. This information, along with some other data, is used by the query optimizer to select an efficient execution plan. Cardinality estimation is inherently inexact, as it is a mathematical model which relies on statistical information. It is also based on several assumptions which, although not documented, have been known over the years – some of them include the uniformity, independence, containment and inclusion assumptions. A brief description of these assumptions follows. Uniformity. Used when the distribution for an attribute is unknown, for example, inside of range rows in a histogram step or when a histogram is not available. Independence. – сямтаме, че данните в колоните са независими освен ако изрично не е казано, че те са. Containment. Смятаме че ако нещо се търси значи съществува. Inclusion. Когато имаме where x = нещо – нещото винаги съществува и стойността му е точно такава, каквато я имаме в хистограмата на статистиките. Stats: Density – the uniqnes of a column Histogram – data distribution
• #22: Statistics on ascending or descending key columns, such as IDENTITY or real-time timestamp columns, might require more frequent statistics updates than the query optimizer performs. Insert operations append new values to ascending or descending columns. The number of rows added might be too small to trigger a statistics update. If statistics are not up-to-date and queries select from the most recently added rows, the current statistics will not have cardinality estimates for these new values. This can result in inaccurate cardinality estimates and slow query performance. For example, a query that selects from the most recent sales order dates will have inaccurate cardinality estimates if the statistics are not updated to include cardinality estimates for the most recent sales order dates. Trace flags 2389 + 2390 With one predicate – no difference except if there are no outdated statistics. If they are the new will consider the total number of rows and the old will consider the statistics With more than one – it considers that they are correlated and calculates it in a different way In Joins – quite better (with column joining). With more than one column – new CE underestimates a lot! With joins with multiple tables and multiple columns there could be even changes in the execution plans! For modulo % - very good! X
• #23: Sys.dm_exec_query_profiles_dynamic + query_optimizer_estimate_cardinality
• #30: http://www.sqlpassion.at/archive/2013/06/27/improved-temp-table-caching-in-sql-server-2014/