How to kill SQL Server Performance Håkan Winther

About me: Håkan Winther  Experience:  SQL server since 1995  SQL 6.5, 7.0, 2000, 2005, 2008, 2008R2, 2012, 2014, 2016, Azure  System development since 1989  Speaker at:  SQLUG 2011  Microsoft Summercamp 2011,2012 & 2013  TechDays 2011, 2012  Microsoft Technical bootcamp 2014: Tap your goldmine  Lab Center 2W 2014  Microsoft Thank god it’s SQL Friday 2015  Certifications:  MCITP: SQL Server 2008, Database Developer  MCTS: Microsoft SQL Server 2008, Implementation and Maintenance  MCSA: Microsoft SQL Server  MCSE: Data platform  Passion: Performance optimization  Blog:

Execution plan  Hardware and configuration methods  Maintanance methods  Programming methods

HARDWARE AND CONFIGURATION

Death by Hardware  Disks  Slow  Not enough  Everything on same disk  Shared with everyone else on a SAN  Memory  Not enough  Nothing left for OS

Death by Default settings  Auto growth  Fill factor  Parallelism  Cost threashold  Max degree  Only 1 tempdb file

Death by power options  Default = balance power options  CPU not running on full speed all the time

Death by standard edition  <128Gb RAM  Lack of online operations  Rebuild index  Lack of partitioning  Lack of compression  No Memory optimized technologies  In-Memory Tables for OLTP  Compiled procedures  Column Store index

DEMO

MAINTENANCE

Death by changing sa password  Someone may actually use SA account!!

Death by bad indexes  Too many  Inserts will be slow  Too few  Reads will be slow  Unused  Wrong column order  Wrong sort order  Wrong clustered index  Never used for seeks, only singleton lookups  Index hints, could work….  …for a while, but then what?

Death by bad statistics  Big tables  No auto update stats  Incrementing columns  New values ”out of range”  Underestimation of query cost  Bad execution plans  Not enough memory allocated

Demo

Death by datamodel  Datatypes  Too big  Wrong type  Implicit conversion  Big tables  Too many columns  Few records / page = many pages to read  Too many records

Death by correlated subqueries  Inner query depends on outer query  RBAR

Death by SELECT *  Clustered index scan or index seek + key lookup depening on  Number of records calculated from statistics

Death by Entity Framework / nHibernate  The lazy way of killing performance, code first  Too big datatypes?  Too denormalized?  Unreadable and unefficient code

Death by optional statements  OVER CLAUSE  Range vs ROW  UNION (ALL)  Distinct values or not

Death by non searchable argument  Index scans instead of seeks  A lot more IO

Death by scalar functions  No statistics = bad execution plan  ”Hidden cost”

Death by table variables  No statistics = bad execution plan

DEMO

Win a 1day SQL 2016 course  Enter your adress at for a chance to win a 1 day course in SQL Server 2016 arranged by SQL Service and LabCenterhttp://bit.ly/sqldag

THANK YOU