SQL Server tuning is a process to eliminate performance bottlenecks and improve application service. This presentation from Confio Software discusses SQL diagramming, wait type data, column selectivity, and other solutions that will help make tuning projects a success, including: •SQL Tuning Methodology •Response Time Tuning Practices •How to use SQL Diagramming techniques to tune SQL statements •How to read executions plans

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,
mark@designmind.com

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
• DeanRichards@confio.com
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

15. DBCC SQLPERF(WAITSTATS)
15

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

21. DM_EXEC_QUERY_PLAN
21

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

24. Execution Plan
24

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
mark@designmind.com