1. SQL Server Performance Tuning Starter Kit Randolph West | Born SQL

2. Please Support Our Sponsors SQL Saturday is made possible with the generous support of these sponsors. You can support them by opting-in and visiting them in the sponsor area.

3. Don’t forget to silence your phone

4. SQL Server Internals The Quick and Dirty Version for the Database Engine

5. Basic Internals  Transaction Log File (LDF)  Virtual Log Files  Data File (MDF, NDF)  Data Page (8KB in size)  Indexes (Clustered, Non-Clustered)  Statistics (Cardinality Estimator)  Buffer Pool

6. Basic Internals: Transaction Log Transaction Log File (LDF: Log Data File) Database File Group VLF Commit on Write

7. Basic Internals: Data File Transaction Log File (LDF: Log Data File) Data File (MDF: Main Data File) (NDF: Non-Primary Data File) Database File Group 8KB 8 x 8KB pages = 1 extent (64KB)

8. Basic Internals: Page Rows ID 1: … ID 2: … ID 3: … ID 4: … ID 6: … ID 5: … Page Header 13 245 6 Slot Array Paul Randal (SQLskills.com): Anatomy of a Page http://goo.gl/gWNjTO

9. Basic Internals: Tables ColID | PageID 1 | 2 7 | 6 ColID | PageID 1 | 1 4 | 4 ColID | Province 1 | AB 2 | ON 3 | ON ColID | Province 4 | ON 5 | AB 6 | SK ColID | PageID 7 | 5 10 | 7 ColID | Province 7 | SK 8 | YT 9 | YT ColID | Province 10 | QC 11 | SK 12 | NU Page 5Page 4 Page 3 Page 2 Page 1 Page 6 Page 7 Clustered on ColID

10. Basic Internals: Indexes Province | PageID AB | 2 QC | 6 Province | PageID AB | 1 ON | 4 Province | ColID AB | 1 AB | 5 NU | 12 Province | ColID ON | 2 ON | 3 ON | 4 Province | PageID QC | 5 SK | 5 Province | ColID QC | 10 SK | 6 SK | 7 Province | ColID SK | 11 YT | 8 YT | 9 Page 5Page 4 Page 3 Page 2 Page 1 Page 6 Page 7 Indexed on Province

11. Basic Internals: Heap id | indid First IAM = indid 0 Extent | Bitmap 110 | 1 111 | 1 112 | 0 113 | 1 Table Data xxxxx | xxxxx Table Data xxxxx | xxxxx Table Data xxxxx | xxxxx Table Data xxxxx | xxxxx Extent 112Extent 111 sys.sysindexes Index Allocation Map Extent 110 Extent 113

12. Basic Internals: Indexes (Contd.)  Heap  No B-tree, no links → all info stored in Index Allocation Map (IAM)  Clustered Index  B-tree, the index is the data, double-linked list  Non-Clustered Index (“a smaller table”)  Unique Indexes and Constraints  Filtered Index (WHERE clause → “an even smaller table”)  Indexed View (persisted data)  Fill Factor (it doesn’t always work the way you think it does)  https://goo.gl/E0BsrB  Fragmented Indexes? Don’t bother rebuilding*.  Update statistics instead.

13. Basic Internals: Statistics  Query Magic Happens Here  Distribution of Data (up to 200 steps)  Density of Data (rows per step)  Tipping Point (selectivity of data)  Auto-updated after 20% plus 500 rows changed  SQL Server 2016 is more intelligent  All query plan costs are based on these values  SQL Server 2014 Cardinality Estimator  DBCC SHOW_STATISTICS  Read more by Gail Shaw, Kimberly L. Tripp and Joe Sack

14. How Do You Make SQL Server Go Faster? Hint: put it all in memory

15. CPU Cache (MB in size) RAM (GB in size) Disk (TB in size) Network ( ∞ in size) L1 cache (128KB) - 700 GB/s L4 cache (128MB) - 40 GB/s DDR3 – 12 GB/s Solid State – 600 MB/s 1 Gbps Ethernet – 125 MB/s Performance vs Storage 4x 20x 3x

16. Put Your Database in Memory Put your database in the Buffer Pool < $10k for 384 GB* * Canadian dollars

17. Where Do I Begin?

18.  Hardware Configuration  Operating System  SQL Server Configuration  Monitoring Tools

19. Hardware  CPU (SMP or NUMA?)  RAM (memory pressure?)  Storage (many options)  Network (SAN? TCP offloading?)

20. Operating System  Physical or Virtual  Version and Edition  Drive allocation  Also cluster size, partition alignment  Instant File Initialization  Power Saving  What else is running on the server?

21. SQL Server Configuration  Version, Edition, Build, and Licence  Part of a Cluster, Mirror or Availability Group?  Trace Flags (1118, 1117*, 3226, possibly 4199)  sp_configure  Cost Threshold for Parallelism? Appropriate to workload.  Max Degree of Parallelism (MAXDOP)? Cores in NUMA node.  Optimize for Ad-Hoc Queries? Turn it on.  Max Server Memory? Appropriate to environment.  Backup Compression? Turn it on.  Lightweight Pooling and Priority Boost? Turn it off.  Agent Jobs  Maintenance tasks  System Databases

22. User Databases  Number of Databases  Data and Transaction Log file allocation  File growth, free space, location, VLFs  I/O Performance  Latency < 10ms  Recovery Mode  Compatibility Level  SQL Server 2014+  Page Verify Option  Always be CHECKSUM  Auto-Update Statistics  Always be on

23. Monitoring Tools  DO YOU HAVE A BASELINE?  Dynamic Management Views  Missing Indexes:  sys.dm_db_missing_index_details  sys.dm_db_missing_index_groups  Wait Statistics: sys.dm_os_wait_stats  Sessions: sys.dm_exec_sessions  Free Tools  sp_WhoIsActive (Adam Machanic)  Diagnostic Scripts (Glenn Berry, SQLskills.com)  sp_Blitz, sp_BlitzIndex, sp_AskBrent (BrentOzar.com)

24. Tuning Process  TempDB performance  “The public toilet of SQL Server” - Brent Ozar  Indexes  Unique clustered indexes on all tables  Non-clustered covering indexes (avoid key lookups)  Included columns (2005+)  Filtered indexes (2008+) (WHERE clause)  Indexed views (materialized views)  Statistics  20% plus 500 rows changed (2016+ has changed)  Query Tuning (the last resort)

25. Query Tuning  Examine the longest running queries  Memory consumers  Sort, hash aggregate, hash join  Blocking operators  Sort, scalar aggregates, hash join, eager spool, any operation that can spill to disk (e.g. worktable)  Types of join  nested loop, merge, hash

26. Query Tuning (Contd.)  Examine the longest running queries  Key / Bookmark Lookups (try a covering index)  Cursors vs CROSS APPLY  Temp tables vs table variables  Collation  Implicit conversions  Craig Freedman: http://goo.gl/H7ywSq

27. Tips and Tricks  Stored procedures beat ad-hoc queries any day  Statistics are updated at 20% plus 500 rows  Avoid query hints at all costs  Parameterised dynamic T-SQL can be good  Tipping point (scans vs seeks)  Parameter sniffing can be bad  OPTIMIZE FOR UNKNOWN could be worse  Table Valued Function  It depends …

28. Contact Me  Blog: https://bornsql.ca/blog  Twitter: @rabryst, @bornsql