Cache issues from T-SQL-generated Plans and How to Manage Them


Published on

Cache issues from T-SQL-generated plans and how to manage them. Webcast by Richard Douglas. To view the recorded webcast, click here:

Looking for a foolproof way to improve SQL Server performance? You’ll find it by intelligently managing cashed plans that T-SQL code generates.

T-SQL code is different from many other languages; you tell it "what" to do and the optimisation engine interprets that command into "how" to do it, then files that information away. Join Dell SQL Server experts as they explain the concepts that support the storage of these “how-to” plans, ways to determine what has been stored, and how to create efficiency at both the database and all-important server level.
This educational session will cover:
•Concepts behind cashed plans
•How to find out what’s been stored
•How to create efficiencies at both query and server levels
•And much more

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Costs associated with query plans and execution contextsWith every query plan and execution context, a cost is stored. The cost partially controls how long the plan or context will live in the plan cache. Plans that cost more are more likely to be kept. Apart from ad-hoc queries where the cost is set as zero, the cost of a query plan is a measure of the amount of resources that were required to produce it. Specifically, the cost is calculated as a number of “ticks" with a maximum value of 31, and is composed of three parts:Cost = I/O cost + context switch cost (a measure of CPU cost) + memory costThe individual parts of the cost are calculated as follows.Two I/Os cost 1 tick, with a maximum of 19 ticks.Two context switches cost 1 tick, with a maximum of 8 ticks.Sixteen memory pages (128 KB) cost 1 tick, with a maximum of 4 ticks. As soon as the size of the Plan Cache reaches 50% of the Buffer Pool size, the next plan cache access decrements the ticks of all of the plans by 1. Notice that because this decrement is performed on a thread that accesses the Plan Cache for plan lookup purpose, the decrement can be considered to occur in a lazy fashion. If the sum of the sizes of all of the caches in SQL Server reaches or exceeds 75% of the Buffer Pool size, a dedicated resource monitor thread is activated and is used to decrement tick counts of all of the objects in all of the caches. Each time that a query plan is reused, its cost is reset to its initial value. For more detail on how the cache responds to memory pressure, review the following article: that the cost formula and pressure limits apply to most caches in the system, not specifically just to the plan cache.
  • Cache issues from T-SQL-generated Plans and How to Manage Them

    1. 1. Managing SQL Server’s Plan Cache Richard Douglas
    2. 2. Agenda • Introductions • What is the plan Cache? • Plan Cache Memory Usage • Finding problem plans in the cache • Events near you • Q&A 2 Plan Cache Global Marketing
    3. 3. Your host • Richard Douglas • Systems Consultant • SQL Server MCITPro • Maidenhead SQL User Group Leader • Blog: • Twitter: @SQLRich • Email: 3 Plan Cache Global Marketing
    4. 4. What is the plan cache? 4 Plan Cache Global Marketing
    5. 5. Query optimization explained simply 1. Query submitted 2. Magic happens 3. Shedload of data returned 5 Plan Cache Global Marketing
    6. 6. Plan cache simplified Query submitted Stored in memory Doesn’t exist Compile Check for plan in cache The more plans, the longer this takes. Be mindful of “cache Exists bloating” Run with plan CPU Intensive 6 Plan Cache Global Marketing
    7. 7. Recompilation Process From “Plan Caching in SQL Server 2008” by Greg Low 7 Plan Cache Global Marketing
    8. 8. Finding Compiles / Recompiles 8 Plan Cache Global Marketing
    9. 9. (Re)Compile Tip 9 Plan Cache Global Marketing
    10. 10. Call & Hit Rates in SoSSE 10 Plan Cache Global Marketing
    11. 11. Recompilations • If schema changes are made to any dependencies of code then a recompilation will occur. This includes: – – – – Tables Views Procedures Indices • Reaching statistics thresholds: • An explicit call to sp_recompile. • Executing a stored procedure using the WITH RECOMPILE option. 11 Plan Cache Global Marketing
    12. 12. Plan Cache Memory Usage 12 Plan Cache Global Marketing
    13. 13. Plan Cache Memory Usage SQL Server Version Cache Pressure Limit SQL Server 2012, SQL Server 2008 and SQL 75% of visible target memory from 0-4GB + Server 2005 SP2 10% of visible target memory from 4Gb64GB + 5% of visible target memory > 64GB SQL Server 2005 RTM and SQL Server 2005 75% of visible target memory from 0-8GB + SP1 50% of visible target memory from 8Gb64GB + 25% of visible target memory > 64GB SQL Server 2000 SQL Server 2000 4GB upper cap on the plan cache 32gb = 5.8gb cache 64gb = 9gb cache 128gb = 12.2gb cache 13 Plan Cache Global Marketing
    14. 14. Ageing out plans Cost = I/O cost + context switch cost (a measure of CPU cost) + memory cost The individual parts of the cost are calculated as follows. • Two I/O’s cost 1 tick, maximum of 19 ticks. • Two context switches cost 1 tick, maximum of 8 ticks. • Sixteen memory pages (128 KB) cost 1 tick, maximum of 4 ticks. 14 Plan Cache Global Marketing
    15. 15. Finding problem plans in the cache 15 Plan Cache Global Marketing
    16. 16. Finding Problem Plans in the Cache In this section: • Examples of cache bloat • Finding IO intensive queries • Finding CPU Intensive queries • Looking for certain plan operations • Looking at Individual plans 16 Plan Cache Global Marketing
    17. 17. Summary • The reason for the plan cache. • Monitoring the plan cache. • Plan cache memory utilisation. • Demonstrated how to find: – Cache bloat – Particular operators – High resource queries 17 Plan Cache Global Marketing
    18. 18. Solution Area Product Description Fast, flexible backup and recovery with industry-leading compression technology Backup and Recovery Product Offerings Discover and resolve performance issues in production before they impact end users and service levels Performance & Operations Deepest possible understanding of database performance and norms Performance Tuning Plan and develop applications that deliver both functionality and Development optimal performance Comprehensive schema, object, security and change management Administration Community, Knowledge, Training Free !!! Project Lucy © 2012 Quest Software Inc. All rights reserved. Community crowdsourcing for SQL Server tracing, health checks and performance Pg. 18 information!
    19. 19. SQLRelay Dates           @SQLRelay2013 11/11/13 – Reading 12/11/13 – Southampton 13/11/13 – Cardiff 14/11/13 – Birmingham 15/11/13 – Hemel Hempstead 25/11/13 – Newcastle 26/11/13 – Manchester 27/11/13 – Norwich 28/11/13 – Bristol 29/11/13 – London
    20. 20. SQL Rally Stockholm (Sweden): 4-6th Nov Amsterdam (Holland): 6 – 8th Nov 013/nordic/Home.aspx 013/amsterdam/Home.aspx 20 Plan Cache Global Marketing
    21. 21. What Do Developers Need to Know About SQL Server? Join Microsoft Certified Master Brent Ozar & Richard Douglas: The database comes with a manual, but let's be honest: nobody's got time for that. Database administrators - let's distill the most important concepts and rules for developers down to 140-character chunks on Twitter on Thursday, October 24th from 10AM to 11AM Eastern. Microsoft Certified Master Brent Ozar will lead the discussion at #dellsql. Register now - 21 Plan Cache Global Marketing
    22. 22. What would you like to see? • Always On Availability Groups • Backups • Clustering • Database Mirroring • Performance Monitoring • Performance Tuning • Installation & Configuration • Best Practices – DBA – Developer • Indexing • Baselining • SSAS • SSIS • SSRS Next Webcast: 19th November 2013 22 Plan Cache Global Marketing
    23. 23. Any questions? 23 Understanding Query Execution Plans Global Marketing
    24. 24. Thank you for attending Richard Douglas @SQLRich