1. When Good Design Goes Bad Bob Duffy Database Architect Prodata SQL Centre of Excellence March 2015

2. Bob Duffy 20 years in database sector, 250+ projects 20 years in database sector, 250+ projects Senior Consultant with Microsoft 2005-2008 Senior Consultant with Microsoft 2005-2008 One of about 25 MCA for SQL Server globally (aka SQL Ranger) One of about 25 MCA for SQL Server globally (aka SQL Ranger) SQL MCM on SQL 2005 and 2008 SQL MCM on SQL 2005 and 2008 SQL Server MVP 2009+ SQL Server MVP 2009+ SSAS Maestro SSAS Maestro Database Architect at Prodata SQL Centre of Excellence Database Architect at Prodata SQL Centre of Excellence http://blogs.prodata.ie/author/bob.aspx http://blogs.prodata.ie/author/bob.aspx http://blogs.prodata.ie/author/bob.aspx bob@Prodata.ie bob@Prodata.ie bob@Prodata.ie @bob_duffy

3. What We Will Cover Stored Procedures Clustered Tables Identity and Primary Keys IndexesFragmentation Naming Conventions PartitioningORM

4. 1. Stored Procedures Why use Stored Procedures ?

5. http://www.sommarskog.se/dyn-search.html The Dreaded Search Screen

6. The Chunky v Chatty Debate Two Types of “Chunkiness” Data Transferred per Call Number of Calls Network latency Important here

7. Stored Procedure Weigh In PerformanceSecurity Plan Cache MaintainabilityChunky Dynamic Design Patterns Slow Interpreted TSQL Application Agility Developer Agility The ORM Debate Chatty

8. 2. Clustered vs Heap Best Practise: Cluster ALL Tables ? Ever Increasing, Narrow, Unique, Static Always use an Identity Column

9. When do Clustered Tables go Bad ? Harder to Scale, especially for some key choices

10. Large Table Scan Workloads Non sequential Clustering Keys Cause Fragmentation Why is Fragmentation the Achilles Heel of table Scans More Pages => More IO Kills Read Ahead and disk performance

11. Heavy NCI Requirement Best Practise “Clustered Index are Better for Seeks” Well it depends on if the seek is on a NCI or not!

12. Clustered Index v Heap Ascending Keys Range Scans Lots of Deletes Tables with Heavy Primary Seek Most Logging Tables Insert and Scan heavy Tables OLTP Transaction Tables (banking) Bulk Loading

13. 3 Always use Identity for Primary/CX Key Best Practise Always Use an Identity Column as Primary Key Extension: Always add a new Surrogate Key This may shoot you in the foot on large Fact Tables

14. The Distributed Database Choice of Identity will cause a lot of pain! How common is this Issue? Very Frequent with replication and new MPP Architectures

15. The Distributed Write Cache ? Identity creates a bottleneck on the DB Serializes new records What if database offline ?

16. The Over Zealous Dimensional Modeller This may go bad if you are not a “single hop” data source

17. 4. We Don’t Need no Indexes? Best Practise. Add Indexes.. To Reduce IO on important Queries Seek rather than scan. SELECT * WHERE CustomerID=2 Narrower Scan. SELECT SUM(Qty) DateKeyCustomerRegionKey Sales € Qty Cost Jan111000 100 80 211000 100 80 311000 100 80 411000 100 80 111000 100 80 211000 100 80 Feb311000 100 80 Mar111000 100 80 April111000 100 80 111000 100 80 May 111000 100 80 June111000 100 80 July111000 100 80 Aug111000 100 80

18. When Indexes go bad OLTP Small Tables Larger Results – See “The Tipping Point” by Kimberly Tripp When upsert is more important then select When every column Indexed High Throughput Queueing Design Patterns DWH Bad “Tipping Points” Staging Tables Tables that we scan When avoiding bad statistics is very hard Data Analytics Where we need guaranteed query performance for varied workloads.

19. Guaranteed Performance !!?! We have a 1TB Table. Query SLA is 5 mins… Add indexes?

20. 5 Stop Worrying about Fragmentation Best Practise – Defragment the hell out of your database Why could this be bad ? Takes a long time and may interfere with query performance Why Could this be not worth the bother ? More Memory will reduce reliance on contiguous disk blocks Most SANs only do random IO anyway Its mainly important if our primary concerns are Scans

21. 6 Naming Conventions Best Practice – use one! Goes Bad When prefix is meta data (object type, data type, size)

22. Naming – Common Sense Project with following prefix standards on SSIS DATA Source Transform Type (LOAD, TRANSFORM, EXTRACT) Package Control Flow Shape

23. 7 Partitioning Maintenance Operations Parallel Queries Best Practise – Partition when table it too big or too slow Ordered Queries Serial Queries Dynamic Parallel Queries

24. 8 ORMs Best Practise ? Hotly debated Good For Developer Agility Code First, Database Second Integrated Debugging Domain Business Model Cache Management Key Management Portable

25. Query Plan Nightmares Source: http://www.scarydba.com/2014/12/19/pretty-plans-vs-performance/ http://www.scarydba.com/2014/12/19/pretty-plans-vs-performance/

26. When ORMs go Bad Can write truly horrible TSQL and Plans Naïve context Parameterisation The Disaster Scenario Lazy/Eager Loading Can be used as an excuse of lack of database expertise Hard to Index for (lots of Select *)

27. Everything has good and bad Aspects It Depends ;-)