Optimizing SQL Server 2012 for
SharePoint 2013
SharePoint Saturday/Friday, Honolulu
March 27, 2015
With Mahalo to our sponsors:
Mahalo!
About the Speaker
•
•
•
•
•
•
•
•
Brian Alderman (MCT / Author / Speaker / Consultant)
CBT Nuggets – www.cbtnuggets.com
brian.alderman@cbtnuggets.com
@brianalderman @cbtnuggets
www.microtechpoint.com – Brian’s Blog
Co-Author SharePoint 2010 Administrator’s Companion
Co-Author SharePoint 2013 Administration Inside Out
Enjoy Travel and Golf
Over 300 Courses and 4500 Hours of Content
Microsoft, Cisco, Juniper, CompTIA, VMWare, PMP, and More
Laptop, Tablet, or Mobile Device
Under $85 a Month
SharePoint Super End User Trifecta:
SharePoint 2013 Site Collection Administration
SharePoint 2013 Site Owners
SharePoint 2013 Collaboration Expert
Managing Office 365 Identities and Requirements (70-346 Exam)
Free Seven Day Trial
Mulletville, Vermont
Garden of the Gods with Pikes Peak
Arizona Golf
19th Hole
Session Agenda
SQL Server Introduction
SharePoint and SQL Server Integration
Demo: SQL Server Configurations to Optimize SharePoint
SQL Server Instance Configurations
Database Configurations
Avoiding Ginormous Transaction Logs
SQL Server Best Practices for Optimizing SharePoint
SQL Server Introduction
SQL Server Introduction
Multiple Instances of SQL Server on One Server
One Default Instance with Multiple Name Instances
Each Instance Managed Individually
Share SQL Server Management Tools
Each Instance Shares Windows Server Resources
Two Types of Databases: System and User
Minimum of Two Files Created Per Database
MDF (Master Data File)
LDF (Transaction Log File)
NDF (Optional for Extending Database)
SQL Server Transaction Log Process
1
Modification is sent by
application to SQL Server
Modification is recorded
in transaction log on disk
3
Buffer
Cache
2
Data pages are located in,
or read into the buffer cache
and then modified
4
Later, CHECKPOINT writes
dirty pages to database
Working with Recovery Models
Recovery Model
Description
Simple
Does NOT permit transaction log (t-log)
backups. Automatically truncates log to
reduce space requirements
Full
Requires LOG BACKUPS to manage t-log
space requirements. Avoids data loss if
damaged or missing database file occurs.
Permits point-in-time recovery.
Bulk Logged
Requires log backups to manage t-log
space requirements. Improves
performance during bulk copy
operations. Reduces t-log space usage by
using minimal logging of operations.
Simple Recovery Model
1
Modification is sent by
application to SQL Server
Modification is recorded
3 in transaction log on disk
Buffer
Cache
2
Data pages are located in,
or read into, the buffer cache
and then modified
4
Later, CHECKPOINT writes
dirty pages to database
and FLUSHES transactions
from T-log.
Full Recovery Model
1
Modification is sent by
application to SQL Server
Modification is recorded
3 in transaction log on disk
Buffer
Cache
2
Data pages are located in,
or read into, the buffer cache
and then modified
4
Later, CHECKPOINT writes
dirty pages to database
but RETAINS transactions
in T-log.
SQL Server Instance Databases
Master
Configuration Database of SQL Server Instance
Msdb
Storage of SQL Server Automation Configuration Information
Resource (Hidden)
Read-Only Database Containing All SQL Server System Objects
Tempdb
Temporary Work Storage Area
Model
Template Used to Create All New Databases
SharePoint and SQL Server
Integration
SharePoint and SQL Server Integration
All SQL Server Versions and SharePoint Versions
Large Majority of SharePoint Data Stored in SQL Server
Farm Configuration Information Stored in SharePoint
Configuration Database in SQL Server
Central Administration Content Stored in Own Content Database
in SQL Server (Blog on how to rename)
Every Web Application Minimum of One Content Database (Blog
on how to rename)
Most Service Applications Have at Least One Database
SharePoint Content Databases
SharePoint Farm Creates Several Databases (20 DB’s if Spousal
Installation and Run Configuration Wizard)
Content Database Contains Several Site Collections
Site Collection Resides in Only One Content Database
Use Full Recovery Model on Production Databases
Control Size of Database (Recommended 200GB)
Site Collection Quota Templates
Maximum Number of Site Collections per Database
Web Application
200GB
200GB
200GB
200GB
250
250
250
250
Site Collections
Site Collections
Site Collections
Site Collections
Project
Sites
Department
Sites
HR
Sites
Marketing
Sites
750mb X 250 = 187,500mb / 1024 = 183gb
SQL Server Instance Configuration
Default File Locations (Move off C:\ Drive)
Minimum and Maximum Memory Settings
Max Degree of Parallelism (MAXDOP) Set to 1
Don’t Enable Auto_Create or Auto_Update Statistics on SP DB’s
Have DBA Create Alias for SharePoint SQL Instance
Not Used by FAST Search SKU (SharePoint 2010, try DNS Alias)
SharePoint Collation – Latin1_General_CI_AS_KS_WS
During Installation of SQL Server Hosting SharePoint Content
During Creation of Content Database in SQL Server
SQL Server Database Configuration
Model Database File Settings
Increase Initial Size of Data and Log Files
Increase Autogrowth Settings (Use MB not %)
Tempdb Database File Settings
Increase Initial Size of Data and Log Files
Increase Autogrowth Settings (Use MB not %)
Use Simple Recovery Model
Place Files on Different Drive from Content Databases
Demo
SQL Server Configurations
Avoiding Ginormous
Transaction Logs
Monday
Sunday
mdf
ldf
Full Backup
(2)
mdf
Wednesday
Tuesday
ldf
mdf
Differential
ldf
Differential
mdf
ldf
Differential
(3)
BACKUP LOG DB_Name TO D:\SQLBackups\Weekly_T_Log.Bak WITH INIT
You Lose mdf file of database on Thursday at 4:00pm
(1) BACKUP LOG DB_Name TO D:\SQLBackups\TempBackup.Bak WITH NORECOVERY
(4) RESTORE LOG FROM D:\SQLBackups\TempBackup.Bak
Best Practices for Optimizing
SharePoint
Best Practices for SharePoint’s SQL Server
Dedicated SQL Server Instance / Server
No Spousal Installations of SQL Server or SharePoint
Database Size Should Not Exceed 200GB
Max Degree of Parallelism (MAXDOP) Set to 1
Create SQL Alias for SQL Server SharePoint Instance
Modify Model System Database Settings
Avoid Auto-Shrinking Databases
Use Database Autogrowth Sparingly
Reduces Fragmentation
Improves Data Entry Performance
Best Practices for SharePoint’s SQL Server
Spread Data Files and Transaction Log Files Across Multiple Drives
or Locate them on RAID 5/10
Create Multiple Tempdb Files on Multiple Drives or RAID 10 for
Drive Hosting Tempdb Files
Generate Database Maintenance Plans
Defragment Drives Containing Content Database Files
Don’t Rebuild or Manage Indexes of SharePoint DB’s
Perform Regular Backups of Database and T-Logs
Continuously Monitor SQL Server Storage and Performance
Perform DBCC CHECKDB Operations Regularly
Just Say NO to Simple Recovery Model
Thank You for Attending
Mahalo for Attending