Downloaded 10 times
Uploaded byBoris Hristov
Top 5 T-SQL Improvements in SQL Server 2014
The document discusses five significant T-SQL improvements introduced in SQL Server 2014, including delayed durability, parallel execution plans, an updated cardinality estimator, inline index definitions, and enhanced partitioning features. It emphasizes the importance of proper database design for performance and encourages thorough testing of queries due to changes in estimations. Additional resources for further learning are also provided.
More Related Content
Similar to Top 5 T-SQL Improvements in SQL Server 2014
![[JSS2015] In memory and operational analytics](https://cdn.slidesharecdn.com/ss_thumbnails/jss2015-inmemoryandoperationalanalytics-151211084342-thumbnail.jpg?width=640&height=640&fit=bounds)
Top 5 T-SQL Improvements in SQL Server 2014
- 1. Top 5 T-SQLImprovements in SQL Server 2014
- 2. That’s not aHekaton Talk!
- 3.
- 4. So who amI? @BorisHristov So who am I?
- 5. things that canmake your life better
- 6. Here’s how thiswill go… time
- 7.
- 8.
- 9. Data pages arelocated in, or read into, the buffer cache and then modified 2 Modification is recorded in transaction log on disk3 Later, checkpoint writes dirty pages to database 4 Buffer Cache Transaction’s lifecycle
- 10. Here’s the reasonwhy it’s slow
- 11. Data pages arelocated in, or read into, the buffer cache and then modified 2 Modification is recorded in transaction log on disk3 Later, checkpoint writes dirty pages to database 4 Buffer Cache Transaction’s lifecycle
- 12. Yes, you can losedata!
- 13.
- 14.
- 15. Prior SQL Server2014: Serial Execution Plans SQL Server 2014: Parallel Execution Plans Why don’t we speed up a bit?
- 16. Talk with theDBAs to design a proper disk and data layout! You want that speed, right?
- 17.
- 18.
- 19. Why is theCE so important? Why is the CE so important?
- 20. The CE has notbeen changed since SQL Server 7.0 …and at the same time
- 21. Queries with Multiple Predicates QueriesJoining Multiple Tables New Data Not Presented in the Stats Almost everywhere… (this, oh btw, means you have to test a lot!) Where to expect changes?
- 22.
- 23. Inline Index Definitions (rememberthis one for later)
- 24. SQL Server 2012 SQLServer 2014 Remember this improvement
- 25.
- 26.
- 27. Numbers 0 … 8000 Partition 2 2501 … 4000 Partition 3 4001 … 8000 Whyis partitioning both cool and not? Partition 1 0 … 2500
- 28.
- 29.
- 30. In summary Delayed Durability ParallelSELECT INTO Cardinality Estimator Inline Index Creation Partitioning Improvements Testing is important!
- 31. Resources you canuse Just a click away!
- 32.
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/