This document discusses SQL Server worst practices related to design, development, installation, and administration. Some key worst practices highlighted include not normalizing database schemas, using dynamic SQL with hardcoded literals, installing SQL Server with default settings, relying on autogrow for disk space management, and having no monitoring or alerting configured. The document encourages learning from other's mistakes to avoid common pitfalls, and provides resources for best practices analysis and SQL Server troubleshooting.

1. SQL START!
ANCONA, 28 SETTEMBRE 2012

2. SQL START!
ANCONA, 28 SETTEMBRE 2012
SQL Server Worst Practices
Gianluca Sartori
gianluca.sartori@sqlconsulting.it

3. Tecnosistemi Marche
Thanks to our sponsors:

4. #sqlstart

5. Gianluca Sartori
• Independent SQL Server
consultant
• Works with SQL Server since version 7
• MCTS, MCITP, MCT
• DBA @ Scuderia Ferrari

6. Agenda
• Best practices or Worst practices?
• What can wrong?
– Design
– Development
– Installation
– Administration

7. Disclaimer:
• Not everything is black or white
• «It depends» is the most likely answer
There are edge cases when one of these worst
practices is the only possible solution

8. Best Practices vs. Worst Practices
• Why Best Practices are not enough
– Too many
– No time
– Lack of experience
– Not clear what happens if we don’t follow them
• Why Worst Practices help
– They show the mistakes to avoid
– We can learn from someone else’s mistakes

9. Worst Practices Areas
Design Development Installation Administration
Schema design
Naming
Data Types
Environment HW validation
OS configuration
SQL installation
Recovery
Security
Capacity
Performance
Monitoring
Code
Test

10. Schema Design
• Not normalizing the schema
– 1NF:
A key, atomic attributes only
– 2NF:
Every attribute depends on the whole key
– 3NF:
Every attribute depends only on the key
«The key, the whole key, nothing but the key,
so help me Codd»

11. Clues of denormalization
• Repeating data  redundancies
• Inconsistent data between tables anomalies
• Data separated by «,»
• Ex: john@gmail.com, john@business.com
• Structired data in «notes» columns
• Columns with a numeric suffix
– Ex: Zone1, Zone2, Zone3 …

12. Schema Design Worst Practices
• No Primary Key o surrogate keys only
– «Id» is not the only possible key!
• No Foreign Keys
– They’re «awkward»
• No CHECK constraint
– The application will guarantee consistency…
• Wrong data types
– Zip code, Telephone Number
– Dates saved as strings
• Use of NULL where not necessary
• Use of «dummy» data (ex: ‘.’ , 0)

13. Schema Design Worst Practices
• Inconsistent naming conventions
– Plural o singular?
– Italian / English
– Hungarian Notation
• tbl…
• vw...
• User objects with reserved system names
• Use of the sp_ prefix
– … less problematic than it might seem!

14. Lookup Tables
Orders
PK order_id int
order_date datetime
FK2 customer_id int
FK1 status_id char(2)
FK3 priority_id tinyint
Order_Status
PK status_id char(2)
status_description nvarchar(50)
Customers
PK customer_id int
name varchar(100)
address varchar(50)
ZIP char(5)
city nvarchar(50)
FK2 state_id char(2)
FK1 country_id char(3)
Countries
PK country_id char(3)
description nvarchar(50)
States
PK state_id char(2)
description nvarchar(50)
Order_Priorities
PK priority_id tinyint
priority_description nvarchar(50)
One lookup table for each attribute

15. OTLT: One True Lookup Table
Orders
PK order_id int
order_date datetime
FK1 customer_id int
status_id char(2)
priority_id tinyint
Customers
PK customer_id int
name nvarchar(100)
address nvarchar(50)
ZIP char(5)
city nvarchar(50)
state_id char(2)
country_id char(3)
LookupTable
PK table_name sysname
PK lookup_code nvarchar(500)
lookup_description nvarchar(4000)
CREATE TABLE LookupTable (
table_name sysname,
lookup_code nvarchar(500),
lookup_description nvarchar(4000)
)
One lookup table for all attributes

16. OTLT: One True Lookup Table
• No Foreign Keys
• Generic data types  nvarchar(?)
– Implicit Conversions
• CHECK constraints are hard to define
• Locking
CHECK(
CASE
WHEN lookup_code = 'states' AND lookup_code LIKE '[A-Z][A-Z]' THEN 1
WHEN lookup_code = 'priorities' AND lookup_code LIKE '[0-9]' THEN 1
WHEN lookup_code = 'countries' AND lookup_code LIKE '[0-9][0-9][0-9]' THEN 1
WHEN lookup_code = 'status' AND lookup_code LIKE '[A-Z][A-Z]' THEN 1
ELSE 0
END = 1
)

