What SQL DBA’s need to know about SharePoint

Presented by:

JD Wade, Lead SharePoint Consultant

Horizons Consulting

Mail: jd.wade@hrizns.com

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

• Availability and Disaster Recovery

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

Use Multiple Networks (Client versus Backend)

Use 64KB allocation units

25% Free Space

SQLIO

Improves Database File Size Changes

Use these two settings together

MS KB 2659143

SQL Enterprise Options Usable by SharePoint

• Online Index Rebuild

• AlwaysOn Availability Groups

• Transparent Data Encryption

• Table Partitioning (SharePoint 2010)

• Snapshots

• Remote BLOB Storage

• Resource Governor

• PowerPivot for SharePoint

• HA for SP integrated SSRS

Ready to Install SQL for SharePoint!

SQL Server Instance Settings

TempDB

Content

16GB

TempDB

Log

1GB

TempDB

Data

1GB

TempDB

Data

1GB

TempDB

Data

1GB

TempDB

Data

1GB4GB

1 SQL per 4 Web Servers

DNS CNAMES

Aliases

SQL Aliases

Prod_ConfigDB

Prod_ContentDB_Portal

Prod_ContentDB_WebSite

Prod_ServApp_ManagedMetadata

Prod_ServApp_SearchAdmin

Prod_App_NintexWorkflow

Use a naming standard

http://autospinstaller.codeplex.com

http://autospinstallergui.codeplex.com

Ready for SharePoint to be installed

Model database ignored

Autogrowth is insurance only

Check recovery model

Helping Out the

SharePoint Admin &

Yourself

SC

SC SC

SC

Content Database

SC

SC SC

SC

Content Database

Typical Content Database

SC

Content Database

100GB

Likes to run solo

SC

Content Database

200GB

Any bigger and needs to be on a diet

SC

Content Database

2TB

All Usage Scenarios

SC

Content Database

16TB

Hard Limit

SC

SC SC

SC

Content Database

SC

SC SC

SC

Content Database

Site Quotas Max Site Coll./DB

Shredded Storage

Indexes

Statistics

DBCC CHECKDB ALTER AUTHORIZATION

Shrink database = BAD Use Backup Compression

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

Disk Latency Requirements

TempDB Data Logs

Use Separate Drive

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 BLOB

Native Remote BLOB Storage

Third-Party Remote BLOB Storage

High Availability

Disaster Recovery

• 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)

Q & Ahttp://wadinghthrough.com/presentations

http://www.hrizns.com

http://twitter.com/jdwade

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