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

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

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

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: SQL Server
Konfiguration
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


Farm Admin & DBA 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


DB-Dateilayout: SQL Server
Konfiguration
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


DB-Dateilayout SQL Server
Konfiguration

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


Disk-Performance: SQL Server
Konfiguration
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


Disk-Performance 1. SQL Server
Konfiguration

Best Practice 1c)

IOPS sicherstellen
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
RAID 10 (RAID 5 0.75
Content-DB (mdf, ndf) Read optimized
bei statischem Inh.) IOPS/GB

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-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




Content-Datenbanken bereitstellen: 2. SharePoint-
Datenbanken
Manuell anlegen!
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 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




Datenbanken überwachen: 3. Überwachung,
Indikatoren
Indikatoren für suboptimale Leistung
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)


Präventive Methodik: 3. Überwachung,
Indikatoren
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)


Überwachungsmethoden 3. Überwachung,
Indikatoren

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.)


Thema 4


SharePoint-Farm




4. Features
Policy Based Management zur
Überwachung

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


4. Features
Performance Data Collection 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


4. Features
SQL Server Utility zur
Überwachung

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


Zusammenfassung:
Features zur Überwachung

Policy Based Management
Performance Data Collector
SQL Server Utility


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


Whitepapers, Guides, Werkzeuge
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


Sql best practices for SharePoint 2010

Sql best practices for SharePoint 2010

Weitere ähnliche Inhalte

Was ist angesagt? (20)

Andere mochten auch (20)

Ähnlich wie Sql best practices for SharePoint 2010 (6)

Mehr von Samuel Zürcher (13)

Sql best practices for SharePoint 2010