Grant Fritchey - Query Tuning In Azure SQL Database
Download as PPTX, PDF1 like628 views
This document discusses query tuning in the Azure SQL Database environment. It explains that query performance is important because resources are out of the developer's control in the cloud. It shows that the main tools for identifying poorly performing queries are SQL Server Management Studio and the Azure SQL Database Management Portal. The portal provides additional monitoring capabilities for activities, query performance, execution plans, and wait states. Resources are provided for further learning about query tuning.
Grant Fritchey - Query Tuning In Azure SQL Database
- 1. Query Performance Tuning in the Cloud Start Grant Fritchey
- 2. Goals Explain the importance of query tuning within the Azure SQL Database environment. Show how the hybrid tool set can be used to identify poor performance. Demonstrate the additional functionality available within the Database Management Portal interface.
- 3. Get in touch Grant Fritchey scarydba.com grant@scarydba.com @gfritchey
- 4. Why Tune Queries? You have no control over: » Where your queries run » How many resources your query uses » How many CPUs/Disks are dedicated to you » When the server is just going to go away Most performance problems are code or structure related One query runs many places
- 5. Then Why Use SQL Database? Speed of delivery Extremely low management cost Cheap prices Expandable capacity
- 6. What’s Old is New Transactions as short as possible Only move the data you need to move Only move the data when you need to move it Tune the queries
- 7. Checking on Throttling Throttling Master Database » Sys.event_log » Sys.database_connection_stats
- 8. Tools for Query Tuning Query Tuning Tools SQL Server Management Studio SQL Database Management Portal Dynamic Management Objects
- 9. Connectivity required SQL Server Management Studio Object Explorer Query window » And not much else Statistics Time Execution Plans Statistics IO
- 10. Monitor Query window Execution Plan Statistics Time SQL Database Management Portal Statistics IO
- 11. Portal: Monitor Connection Activity » Including throttled connections Cache dependent Query Performance » Aggregation » Details
- 12. Execution plans » Actual » Estimated Roughly same as SSMS query window » No drag & drop for object names » No code completion Portal: Query Window No properties » SET STATISTICS IO/TIME ON/OFF
- 13. Graphical Can be saved Highlighting Properties Portal: Execution Plans
- 14. Reset on database move » Not reboot, restart, attach, detach, etc. Operating system information is gone DMO Differences No clickable execution plans
- 15. Expected wait types » RESOURCE_SEMAPHORE » *IO_LATCH » SOS_SCHEDULER_YIELD Special wait types » SE_REPL_SLOW_SECONDARY_THROTTLE » SE_REPL_COMMIT_ACK sys.dm_exec_requests does show waits sys.dm_db_wait_stats Wait State Monitoring
- 18. Goals Explain the importance of query tuning within the Azure SQL Database environment. Show how the hybrid tool set can be used to identify poor performance. Demonstrate the additional functionality available within the Database Management Portal interface.
- 19. Scarydba.com/resources Resources SQL Server 2012 Query Performance Tuning by Grant Fritchey Performance Tuning with SQL Server Dynamic Management Views by Louis Davidson and Tim Ford Windows Azure SQL Database and SQL Server – Performance and Scalability Compared and Contrasted
- 20. Get in touch Grant Fritchey scarydba.com grant@scarydba.com @gfritchey
Editor's Notes
- #8: Sys.event_log: Event_type = throttling, throttling_long_transaction, deadlockEvent_subtype = actual reasonDescription Sys.database_connection_stats, aggregated connection info on 5 minute intervalsTwo levels of throttling, soft throttle on resources, killed connection both are in the details of sub-type40549 Session blocking system task for long period of time (20 seconds)40550 Session is consuming too many locks (1 million)40551 Session is consuming too much tempdb space (5gb)40552 Transaction consuming too much log space or active transaction preventing log truncation40553 Sessoin consuming memory (16mb) and there are memory waits (20 seconds)
- #12: Just note objects available. Design and viewing & drag & drop from the Object Explorer to the query window
- #13: Nothing magic, normal query window behavior including formatting & code coloring
- #14: Again, normal stuff, note, execution times are for the server, not including latency
- #15: Actual execution plan generated against SQL Database from SSMS
- #16: SELECT operator from SQL Database. Point out information about memory & parallelism. Only real difference is NonParallelPlanReason. But that’s a difference that is reflected in SSMS.
- #17: This is the property sheet from a SQL Server database SELECT operator.Note that for identical queries and identical data sets the operator cost estimates are different.
- #19: Remember that the query performance is based on what’s in cache.
- #20: Nothing exciting, but useful information. Note ability to modify time frame & layout
- #21: Some customizable metrics. Most noteworthy for our purposes is the Throttled Connections
- #22: Main management page. Queries are clickable. Columns are sortable.
- #26: Note Save As, Open, etc. Syntax highlighting (of a sort).
- #27: Works like tabs. You can look at more than one object or query and switch between them
- #28: Query & results. No shocks
- #29: In order to see the stats, must be run from the query. NOTE: You can include GO statements.
- #35: Note that clicking on Actual Plan runs the query, not a toggle in this case.
- #36: Mention that clicking on the icons in the lower left will hide the tool bar.
- #39: Also sort by Merge, Hash, Sort, Scan, Seek, Warnings
- #42: Se_repl_slow_secondary_throttle is due to secondary machines causing waits while information is transferred to them.Mention that when dealing with how to fix one of the three, cpu, io, memory; the solution is scale out with more hardware, but you have to deal with necessary changes to coding mechanisms.REPL is either a “Noisy neighbor” or you’re moving too much data. You’ll know you’re a noisy neighbor because you’ll be getting throttling alerts
- #44: Just remember that there is ALWAYS memory pressure affecting the cache
- #45: Be sure to mention that fragmented indexes leads to additional storage overhead and with limited options here, you pay for more, so defragmented indexes save the company money. Also more fragmentation can lead to longer running queries, so you may experience throttling.Operational stats is current activity