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

Building perfect sql servers, every time -oops

on

  • 1,071 views

 

Statistics

Views

Total Views
1,071
Views on SlideShare
268
Embed Views
803

Actions

Likes
1
Downloads
24
Comments
0

5 Embeds 803

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

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Building perfect sql servers, every time -oops Building perfect sql servers, every time -oops Presentation Transcript

  • Building Perfect SQL Servers, Every Time Joey D’Antoni PASS DBA Fundamentals Virtual Chapter 01-April-2014
  • 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
  • Overview SQL Server Default Installation What Do You Need to Fix? The Importance of Standards Automating the Process Building a Private Cloud
  • SQL Server Installation
  • 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
  • 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
  • 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
  • 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*
  • 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)
  • 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
  • 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
  • Backup Compression • This costs a little bit of CPU— but your backups and restores will greatly benefit • In Standard Edition from 2008 R2 forward
  • 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”
  • Remote Dedicated Administrator Connection • Provides dedicated CPU, memory and scheduler • By default, only works via RDP or physically on server
  • 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
  • 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
  • The Cloud • ALL OF THE ABOVE APPLIES TO AZURE VMs!
  • Standards Are Important
  • 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
  • Standards Cont’d • Standard HW is good and can really help • Work with Sys Admin teams for guidance on O/S level
  • Exceptions
  • Process Automation
  • 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
  • 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
  • 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
  • Trust But Verify • Even though you doing this great process • Still verify everything • Leverage your infrastructure server • Build Pretty Reports
  • 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
  • Private Cloud User Interface (Intranet) Service Management Layer (System Center, Others) Backend Infrastructure
  • Lessons Learned • Capture Owner Info • Acknowledge servers may not be managed • Release a little bit of control
  • Summary • Do this stuff • Automate and Repeat • Your Servers will love you Slides joedantoni.wordpress.com Twitter @jdanton Email jdanton1@yahoo.com