what sql dbas need to know about sharepoint-kansas city, sept 2013
DESCRIPTION
With the number of deployments of SharePoint exponentially growing every day, as a DBA, it is very likely you are going to have SharePoint databases on SQL Servers you support. This session reviews SharePoint strictly from the SQL Server perspective. You will learn how SharePoint is optimized for SQL, how to properly manage and maintain the SharePoint databases, how to optimize the SQL configuration for SharePoint, what settings in SharePoint need to be changed or not changed to maintain SQL Server performance, supported methods for providing high availability and disaster recovery, and the part SharePoint and SQL each play in the Microsoft Business Intelligence story.TRANSCRIPT
What SQL DBA’s need to know about SharePoint
Presented by:
JD Wade, Lead SharePoint Consultant
Horizons Consulting
Mail: [email protected]
Blog: http://wadingthrough.com
LinkedIn: http://linkedin.com/in/jdwade
Twitter: @JDWade
Agenda•
SharePoint Primer
• Before Turning It Over
• Helping Out the SharePoint Admin & Yourself
• Performance Considerations
• The Kitchen Sink
•Remote BLOB Storage
•Availability and Disaster Recovery
•Access Services
• Business Intelligence
SharePoint
Database
Schema
SharePoint Primer
Single Business Productivity Platform leading to
common:
- End-user Experience
- Rich Integrated Capabilities
- Toolset and Development
- Deployment and Management
Users
TeamsCorporate Departments
Empowerment
Knowledge
Management
Portal
Regulatory
Compliance
Repository
Corporate
Web
Presence
Sales
Division
Portal Custom
SAP
Front-End Team “ABC”
Site
Project
“X” Site
Weekly
Issue
Tracking
Meeting
Business
Intelligence
Dashboard
R&D
Community
Geneva
Office
Site
Employee
Portal
Extranet
Collab
Site
Config
Content Service
Application
3rd Party
BI
Before Turning It Over
Minimums!
10GB 1TB
1,000 users 10,000 users
Recommended
<10GB 10GB-1TB 1-2TB
5-16TB2-5TB
>64GB64GB
32GB16GB8GB
SharePoint/Database
Client/Public
HOSTS
SQLIO
MS KB 2659143
Ready to Install SQL for SharePoint!
TempDB
Content
16GB
TempDB
Log
1GB
TempDB
Data
1GB
TempDB
Data
1GB
TempDB
Data
1GB
TempDB
Data
1GB4GB
Prod_ConfigDB
Prod_ContentDB_Portal
Prod_ContentDB_WebSite
Prod_ServApp_ManagedMetadata
Prod_ServApp_SearchAdmin
Prod_App_NintexWorkflow
Ready for SharePoint to be installed
.LDF
Data
Data
.MDFAdd
Content
Content Database Located on Hard Drive
Checkpoint
Data
Data
Full Recovery Model (Recommended)
.MDF .LDFAdd
Content
Content Database Located on Hard Drive
Checkpoint
Data
Data
Simple Recovery Model
Helping Out the
SharePoint Admin &
Yourself
SC
SC SC
SC
Content Database
SC
SC SC
SC
Content Database
SC
Content Database
100GB
SC
Content Database
200GB
SC
Content Database
2TB
SC
Content Database
16TB
SC
SC SC
SC
Content Database
SC
SC SC
SC
Content Database
Site Quotas Max Site Coll./DB
Index Columns
Make multiple views
Performance
Considerations
Data: 20 ms
Logs: 20 ms
Data: 10 ms
Logs: 10 ms
Data: 10 ms
Logs: 5 ms
TempDB Data Logs
Primary Filegroup
Data Data Data
Content Database
Data
Standard Environment
TempDB
Tran Logs
Search
Data File
Content
Data File
Read (Archive) Environment
TempDB
Tran Logs
Search
Data File
Content
Data File
The Kitchen Sink
Business
Intelligence
SharePoint
App Server
SharePoint SQL
SQL
SharePoint
Web Server
Classic Claims
SharePoint SQL
SQL
SharePoint 2010/2013
Service Apps
BCS
Excel Services
PerfPoint Srv.
Visio Services
Secure Store
Site Templates
BI Center
SharePoint
App Server
SharePoint
Web Server
SharePoint SQL
SQL
SharePoint 2010/2013
SQL 2008 & 2008 R2
Reporting Services
SharePoint
App Server
SharePoint
Web Server
SharePoint
App Server
SharePoint SQL
SQL
SharePoint
Web Server
Reporting Services
SharePoint 2010/2013
SQL 2008 & 2008 R2
SharePoint
App Server
SharePoint SQLSharePoint
Web Server
Reporting Services Local Mode
SharePoint 2010/2013
SQL 2008 R2
SharePoint SQL
SQL
SharePoint 2010/2013
SQL 2012
Reporting Services
SharePoint
App Server
SharePoint
Web Server
SharePoint
App Server
SharePoint SQL
SQL
SharePoint
Web Server
Reporting Services
SharePoint 2010
SQL 2012
SharePoint SQL
SharePoint 2010
SQL 2008 & 2008 R2
SQL 2012PowerPivot for SharePoint
SharePoint
App Server
SharePoint
Web Server
SQL
SharePoint 2013
SQL 2012 SP1
Reporting Services
SharePoint SQL
SSAS
SharePoint Integrated
Native Mode
SharePoint 2010/2013
SQL 2012 SP1
PowerPivot for SharePoint
SharePoint
App Server
SharePoint
Web Server
SharePoint 2010/2013
SQL 2012
Reporting Services
Kerberos
Protocol Transition
• Uses Protocol Transition (Domain limited)
(Constrained Only)
• Excel Services
• Visio Services
• PerformancePoint
• InfoPath Form Services
• SQL SSRS 2012
• Access Service 2013
• Does NOT Use Protocol Transition (Forest limited)
(Unconstrained or Constrained)
• SQL Reporting Services 2008 R2
• BCS
• Project Server
• Doesn’t usually require Kerberos
• PowerPivot for SharePoint Server
Srv1
Datamart
Srv2
Cubes
Srv3 Srv4
Web
Srv1
Datamart
Srv2
Cubes
Srv3 Srv4
Web
Srv1
Datamart
Srv2
Cubes
Srv3 Srv4
Web
FBA Kerberos
Srv1
Datamart
Srv2
Cubes
Srv3 Srv4
Web
References• SharePoint Conf 2009: SPC319: SQL Server Best Practices for SharePoint Deployments: Burzin
Patel, Senior Program Manager, Microsoft Corporation
• Database maintenance for SharePoint 2010 Products
http://technet.microsoft.com/en-us/library/cc262731(v=office.14).aspx
• Tuning SQL Server 2012 for SharePoint 2013 Jump Start
http://www.microsoftvirtualacademy.com/Content/ViewContent.aspx?et=2591&m=2586&ct=15858
Q & A
Notes
• Why are database changes not supported?
• Single data platform for all workloads
• Change for one may adversely affect another
• Upgrade and Servicing expects solid DB contract
• App logic is heavily dependent on DB specifics
• App enforces constraints and integrity!
• http://support.microsoft.com/kb/841057
• SharePoint manages its own name value pair (NVP) indexes
• There are four types of databases in a SharePoint farm
• Config
• Content
• Service Application
• Third-party/BI applications
• Over 20 databases in a standard SharePoint farm installation
• Database types and descriptions http://technet.microsoft.com/en-us/library/cc678868.aspx
SharePoint Primer
• SharePoint can use some functionality of Enterprise Edition
• Online Index Rebuild
• AlwaysOn Availability Groups (SQL 2012)
• Transparent Data Encryption
• Table Partitioning (SharePoint 2010)
• Snapshots
• Content Deployment
• Backup
• Remote BLOB Storage
• Resource Governor
• PowerPivot for SharePoint
• HA for SharePoint integrated Reporting Services
Server Setup
• Format database and log drives with 64KB allocation units. Up to 30% performance improvement
especially for backup and restore. Discuss pages and extents
• NTFS drives should always have 25% free space
• Heavy TempDB consumer, always do the following
• Split data files into one file for each core on server
• Total TempDB size should be 25% of the largest content database
• Equally distribute space to each data file
• Log files should be 25% of total database size
• Set AutoGrowth to fixed amount
Server Setup
• If SharePoint farm is Production or Tier 1, use lock pages in memory. If virtual and not critical, you
can leave off lock pages to get greater density on the host.
• If using lock pages, set maximum memory
• JD’s rule of thumb is leave 2GB available to OS and other apps for Dev/Test. But formula to really
use is
Server Setup
• Ensure SQL service account has Perform Volume Maintenance rights
• Set MAXDOP to 1
• SharePoint should be in its own instance
• Set Fill Factor to 80
• Set at Instance level, not at database
• Memory guidelines
• Up to about 10GB of content: 8 GB
• 10GB – 1TB: 16 GB
• 1TB – 2TB: 32 GB
• 2TB – 5TB: 64 GB
• Above 5TB: over 64GB can improve caching speed
Server Setup
• Server core minimum requirements
• Up to 10GB content or below 1,000 users: 4 cores
• Up to 1TB content or up to 10,000 users: 8 cores
• Work with SharePoint Admins to create a database naming scheme. Here are some examples:
• Prod_ConfigDB
• Prod_ContentDB_Portal
• Prod_ContentDB_WebSite
• Prod_ServApp_ManagedMetadata
• Prod_App_NintexWorkflow
• Manually deploy service apps, use AutoSPInstaller or pre-create databases to get rid of GUIDs in
database names
• http://technet.microsoft.com/en-us/library/cc262869(v=office.14).aspx
Server Setup
• Recommend the SharePoint Admin use SQL aliases. DNS CNAMES are OK. But with an alias,
you can specify the port number which improves performance and they are usually easier to
change.
• Recommended to use dual networks on SharePoint servers. One NIC is client facing and other
NIC is database facing.
• If more than four web servers, use a second SQL server. SharePoint loves connections.
Server Setup
• SharePoint ignores the model database. Either manage manually or setup scripted maintenance
plan for autogrowth settings. Set autogrow to a fixed size, not percentage. Set fixed size based on
expected total database size.
• Don’t rely on autogrow, Work with SP admins to pre-grow for expected use. Size databases
appropriately
• Autogrow should be just the insurance policy. Work with SharePoint administrator to appropriately
size content databases
• They can limit site collection size by using a “site quota”
• They can limit the number of site collections in a content databases using the “Maximum
Site” settings on the content database.
• Don’t forget about recycle bins (SC, site, and inside SC)
Database Management
• Site collections about 100GB should be in a content database by themselves. SharePoint Admins
can move site collections to different databases.
• Main purpose is for backup and recovery.
• In general, for normal general collaboration usage of SharePoint, site collections should not
exceed 200GB (soft limit)
• Good database sizing article: http://technet.microsoft.com/en-us/library/cc298801.aspx
• Remote BLOB storage does NOT change sizing guidelines
Database Management
• Database size support limits
• General Usage Scenarios: 200GB
• All Usage Scenarios: 2TB
• Disk subsystem should provide 0.25-2 IOPS per GB
• Plans developed for HA, DR, capacity, and performance
• Backup and Restore testing
• Document Archive Scenario: No limit
• Above requirements
• Less than 5% of content accessed/month
• Less than 1% of content modified/month
• 16TB is SharePoint’s limit for a content database because it can only use one filegroup
Database Management
• Use SQLIO to test storage prior to deployment
• http://www.microsoft.com/en-us/download/details.aspx?id=20163
• http://support.microsoft.com/kb/231619
• Do NOT enable auto-create statistics. Leave it alone. SharePoint sets it as needed. Can change
execution plans from one SQL server to another. SharePoint provides coded hints for queries as
needed.
• SharePoint 2013 has a new feature called Shredded Storage. Only saves deltas. 30-40%
reduction of space used for versioning.
• Check Recovery Model meets your requirements. Some are set to Full and others to Simple by
default.
• Recommend the configuration database be set to Simple.
• ConfigDB can only be restored if the SharePoint farm was offline when backed up.
Database Management
• Ideally, TempDB, Database and Transaction Logs should all be on separate drives.
• For content database performance improvement, you can use multiple data files
• Only create files in the primary filegroup
• Put each data file on separate drive
• Number of files should equal number of cores
• Not supported for other databases
• Disk Latency Requirements
• Low: 20 ms
• Middle: 10 ms
• High: 10 ms for data, 5 ms for logs
Operations and
Performance
• If performance improvements are needed for databases, in a standard environments, this is the
order of priority
• TempDB data and logs files
• Database transaction logs
• Search data files
• Content database data files
• For primary read (archive) environments, the order is
• TempDB data and logs files
• Search data files
• Content database data files
• Database transaction logs
Operations and
Performance
• SharePoint manages index fragmentation normally through SharePoint Health Analyzer rules. See
white paper in References for best discussion of index fragmentation. Some databases are not
monitored or sometimes manual intervention is needed.
• Schedule regular DBCC checks
• DBCC repair with data loss is NOT supported
• Maintain farm account as DBO for moves/restores
• Normally, don’t shrink databases except when bulk changes have been made
• So here is what you need to chat with your SharePoint admin about never changing
• Changing certain SharePoint thresholds will start SQL doing table locks rather than row
locks.
• Use indexed columns instead
Operations and
Performance
• Supported options for HA and DR in SharePoint
• Clustering
• Synchronous Mirroring (SharePoint is mirror aware)
• Synchronous AlwaysOn AG
• Asynchronous Mirroring
(some database types only)
• Asynchronous AlwaysOn AG
(some database types only)
• Log Shipping (some database types only)
• Supported HA/DR options for SP databases
http://technet.microsoft.com/en-us/library/jj841106.aspx
• SharePoint does not support the use of SQL transactional replication or merge replication
Availability and
Disaster Recovery
• When evaluating HA/DR options, remember
• Web server to database response time must be less than 1ms
• Network needs to support 1 gigabyte per second bandwidth
Availability and
Disaster Recovery
• Remote BLOB storage
• Does not change storage limits
• Requires SQL Enterprise
• Helps to lower costs because cheaper storage can be used to store large, read intensive BLOBs
• Uses either filestream or third-party provider
• Microsoft filestream provider does not support
• Encryption of BLOBs
• Using data compression
• Use when you many large BLOBs (over 256KB) for read-intensive or read-only access.
• Savings on lower cost storage should outweigh increased IT operations complexity
• Third party options have much more flexibility and can allow BLOBs greater than 2TB but at a cost
• 20ms response time for first byte requirement
Availability and
Disaster Recovery