Optimizing SQL Server 2008

For blazing fast SharePoint sites

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

Agenda

• Quick review of database basics

• Optimize the server

• Optimize tempdb

• Optimize Content DBs

• Scaling out

• Best Practices

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

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

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

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

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

OPTIMIZING SQL SERVER

Demo

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

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

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

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 DBFor more, see http://slidesha.re/t1xnxD

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

SIZE AFFECTS PERFORMANCE

Demo

Book giveaway

• What is the recommended size when

configuring tempdb?

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

Scaling storage

• Multiple storage arrays (RAID 1+0)

• Break out into multiple LUNs

• Add additional data files to DB, one per

array

• Advice

● Many smaller drives >

fewer larger ones

● RAID 1+0 > RAID 5

Data

\SP_DocCenter_1.mdf

\SP_DocCenter_2.ndf

\SP_DocCenter_3.ndf

\SP_DocCenter_4.ndf

\SP_DocCenter.ldf Log

F:

G:

H:

I:

J:

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

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

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

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

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

Book giveaway

• What are the three primary types of

databases that SharePoint uses?

randy.williams@avepoint.com

http://linkd.in/plEEb1

@tweetraw

Questions?

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)

We want your feedback!

Use this QR code or visit:http://sps.la/feedback

Silver Sponsors: