1. Building Perfect SQL
Servers, Every Time
Joey D’Antoni
PASS DBA Fundamentals Virtual Chapter
01-April-2014

2. Joey D’Antoni
• Joey has over 15 years of experience with a wide variety of data platforms, in both Fortune 50
companies as well as smaller organizations
• He is a frequent speaker on database administration, big data, and career management
• He is the co-president of the Philadelphia SQL Server User’s Group
• MSCE, Business Intelligence
• He wants you to make sure you can restore your data
Joedantoni.wordpress.com – Blog, Slides
http://bit.ly/SQLColumnstore -- Slides, Resources

3. Overview
SQL Server Default Installation
What Do You Need to Fix?
The Importance of Standards
Automating the Process
Building a Private Cloud

4. SQL Server Installation

5. Set Max Memory
• The default setting for max server memory is 2147483647 MB
(2.1 Petabytes!!!)
• If this setting is not changed SQL Server will attempt to grab all
of the memory on the box
• This can lead to paging of the Windows O/S
• Best Practice is to allocate 80% of memory to SQL Server
• The one exception is very large memory servers—
Windows generally needs about 6-8 GB to run
comfortably
• Minimum Memory doesn’t need to be set generally

6. Configure MaxDOP
• Default setting is 0 which uses all
available processors in parallel
query execution
• This can lead to CXPACKET and
Scheduler waits
• Best Practice
• For servers > 8 CPUs = MAXDOP=8
• For servers < 8 CPUs = MAXDOP 0 to
n (where N=CPUs per NUMA node)
• Sharepoint MAXDOP=1

7. Change Model File Sizes
• Initial Size and Autogrowth are
way too small initially
• There is no right number—base
on roughly how big your
databases will be
• Definitely, change autogrowth
to remove percentage growth
and go with fixed value
• Goal is to avoid file system
fragmentation

8. Change Model Recovery Model
• By default—Model is in full recovery mode
• Typically I set to simple—if a database
needs to be in full recovery mode, set it
manually
• If you need databases in full recovery mode
be sure to set up transaction log backups*

9. Add Files to TempDB
• If the number of logical processors
< 8 then number of TempDB Files =
number of CPUs (but start with 4)
• If logical processors > 8, then
number of TempDB Files = 8
• If contention continues add files in
multiples of 4
• All TempDB files should be the
same size and have same
autogrowth settings
• Consider using trace flags
(1117,1118)

10. Create SQL Agent Alerts for Critical Errors
• Ensures you get notified when something bad happens on
your server
• Know that problems are happening before your users do
• Can tie alerts to actions and/or pages

11. Cost Threshold for Parallelism
• This is a your mileage
may vary setting
• The default of 5 is
generally too low for
everything except pure
OLTP
• Start with 50 and move
from there

12. Backup Compression
• This costs a little bit of CPU—
but your backups and
restores will greatly benefit
• In Standard Edition from
2008 R2 forward

13. Instant File Initialization
• SQL Server will by default
zero out a data file on a
growth
• Grant Windows permission to
SQL Server process account to
“Perform Volume
Maintenance Tasks”

14. Remote Dedicated Administrator
Connection
• Provides dedicated CPU,
memory and scheduler
• By default, only works via
RDP or physically on server

15. Maintenance
• The built in maintenance
plans in SQL Server aren’t
bad—they just aren’t
good
• Ola Hallengren SQL Server
Maintenance Solution
• CheckDB, Index
Maintenance, Statistics, B
ackups

16. Patch SQL Server
• Find out the current Service Pack and Cumulative Update level
(sqlserverbuilds.blogspot.com)
• Patch your server—no time like install time
If you are using SQL Server 2012 and up:
• Updatesource parameter
• Can use Windows Update (MU)
• Or local source UNC or local path

17. The Cloud
• ALL OF THE ABOVE APPLIES TO AZURE VMs!

18. Standards Are Important

19. Standards
• Having written build standards is important
• Consider everything
• Drive Locations
• Standard Volume Sizes
• Storage
• Editions, settings, builds
• O/S
• HA and DR options
• Security
• Revisit standards at least every 6 months

20. Standards Cont’d
• Standard HW is good and can really help
• Work with Sys Admin teams for guidance on O/S level

21. Exceptions

22. Process Automation

23. Infrastructure Server
• This is optional—but can be
really handy
• Store installation files
• Use as update source for SQL
Server installs
• Use as metadata and monitoring
hub for your environment
• Should be very secured
• Can be VM

24. Script your Installs
• Don’t use the GUI
• Automate for consistency, and speed
• You should still QA—this process is
dependent on things like having
standard disk letters

25. Virtual Machines
• This can get a little complicated
• I’ve taken two approaches
• Install SQL at build time (messy)
• Clone VM and make changes
• You may want different settings

26. Trust But Verify
• Even though you doing this great
process
• Still verify everything
• Leverage your infrastructure server
• Build Pretty Reports

27. Building A Private Cloud
• Case Study
• Make Decisions for 80% of
your environment
• SQL Server Components
aren’t bad—Windows is a
little trickier
• This process had more
management/sprawl issues
than technical ones

28. Private Cloud
User Interface
(Intranet)
Service
Management Layer
(System Center,
Others)
Backend
Infrastructure

29. Lessons Learned
• Capture Owner Info
• Acknowledge servers may not be managed
• Release a little bit of control

30. Summary
• Do this stuff
• Automate and Repeat
• Your Servers will love you
Slides joedantoni.wordpress.com
Twitter @jdanton
Email jdanton1@yahoo.com