17. EAV: Entity, Attribute, Value
Customers
PK customer_id int
name nvarchar(100)
address nvarchar(50)
ZIP char(5)
city nvarchar(50)
state_id char(2)
country_id char(3)
AttributeNames
PK attribute_id int
PK,FK1 entity_id int
attribute_name nvarchar(128)
AttributeValues
PK,FK1 attribute_id int
PK,FK1 entity_id int
PK,FK2,FK3 id int
value nvarchar(4000)
Entities
PK entity_id int
entity_name nvarchar(128)
Orders
PK order_id int
order_date datetime
customer_id int
status_id char(2)
priority_id tinyint

18. EAV: Entity, Attribute, Value
• Disadvantages:
– Generic data types  Ex: varchar(4000)
– No Foreign Keys
– No CHECK constraints
– Multiple accesses to the same table
• One access per attribute
• Advantages
– Dynamic schema: no need to alter the database
• Replication, distributed environments

19. EAV: Entity, Attribute, Value
• Workaround:
– PIVOT / Crosstab
– View + INSTEAD OF triggers
• Alternatives:
– SPARSE columns
– XML
– Key-value store databases
• Azure Table storage, Redis
– Document-oriented databases
• MongoDB, RavenDB

20. DEMO:
EAV Design

21. Development Worst Practices
Development Environment
• No database schema versioning
• No abstraction level
– Views, Functions, Stored Procedures
• Development with sysadmin privileges
– In produzione it won’t be sysadmin!

22. Development Worst Practices
Code
• No transactions
• No error handling
– @@ERROR is a thing of the past!
• Wrong isolation levels
– NOLOCK = no consistency!
• SELECT *
• Dynamic SQL with hardcoded literals
• Code vulnerable to SQL injection

23. Development Worst Practices
Test
• Not testing all the code
– Representative data volumes
• Test in production
– Can alter production data
– Interferes with production users
• Test in development environment
– Useful at most for unit tests

24. Installation Worst Practices
• Using inadequate or unbalanced HW
• Installing accepting all the defaults
– Data files on the system drive!
• Installing unused components
• Installing multiple services on the same
machine

25. I/O Worst Practices
• Choosing a wrong RAID level
– RAID 0 offers no protection!
• Planning storage with capacity in mind
• Partition misalignment
• Using the default allocation unit (4Kb)

26. What does a database need?
Brent Ozar

27. Administration Worst Practices
Backup and Recovery
• No backup
– With FULL recovery it’s a timebomb
– Ignoraring RPO and RTO
• No test restores
• No consistency checks
– DBCC REPAIR_ALLOW_DATA_LOSS
Our responsibility is to perform restores, not backups!

28. Administration Worst Practices
Security
• Too many sysadmin
• Using SQL Authentication
– Weak passwords
• 123
• P4$$w0rd
• Same as username
• No auditing

29. Administration Worst Practices
Capacity
• Not checking disk space
– No space left = database halted!
– Am I taking backups?
• Relying on autogrow
• Not presizing tempdb
– Different file size = striping penalty

30. Administration Worst Practices
Maintenance
• Not maintaining indexes and statistics
• Using catch-all maintenance plans
• Updating statistics after rebuilding indexes

31. Performance Tuning

32. Performance Worst Practices
Query Optimization
RBAR: Row By Agonizing Row
– Cursors
– WHILE loops
– App-side cursors
– Scalar and multi-statement functions
Jeff Moden
Let’s use set-based code
The optimizer knows better

33. Performance Worst Practices
Query Optimization
• One query to rule them all
– The optimizer is good, not perfect
– «divide et impera» delivers better performance
• DISTINCT for all queries
• Query HINTs

34. Performance Worst Practices
Indexing
• Accepting all suggestions from Tuning Advisor
• Duplicate indexes
• An index for each column
– Indexes are not for free!
• Suboptimal Clustered Index
– Unique
– Small
– Unchanging
– Ever increasing or decreasing
Prefer NEWSEQUENTIALID()
over NEWID()

35. Performance Worst Practices
Server Tuning
• «Throwing HW» at the problem
– A faster machine won’t fix structural issues
• Using «advanced» options without testing
– NT Fibers (lightweight pooling)
– Priority Boost

36. Administration Worst Practices
Monitoring
• Reactive paradigm (no monitoring)
• Lack of alerting
– Severity > 16
• Too much noise in alerts
– Everybody will just ignore them altogether

37. Resources
Free Tool:
Best Practices Analyzer
• Highlights configuration parameters that don’t
comply with best practices
• Highlights potential problems
• Offers recommendations
http://www.microsoft.com/en-us/download/details.aspx?id=15289

38. Risorse
Free e-book:
Troubleshooting
SQL Server
• Jonathan Kehayias
• Ted Krueger
– Gail Shaw
– Paul Randal
http://www.simple-talk.com/books/sql-books/troubleshooting-
sql-server-a-guide-for-the-accidental-dba/

39. Thank you!
Don’t forget to complete the
Feedback forms
Tell us about this session on Twitter
#sqlstart