© 2009 Quest Software, Inc. ALL RIGHTS RESERVED
SQL and Storage Considerations for SharePoint Server 2010
Mike Watson
Sr. Product Manager
Quest Software
2
About Mike• Product Manager at Quest responsible for availability, scalability, and
manageability.• Previously instructor for the Microsoft Certified Master program on
several topics including Backup/Restore, HA, and DR.• Entrepreneur, Mad Scientist, and soon an Author.• Previously at Microsoft. Went from support to designing some of
Microsoft’s most critical services in just 5 years. • U.S. Army before that. Computers, Finance, Accounting, and Armor
(M1A2 Tank)
3
www.SharePointMadScientist.com
4
Agenda
• What’s new in SharePoint 2010– Better Architecture
– More Applications
– Command and Control
• SQL best practices
• Storage best practices
5
What’s Changed in SharePoint 2010
• More functionality out of the box
• Big change to services
• Bigger variety in workloads
• Harder to make recommendations
• Some lessons learned built in
6
SharePoint 2010: Bigger Than Ever!
7
But Wait! There’s More!
8
Services in SharePoint 2007
SSP (Profiles)
9
Services in SharePoint 2010 (a la carte)
10
11
12
Better Multi-Tenancy
IPSEC or
SSLSSL
13
Tenant Admin Page
14
Database Mirroring Support
• Support for automatic failover using SQL mirroring high availability mode
• Leverage failover partners for each database you create
• Read more about how this works on my blog http://www.sharepointmadscientist.com/Lists/Posts/Post.aspx?ID=46
– No automatic provisioning
– No automatic failover using high protection mode
– Keep database mirroring best practices in mind. Less than 50 database per instances... since we already have so many, you can see that can be a problem.
15
Database Mirroring with SharePoint 2010
16
Database Mirroring in SharePoint 2010
17
Demo• High Availability using Database Mirroring
18
Command & Control
• Throttling – Tell end users to leave you alone. Your busy!• Large List controls – tell end users they’re crazy trying to
make that query, but admins, no problem!• SharePoint designer – maybe not• Developer Dashboard – Learn just how bad your
developers are. • Sandboxing – More like prison for unsavory code.• SQL Resource Governor – The nuclear option!
19
Turn on the Developer Dashboard
• STSADM• C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\BIN>stsadm -o setproperty -pn developer-dashboard -pv ondemand
• Powershell• Run Powershell from the start menu as administrator by right clicking.• Execute a Dashboard.ps1 script file containing this:• • $ddSettings =
[Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings;
• $ddSettings.DisplayLevel = ‘OnDemand’;• $ddSettings.RequiredPermissions =’EmptyMask’;• $ddSettings.TraceEnabled = $true;• $ddSettings.Update()
• Display Options = “On”, "Off" or "OnDemand"
20
Large List Controls
Configurable List Throttling
And Thresholds
You control when and how much!
List throttling controls forces end users to create more efficient views with < x number of items.
21
SQL Best Practices
22
SQL Health = SharePoint Health!
Sub-optimal SQL perf will radiate to other components in the farm.
Database Management is Paramount!
23
Databases in SharePoint 2007
24
Databases in SharePoint 2010
25
• Use 64Bit!• Configure Memory
– Min & Max values = Total memory – 2GB for OS overhead
• On 32bit configure AWE – http://technet.microsoft.com/en-us/library/ms175581.aspx
• Configure Temp DB– Allocate 1 data file per processor core
• Pregrow databases & never autogrow• Align partitions
– 64KB or 256KB
• Use 64KB or larger multiple for RAID stripe size• Dedicate storage for SQL• Use RAID 10
Configure SQL to conform w/ best practices
26
Pregrow databases and never autogrow
27
Best Practices AnalyzerHealth Rules
Runs on a Timer Job
Create your own!
Repair Auto-
magically!
28
Demo• SQL Best Practices using SharePoint Health Analyzer
29
• Virtual is never as good as physical (sharing)• Some virtualization features don’t work well
– E.g. Resource pool allocation aka overcommit
• Virtualization introduces some artificial limitations to scaling up– Processor limitations per machine– Ability to leverage memory– Sharing across bottlenecks (hw bus, NIC)
• Some roles work better with virtualization than others…
Virtualization is Great But Be Careful!
30
31
Assign appropriate hardware to VM’sWeb App SQL
Processor
Minimum 2.5Ghz 2.5Ghz 1.4Ghz
Recommended >3Ghz Dual >2.5Ghz Dual >2.0Ghz
Best Practice 3.0 Ghz Quad 3.0Ghz Quad Dual 2.0 Quad
Memory
Minimum 2GB 2GB 512MB
Recommended >2GB 4GB >2GB
Best Practice 8GB 16GB 32GB
32
Storage Best Practices
33
Manage Storage Capacity
34
Temp Logs Search Data
Allocate as many disks as
needed to SQL
35
Think Disk IO! Not Disk Capacity!
36
Calculating Disk IO – An Example
37
Best Practices – SQL Disk IO
Allocate separate and dedicated disks with the following specifications:
* Raid 1 or variants (0+1, 1+0)
** Depends on type and amount of content being indexed
*** 2000 IOPS minimum. Plan on 1500 IOPS per simultaneous crawl. (e.g. 3 crawls = 4500 IOPS)
**** Use Raid 5 when redundancy needs are met with replication
38
Use RAID 10
39
Demo• Monitoring storage IO
40
Summary
• SharePoint 2010 is Big!• SharePoint 2010 = X…ability• SQL Optimization and Management is
Paramount!• & Storage Optimization too!• SharePoint scales out well. Adjust SQL
accordingly
41
Quest Solutions for SharePoint
Site Administrator for SharePoint
Understand, manage and secure
your SharePoint environment
Migration Manager for SharePoint
SharePoint to SharePoint migration
File Migrator for SharePoint
File shares to SharePoint migration
Recovery Manager for SharePoint
Granular SharePoint recovery for enterprise-
level needs
Quest Web Parts
Enable rapid development of
SharePoint applications
Public Folder Migrator for SharePoint
Exchange Public Folders to SharePoint migration
Notes Migrator for SharePoint
Notes application content to SharePoint migration
Quest SQL Server Solutions
Maximize SQL Server performance while
simplifying tasks and providing visibility and
control
Recommended
