SQL Server Tuning to Improve Database Performance

Tuna Helper Tuna Helper

For SQL Server DBAsFor SQL Server DBAs

Speaker: Dean RichardsSenior DBA, Confio Software

San Francisco SQL Server User Group

April 2010

Mark Ginnebaugh, User Group Leader,

mark@designmind.com

2

Tuna HelperProven Process for SQL Tuning

Dean Richards

Senior DBA, Confio Software

Tuna Helper – Proven Process for SQL Tuning

3

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

� Senior DBA for Confio Software

• DeanRichards@confio.com

� Current – 20+ Years in SQL Server & Oracle

• DBA and Developer

�

Who Am I?

4

� Specialize in Performance Tuning

� Review Performance of 100’s of Databases for Customers and Prospects

� Common Thread – Paralyzed by Tuning

� Introduction

� Challenges

� Identify - Which SQL and Why

� Gather – Details about SQL

Agenda

5

� Gather – Details about SQL

� Tune – Case Study

� Monitor – Make sure it stays tuned

� Tuning is Hard

� This Presentation is an Introduction

• 3-5 day detailed classes are typical

� Providing a Framework

Introduction

6

� 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

Challenges

� Requires Expertise in Many Areas

• Technical – Plan, Data Access, SQL Design

• Business – What is the Purpose of SQL?

� Tuning Takes Time

7

• Large Number of SQL Statements

• Each Statement is Different

� Low Priority in Some Companies

• Vendor Applications

• Focus on Hardware or System Issues

� 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

Identify – End-to-End

8

� 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

Identify – End-to-End Time

9

� User / Batch Job Complaints� Tracing a Session / Process� Queries Performing Most I/O (LIO, PIO)� Queries Consuming CPU� Queries Doing Table or Index Scans�

Identify – Which SQL

10

� 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

Measure Response/Wait Time

Focus on End User Response Time

11

� Understand the total time a Query spends in Database

� Measure time while Query executes

� SQL Server helps by providing Wait Types

� Tellers are the CPUs

� Customers being helped are “running”

� Customers waiting in line are “runnable”

� Customer 1 Requires Higher Level Signature

Banking Analogy

12

� 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”

sysprocesses

loginame

hostname

programname

spid

Wait Time Tables (SQL 2000)

http://support.microsoft.com/kb/822101

� WaitType – internal binary, 0 means SPID is on CPU and not waiting

�

13

spid

dbid

waittype

waittime

lastwaittype

waitresource

sql_handle

stmt_start

stmt_end

cmd

� LastWaitType – string value

� WaitTime – ms of wait for current waittype

� WaitResource – more details about what is being waited on

dm_exec_query_stats

execution_count

total_logical_writes

total_physical_reads

total_logical_reads

Wait Time Tables (SQL 2005/8)

dm_exec_requests

start_time

status

sql_handle

plan_handle

start/stop offset

database_id

user_id

http://msdn.microsoft.com/en-us/library/ms188754.aspx

14

dm_exec_sql_text

text

dm_exec_sessions

login_time

login_name

host_name

program_name

session_id

user_id

blocking_session

wait_type

wait_timedm_exec_query_plan

query_plan

DBCC SQLPERF(WAITSTATS)

15

� Which scenario is worse?

� SQL Statement 1

• Executed 100 times

• Caused 10 minutes of wait time for end user

Wait Time Scenario

16

• 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”

� 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

Identify – Simplification

17

• Get the definition of views

• Understand Distributed Queries

� Determine the SQL

� Understand End-to-End

� Measure Wait Time

� Simplify Statement

Identify – Summary

18

� Simplify Statement

� 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)

Gather - Metrics

19

• 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

� 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

Gather – Execution Plan

20

� 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

DM_EXEC_QUERY_PLAN

21

� <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

Gather – Bind Values

22

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

� 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

Example SQL Statement

23

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

Execution Plan

24

CLASSclass_idnameclass_level

STUDENTstudent_idfnamelname

REGISTRATIONclass_idstudent_idsignup_datecancelled

Gather - Relationships

25

cancelled

� Table Definition

• Where does it physically reside

• Large columns?

• Data Profile Viewer – Integration Services

� Existing Indexes

Gather – Table Information

26

� Existing Indexes

• Names of all existing indexes

• Columns those indexes contain

� Metrics

• How long does it take currently

• What does the query wait for (wait types)

� Plan

Gather – Summary

27

• DM_EXEC_QUERY_PLAN

• Actual Execution Plan

• Do not use Estimated Plans unless necessary

� Table Relationships

� Table Information

• Columns and Existing Indexes

Tune – Create SQL Diagram

registration5 30

.04

� SQL Tuning – Dan Tow• Great book that teaches SQL Diagramming• http://www.singingsql.com

28

student class

1 1

.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

create index cl_name on class(name)

Tune – New Execution Plan

29

� Metric – Takes 0:20 to execute

� Why would an Index Scan still occur on REGISTRATION?

Gather – Existing Indexes

30

create index reg_alt on registration(class_id)

Tune – New Execution Plan

31

� Metric – Takes 0:03 to execute

create index reg_alt on registration(class_id)

include (signup_date, cancelled)

Tune – Better Execution Plan

32

� Metric – Takes 0:01.8 to execute

create index reg_can on registration(cancelled, signup_date)

include (class_id, student_id)

Tune – Alternative from SSMS

33

� Metric – Takes 0:08 to execute

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

34

• 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

Ignite for SQL Server

35

40%

Improvement

� Identify• What is the Bottleneck

• End-to-End view of performance

• Simplify

� Gather• Metrics – Current Performance

Summary

36

• Metrics – Current Performance

• Wait Time

• Execution Plan

• Object Definitions and Statistics

� Tune• SQL Diagrams – Dan Tow

� Monitor• New Metrics, Wait Time Profile, Execution Plan

Confio Software

� Wait-Based Performance Tools

� Igniter Suite

• Ignite for SQL Server, Oracle, DB2, Sybase

� Provides Help With

37

� Provides Help With

• Identify

• Gather

• Monitor

� Based in Colorado, worldwide customers

� Free trial at www.confio.com

To learn more or inquire about speaking opportunities, please contact:

Mark Ginnebaugh, User Group Leader

mark@designmind.com