Building perfect sql servers, every time -oops
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Building perfect sql servers, every time -oops

  • 1,236 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,236
On Slideshare
363
From Embeds
873
Number of Embeds
5

Actions

Shares
Downloads
26
Comments
0
Likes
1

Embeds 873

http://joedantoni.wordpress.com 646
http://joeydantoni.com 218
http://www.newsblur.com 5
http://www.google.com 2
http://newsblur.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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