Your SlideShare is downloading. ×
  • Like
  • Save
Optimizing SQL Server 2008 for Blazing Fast SharePoint Sites
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Optimizing SQL Server 2008 for Blazing Fast SharePoint Sites


Bottlenecks in SQL Server are one of the top reasons for badly performing SharePoint sites. And without any clear prescriptive guidance, most SharePoint admins just point SharePoint to a database …

Bottlenecks in SQL Server are one of the top reasons for badly performing SharePoint sites. And without any clear prescriptive guidance, most SharePoint admins just point SharePoint to a database server. This session covers specific optimization improvements that can quickly and easily boost performance. We'll first discuss how to optimize the database server and scale your storage tier. We'll then focus on tuning tempdb, content and search databases. We'll analyze how SharePoint’s performance degrades as content databases grow and what you can do to help prevent it. Finally, we'll assess whether RBS (Remote BLOB Storage) really makes a difference and if you should consider using it.

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


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • v4iMMm


  • 1. Optimizing SQL Server 2008 For blazing fast SharePoint sites
  • 2. Randy Williams • Enterprise Trainer & Evangelist • Based in San Diego, CA • SharePoint MVP alum (2009 – 2011) • Speaker at many global conferences• 20+ years in IT ● Developer, consultant, trainer, author• Columnist: SharePoint Pro magazine•• @tweetraw
  • 3. Agenda• Quick review of database basics• Optimize the server• Optimize tempdb• Optimize Content DBs• Scaling out• Best Practices
  • 4. Quick Review of Database Basics• Each database consists of ● One or more data files (.mdf, .ndf) ● One or more log files (.ldf)• When changes occur 1. Log is written to first 2. Checkpoint process commits changes to data files • In simple recovery inactive transaction in log is truncated
  • 5. How SharePoint Uses SQL• One configuration DB per farm• Each web app has one or more content DBs ● Container for site collections ● All SharePoint content, including files, is stored in content DB• Service application databases ● Search databases are usually most important when optimizing
  • 6. The Most Important Factors1. RAM2. CPU3. Storage ● SAN is best for performance (greatest IOPS) ● Work with your storage vendor when configuring Logical Unit Numbers (LUNs)4. Network
  • 7. Optimize the DB Server• Do not run non-SQL apps on SQL Server• Dedicate SQL Server to one SharePoint Farm• If virtualizing ● Virtualize WFE and app servers first ● SQL can be virtualized, but it will affect performance
  • 8. Optimize the SQL Instance• Adjust database default locations ● Never place on C: drive ● Log and data on separate LUNs/physical disks• Adjust server memory settings if running multiple instances• Use 64KB allocation units when formatting data and log partitions
  • 10. Optimizing tempdb• Pre-size – set to 25% of largest DB• Use AutoGrow of ~100MB – if growing, increase initial size• Use multiple data files of same size – latest guidance is ¼ - 1 per physical CPU ● Each file on a separate LUN, if possible ● Store log on its own LUN• Use RAID 1+0
  • 11. When working with a SharePoint DB• Do not do any of following ● Do not add, change or remove any built-in objects (tables, views, stored procedures, triggers, indexes) ● Do not directly select from tables or views ● Change the database collation• Logging DB is the only exception
  • 12. After creating a content DB• Add multiple files of same size to primary file group ● Ideally: count should equal # of cores per NUMA node (ask your hardware vendor if unsure)• If DB is expected to grow large – pre-size the data files ● Set autogrow between 50-100MB per file• Preset log to about 25% ● Set autogrow between 20-40MB
  • 13. Optimizing content DBs • Very active content DBs should be placed on their own LUNs • Use RAID 5 or RAID 1+0 • In most cases, keep size < 200GB ● Why? Recovery and performance reasons ● Use site collection quotas ● Don’t forget about the 2nd stage recycle bin ● Use PowerShell to create site collections - store in specific content DBFor more, see
  • 14. Why are larger DBs slower?• Read queries take longer ● More rows to filter, group and sort• Write queries take longer• Increased lock contention ● Causes more blocking• More data, but data cache same size• DB maintenance takes longer ● reindex ● dbcc checkdb
  • 16. Book giveaway• What is the recommended size when configuring tempdb?
  • 17. Achieving storage performance• Storage array (RAID 1+0) ● 10 300GB SAS drives, 15k RPM ● 1.5 TB effective space ● ~1500 IOPS = 1.0 IOPS/GB• Set of drives (RAID 1+0) ● 4 750GB SATA drives, 10k RPM ● 1.5 TB effective space ● ~300 IOPS = 0.2 IOPS/GB• Go with higher quality storage ● SAS > SATA ; SAN > DAS
  • 18. Scaling storage• Multiple storage arrays (RAID 1+0)• Break out into multiple LUNs• Add additional data files to DB, one per array F:SP_DocCenter_1.mdf• Advice G: SP_DocCenter_2.ndf Data ● Many smaller drives > H: SP_DocCenter_3.ndf I: SP_DocCenter_4.ndf fewer larger ones J: SP_DocCenter.ldf Log ● RAID 1+0 > RAID 5
  • 19. Optimizing Search DBs• Max of 25 million items per each crawl and property DB• Store crawl and property DBs on separate, dedicated LUNs• Add data files to match Content DBs• Use RAID 1+0 storage• Consider storing on dedicated SQL server
  • 20. Scaling out for performance• For large, high-performance farms, scale out to multiple SQL servers• No limit to the number of servers – each database can have its own ● Best practice is to break out across some logical boundary (web app, service apps, etc.)• Using clustered SQL servers? ● Consider using instances and make each instance active on a separate physical node
  • 21. Reindexing DBs• Fragmentation happens by design – primary key uses GUID columns• Indexes are rebuilt daily as part of health analyzer job• No manual reindex needed ● Do not drop and recreate indexes
  • 22. RBS Guidance • Consider using in document-heavy databases • Trade off ● Storage cost & performance benefits versus ● More complex architecture (support, DR, HA) • Consider third party providers ● More full-featured solutions • In general ● Do not externalize documents <1MB ● Ideal number varies widelyFor more, see
  • 23. Best Practices• Use SQL 2008 R2 Enterprise for best performance• Backup logs regularly to prevent runaway log files• Do not use autoshrink ● Shrink manually only when needed• Do not use multiple file groups ● Not supported by SharePoint• Run database integrity checks• Use Instant File Initialization ●
  • 24. Book giveaway• What are the three primary types of databases that SharePoint uses?
  • 25. Questions? @tweetraw
  • 26. Victory Lap- social event "SharePoint Victory Lap" Social Event for SPSLA will be at: 5:30pm to 8pm atDi Piazzas (5205 E. Pacific Coast Hwy, 90804)
  • 27. We want your feedback! Use this QR code or visit: Silver Sponsors: