1. SharePoint 2010 – High Availability
Considerations for SQL Server Backend
Roger Breu
Technical Specialist Data Platform
roger.breu@microsoft.com

2. Why Do You Need HA/DR?
Availability during planned downtime
Patching and service pack installations
Hardware and software upgrades/migrations
System reconfiguration
Database maintenance
Application upgrade
Protection against unplanned downtime
Human error is the number one cause of failure
Site disasters
Hardware malfunction
Data corruption
Software crash

3. Agenda
Why care about SQL Server?
SQL Server High Availability and Disaster Recovery
Configuration Best Practices
Optimizing Performance
Q&A

4. Why care about SQL Server?

5. SharePoint and SQL Server
SharePoint Admins and SQL DBA’s #!
SharePoint heavily dependent upon SQL
SQL DBA’s want control of DB’s
DBA’s think SharePoint = DB sprawl
SharePoint Admins want control of Farms
Yet, storage architecture and SQL Server
availability/scalability is critical to success

6. SharePoint and SQL Server
You need coordination to make it work!
SharePoint Admin and SQL DBA synchronize on
DB’s required, sizing, growth, capacity,
distribution, usage profiles, backup and
restore, HA and DR
DBA’s pre-construct and pre-size DB’s, monitor
via SQL
SharePoint Admin connects to DB’s, monitor
via CA
Coordinate backup and restore

7. SQL Server High Availability and
Disaster Recovery

8. SQL Server 2008 R2 HA/DR technologies
For SharePoint 2010
Database mirroring
Failover clustering
Transactional and peer-to-peer replication
Log shipping
Backup and restore

9. SQL Server Database Mirroring
Implemented on a per-database level
Transactions sent from Principal to Mirror
Principal and Mirror must be separate SQL
servers
Optional “witness” server for automatic
failover
Provides a “warm” standby in case of
failure

10. SQL Server Database Mirroring
3
Witness Server
Principal
Down!
2
4
I’m OK!
1 2
Encrypted Channel
5
5
Principal New
Mirror
Principal

11. SQL Server Database Mirroring
Three operation modes:
Operation Modes
Transfer
Mode Safety Level Failover
Mechanism
High
Full (no witness) Synchronous Manual
Safety/Protection
Full (with Manual and
High Availability Synchronous
witness) Automatic
High Performance Off Asynchronous Forced

12. SQL Server Failover Clustering
Implemented at the SQL Server Instance level
Shared cluster name and automatic failover
Disk subsystem is shared meaning single point
of failure SharePoint Web Front Ends
SQL Failover Server Cluster
Heartbeat
Node A Node B
Shared
Disk Array

13. SQL Server Failover Clustering /
2 datacenters
Disk subsystem can be replicated, no single
point of failure
Replication, especially synchronous will affect
performance SharePoint Web Front Ends
SQL Failover Server Cluster
Heartbeat
Node A Node B
Shared Shared
Disk Disk
Array Array

14. SQL Server Failover SQL Server High-
Clustering Availability Mirroring
Mirror takes over immediately upon failure.
Cluster member takes over immediately
Time to failover (faster than failover clustering, no move of
upon failure.
disks)
Failure is automatically detected by the
Failure is automatically detected by
database; SharePoint Server 2010 is aware
database nodes; SharePoint Server 2010
Steps required for failover? of the mirror location, if it has been
references the cluster so that failover is
configured correctly, so that failover is
seamless and automatic.
automatic.
Does not protect against failed storage, Protects against failed storage because
Protection against failed storage? because storage is shared between nodes both the principal and mirror database
in the cluster. servers write to local disks.
Storage types supported Shared storage direct-attached storage (DAS) possible
Principal, mirror, and witness servers must
Members of the cluster must be on the
Location requirements be on the same LAN (up to 1 millisecond
same subnet.
latency round trip).
SQL Server full recovery model
recommended. You can use the SQL Server
Recovery model simple recovery model, but the only Requires SQL Server full recovery model.
available recovery point if the cluster is lost
will be the last full/diff backup.
High-availability mirroring introduces
Some decrease in performance may occur transactional latency because it is
Performance overhead
while a failover is occurring. synchronous. It also requires additional
memory and processor overhead.
The operational burden is larger than
Operational burden Set up and maintained at the server level. clustering. Must be set up and maintained
for all databases.

15. HA Configuration

16. SQL Server Log Shipping
Backup-Restore based technology that
relies on transaction log files
Configurable frequency of shipping
No automatic failover
Allows you to replicate data to several
instances of SQL

17. DR Configuration

18. SharePoint 2010 – High Availability
Considerations for SQL Server Backend
DEMO
Failover Clustering +
Database Mirroring

19. HA Configuration
Verbier
Samnaun
DavosMirror
TDCore
Davos
ISCHGL
Lenzerheide

20. Configuration Best Practices
Sizing & Co.

21. Server Config
AntiVirus Config
Exclude SQL Server Data/Tlog/Backup Files
High Performance mode for database
Server
Default Setting: «Balanced Mode»
Recommendation: «High Performance»
no Energy Saving anymore

22. Storage
Recommended I/O Capacities
Type RAID level IOPS SAN Optimization
tempdb RAID-10 2 IOPS/GB Write optimized
Transaction Logs RAID-10 2 IOPS/GB Write optimized
Search Database RAID-10 2 IOPS/GB Read/Write optimized
Content
RAID-10* 0.75 IOPS/GB Read optimized
Databases
* Raid-5 can be used for static web content

23. Storage
Optimizing SQL Server I/O Subsystem
Ensure correct HBA driver and firmware versions
Use SQLIO.exe to measure I/O performance
Configure correct NTFS Allocation Unit Size
64K best; default (4K) can result in a 30% perf hit
To view: chkdsk <drive_letter>
To set: format E: /Q /FS:NTFS /A:64K /V:Data1 /Y
Ensure correct Windows “Sector Alignment”
Incorrect setting can result in up to 50% perf hit
64K most common. Windows 2008 aligns sectors by default
Whitepaper SQL CAT – Disk alignment Best Practices
http://msdn.microsoft.com/en-us/library/dd758814.aspx

24. Prioritizing Database Volumes
Separate database volumes into unique logical unit
numbers (LUNs) consisting of unique physical disk
spindles
Prioritize data among faster disks with ranking:
SQL TempDB data files and transaction log files
Database transaction log files
Search databases
Content databases
In a heavily read-oriented portal site, prioritize data over
logs
Separate out Search database transaction log from
content database transaction logs
Physical Storage Recommendations:
http://technet.microsoft.com/en-us/library/cc298801.aspx

25. SQL Server Setup
Use newest SQL Server version and Service Pack
Use the Sharepoint Collation Latin1_General_CI_AS_KS_WS
Setup SQL Server with Scripts
Install only needed components and features
Use SQL Aliases on WFE Servers to connect to
SQL Server Instance for easier migrations in
future
Ensure that SQL Server Service Account has
following privileges
Lock Pages in Memory
Perform Volume Maintenance Tasks

26. SQL Server Configuration
Use Traceflag 1117 (when using autogrow and multiple datafiles)
Max Server Memory (leave at least 2-3GB
to the OS)
Set default index fill factor = 80%
Enable Backup Compression default
Set MAXDOP = 1

27. TempDB Configuration
Number of Data files = number of cores
(min 4/max 8)
Data file sizes consistent across all data
files
Pregrow data and tlog files
Configure meaningful growth increments
Data files spread across unique LUNs
Separated from Content DB, Search DB, etc.

28. Content DB Configuration
Choose the appropriate recovery model
Only use Full recovery model if you:
Implement a backup strategy that includes regular (e.g. hourly)
backups of the transaction logs
Use a High Availability configuration, such as Log Shipping or
Database Mirroring
There is no point in using Bulk-Logged as SharePoint code does
not contain any BULK INSERT or SELECT INTO statements
Otherwise use Simple to facilitate manageability
Configure the model database accordingly to avoid having
to change the options of each new database after it was
created
Do not change any Auto Setting!
AUTO CREATE STATISTICS = FALSE
AUTO UPDATE STATISTICS = FALSE

29. Content Databases - Continued
Pre-construct and pre-size
Deploy using DBA-created databases
http://technet.microsoft.com/en-
us/library/cc262869.aspx
“Autogrow” feature on for safety
Use RAID 5 or RAID 10 LUNs depending on
your performance needs
Number of Data files = number of cores (in
primary filegroup)
General SQL Server Best Practice would be to have
only master data file (mdf) in primary filegroup
and add additional files with a secondary filegroup
Tlog File = 1 (one is enough as it is
sequentially written)

30. SharePoint 2010 – High Availability
Considerations for SQL Server Backend
DEMO
SQL Server Configuration
Database Growth

31. Optimizing Performance

32. Optimize your existing
environments
Check at least for initial file sizes and
growth increments
Check for large transactionlog files
Use DBCC Loginfo to get an idea on the
internal fragmentation level of your
transactionlog files
Lower fragmentation leads to more
performacne, faster failover, faster restores

33. Maintenance in General
Physical Volume File Fragmentation:
IS NOT NEEDED If you work with best practices like presizing and
good growth increments
Absolutely recommended reading:
Database Maintenance for Microsoft
SharePoint 2010 Products
http://www.microsoft.com/downloads/details.aspx?FamilyID=246DBCA
0-F03C-4DFF-A1B9-F510F7FC8A6A&amp;amp;displaylang=e

34. Databases Maintenance
Do’s
Have reliable backups for all databases before
implementing maintenance operations
Check for and repair consistency errors by using
DBCC CHECKDB
Defragment indexes by either reorganizing them or
rebuilding them (Maintenance Plan or custom
scripts), or use the dbo.proc_DefragmentIndices
procedure
Update statistics
In a managed environment use standardized scripts
for all databases and disable Database Maintenance
Health Analyzer Rules

35. Databases Maintenance
Don'ts
Drop and re-create indexes
Rebuild indexes or run consistency checks during
business hours
Set fill factor for individual tables or indexes
Auto-shrink databases
Shrink databases manually unless you really need to
DBCC Checkdb REPAIR_ALLOW_DATA_LOSS not
supported (REPAIR_REBUILD supported, but not
always possible)

36. SharePoint 2010 – High Availability
Considerations for SQL Server Backend
DEMO
How to check if
everything is healthy and
optimized?

37. Use SQL Server Enterprise Edition
SQL Server 2008 R2 and SharePoint 2010 Better together WP:
http://technet.microsoft.com/en-us/library/cc990273.aspx
Online Operations (Index Rebuilds, Page/File Restore)
Faster Recovery/Failover (more redo threads, partial database
availability)
Asynchronous Database Mirroring for DR
Hot Add CPU/RAM (important for dynamic virtual environments)
Unlimited Virtualization (with SA) and Application License Mobility
Compression for Search DB
Transparent Database Encryption
Resource Governor
Business Intelligence
Remote Blob Storage
More than 2 Cluster Nodes

38. Q&A

39. Additional Resources
High Availability and Disaster Recovery for SharePoint
Server 2010: http://technet.microsoft.com/en-
us/sharepoint/ff601831.aspx
Boundaries and Limits Document:
http://technet.microsoft.com/en-us/library/cc262787.aspx
Performance and capacity management (SharePoint Server
2010):http://technet.microsoft.com/en-
us/library/cc262971.aspx
SQL Server and storage (SharePoint Server 2010):
http://technet.microsoft.com/en-us/library/cc263420.aspx
HP SharePoint Sizer:
http://sizers.houston.hp.com/sb/installs/SharePoint2010Size
r.zip

40. © 2010 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.