SQL Server Tuning to Improve Database Performance
9 likes7,450 views
The document outlines a presentation by Dean Richards on the proven process for SQL tuning, emphasizing the challenges of tuning and the importance of a comprehensive understanding of both technical and business aspects. It details the steps involved in tuning SQL queries, including identifying bottlenecks, gathering metrics, simplifying queries, and monitoring improvements. The presentation also highlights the iterative nature of SQL tuning and the role of tools like Confio's Ignite suite in aiding the tuning process.
SQL Server Tuning to Improve Database Performance
- 1. Tuna Helper For SQL Server DBAs Speaker: Dean Richards Senior DBA, Confio Software San Francisco SQL Server User Group April 2010 Mark Ginnebaugh, User Group Leader, [email protected]
- 2. Tuna Helper Proven Process for SQL Tuning Dean Richards Senior DBA, Confio Software 2
- 3. Tuna Helper – Proven Process for SQL Tuning Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime. Chinese Proverb 3
- 4. Who Am I? Senior DBA for Confio Software • [email protected] Current – 20+ Years in SQL Server & Oracle • DBA and Developer Specialize in Performance Tuning Review Performance of 100’s of Databases for Customers and Prospects Common Thread – Paralyzed by Tuning 4
- 5. Agenda Introduction Challenges Identify - Which SQL and Why Gather – Details about SQL Tune – Case Study Monitor – Make sure it stays tuned 5
- 6. Introduction Tuning is Hard This Presentation is an Introduction • 3-5 day detailed classes are typical Providing a Framework • Helps develop your own processes • There is no magic tool • Tools cannot reliably tune SQL statements • Tuning requires the involvement of you and other technical and functional members of team 6
- 7. Challenges Requires Expertise in Many Areas • Technical – Plan, Data Access, SQL Design • Business – What is the Purpose of SQL? Tuning Takes Time • Large Number of SQL Statements • Each Statement is Different Low Priority in Some Companies • Vendor Applications • Focus on Hardware or System Issues 7
- 8. Identify – End-to-End Business Aspects • Who registered yesterday for SQL Tuning • Why does the business need to know this • How often is the information needed • Who uses this information Technical Information • Review ERD • Understand tables and the data (at a high level) End-to-End Process • Understand application architecture • What portion of the total time is database • Where is it called from in the application 8
- 9. Identify – End-to-End Time 9
- 10. Identify – Which SQL User / Batch Job Complaints Tracing a Session / Process Queries Performing Most I/O (LIO, PIO) Queries Consuming CPU Queries Doing Table or Index Scans Known Poorly Performing SQL Highest Response Times (Wait Types) SELECT sql_handle, statement_start_offset, statement_end_offset, plan_handle, execution_count, total_logical_reads, total_physical_reads, total_elapsed_time, st.text FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st ORDER BY total_elapsed_time DESC 10
- 11. Measure Response/Wait Time Focus on End User Response Time Understand the total time a Query spends in Database Measure time while Query executes SQL Server helps by providing Wait Types 11
- 12. Banking Analogy Tellers are the CPUs Customers being helped are “running” Customers waiting in line are “runnable” Customer 1 Requires Higher Level Signature • Customer 1 “waits” on “Signature” • Customer 2 is checked out, i.e. “running” • Customer 3 is “runnable” Signature is Completed • Customer 1 goes to “runnable” 12
- 13. Wait Time Tables (SQL 2000) http://support.microsoft.com/kb/822101 WaitType – internal binary, 0 sysprocesses loginame means SPID is on CPU and not hostname programname spid waiting dbid waittype waittime LastWaitType – string value lastwaittype waitresource WaitTime – ms of wait for sql_handle stmt_start stmt_end current waittype cmd WaitResource – more details about what is being waited on 13
- 14. Wait Time Tables (SQL 2005/8) http://msdn.microsoft.com/en-us/library/ms188754.aspx dm_exec_requests dm_exec_query_stats start_time execution_count status total_logical_writes sql_handle total_physical_reads plan_handle total_logical_reads start/stop offset database_id user_id blocking_session wait_type dm_exec_query_plan wait_time query_plan dm_exec_sessions login_time dm_exec_sql_text login_name text host_name program_name session_id 14
- 16. Wait Time Scenario Which scenario is worse? SQL Statement 1 • Executed 100 times • Caused 10 minutes of wait time for end user • Waited 90% of time on “PAGEIOLATCH_SH” SQL Statement 2 • Executed 1 time • Caused 10 minutes of wait time for end user • Waited 90% on “LCK_M_X” 16
- 17. Identify – Simplification Break Down SQL Into Simplest Forms • Complex SQL becomes multiple SQL • Sub-Queries Should be Tuned Separately • Tuned SQL in Stored Procedures Separately • Get the definition of views • Understand Distributed Queries 17
- 18. Identify – Summary Determine the SQL Understand End-to-End Measure Wait Time Simplify Statement 18
- 19. Gather - Metrics Get baseline metrics • How long does it take now • What is acceptable (10 sec, 2 min, 1 hour) Collect Wait Type Information • Locking / Blocking (LCK) • I/O problem (PAGEIOLATCH) • Latch contention (LATCH) • Network slowdown (NETWORK) • May be multiple issues • All have different resolutions Document everything in simple language 19
- 20. Gather – Execution Plan SQL Server Management Studio • Estimated Execution Plan - can be wrong • Actual Execution Plan – must execute query, can be dangerous in production and also wrong in test SQL Server Profiler Tracing • Event to collect: MISC: Execution Plan • Works when you know a problem will occur DM_EXEC_QUERY_PLAN • Real execution plan of executed query 20
- 22. Gather – Bind Values <is there something like V$SQL_BIND_CAPTURE> SELECT name, position, datatype_string, value_string FROM v$sql_bind_capture WHERE sql_id = '15uughacxfh13'; NAME POSITION DATATYPE_STRING VALUE_STRING ----- ---------- --------------- ------------ :B1 1 BINARY_DOUBLE Bind Values also provided by tracing • Level 4 – bind values • Level 8 – wait information • Level 12 – bind values and wait information 22
- 23. Example SQL Statement Who registered yesterday for SQL Tuning SELECT s.fname, s.lname, r.signup_date FROM student s INNER JOIN registration r ON s.student_id = r.student_id INNER JOIN class c ON r.class_id = c.class_id WHERE c.name = 'SQL TUNING' AND r.signup_date BETWEEN @BeginDate AND @EndDate AND r.cancelled = 'N' Execution Time – 1:30 to execute Wait Types – Waits 90% on PAGEIOLATCH_SH 23
- 25. Gather - Relationships CLASS REGISTRATION STUDENT class_id class_id student_id name student_id fname class_level signup_date lname cancelled 25
- 26. Gather – Table Information Table Definition • Where does it physically reside • Large columns? • Data Profile Viewer – Integration Services Existing Indexes • Names of all existing indexes • Columns those indexes contain 26
- 27. Gather – Summary Metrics • How long does it take currently • What does the query wait for (wait types) Plan • DM_EXEC_QUERY_PLAN • Actual Execution Plan • Do not use Estimated Plans unless necessary Table Relationships Table Information • Columns and Existing Indexes 27
- 28. Tune – Create SQL Diagram SQL Tuning – Dan Tow • Great book that teaches SQL Diagramming • http://www.singingsql.com registration .04 5 30 1 1 student class .002 select count(1) from registration where cancelled = 'N' and signup_date between '2009-04-08 00:00' and '2009-04-08 23:59' 3562 / 80000 = .0445 select count(1) from class where name = 'SQL TUNING' 2 / 1000 = .002 28
- 29. Tune – New Execution Plan create index cl_name on class(name) Metric – Takes 0:20 to execute Why would an Index Scan still occur on REGISTRATION? 29
- 30. Gather – Existing Indexes 30
- 31. Tune – New Execution Plan create index reg_alt on registration(class_id) Metric – Takes 0:03 to execute 31
- 32. Tune – Better Execution Plan create index reg_alt on registration(class_id) include (signup_date, cancelled) Metric – Takes 0:01.8 to execute 32
- 33. Tune – Alternative from SSMS create index reg_can on registration(cancelled, signup_date) include (class_id, student_id) Metric – Takes 0:08 to execute 33
- 34. Monitor Monitor the improvement • Be able to prove that tuning made a difference • Take new metric measurements • Compare them to initial readings • Brag about the improvements – no one else will Monitor for next tuning opportunity • Tuning is iterative • There is always room for improvement • Make sure you tune things that make a difference Shameless Product Pitch - Ignite 34
- 35. Ignite for SQL Server 40% Improvement 35
- 36. Summary Identify • What is the Bottleneck • End-to-End view of performance • Simplify Gather • Metrics – Current Performance • Wait Time • Execution Plan • Object Definitions and Statistics Tune • SQL Diagrams – Dan Tow Monitor • New Metrics, Wait Time Profile, Execution Plan 36
- 37. Confio Software Wait-Based Performance Tools Igniter Suite • Ignite for SQL Server, Oracle, DB2, Sybase Provides Help With • Identify • Gather • Monitor Based in Colorado, worldwide customers Free trial at www.confio.com 37
- 38. To learn more or inquire about speaking opportunities, please contact: Mark Ginnebaugh, User Group Leader [email protected]