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
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
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?
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:
