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.

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
• randy.williams@avepoint.com
• @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 Factors
1. RAM
2. CPU
3. 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

9. Demo
OPTIMIZING SQL SERVER

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 DB
For more, see http://slidesha.re/t1xnxD

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. Demo
SIZE AFFECTS PERFORMANCE

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 widely
For more, see bit.ly/v4iMMm

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. Book giveaway
• What are the three primary types of
databases that SharePoint uses?

25. Questions?
randy.williams@avepoint.com
http://linkd.in/plEEb1
@tweetraw

26. Victory Lap- social event
"SharePoint Victory Lap" Social Event for
SPSLA will be at: 5:30pm to 8pm at
Di Piazzas (5205 E. Pacific Coast Hwy, 90804)

27. We want your feedback!
Use this QR code or visit:
http://sps.la/feedback
Silver Sponsors: