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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Building perfect sql servers, every time -oops

1,620
views

Published on


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,620
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

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

×