This document discusses how to maintain a healthy SharePoint environment. It emphasizes the importance of properly configuring and managing the SQL Server database that SharePoint runs on. It provides guidance on capacity planning, hardware sizing, maintenance best practices, and understanding SharePoint limitations and thresholds. The goal is to ensure the SQL Server infrastructure can support the SharePoint implementation and meet performance requirements.

1. What you need to know to have a healthy
SharePoint environment
Enrique Lima
Pinnacle of Indiana
elima@pinnacleofindiana.com
Twitter: @enriquelima

2.  Enrique Lima
 elima@pinnacleofindiana.com
 SharePoint Practice Lead
 Pinnacle of Indiana
 Microsoft Community Contributor
 Member of the Geekswithblogs.net Community - Influencer
 http://geekswithblogs.net/enriquelima
 @enriquelima - twitter.com/enriquelima
 Member of INETA

3.  Try to stay awake!
 Importance of SQL Server
 SharePoint and SQL Server
 Capacity Planning
 Configuration
 Physical vs. Virtual
 Processor
 Memory
 Storage
 tempdb
 Content
 In Closing

4.  Industry seems to be focused more on the
development of the SharePoint solutions
 Little focus on infrastructure
 SQL Server
 Storage
 Capacity / Performance Planning
 Disaster Recovery
 High-Availability
 Management does not even know SharePoint runs on
SQL Server
 SQL Server can be “scary stuff”
 Get to know the Health Analyzer and it’s “quirks”.
Database maintenance for SharePoint Server 2010

5.  SharePoint 2010 Health Analyzer
 Routine database maintenance
 Check database integrity (DBCC CHECKDB)
 Defragmenting indexes – rebuild/reorg.
 Fill Factor
 Monitor Performance
 SQL Server Perspective
▪ CPU
▪ Memory
▪ Disk I/O

6.  SQL Server configuration
 Do not enable auto-create statistics
 Set max degree of parallelism (MAXDOP) to 1
 Configure SQL Server connection aliases for each
database server in your farm
 Autogrowth setting for file size
▪ Content
▪ Search

7.  Know your limits, Software Boundaries
 Yes, there is a formula:
 Database size = ((D × V) × S) + (10 KB × (L + (V × D)))
 D = # of Docs
 V = # of non-current versions
 S = Avg. Size of Docs
 L = List Items

8.  Number of Docs (D) 200,000
 Average Size of Docs (S) 250KB
 List Items (L) 600,000
 Number of non-current versions (V) 2
(Assume max 10 allowed)
 Database size = (((200,000 x 2)) × 250) + ((10
KB × (600,000 + (200,000 x 2))) =
110,000,000 KB or 105 GB

9.  Boundaries
 Absolute limit
 Example: 2GB document size limit
 Thresholds
 A default value that cannot be exceeded unless the value is modified
 Exceeding threshold may impact performance
 Example: Document size limit of 50MB by default
 Supported Limit
 Defined by testing and represent a known limitation of the product
 Exceeding supported limit may cause unexpected results, significant
performance degradation or other detrimental effects
 Example: Support 500,000 site collections per web app.

10. SharePoint 2007 SharePoint 2010
Items per view 2000 5000
Docs per Library 5M 10 M
Database Size 100GB 200GB (1TB for workloads)
Content DB per Web App 100 300

11.  Plan for your SQL Server spread.
 Negotiate Volume
 Size
 Placement
 LUNs are a precious thing …
 … but so is the performance of your
environment

12. Drive Letter Purpose LUN Negotiated
LUN
C: System (OS) 1 1
D: User Data 2 2
L: SQL Log Files 3 3
P: Page File 4 1
R: Local Backup Store 5 5
S: SQL Server System Databases 6 2
T: TempDB 7 4

13.  Of course it can be virtualized.
 Virtual is not as forgiving as Physical
 Know and work with memory management
 Understand SQL Server in Virtual
environments will test more than just
compute.
 Disk I/O, SQL I/O is very important

14.  IMPORTANT TO CAPACITY PLAN MEMORY
CORRECTLY FOR LARGE NUMBER OF CPUS
 Rule of thumb: 4-6GB per core
 Worker Thread configuration:
CPUs 32-bit 64-bit
Up to 4 256 512
8 288 576
16 352 704
32 480 960

15.  Adjust the Out of Box Memory Limit
 If Virtual:
 Configure a minimum of memory to work with
 Be careful with over allocation of memory in the
pool
 Magic Formula:
 Memory to Allocate = Server Memory * 0.8

16.  Measure I/O Performance
 SQLIO
 CrystalDiskMark
 NTFS Allocation and Sector Alignment
 Be mindful of Thin Provisioning
 Separation of I/O intensive databases
 Content
 Search
 Do not forget about
 Versioning
 Recycle Bin
 Mind your Free Space

17.  SharePoint 2010 heavily uses the tempdb system
database
 Don’t forget that tempdb is used for other
purposes, some of which are I/O intensive
 DBCC CHECKDB
 Index Rebuilds
 Best practices:
 Multiple data files
▪ On separate LUN
▪ Equal in size
▪ Auto-growth in MB (decent size)
 Log file on separate LUN

18.  Simple
 Bulk-logged
 Full

19.  Organizations will use SharePoint to store content
 It starts by referring to it as a “next generation file share”
 But can (hopefully) evolve to a Corporate Knowledge approach
 All content is stored in one or more content databases
 “All eggs are in one basket”
 Disaster recovery is critical
 Availability is important
 Performance of content database(s) is key to the user experience
 Capacity planning
 Performance planning
 Provisioning of DBs
 Central Admin
 DBA Created

20.  Get to know SQL Server
 Get to know SharePoint
 Understand the Metrics and Performance
Counters

21.  http://mtme.me/7b8619

22.  Storage and SQL Server capacity planning
and configuration.
http://technet.microsoft.com/en-
us/library/cc298801.aspx
 Software boundaries and limits.
http://technet.microsoft.com/en-
us/library/cc262787.aspx
 Database Types.
http://technet.microsoft.com/library/cc67886
8(office.14).aspx