'Natural born killers, SQL performance issues to avoid'

Natural Born Killers, performance
issues to avoid
Richard Douglas
Editor in chief of SQLServerPedia

Natural Born Killer

http://www.flickr.com/photos/merille/4747615138/sizes/z/in/photostream/

2 Natural Born Killers

Adhering to best practices?

http://www.flickr.com/photos/12693492@N04/1338123903/sizes/m/in/photostream/


Your host

• Richard Douglas
• Systems Consultant /
Editor in Chief of SQLServerPedia
• SQL Server MCITPro
• Maidenhead SQL User Group Leader
• Blog: http://SQL.RichardDouglas.co.uk
• Twitter: @SQLRich
• Email: Richard.Douglas@Quest.com
Richard_Douglas@Dell.com


Agenda
• Statistics

• Table Design

• SELECT pitfalls

• RBAR

• Scalar UDF’s

• Indices

• Key lookups

• Sargability

• Table variables

• Parameter sniffing


Statistics

• SQL uses a cost based optimizer
• Costs influenced by statistics


Statistics
• Creating Statistics
– Automatic
– Manual
– CREATE STATISTICS
– Sp_CreateStats

• Updating Statistics
Permanent Table Temporary Table
1st record 1st record
- 6 records
LT 500 recs, 500 changes LT 500 recs, 500 changes
GT 500 recs, 500 changes + 20% GT 500 recs, 500 changes + 20%
• Sp_UpdateStats
• UPDATE STATISTICS


Table Design

http://www.flickr.com/photos/aresauburnphotos/2699269321/sizes/o/in/photost
ream/


Example of bad design


Example of a better design


Table Design – Size comparison


Good table design benefits
• Minimise the CPU overhead.
• Increase the number of records in the buffer cache.
• Reduce the amount of physical disk IO.
• Reduce the amount of network traffic.
• Reduce the data file size(s).
• Reduce the working size of the Transaction Log.
• Reduce Full/Diff /T-Log backup file size.
Thereby increasing your ability to deliver your RTO.
• Keep transaction time to a minimum.

Source: http://cheezburger.com/View/5939764992


SELECT *
• Returns all data from one or more tables.
– Pulls unnecessary data into the buffer cache
– Can result in excessive IO
– Increases network activity
– Can hide important data in Missing Index DMV’s

• Adding new attributes
– May break existing code

• Increases code fix time

• SQL Azure
– Paying for data transfer.


SELECT * - A resolution


RBAR Vs. Set Based


Scalar User Defined Functions

• The Good
– Re-Usable code

• The Bad
– Runs once per record in record set
– They don’t take advantage of parallelism
– They use Nested Loop joins regardless

• The Ugly
– So ugly it’s hidden from IO statistics

Scalar UDF Solutions and Alternatives

• If you have to use them:
– View the actual IO usage in Profiler

• If you can replace them:
– Look at Table Value Functions
– Look at CLR


Indexing strategies
It’s all about DWI knowledge:

D W n
a o
I
t r t
a k e
l r
o n
a a
d l
s


Golden Rules for Clustered Indexes
Bad example; Surname, Firstname, Middle Initial
• Narrow
Impacts nonclustered indexes
• Static
• Progressive Fragmentation
• Unique
• Fixed width Space impact
• Not Null
This example will have 13 bytes of overhead alone;
• 4 byte uniquifier
• 2 byte variable offset + 6 bytes for variable length fields
23
• 1 byte for NULL values and NULL bitmap
Natural Born Killers

Golden Rules for NonClustered Indexes

• Have an optimal clustered key
• Not narrow
• Reduce unnecessary overhead
– Fixed Width
– Not null

• Consolidate
• Index foreign keys


Key Lookups – The silent killer


Sargability

• SARGable – “Search ARGument able”

• T-SQL functions around a predicate can break
SARGability

• Some caveats to remember


Table Variables Vs. Temp Tables

Table Variables
• Fast when used with small data sets.
• Have a limited scope
• Use less locking and logging resources than temp tables
– http://sql.richarddouglas.co.uk/archive/2011/06/rollback-gotchas-part-2-2.html

• Estimated statistics always show 1 record
• Cannot be altered after they are declared
• Mythbuster - MAY be memory only, this isn’t guaranteed
• Generally faster with smaller data sets


Table Variables Vs. Temp Tables

Temp Tables
• Uses statistics
– Stat population will cause recompiles (statement level in 2005 +)
– Can create better plans

• Wider scope
• Can be rolled back
• Can be altered after creation
• Generally faster with larger data sets

Parameter Sniffing
• What is it?
– It’s all a matter of statistics

• How do I know when it will affect me?
– Monitor the IO and CPU
– This means baselining your environment

• What are my options?
– Rewrite dynamic queries
– Query Hints:
– WITH RECOMPILE
– OPTIMIZE FOR
– Plan Guides


Free posters, training DVDs, white papers, and more
http://www.quest.com/landing/?id=5700

1. SQL Server Blog Aggregator & Wiki at http://www.sqlserverpedia.com.
2. Product Overviews at http://www.quest.com/sql-server/#c-Performance-
Management. Plus, http://toadworld.com!
3. Discussion forums at
http://sqlserver.quest.com/forumindex.jspa?categoryID=208.
4. Product video tutorials at http://db-
management.com/blog/category/sqlserver/tutorials-sqlserver/.

Solution Area Product Description

Backup and
Fast, flexible backup and recovery with
Recovery industry-leading compression technology

Performance Discover and resolve performance issues in
production before they impact end users and
& Operations
service levels

Performance Deepest possible understanding of database
Tuning performance and norms

Development Plan and develop applications that deliver
both functionality and optimal performance

Comprehensive schema, object, security and
Administration change management

Community,
Project Community crowdsourcing for SQL Server
Knowledge,
tracing and performance information!
Training Lucy
© 2012 Quest Software Inc. All rights reserved. Pg. 32

'Natural born killers, SQL performance issues to avoid'

More Related Content

Viewers also liked

Similar to 'Natural born killers, SQL performance issues to avoid'

Recently uploaded

'Natural born killers, SQL performance issues to avoid'