Optimizing SQL Server 2008 for Blazing-fast SharePoint Sites


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
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
    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
    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: