Download to read offline
Uploaded byBoris Hristov
Top 5 T-SQL Improvements in SQL Server 2014
The document discusses key T-SQL improvements in SQL Server 2014 as presented by Boris Hristov, highlighting features such as delayed durability, new execution plans, cardinality estimator enhancements, inline index definitions, and improvements in partitioning. Hristov emphasizes the importance of proper database design and testing for optimal performance. Resources for further information and feedback are also provided.
More Related Content
Similar to Top 5 T-SQL Improvements in SQL Server 2014
Top 5 T-SQL Improvements in SQL Server 2014
- 1. Boris Hristov SQL ServerMVP, Speaker, Trainer, Blogger and DBA Top 5 T-SQL Improvements in SQL Server 2014
- 2.
- 3. That’s not aHekaton Talk!
- 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 Click me!
- 32. Please give feedbackto us http://speakerscore.com/sqlsaturday376 Thank you!
- 33.
Editor's Notes
- #2 Поздрав и благодарности, че все още сте тук за последната сесия? Уморени ли сте вече много? Нали знаете как се говори само за 1 – 2 неща, които са ключови. Иска ми се да ви разкажа и определено да ви покажа 5 други, които определено могат да ви помогнат в ежедневието ви за това да направите приложенията ви по – добри. Така казано...
- #4 Ценя времето ви и искам да ви кажа, че ако сте дошли за това или Clustered Columnstore индекси – няма да чуете нищо. Както и няма да е вери дийп сесия, защото за всяко от нещата, които ще видите може да се изнесе отделна такава (а и все пак е последна сесия, предпочитам да енджойнете) Прекалено нови неща, за които още няма почти никаква информация в интернет или поне толкова колкото би ни се искало.
- #5 Казвам се Борис Христов и работя като Senior SQL Server DBA за HP В същото време съм Автор за Pluralsight SQL Server MVP съм, което означава, че може да ме видите или чуете да говоря доста често както тук, така и на доста събития в цяла европа Не на последноя място се занимавам и с обчения и със SQL Hangouts
- #6 Да се захващаме
- #7 Така ще протече като последното е интересно и ще е нестандартно. + НАГРАДИТЕ!
- #8 Колко от вас са чували това? Standard Edition на продукта... Change tracking and change data capture All 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 clustering Some delayed durable transaction writes might be lost. Transaction Replication Delayed durable transactions do not guarantee their replication. Transactions are only replicated after they have been made durable. Log shipping Only transactions that have been made durable are included in the log that is shipped. Log Backup Only transactions that have been made durable are included in the backup.
- #9 Всяка една система като SQL Server ни дава възможност да контролираме тези 4. Atomic – Error handling and how we use it Consistent – Foreign keys, check constraints, triggers, validation rules. Isolated – locking, isolation levels Durable – Кой се грижи за това? transaction log – rolling back and forward Нека се фокусираме върху последното. Как „преминава“ една транзакция?
- #10 Transaction starts -> data is modified in the memory and changes are constantly (sync) send to the log. Once we commit the change and we have all the log records on the log we return the control. W-A-L – Write ahead logging механизъм ЧУДЕСНО! Какво става ако вие сте написали невероятно приложение, но дисковете ви са бавни (за тлога)? Ами ... Започвате да виждате, че нещо тези инсърти / ъпдейти и т.н не минават така бързо както ви се иска
- #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
- #13 THERE IS NO ACID ANYMORE!
- #14 Locks are same, just released faster Ways to flush – sp_flushes, durable transaction or 60KB log buffer full
- #15 Колко отвас използват SELECT INTO? Колко от вас са чували, че има подобрения за него в 2014?
- #16 Подобрението е доста, доста простичко...
- #17 За да можете да извлечете максимума от паралелизма. Пример със ССД-то 7 секунди вместо 18.
- #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
- #21 А също така е и доста комплексна задача. Изчисленията, които трябва да прави CE трябва да „правилни“ за почти всички клиенти на Майкрософт...
- #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
- #29 Stats are per partition. Can be updated per partition. 20% rule applies on partition level now!
- #30 http://www.sqlpassion.at/archive/2013/06/27/improved-temp-table-caching-in-sql-server-2014/
- #31 SQL Server 2014 има достатъчн оподобрения, които