What SQL DBAs need to know about SharePoint

JD Wade, MCITPSharePoint ConsultantHorizons ConsultingTwitter: http://twitter.com/jdwadeBlog: http://wadingthrough.com

Why, oh why, oh why?

Single Platform – Power and Challenge!

Single Business Productivity Platform leading to common:- End-user Experience- Rich Integrated Capabilities- Toolset and Development- Deployment and Management

Users

TeamsCorporate Departments

Empowerment

KnowledgeManagementPortal

RegulatoryComplianceRepository

CorporateWebPresence

SalesDivisionPortal Custom

SAPFront-End Team “ABC”

SiteProject“X” Site

Weekly IssueTrackingMeeting

BusinessIntelligenceDashboard

R&DCommunity

GenevaOfficeSite

EmployeePortal

ExtranetCollabSite

SQL ImplementationCommonly Perceived Gaps

SharePoint tables are too wide, wraps rowsSharePoint manages its own (NVP) indexesSharePoint adds force-order, query hintsMissing indexes for common operationsExcessive use of Dynamic queriesNo SQL Referential Integrity OR key constraintsDBCC with data loss not supportedMissing integration of Back-up/Restore

Why are DB Changes Not Supported?

Single data platform for all workloads

Change for one may adversely affect anotherUpgrade and Servicing expects solid DB contractApp logic is heavily dependent on DB specificsApp enforces constraints and integrity!

Workloads with conflicting platform needs

CorpWeb

Presence

Team Collab Site

• Mostly Read• Article Pages• Search and structured

queries

• Read Writes• Office Documents• Organization and

ad-hoc queries

Users

Empowerment

Storage

Storage5 Key Points to Consider

HBA

SQL ServerHBA

tempdb tempdb T-log

DB T-logs Content DBs Search DB

App Server App Server App Server…

1

2 3

45

StorageOptimizing SQL Server I/O Subsystem

Ensure correct HBA driver and firmware versionsUse SQLIO.exe to measure I/O performanceConfigure correct NTFS Allocation Unit Size

64K best; default (4K) can result in a 30% perf hit

To view: chkdsk <drive_letter>

Ensure correct Windows “Sector Alignment”Incorrect setting can result in up to 50% perf hit

Use diskpart to check and set alignment

64K most common. Windows 2008 aligns sectors by default

Free space on NTFS partition should be > 25%

StorageDatabase Configuration

Recommended database file placement priority (fastest to slowest drive)

tempdb data and t-log filesDb transaction log filesSearch db data filesContent db data files

In a heavily read-oriented portal site, prioritize data over logs.Place tempdb, Content db and t-logs on separate LUNsUse multiple data files for Content and Search dbs

Distribute equi-sized data files across separate disks# of data files should be <= # of processor coresMultiple data files are not supported for other dbs

Place SharePoint Search crawl and query processing tables on separate spindles

StorageDatabase Sizing

Site Collections > 15GB, use SQL BackupsLimit Content DBs to 100 GB (soft limit)

If larger consider differential backups usingSQL or DPM

Size SQL Server data files appropriatelyPre-allocate data file to cover anticipated size of Content db

Rely on SQL ‘Autogrow’ only as a catastrophic insurance policy

Set SQL ‘Autogrow’ to fixed value appropriate for size of db

Use dedicated database for large Site Collections (> 50GB)Configure tempdb data files = No of proc coresConfigure tempdb to be at least 10% (25% preferred) of total Content db size, or the size of the largest table - whichever is greater

Configuration

Configuration Typical Deployment Sizes

Metric Small Medium Large

Content db size < 50GB 50GB > 50GB

# of Content dbs < 20 20 > 20

# of concurrent requests to SQL < 200 200 > 200

# of Users < 1000 1000 > 1000

# of items in regularly accessed list < 2000 2000 > 2000

# of columns in regularly accessed list < 20 20 > 20

Resource Small Medium Large

Recommended DB server memory 8 GB + 16 GB + 32 GB +

Processor L2 cache 2 MB > 2 MB > 2MB

Bus bandwidth Medium High High

Disks latencies (msec) < 20 < 10< 10 (data)< 5 (T-log)

Network Gigabit Gigabit Gigabit

Network latency (msec) < 1 < 1 < 1

Configuration Recommended Capacities

ConfigurationProcessors

Deploy on 64-bit, especially if >1000 users, or >100 GB of data

Use 64-bit SQL Server if using 64-bit OS

IA-64 only supported on db tier, not on app tier

Set ‘Max Server Memory’ SQL Max Memory = TotalPhyMem

- (NumOfSQLThreads * ThreadStackSize)- (1GB * CEILING(NumOfCores/4))- (Any mem required for ‘other’ apps)

NumOfSQLThreads = 256 + (NumOfProcessors*- 4) * 8

ThreadStackSize = 1 MB on x862 MB on 64-bit (x64)4 MB on 64-bit (IA64)

On 64-bit use LPiM privilege for SQL Server accountIf using SQL Std edition need following CU + trace flag

CU2 for SQL Server 2008 SP1 (KBA 970315)CU4 for SQL Server 2005 SP3 (KBA 970279)

Configuration Memory

* If NumOfProcessors > 4, else 0.

ConfigurationUse SQL Server connection alias

Simplifies redirecting WFEs to a different db instance

Do not modify SPT schemaNo new columns orindexes permittedUse SharePoint toolsto index columns

Test use of MAXDOP = 1

Separate instance for SharePoint Databases

Set Fill Factor to 70

SharePoint ignores Model Autogrow settings

Configuration

Maintenance

Monitor SQL Server performance regularly

Check integrity of the database routinely

DBCC CHECKDBCan use REPAIR_REBUILD option to fix errors (not always possible)

REPAIR_ALLOW_DATA_LOSS not supportedTime consuming operation, run during non-peak hoursFor very large DBs consider using option MAXDOP=1

Defragment physical files

Maintain farm account as DBO for moves/restores

Maintenance

Content and Search dbs most susceptibleRebuild / Reorganize indexes to eliminate fragmentation

Reorganize index when fragmentation between 10-70%Rebuild index when fragmentation > 70%

Existing index options used before the rebuild operation are not restored. Issue resolved in SQL Server 2005 SP2 and higher

Use sys.dm_db_index_physical_stats to measureMore accurate than DBCC SHOWCONTIG, often reports higher fragmentation numbers

Auto-defrag only available in MOSS 2007 SP2 and for Content dbs but may need manual defragmentation

Database Maintenance for SharePoint white paper

MaintenanceFragmentation

MaintenanceShrinking Database Size

Only shrink Content databases, not othersOnly perform if free space > 50% (after content reorg)Do not perform as part of maintenance planAllocate 10-20% growth allowance when determining target size

High Availability

High availability options supported:Failover Clustering (local & stretch clusters)Database mirroring (Sync & Async)

Log Shipping often used in conjunction to provide disaster recovery

High AvailabilityDatabase Mirroring Configurations

Secondary Server FarmPrimary Server Farm

Principal instance Mirror instance

Web, query and application server

Web, query and application server

Index and application server

SQL Server 1 SQL Server 2

High safety or

High performancemirroring

Configuration

Central administration

WSS search

SSP search

SSP content

SSP

Content

Configuration

Central administration

WSS search

SSP Search

Content

Web, query and application server

Web, query and application server

Index and application server

SSP

SSP Content

DB Mirroring within farm(Synchronous)

DB Mirroring across farms(Asynchronous)

Secondary Server FarmPrimary Server Farm

Principal instance Mirror instance

Web, query and application server

Web, query and application server

Index and application server

SQL Server 1 SQL Server 2

High safety or

High performancemirroring

Configuration

Central administration

WSS search

SSP search

SSP content

SSP

Content

Configuration

Central administration

WSS search

SSP Search

Content

Web, query and application server

Web, query and application server

Index and application server

SSP

SSP Content

Needs to be individually configured for each SPT db

Requires Full Recovery model

Both Synchronous and Asynchronous modes supported

Synchronous DBM mode with witness server recommended for high availability

Transfer SPT logins from Primary to Mirror serverScript available in KBA 918992

DB Mirroring SQL end-points should be encrypted when channel is not secured by other means

High AvailabilityDatabase Mirroring

Only supported on SQL Server Standard and Enterprise editions

Standard edition only supports Synchronous mirroringOn Standard edition 1 redo thread per db; on enterprise edition 1 redo thread per db per 4 coresWitness server can run on SQL Express

Several improvements in SQL Server 2008 DBMLog stream compressionAutomatic Page RepairPending send buffers limit increased from 3 to 64

High AvailabilityDatabase Mirroring

Asynchronous DBM can be used to provide redundancy for Content dbs across farms

Does not guarantee consistency

DBs that cannot be Async mirroredConfiguration & Central Admin Content dbs

Contain location specific references, must be rebuild at mirror site

SSP dbs only if using SearchSearch requires sync between SSP dbs, Search db, and index (index file cannot be mirrored)

High AvailabilityAsynchronous Mirroring

Upcoming Attractions

Improved Reporting Services in SharePoint integrated mode

Easier installExtract data from SharePoint 2007 or 2010 listsSSRS is reporting engine for SharePoint Access Services reporting

PowerPivot for SharePoint“SSAS in SharePoint integrated mode”

SQL 2008 R2SharePoint Integration

Support for RBS using SQL FilestreamRestore items directly from SQL database

AvePoint add-onSupport for SQL Mirroring built-inAccess ServicesPerformancePoint built-in

SharePoint 2010

Q & A

Primary slide content with modifications from:SharePoint Conference 2009SPC319: SQL Server Best Practices for SharePoint Deployments

Burzin Patel, Senior Program ManagerMicrosoft Corporation

Database Maintenance for SharePoint white paperhttp://technet.microsoft.com/en-us/library/cc262731.aspx

Sources