Sql best practices for SharePoint 2010

SQL Server Best Practice für SharePoint 2010

René Balzano

Technology Solutions Professional Data Platform, Microsoft Switzerland

ADVIS AfterWorkShop vom 30. März 2011

Slide 2 | Best Practice für SharePoint, März 2011

Themenfokus: SharePoint-Performance

Sicherstellen der hohen Performance einer SharePoint-

Infrastruktur

Gewährleisten der Skalierbarkeit ohne

Performanceverlust bezüglich Datenmenge und

Zugriffshäufigkeit

Messen und Überwachen dieser Qualitätsmerkmale

Hohe SharePoint-Performance wird primär durch hohe

SQL Server-Performance erreicht

SQL Server-Performance wird primär durch Disk-

Zugriffszeiten bestimmt


Themen

Installation und Konfiguration von SQL Server für den

Betrieb von SharePoint 2010

Bereitstellen und Warten von Datenbanken einer

SharePoint-Farm

Überwachungsmethoden und elementare

Performanceindikatoren

Nutzen von SQL Server Features für Wartung,

Überwachung und Performanceoptimierung


Thema 1




SharePoint-Farm






FarmAdmin & DBA:

Zwei getrennte Aufgabenbereiche!

SQL Server DBA Erzeugt und konfiguriert Datenbanken, überwacht diese

Entscheidet über Storagearchitektur, Dateilayout, Datenbankkonfiguration

Zwei wichtige Werkzeuge: SSMS, PerfMon

SharePoint Farm Admin Verbindet Farm und Site Collections mit vorkonfigurierten Datenbanken,

betreibt SharePoint darin

Entscheidet über Farmarchitektur, Services, Site Collections

Zwei wichtige Werkzeuge: CentralAdmin, PowerShell

Backup und Restore als gemeinsam koordinierter Effort

SQL Server Konfiguration


Best Practice 1a)

Für das Konfigurieren von SQL Server und das Erstellen von SharePoint-

Content-DB nicht die SharePoint-Standarddialoge verwenden

SQL Server manuell durch den SQL Server-DBA konfigurieren lassen

SharePoint-Content-DB manuell oder automatisiert durch den SQL

Server-DBA erstellen lassen

Erst, nachdem eine leere Content-DB bereitgestellt wurde, diese durch

den Farm Admin mit einer SharePoint-Farm verbinden lassen

Farm Admin & DBA SQL Server Konfiguration


DB-Dateilayout:

Verteilen!

Die Dateien der SQL Server-

Datenbanken weisen

unterschiedliche Nutzungs-

profile auf

Der Zugriff auf viele dieser

Dateien erfolgt gleichzeitig

und konkurrenziert sich

In hochperformanten

SQL Server-Anwendungen

sind diese Dateien auf

unabhängige LUN (Partitionen,

Spindeln, ...) verteilt



Best Practice 1b)

Für diese SQL Server-Datenbankdateien je separate LUN/Spindeln

belegen:

• tempdb Data (.mdf/.ndf) und Log (.ldf)

• Transaktionslog von Content-Datenbanken (.ldf)

• Daten von Search-Datenbanken (.mdf/.ndf)

• Transaktionslog von Search-Datenbanken (.ldf)

• Daten von Content-Datenbanken (.mdf/.ndf)

Die schnellsten Disk-Subsysteme gemäss der obigen Prioritätenfolge

belegen

DB-Dateilayout SQL Server Konfiguration


Disk-Performance:

Dedizierte IOPS sicherstellen!

Problematisch Disk-Subsysteme, welche durch mehrere Dienste und Applikationen

genutzt werden und nicht exklusiv für SQL Server zur Verfügung stehen

SAN-Architekturen, die unabhängig von den darauf zugreifenden

Diensten und Applikationen verwaltet werden (Konflikt DBA / SAN-Admin)

Ideal Ein Disk-Subsystem bzw. eine SAN-Infrastruktur pro Anwendung, z.B. für

die Datenhaltung von SQL Server für eine SharePoint-Umgebung

Pragmatisch IOPS (Disk I/O per Second) beim SAN-Admin 'bestellen' und periodisch

selber verifizieren



Best Practice 1c)

IOPS sicherstellen

Berechnungsbeispiel: 10 x Fibre Ch. 15K Disk = 10 x 200 IOPS = 2'000

IOPS -> 2'000 IOPS / (0.75 IOPS pro GB) = 2.6 TB Content

Leistung messen (vorab sowie periodisch im Betrieb): SQLIO.EXE

Commandline-Werkzeug für das Erzeugen und Messen typischer SQL

Server-Diskzugriffsprofile (Download-URL im Anhang)

Disk-Performance 1. SQL Server Konfiguration

Dateityp RAID Level IOPS SAN Optimierung

tempdb RAID 10 2 IOPS/GB Write optimized

Transaktionslog (ldf) RAID 10 2 IOPS/GB Write optimized

Search-DB (mdf, ndf) RAID 10 2 IOPS/GB Read/Write optimized

Content-DB (mdf, ndf) RAID 10 (RAID 5

bei statischem Inh.) 0.75

IOPS/GB Read optimized


Disk-Subsystem optimieren 1. SQL Server Konfiguration

Best Practice 1d)

NTFS Allocation Unit Size auf 64k setzen = SQL Server Extent Size

• Bis 30% Performanceeinbusse bei Defaulteinstellung (4k)

Sector Alignment bei 64k (128k, 256k, 1024k) sicherstellen

• Bis 50% Performanceeinbusse bei Misalignment

• Mit Windows 2008 oder höher partitioniert: Automatisch richtig


SQL Server Installation optimieren 1. SQL Server Konfiguration

Best Practice 1e) tempdb

• Anzahl DB-Dateien (mdf, ndf) = Anzahl Prozessorkerne, jedoch max. 8 (effektiv auch wenn auf gleicher Partition abgelegt)

• SQL Server 2008 und höher mit Traceflag -T1117 starten (Wachstum der DB-Dateien erfolgt so synchron)

• Autogrow zwar einstellen (MB, keine %), aber möglichst vermeiden: tempdb-Grösse nach Einlaufzeit messen, dann als Initialgrösse festsetzen

• Falls pagelatch Counter ansteigt: Transaktionslog auf separate Partition

Service Account

• Lock Pages in Memory Privileg zuweisen: Verhindert OS Paging für von SQL Server belegten Arbeitsspeicher

• Perform Volume Maintenance Tasks Privileg zuweisen: Verhindert Zero File Initialization für Datenbankdateien

Collation

• Bei SQL Server Installation Latin1_General_CI_AS_KS_WS Collation verwenden


SQL Server Konfiguration optimieren 1. SQL Server Konfiguration

Best Practice 1f)

MAX SERVER MEMORY festlegen (sp_configure)

• Faustregel: OS Memory - (2-3 GB)

max degree of parallelism auf 1 setzen (sp_configure)

• Für individuelle Tasks verändern (z.B. Index Rebuild mit MAXDOP 0)

FILL FACTOR auf 70 (%) setzen (sp_configure)

• Reduziert initialen Füllgrad von Disk-Pages, vermindert Fragmentierung

Keine AUTO-Einstellungen verändern


Zusammenfassung:

Best Practice der SQL Server Konfiguration

1a) Rollenteilung SQL DBA und Farm Admin

1b) Datenbank-Dateilayout (System und Content)

1c) Anforderungen Disk-Performance

1d) Optimierung Disk-Subystem

1e) Optimierung SQL Server Installation

1f) Optimierung SQL Server Konfiguration


Thema 2




SharePoint-Farm






Das manuelle Verändern von SQL Server-Datenbanken,

welche Teil einer SharePoint-Infrastruktur sind, wird durch

den Microsoft-Support derzeit nicht unterstützt

Das automatische Erzeugen von Content-Datenbanken

durch die SharePoint-Dialoge berücksichtigt nicht alle

Best Practice-Empfehlungen aus SQL Server-Optik

Content-Datenbanken dürfen leer angelegt und manuell

konfiguriert werden, bevor man sie mit SharePoint

verbindet

Content-Datenbanken bereitstellen:

Manuell anlegen!

2. SharePoint- Datenbanken


Content-Datenbanken bereitstellen

2. SharePoint- Datenbanken

Best Practice 2a)

Content-Datenbanken 'manuell' per Transact-SQL-Script erstellen

• Optimales Dateilayout und weitere Einstellungen sicherstellen

• Datenbanken erst anschliessend via SharePoint-Dialog mit einer Farm

verbinden


Content-Datenbanken optimieren 2. SharePoint- Datenbanken

Best Practice 2b)

Pro Site Collection eine separate Datenbank verwenden (Handhabung)

Pro Prozessorkern eine Datenbankdatei (mdf, ldf) anlegen, maximal 8

• nur für Content- und Search-DB, vgl. tempdb

• Transaktionslog benötigt immer nur 1 Datei

Auf Zielgrösse vordimensionieren, trotzdem Autogrow aktivieren (keine %)

Recovery Model auf FULL oder SIMPLE setzen

• Wahl gemäss angewendetem Backups- und Replikationsszenario

Search-Datenbank komprimieren (bedingt SQL Server Enterprise Edition)

• Performanceverbesserung von 40-60% für Search

• Das Komprimieren anderer SharePoint-Datenbanken ist nicht unterstützt


Datenbanken warten 2. SharePoint- Datenbanken

Best Practice 2c)

Backups anlegen und prüfen, bevor Maintenance Tasks ausgeführt werden

Konsistenz regelmässig prüfen mittels DBCC CHECKDB (non peak hours)

Indizes regelmässig defragmentieren (non peak hours)

• SharePoint Health Analyzer-Rules (Durchführungszeitpunkt optimieren)

• dbo.Proc_DefragIndexes jeder SharePoint-Datenbank per SQL Server Agent-Task nächtlich ausführen

• Zudem: Nie einen DB-Shrink ausführen (führt zu grosser Fragmentierung)

Statistiken regemässig aktualisieren (non peak hours)

• SharePoint Health Analyzer-Rule (Durchführungszeit optimieren)

• dbo.Proc_UpdateStatistics jeder SharePoint-Datenbank nach grossen Datenimporten/-mutationen manuell ausführen


Zusammenfassung:

Best Practice der Datenbankkonfiguration

2a) Content/Search-Datenbanken manuell anlegen

2b) Content/Search-Datenbanken optimieren

2c) Datenbanken warten


Thema 3




SharePoint-Farm






Indexfragmentierung Vgl. Wartungsaufgaben

Beheben ab 10% per Reorganisation, ab 30% per Rebuild

Wait-Statistiken Durch SQL Server geführte Wait-Statistiken geben Auskunft über die

Gründe, weshalb Transaktionen nicht schnellstmöglich ausgeführt wurden

• Parallelisierung CXPACKET -> MAXDOP

• Locking LCK_M_xx_yy -> DB-Design, Hardware

• Network ASYNC_NETW... -> Latenz zum Web Frontend

Server

• Disk-IO PAGEIOLATCH -> Disk-Subsystem

• Contention PAGELATCH -> tempdb-Dateilayout (mdf, ldf)

Datenbanken überwachen:

Indikatoren für suboptimale Leistung

3. Überwachung, Indikatoren


Präventive Methodik:

Baselining

Für elementare Indikatoren zu Beginn eines Applikations-

Lebenszyklus Baseline-Werte erheben

Periodisch diese Indikatoren erneut erheben und mit der

Baseline vergleichen

Beispiel:

Für die Leistung des Disk-Subsystems mittels SQLIO bei

Betriebsstart eine Baseline erheben sowie periodisch

verifizieren (v.a. bei Betrieb in geteilter SAN-Infrastruktur)



Manuell, systemnah: DMV abfragen Dynamic Management Views (DMV) zeigen jede Systemeigenschaft der SQL Server-Infrastruktur detailliert an

Abfrage erfolgt via SQL Server Management Studio, z.B. SELECT * FROM sys.dm_os_wait_stats

Die Resultate solcher DMV-Abfragen lassen sich, mit Timestamps versehen, als Tabellen speichern und so als Baseline verwenden

Manuell, grafisch Der Windows Performance Monitor zeigt viele dieser Indikatoren grafisch an

Automatisch, SQL Server-eigene Funktionen SQL Server stellt für die wichtigsten Indikatoren Überwachungsfunktionen und automatisch erstellte Reports zur Verfügung (siehe nächstes Kapitel)

Automatisch, Microsoft System Center Die System Center Suite (nicht Bestandteil von SQL Server) überwacht auch SQL Server-Infrastrukturen (neben allen anderen Microsoft-Produkten)

Sie bietet proaktive Notifikation wie auch Wartungsunterstützung (z.B. automatisierte Installation von ServicePacks usw.)

Überwachungsmethoden



Thema 4




SharePoint-Farm






Standardfunktionalität der SQL Server Standard Edition

Erlaubt das Abfragen beliebiger Systeminformationen

einer SQL Server-Infrastruktur

Beispiel: Lief in den letzten 24 Stunden irgendwo ein

Backup nicht?

Beispiel: Läuft irgendwo eine Datenbank im FULL

Recovery Model und ohne Log-Backups?

Vordefinierte Policies umfassen die Empfehlungen des

Best Practice Analyzers

Policy Based Management

4. Features zur Überwachung


Standardfunktionalität der SQL Server Standard Edition

Legt ein Management Data Warehouse (MDW,

Datenbank) auf der überwachten SQL Server-Instanz an

Standard-Reports zeigen die wichtigsten Indikatoren auf

der Zeitachse an

Einschalten und im Hintergrund mitlaufen lassen hat

keine relevante Leistungseinbusse zur Folge

Empfohlen als präventive Massnahme, um in

Problemsituationen auf historische Daten zurückgreifen

zu können

Grösse des MDW ist zu überwachen

Performance Data Collection



Funktionalität der SQL Server Enterprise Edition

Äquivalent zur Performance Data Collection, erlaubt

jedoch das Überwachen mehrerer SQL Server-Instanzen

durch einen zentralen Utility Control Point mit zentralem

Management Data Warehouse

Stellt ein Management Dashboard zur Verfügung

SQL Server Utility



Policy Based Management

Performance Data Collector

SQL Server Utility

Zusammenfassung:

Features zur Überwachung


Zusammenfassung




SharePoint-Farm






Weitere interessante Themen

Remote BLOB Storage

Backup Compression

Database Compression (Enterprise Edition)

Resource Governor (Enterprise Edition)

Transparent Data Encryption (Enterprise Edition)

Integration von SharePoint-Infrastrukturen mit

Cloud-basierten SQL Azure-Datenbanken


SQL Server-Dimensionierung für SharePoint Storage and SQL Server capacity planning and configuration (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc298801.aspx

SharePoint Server 2010 performance and capacity test results and recommendations: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fd1eac86-ad47-4865-9378-80040d08ac55

SQL Server Storage SQL Server PreDeployment Best Practices: http://technet.microsoft.com/de-ch/library/cc966412(en-us).aspx

Disk Partition Alignment Best Practices for SQL Server: http://msdn.microsoft.com/en-us/library/dd758814.aspx

SQLIO: Leistung (IOPS) verifizieren: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9a8b005b-84e4-4f24-8d65-cb53442d9e19

SQLIOSim: Lasttest (Simulation) für Disk-Subsystem: http://support.microsoft.com/kb/231619/en-us

Konfiguration von SQL Server unter SharePoint 2010 Operations Guide for Microsoft SharePoint Server 2010: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=944519e8-e130-4e7a-8a8d-978b10af77c1

Database Types and Descriptions (SharePoint 2010): http://technet.microsoft.com/en-us/library/cc678868.aspx

Deploy using DBA-created Databases (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc262869.aspx

Nicht unterstützte Änderungen an SharePoint-DB: http://msdn.microsoft.com/en-us/library/dd587585(office.11).aspx / http://support.microsoft.com/kb/841057

Remote BLOB Storage Download: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52

Whitepaper (Feb 2011): http://download.microsoft.com/download/9/5/2/9521D8DA-5D3C-4817-BB9D-B5B1BD293365/SQL_Server_2008_R2_Remote_Blob_Storage.docx

Maintenance-Scripts und -Toolsets Index Defrag http://support.microsoft.com/kb/943345/en-us

Ola Hallengren: Indexoptimierung, Backup http://ola.hallengren.com/

Glen Barry: Diagnose http://sqlserverperformance.wordpress.com/2010/04/27/sql-server-2008-and-2008r2-diagnostic-information-queries/

Michelle Ufford: Index Defragmentierung http://sqlfool.com/2010/04/index-defrag-script-v4-0/

Paul Nielsen: Datenbankkompression, viele weitere Themen: http://sqlblog.com/blogs/paul_nielsen/archive/2008/03/13/whole-database-data-compression-procs.aspx

Whitepapers, Guides, Werkzeuge

http://technet.microsoft.com/en-us/library/cc298801.aspx



http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fd1eac86-ad47-4865-9378-80040d08ac55









http://technet.microsoft.com/de-ch/library/cc966412(en-us).aspx






http://msdn.microsoft.com/en-us/library/dd758814.aspx





http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9a8b005b-84e4-4f24-8d65-cb53442d9e19










http://support.microsoft.com/kb/231619/en-us




http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=944519e8-e130-4e7a-8a8d-978b10af77c1



















http://msdn.microsoft.com/en-us/library/dd587585(office.11).aspx





http://support.microsoft.com/kb/841057

http://support.microsoft.com/kb/841057

http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52










http://download.microsoft.com/download/9/5/2/9521D8DA-5D3C-4817-BB9D-B5B1BD293365/SQL_Server_2008_R2_Remote_Blob_Storage.docx















http://ola.hallengren.com/

http://ola.hallengren.com/

http://sqlserverperformance.wordpress.com/2010/04/27/sql-server-2008-and-2008r2-diagnostic-information-queries/
















http://sqlfool.com/2010/04/index-defrag-script-v4-0/










http://sqlblog.com/blogs/paul_nielsen/archive/2008/03/13/whole-database-data-compression-procs.aspx









