Optimizing SQL Server 2008    For blazing fast SharePoint sites
Randy Williams           • Enterprise Trainer & Evangelist           • Based in San Diego, CA           • SharePoint MVP a...
Agenda•   Quick review of database basics•   Optimize the server•   Optimize tempdb•   Optimize Content DBs•   Scaling out...
Quick Review of Database Basics• Each database consists of  ●    One or more data files (.mdf, .ndf)  ●    One or more log...
How SharePoint Uses SQL• One configuration DB per farm• Each web app has one or more content  DBs  ●   Container for site ...
The Most Important Factors1. RAM2. CPU3. Storage  ●   SAN is best for performance (greatest IOPS)  ●   Work with your stor...
Optimize the DB Server• Do not run non-SQL apps on SQL Server• Dedicate SQL Server to one SharePoint  Farm• If virtualizin...
Optimize the SQL Instance• Adjust database default locations  ●   Never place on C: drive  ●   Log and data on separate LU...
DemoOPTIMIZING SQL SERVER
Optimizing tempdb• Pre-size – set to 25% of largest DB• Use AutoGrow of ~100MB – if growing,  increase initial size• Use m...
When working with a SharePoint DB• Do not do any of following  ●   Do not add, change or remove any built-in objects      ...
After creating a content DB• Add multiple files of same size to primary  file group  ●   Ideally: count should equal # of ...
Optimizing content DBs   • Very active content DBs should be placed     on their own LUNs   • Use RAID 5 or RAID 1+0   • I...
Why are larger DBs slower?• Read queries take longer  ●   More rows to filter, group and sort• Write queries take longer• ...
DemoSIZE AFFECTS PERFORMANCE
Book giveaway• What is the recommended size when  configuring tempdb?
Achieving storage performance• Storage array (RAID 1+0)  ●   10 300GB SAS drives, 15k RPM  ●   1.5 TB effective space  ●  ...
Scaling storage• Multiple storage arrays (RAID 1+0)• Break out into multiple LUNs• Add additional data files to DB, one pe...
Optimizing Search DBs• Max of 25 million items per each crawl and  property DB• Store crawl and property DBs on separate, ...
Scaling out for performance• For large, high-performance farms, scale  out to multiple SQL servers• No limit to the number...
Reindexing DBs• Fragmentation happens by design –  primary key uses GUID columns• Indexes are rebuilt daily as part of hea...
RBS Guidance  • Consider using in document-heavy databases  • Trade off       ●   Storage cost & performance benefits vers...
Best Practices• Use SQL 2008 R2 Enterprise for best performance• Backup logs regularly to prevent runaway log files• Do no...
Book giveaway• What are the three primary types of  databases that SharePoint uses?
Questions?  randy.williams@avepoint.com  http://linkd.in/plEEb1  @tweetraw
Victory Lap- social event  "SharePoint Victory Lap" Social Event for     SPSLA will be at: 5:30pm to 8pm atDi Piazzas (520...
We want your feedback!                   Use this QR code or visit:                   http://sps.la/feedback              ...
Upcoming SlideShare
Loading in...5
×

Optimizing SQL Server 2008 for Blazing Fast SharePoint Sites

5,399

Published on

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
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,399
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • v4iMMm
  • Optimizing SQL Server 2008 for Blazing Fast SharePoint Sites

    1. 1. Optimizing SQL Server 2008 For blazing fast SharePoint sites
    2. 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• randy.williams@avepoint.com• @tweetraw
    3. 3. Agenda• Quick review of database basics• Optimize the server• Optimize tempdb• Optimize Content DBs• Scaling out• Best Practices
    4. 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. 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. 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. 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. 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
    9. 9. DemoOPTIMIZING SQL SERVER
    10. 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. 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. 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. 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 http://slidesha.re/t1xnxD
    14. 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
    15. 15. DemoSIZE AFFECTS PERFORMANCE
    16. 16. Book giveaway• What is the recommended size when configuring tempdb?
    17. 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. 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. 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. 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. 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. 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 bit.ly/v4iMMm
    23. 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 ● http://bit.ly/bRhdgH
    24. 24. Book giveaway• What are the three primary types of databases that SharePoint uses?
    25. 25. Questions? randy.williams@avepoint.com http://linkd.in/plEEb1 @tweetraw
    26. 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. 27. We want your feedback! Use this QR code or visit: http://sps.la/feedback Silver Sponsors:

    ×