SQL Server für SharePoint Server Subscription Edition

1 Worum es geht

SharePoint Server Subscription Edition ist im Kern eine große, freundliche Web-Oberfläche, die vor einem SQL Server sitzt und den ganzen Tag Fragen stellt. Jedes Dokument, jede Listenzeile, jede Berechtigung, jede Version und jeder Suchtreffer landet irgendwann in einer Datenbank. Wenn SharePoint lahmt, liegt die Ursache deshalb erstaunlich oft gar nicht in SharePoint, sondern eine Etage tiefer: bei einem SQL Server, den jemand nach dem Motto „Weiter, Weiter, Fertig“ installiert und danach nie wieder angefasst hat.

Dieses Dokument nimmt dich vom leeren Windows Server bis zum ruhigen, gut überwachten Produktivbetrieb mit. Es ist bewusst technisch tief gehalten: mit konkreten Einstellungen, T-SQL und PowerShell zum Kopieren, Richtwerten aus der Praxis und den typischen Stolperfallen, die man sonst erst nachts um drei kennenlernt.

FAKTENKASTEN · Auf einen Blick Unterstützt: SQL Server Standard oder Enterprise für Windows mit Kompatibilitätsgrad 150, also SQL Server 2019 ab CU5, SQL Server 2022 und künftige Versionen, die Grad 150 beherrschen. Nicht unterstützt: SQL Server Express und Azure SQL Database. Azure SQL Managed Instance nur, wenn die Farm selbst in Azure läuft. Pflicht: max degree of parallelism = 1 auf der Instanz. Ohne das gibt es keine Farm. Kompatibilitätsgrad 150 für alle SharePoint-SE-Datenbanken, auch wenn die Instanz 160 oder 170 könnte. Verschlüsselung: Ab Version 24H2 werden neue Datenbanken standardmäßig mit „Mandatory“ angebunden, „Strict“ (TDS 8.0) erfordert SQL Server 2022 oder neuer. Goldene Regel: Eigene Instanz für SharePoint, keine Mitbewohner.

 

1.1 Für wen dieses Dokument gedacht ist

Für SharePoint-Administratoren, die wissen wollen, was unter ihrer Farm passiert, für DBAs, die eine SharePoint-Instanz übernehmen und sich wundern, warum hier alles anders ist, und für IT-Leiter, die einschätzen wollen, ob ihre Datenbankschicht trägt. Grundkenntnisse in SQL Server und SharePoint setze ich voraus. Wer noch nie ein sp_configure abgesetzt hat, kommt trotzdem mit, muss aber ab und zu nachschlagen.

1.2 Die drei Grundgesetze

Bevor es in die Details geht, drei Sätze, die du dir über den Monitor kleben kannst. Fast jeder Fehler, den ich in SharePoint-Datenbankumgebungen gesehen habe, verstößt gegen mindestens einen davon.

SharePoint gehört die Datenbank, nicht dir. Schema, Indizes, Statistik-Einstellungen und Prozeduren verwaltet SharePoint selbst. Wer dort eigenmächtig Indizes anlegt, Trigger einbaut oder Tabellen anfasst, verlässt den unterstützten Rahmen.

Die Instanz gehört dir. Speicher, TempDB, Storage, Backup, Hochverfügbarkeit, Patchen und Überwachung sind komplett deine Baustelle. SharePoint kümmert sich darum nicht.

Latenz schlägt Rechenleistung. SharePoint feuert sehr viele kleine Abfragen ab. Ein SQL Server mit 64 Kernen hinter einem lahmen Storage verliert gegen einen mit 8 Kernen auf flotter NVMe.

2 Plattform, Versionen und Editionen

2.1 Unterstützte Kombinationen

Microsoft formuliert die Unterstützung für SharePoint SE bemerkenswert offen: Unterstützt ist jede Standard- oder Enterprise-Edition von SQL Server für Windows, die den Datenbank-Kompatibilitätsgrad 150 unterstützt. Ausdrücklich genannt sind SQL Server 2019 ab Cumulative Update 5 und SQL Server 2022. Neuere Versionen fallen unter die Formulierung „künftige Versionen“, solange sie Grad 150 anbieten.

Komponente	Unterstützt	Bemerkung
SQL Server 2019	Ja, ab CU5	Mindestversion, für Neuinstallationen nur noch zweite Wahl
SQL Server 2022	Ja	Empfohlene Basis, TDS 8.0 (Strict) möglich
SQL Server 2025	Ja, über die Grad-150-Regel	Datenbanken trotzdem auf Grad 150 betreiben, Supportstand vor Einführung kurz gegenprüfen
SQL Server Express	Nein	Auch nicht für das Testlabor „nur mal eben“
Azure SQL Database	Nein	Weder für Inhalt noch für Dienstanwendungen
Azure SQL Managed Instance	Nur bei Farm in Azure	Hybride Konstruktionen (Farm lokal, MI in Azure) sind nicht unterstützt
Windows Server 2019/2022/2025	Ja	Desktop Experience oder Server Core

Tabelle 1: Supportmatrix Datenbankserver für SharePoint Server Subscription Edition

PRAXISTIPP · Welche Version nehmen? Für eine Neuinstallation im Herbst 2026 ist SQL Server 2022 auf Windows Server 2022 oder 2025 die entspannte Wahl: ausgereift, TDS 8.0 mit TLS 1.3 möglich, lange Restlaufzeit. SQL Server 2025 geht ebenfalls, bringt für SharePoint aber kaum Vorteile, weil die Datenbanken ohnehin auf Grad 150 laufen und viele neue Optimierer-Funktionen an höhere Grade gebunden sind.

 

2.2 Standard oder Enterprise?

Die Edition entscheidet weniger über Geschwindigkeit als über Hochverfügbarkeit. SharePoint bringt je nach Ausbau schnell 15 bis 30 Datenbanken mit. Und genau da wird die Standard-Edition unbequem.

Kriterium	Standard	Enterprise
Always On Availability Groups	Nur Basic AG: eine Datenbank pro AG, zwei Replikate, kein lesbarer Sekundärknoten	Volle AG: beliebig viele DBs pro AG, bis zu 8 Sekundärreplikate
Failover Cluster Instance	Ja, zwei Knoten	Ja, mehr Knoten
Online-Indexoperationen	Nein	Ja (SharePoint nutzt das bei der Indexpflege, wo verfügbar)
Ressourcengrenzen	Kern- und Speicherdeckel je nach Version	Betriebssystemgrenze
Typischer Einsatz	Kleine bis mittlere Farm mit FCI oder ohne HA	Mittlere bis große Farm mit AG und DR-Standort

Tabelle 2: Editionsvergleich aus SharePoint-Sicht

ACHTUNG · Basic AG und SharePoint Mit Basic Availability Groups brauchst du für jede SharePoint-Datenbank eine eigene AG mit eigenem Listener. Bei 25 Datenbanken sind das 25 Listener, 25 IP-Adressen und ein Failover-Verhalten, bei dem Config-Datenbank und Inhaltsdatenbanken auf verschiedenen Knoten landen können. Das funktioniert technisch, ist im Betrieb aber eine Zumutung. Wenn AG, dann Enterprise. Wenn das Budget das nicht hergibt, ist eine Failover Cluster Instance mit Standard die ehrlichere Lösung.

 

2.3 Kompatibilitätsgrad 150

SharePoint SE ist gegen den Kompatibilitätsgrad 150 getestet und validiert. Legt SharePoint eine Datenbank auf einer SQL-2022-Instanz an, bekommt sie aber erst einmal den Standard der Instanz, also 160. Microsoft empfiehlt ausdrücklich, SharePoint-SE-Datenbanken auf Grad 150 zu setzen, weil höhere Grade den Optimierer anders arbeiten lassen und das bei SharePoint-Abfragen zu mehr CPU-Last und schlechteren Plänen führen kann.

Der elegante Trick: Setze die Systemdatenbank model auf Grad 150. Neue Datenbanken erben ihren Kompatibilitätsgrad von model, und du musst nicht nach jedem neuen Content-DB-Anlegen nachkorrigieren. Trotzdem gehört eine Prüfung in die monatliche Routine.

T-SQL: Kompatibilitätsgrad setzen und prüfen — model auf 150, damit neue SharePoint-DBs den richtigen Grad erben ALTER DATABASE [model] SET COMPATIBILITY_LEVEL = 150;   — Bestand prüfen: alles, was nicht 150 ist SELECT name, compatibility_level FROM sys.databases WHERE database_id > 4 AND compatibility_level <> 150;   — Korrektur pro Datenbank ALTER DATABASE [WSS_Content_Intranet] SET COMPATIBILITY_LEVEL = 150;

 

3 Architektur und Kapazitätsplanung

3.1 Referenzarchitektur

Abbildung 1 zeigt das Zielbild einer mittleren bis großen Farm: SharePoint-Server in MinRole-Rollen, auf jedem Server ein SQL-Alias, dahinter ein Availability-Group-Listener und drei SQL-Knoten, zwei davon synchron im Rechenzentrum, einer asynchron am DR-Standort. Kleinere Umgebungen kommen mit einem einzelnen SQL Server oder einer Zwei-Knoten-FCI aus. Das Prinzip mit dem Alias gilt trotzdem immer.

Abbildung 1: Referenzarchitektur einer SharePoint-SE-Farm mit Always-On-Datenbankschicht

3.2 Eine eigene Instanz, bitte

SharePoint stellt Anforderungen an die Instanz, die andere Anwendungen nicht mögen. Allen voran MAXDOP 1: Ein ERP-System, ein Data Warehouse oder eine Reporting-Datenbank, die sich die Instanz mit SharePoint teilen, verlieren damit jegliche Parallelisierung. Dazu kommen die Kollation, die Speicherkonkurrenz und das gemeinsame Patchfenster. Die saubere Lösung ist eine dedizierte Instanz, bei größeren Farmen ein dedizierter Server oder Cluster.

AUS DEM CONSULTANT-ALLTAG · Die WG im SQL Server Bei einem Kunden teilte sich SharePoint die Instanz mit der Warenwirtschaft. Der ERP-Dienstleister hatte MAXDOP auf 8 gestellt, „weil die Monatsabschlüsse sonst ewig dauern“. Drei Wochen später fiel ein SharePoint-CU auf die Nase, weil die Konfiguration nicht mehr passte, und der Monatsabschluss lag mitten im Patchfenster. Beide Parteien hatten recht, und genau deshalb gehören sie nicht in dieselbe Instanz.

 

3.3 Grenzen und Größen für Inhaltsdatenbanken

Die bekannten Microsoft-Grenzwerte sind keine harten Abbruchkanten, sondern Erfahrungswerte, bei denen Betrieb, Backup und Wiederherstellung beherrschbar bleiben. Die wichtigste Größe ist dabei nicht die technische Machbarkeit, sondern die Restore-Zeit: Wie lange darf eine Abteilung ohne ihre Dokumente sein?

Grenzwert	Wert	Was er praktisch bedeutet
Empfohlene Größe pro Inhaltsdatenbank	200 GB	Komfortzone für Backup, Restore und Upgrade
Unterstützt bei Kollaboration	bis 4 TB	Nur mit Storage, das mindestens 0,25 IOPS pro GB liefert, empfohlen sind 2 IOPS pro GB, und mit getesteter Backup-/Restore-Strategie
Archivszenarien (Dokumentcenter, Records Center)	ohne feste Grenze	Nur bei sehr geringer Schreiblast und überwiegend lesendem Zugriff
Elemente pro Inhaltsdatenbank	60 Mio.	Dokumente und Listenelemente inkl. Versionen zählen mit
Websitesammlungen pro Inhaltsdatenbank	max. 10.000	Davon höchstens 2.500 ohne persönliche Websites, der Rest MySites

Tabelle 3: Kapazitätsgrenzen für Inhaltsdatenbanken (Microsoft-Richtwerte)

MERKSATZ Plane die Größe einer Inhaltsdatenbank rückwärts: Nimm deine maximal akzeptable Wiederherstellungszeit, miss den realen Restore-Durchsatz deines Backup-Systems und rechne daraus die Obergrenze aus. Alles andere ist Wunschdenken mit Tabellenformatierung.

 

3.4 Sizing des SQL Servers

Für den Arbeitsspeicher gibt es seit Jahren bewährte Richtwerte in Abhängigkeit vom Gesamtvolumen der Inhalte. Sie sind ein Startpunkt, kein Naturgesetz. Entscheidend ist später die gemessene Page Life Expectancy und die Frage, ob die häufig genutzten Daten im Buffer Pool bleiben.

Farmgröße (Inhalt gesamt)	RAM SQL Server	CPU-Kerne	Anmerkung
Klein, bis 2 TB	16 bis 32 GB	4 bis 8	Ein Server, Standard-Edition reicht oft
Mittel, 2 bis 5 TB	32 bis 64 GB	8 bis 16	Suche auf eigene Volumes legen
Groß, 5 bis 10 TB	64 bis 128 GB	16 und mehr	AG, getrennte Instanz für Suche erwägen
Sehr groß, über 10 TB	128 GB und mehr	nach Messung	Mehrere Instanzen, sauberes Datenbank-Sharding

Tabelle 4: Richtwerte für die Dimensionierung

Bei der CPU gilt: Wegen MAXDOP 1 läuft jede einzelne Abfrage auf genau einem Kern. Hohe Einzelkernleistung ist also wichtiger als viele Kerne. Ein Prozessor mit hoher Taktfrequenz schlägt bei SharePoint ein Kern-Monster mit niedrigem Takt. Wer nach Kernen lizenziert, freut sich doppelt.

3.5 Netzwerk

Zwischen SharePoint-Servern und SQL Server verlangt Microsoft eine Latenz von unter einer Millisekunde in eine Richtung, und zwar in 99,9 Prozent der Fälle. Das schließt SQL-Server am anderen Ende einer WAN-Strecke für den Normalbetrieb aus. Synchrone AG-Replikate an einem zweiten Standort sind nur sinnvoll, wenn die Standorte über eine echte RZ-Kopplung verbunden sind. Für weiter entfernte Standorte ist der asynchrone DR-Knoten gedacht.

4 SQL Server installieren und vorbereiten

4.1 Windows vorbereiten

Energieoptionen auf „Höchstleistung“ stellen. Der Standard „Ausbalanciert“ taktet die CPU herunter und kostet bei SharePoint messbar Antwortzeit. Bei virtuellen Maschinen auch die Einstellung im Hypervisor und BIOS des Hosts prüfen.

Volumes wie in Abbildung 2 trennen und Daten-, Log- und TempDB-Volumes mit einer Zuordnungseinheit von 64 KB formatieren.

Virenscanner ausschließen: Datenbank- und Logdateien (.mdf, .ndf, .ldf), Backup-Verzeichnisse und die SQL-Server-Prozesse. Ein Echtzeitscanner, der jede Log-Schreiboperation prüft, ist ein hervorragender Performance-Killer.

Auslagerungsdatei auf dem Systemlaufwerk lassen, aber nicht auf ein Minimum kastrieren, damit Speicherabbilder bei Abstürzen möglich bleiben.

Abbildung 2: Empfohlenes Volume-Layout für einen SQL Server mit SharePoint-Datenbanken

PowerShell: Volume formatieren und Energieplan setzen # Daten-Volume mit 64-KB-Zuordnungseinheit formatieren (Beispiel E:) Format-Volume –DriveLetter E –FileSystem NTFS –AllocationUnitSize 65536 –NewFileSystemLabel "SQLDATA"   # Kontrolle: "Bytes Per Cluster" muss 65536 sein fsutil fsinfo ntfsinfo E: | Select-String "Bytes Per Cluster"   # Energieplan Höchstleistung aktivieren powercfg /setactive SCHEME_MIN

 

4.2 Dienstkonten

Für den Datenbankdienst und den SQL Server Agent bieten sich Group Managed Service Accounts (gMSA) an. Sie werden von SQL Server unterstützt, das Kennwort rotiert Active Directory automatisch, und niemand kann sich damit interaktiv anmelden. Für Kerberos-Authentifizierung zwischen SharePoint und SQL Server muss für das Dienstkonto ein Service Principal Name registriert sein, sonst fällt die Anmeldung auf NTLM zurück.

PowerShell: gMSA und SPN # gMSA für SQL Server anlegen (einmalig, auf einem DC oder mit RSAT) New-ADServiceAccount -Name gmsaSQLSP –DNSHostName gmsaSQLSP.contoso.local –PrincipalsAllowedToRetrieveManagedPassword "SQL-SP-Server"   # SPN für Standardport und Listener registrieren setspn -S MSSQLSvc/sqlsp01.contoso.local:1433 CONTOSO\gmsaSQLSP$ setspn -S MSSQLSvc/sql-ag-listener.contoso.local:1433 CONTOSO\gmsaSQLSP$

 

4.3 Setup-Entscheidungen

Einstellung im Setup	Empfehlung	Warum
Features	Database Engine Services, Volltextsuche nicht nötig	SharePoint nutzt die eigene Suche, nicht die SQL-Volltextsuche
Instanzname	Benannte Instanz oder Standardinstanz, Zugriff immer über Alias	Der Alias entkoppelt die Farm vom echten Servernamen
Kollation	Latin1_General_CI_AS_KS_WS	SharePoint legt seine DBs ohnehin mit dieser Kollation an, die Instanz sollte passen, damit TempDB-Vergleiche nicht scheitern
Authentifizierung	Windows-Authentifizierung	SharePoint verbindet sich mit Windows-Konten, SQL-Logins braucht es nicht
Instant File Initialization	Aktivieren (Häkchen „Perform Volume Maintenance Tasks“)	Datendateien wachsen ohne Nullen-Schreiben, Restores werden schneller
TempDB	Anzahl Dateien = Kerne, maximal 8, alle gleich groß	Vermeidet Allokationskonflikte
Verzeichnisse	Daten E:, Log F:, TempDB T:, Backup B:	Siehe Abbildung 2

Tabelle 5: Entscheidungen im SQL-Server-Setup

ACHTUNG · Kollation nachträglich ändern Die Kollation einer Instanz nachträglich zu ändern bedeutet praktisch, die Systemdatenbanken neu aufzubauen. Das ist kein Klick, das ist ein Wochenende. Also: im Setup einmal richtig auf Latin1_General_CI_AS_KS_WS stellen und nie wieder darüber nachdenken.

 

5 Instanz konfigurieren

5.1 Die Pflichteinstellungen

Die folgende Tabelle ist das Herzstück der Instanzkonfiguration. Die erste Zeile ist nicht verhandelbar, der Rest ist bewährte Praxis.

Einstellung	Wert	Begründung
max degree of parallelism	1 (Pflicht)	SharePoint prüft das beim Anlegen der Farm. Parallele Pläne erzeugen bei den SharePoint-Abfragen mehr Probleme als sie lösen
max server memory (MB)	Gesamt-RAM minus 4 GB bzw. minus 10 %	Dem Betriebssystem Luft lassen, sonst wird es eng beim Paging
min server memory (MB)	ca. 50 % von max	Verhindert, dass die Instanz unter Druck zu weit schrumpft
backup compression default	1	Kleinere Backups, kürzere Laufzeit, kaum CPU-Nachteil
remote admin connections	1	Dedicated Admin Connection auch remote, Rettungsanker bei hängender Instanz
optimize for ad hoc workloads	1	Spart Plan-Cache bei vielen Einmal-Abfragen
fill factor (%)	Standard lassen oder 80	Microsoft hat für SharePoint früher 80 empfohlen, bringt nur bei sehr schreiblastigen Inhalten etwas
cost threshold for parallelism	egal	Mit MAXDOP 1 gibt es keine Parallelität mehr

Tabelle 6: Instanzeinstellungen für SharePoint SE

T-SQL: Instanzkonfiguration EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max degree of parallelism', 1; EXEC sp_configure 'max server memory (MB)', 57344; — Beispiel: 64 GB RAM EXEC sp_configure 'min server memory (MB)', 28672; EXEC sp_configure 'backup compression default', 1; EXEC sp_configure 'remote admin connections', 1; EXEC sp_configure 'optimize for ad hoc workloads', 1; RECONFIGURE;   — Kontrolle SELECT name, value_in_use FROM sys.configurations WHERE name IN ('max degree of parallelism','max server memory (MB)', 'min server memory (MB)','backup compression default', 'remote admin connections','optimize for ad hoc workloads');

 

5.2 TempDB richtig aufsetzen

TempDB ist bei SharePoint kein Nebenschauplatz: Sortierungen, Arbeitstabellen, Versionsspeicher und Zwischenergebnisse großer Listenabfragen landen dort. Die Regeln sind simpel und trotzdem in der Hälfte aller Umgebungen verletzt: mehrere gleich große Datendateien, feste Wachstumsschritte in MB, vorab auf realistische Größe gebracht und auf dem schnellsten verfügbaren Storage.

T-SQL: TempDB-Dateien — Beispiel: 8 Kerne, 8 TempDB-Datendateien à 8 GB, Log 16 GB ALTER DATABASE tempdb MODIFY FILE (NAME = N'tempdev', SIZE = 8GB, FILEGROWTH = 1GB); ALTER DATABASE tempdb MODIFY FILE (NAME = N'templog', SIZE = 16GB, FILEGROWTH = 2GB); ALTER DATABASE tempdb ADD FILE (NAME = N'temp2', FILENAME = N'T:\TempDB\temp2.ndf', SIZE = 8GB, FILEGROWTH = 1GB); — … temp3 bis temp8 analog   — Kontrolle: alle Dateien gleich groß? SELECT name, size/128 AS size_mb, growth/128 AS growth_mb FROM tempdb.sys.database_files;

 

5.3 Die model-Datenbank als Vorlage

SharePoint legt neue Datenbanken mit CREATE DATABASE an, und die erben Größe, Wachstum, Recovery-Modell und Kompatibilitätsgrad von model. Wer model sauber vorbereitet, bekommt automatisch vernünftige neue Inhaltsdatenbanken statt der berüchtigten Mini-Startgröße mit winzigen Wachstumsschritten.

T-SQL: model vorbereiten ALTER DATABASE [model] SET COMPATIBILITY_LEVEL = 150; ALTER DATABASE [model] SET RECOVERY FULL; ALTER DATABASE [model] MODIFY FILE (NAME = N'modeldev', SIZE = 1GB, FILEGROWTH = 1GB); ALTER DATABASE [model] MODIFY FILE (NAME = N'modellog', SIZE = 512MB, FILEGROWTH = 512MB);

 

5.4 Was du nicht einstellen solltest

Einige gut gemeinte Optimierungen aus dem allgemeinen SQL-Tuning sind bei SharePoint schädlich oder schlicht nicht unterstützt. Microsoft untersagt Änderungen an SharePoint-Datenbanken, die über das Dokumentierte hinausgehen, und dazu gehören auch Datenbankoptionen.

Auto Create Statistics bleibt auf den SharePoint-Datenbanken aus. SharePoint setzt das selbst und pflegt Statistiken über eigene Prozeduren. Automatisch erzeugte Statistiken können Ausführungspläne drastisch verändern.

Read Committed Snapshot Isolation nicht aktivieren. SharePoint ist darauf nicht getestet.

Eigene Indizes, Trigger, Partitionierung oder Datenkompression in SharePoint-Datenbanken sind tabu.

Query Store höchstens zur Diagnose einsetzen, keine Pläne erzwingen. Erzwungene Pläne überleben SharePoint-Updates schlecht.

Auto Shrink nie. Wirklich nie.

6 Farm anbinden: Alias, Konten, Verschlüsselung

6.1 Der SQL-Alias

Ein SQL-Alias ist ein Eintrag in der Registrierung jedes SharePoint-Servers, der einen logischen Namen auf einen echten Server samt Port abbildet. SharePoint speichert in seiner Konfiguration nur den Alias. Ziehst du die Datenbanken später auf einen neuen Server oder hinter einen Listener um, änderst du den Alias auf allen SharePoint-Servern und bist fertig, ohne die Farm umzubauen. Das ist die billigste Versicherung, die es im SharePoint-Betrieb gibt.

PowerShell: SQL-Alias anlegen # Auf JEDEM SharePoint-Server ausführen (64- und 32-Bit-Zweig) $alias = "SPSQL" $target = "DBMSSOCN,sql-ag-listener.contoso.local,1433" # TCP, Server, Port   foreach ($path in "HKLM:\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo") { if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null } New-ItemProperty -Path $path -Name $alias -Value $target -PropertyType String -Force | Out-Null }   # Test: Verbindung über den Alias $c = New-Object System.Data.SqlClient.SqlConnection "Server=SPSQL;Integrated Security=SSPI;Encrypt=True" $c.Open(); $c.ServerVersion; $c.Close()

 

PRAXISTIPP · Feste Ports statt SQL Browser Gib benannten Instanzen einen festen TCP-Port und trage ihn im Alias ein. Dann brauchst du den SQL-Browser-Dienst und UDP 1434 nicht, die Firewall-Regeln werden übersichtlich und Verbindungsprobleme nach einem Neustart sind Geschichte.

 

6.2 Konten und Berechtigungen

SharePoint braucht keinen Systemadministrator auf dem SQL Server. Es braucht genau zwei Konten mit klar umrissenen Rechten.

Konto	Rechte auf SQL Server	Hinweise
Setup-Konto (z. B. sp_setup)	Serverrollen dbcreator und securityadmin	Zusätzlich lokaler Administrator auf den SharePoint-Servern, nicht auf dem SQL Server
Farmkonto (z. B. sp_farm)	Wird von SharePoint selbst berechtigt: db_owner auf Config und Central-Admin-Inhalt, Serverrollen dbcreator und securityadmin	Nie manuell zum sysadmin machen, auch nicht „vorübergehend“
Dienstanwendungs- und Web-App-Pools	Werden von SharePoint pro Datenbank berechtigt (Rolle SPDataAccess)	Nicht von Hand nachpflegen, sondern über SharePoint-Cmdlets

Tabelle 7: Konten und Rechte

AUS DEM CONSULTANT-ALLTAG · Sysadmin für alle Der Klassiker in gewachsenen Farmen: Irgendwann hat jemand das Farmkonto zum sysadmin gemacht, weil ein Upgrade hakte. Fünf Jahre später ist das Farmkonto sysadmin, das Setup-Konto sysadmin, zwei App-Pool-Konten sysadmin und keiner weiß mehr, warum. Bei der nächsten Sicherheitsprüfung gibt es dafür die rote Karte, und das völlig zu Recht. Aufräumen geht, kostet aber einen Testlauf mit jedem Dienst.

 

6.3 Verbindungsverschlüsselung und TDS 8.0

Mit dem Feature-Update Version 24H2 hat SharePoint SE die Steuerung der Verbindungsverschlüsselung zu SQL Server bekommen. Für jede Datenbank gibt es drei Stufen, die du beim Anlegen der Farm und beim Anlegen oder Einbinden von Datenbanken über den Parameter –DatabaseConnectionEncryption wählst.

Abbildung 3: Die drei Verschlüsselungsstufen für Datenbankverbindungen

Optional: Verschlüsselung nur, wenn der SQL Server sie erzwingt. Das ist der Zustand aller Datenbanken, die vor 24H2 eingebunden wurden.

Mandatory: TLS ist Pflicht, sonst scheitert die Verbindung. Standard für neue Datenbanken ab 24H2.

Strict: TDS 8.0, die TLS-Aushandlung erfolgt vor jedem TDS-Paket, das Zertifikat wird immer geprüft. Setzt SQL Server 2022 oder neuer voraus. TLS 1.3 gibt es dabei erst ab Windows Server 2022 auf beiden Seiten.

Voraussetzung für Mandatory und Strict ist ein Serverzertifikat auf dem SQL Server, ausgestellt von einer Zertifizierungsstelle, der die SharePoint-Server vertrauen. Der Antragstellername bzw. die alternativen Namen (SAN) müssen den Namen enthalten, den der Client tatsächlich anspricht. Bei einer AG ist das der Listener, bei einem Alias der Zielname im Alias, nicht der Alias selbst.

PowerShell: Farm mit TDS 8.0 anlegen $farm = Get-Credential CONTOSO\sp_farm $pp = Read-Host -AsSecureString "Farm-Passphrase"   New-SPConfigurationDatabase -DatabaseName "SP_Config" -DatabaseServer "SPSQL" ` -AdministrationContentDatabaseName "SP_AdminContent" ` -Passphrase $pp -FarmCredentials $farm -LocalServerRole Application ` –DatabaseConnectionEncryption Strict

 

ACHTUNG · Erst testen, dann umstellen Bevor du Bestandsdatenbanken auf Strict hebst: Zertifikatskette, SAN, Ablaufdatum und die Erneuerung im Blick haben. Ein abgelaufenes SQL-Zertifikat bei Strict heißt: komplette Farm offline. Trag das Ablaufdatum in deine Zertifikatsüberwachung ein und plane die Erneuerung mindestens vier Wochen vorher. Die genaue Parameterliste der Cmdlets hängt von deinem Patchstand ab, ein kurzes Get-Help New-SPContentDatabase -Parameter DatabaseConnectionEncryption klärt das.

 

7 Die Datenbanken im Detail

Eine SharePoint-SE-Farm ist kein Monolith, sondern eine kleine Datenbanklandschaft mit sehr unterschiedlichen Charakteren. Manche Datenbanken sind winzig, aber unverzichtbar, andere riesig und hungrig nach I/O, wieder andere könnte man im Notfall einfach neu aufbauen. Wer die Unterschiede kennt, verteilt Storage, Backup-Aufwand und HA-Schutz dorthin, wo sie wirken.

Abbildung 4: Datenbanklandschaft einer SharePoint-SE-Farm und ihr Lastprofil

7.1 Steckbriefe

Datenbank	Größe / Last	Recovery-Modell	AG sync / async	Hinweise
Konfiguration	klein, sehr viele Lesezugriffe	FULL (bei AG) sonst SIMPLE möglich	ja / nein	Herz der Farm, ohne sie startet nichts
Central-Admin-Inhalt	klein	FULL (bei AG) sonst SIMPLE möglich	ja / nein	Kann im Notfall neu erzeugt werden
Inhaltsdatenbanken	groß, gemischte Last	FULL	ja / ja	Hier liegt der eigentliche Wert der Farm
Search Administration	klein, kritisch	SIMPLE (bei AG FULL)	ja / nein	Mit den übrigen Such-DBs konsistent sichern
Crawl Store	mittel, sehr schreiblastig	SIMPLE (bei AG FULL)	ja / nein	Schnelles Storage, hohe Log-Last
Link Store	wächst mit Abfragen	SIMPLE (bei AG FULL)	ja / nein	Klickdaten für die Relevanz
Analytics Reporting	wächst stetig	SIMPLE (bei AG FULL)	ja / ja	Bei Bedarf aufteilen
Managed Metadata	klein, viel Lesen	FULL	ja / ja	Taxonomie, für viele Inhalte zentral
User Profile, Social, Sync	mittel	FULL	Profile/Social ja / ja, Sync ja / nein	Sync-DB lässt sich neu aufbauen
Secure Store, BCS, App Mgmt, Subscription Settings	klein	FULL	ja / ja	Secure Store nur mit Hauptschlüssel wiederherstellbar
State Service	klein	FULL	ja / nein	Workflow- und Formularstatus
Usage / Logging	schreiblastig, wächst schnell	SIMPLE	ja / ja, aber selten nötig	Entbehrlich, oft bewusst aus der AG herausgehalten

Tabelle 8: SharePoint-SE-Datenbanken und ihre Betriebsparameter

FAKTENKASTEN · Was „AG async: nein“ bedeutet Microsoft unterstützt für einige Datenbanken nur synchrone Replikation. Konfiguration, Central-Admin-Inhalt, Suchdatenbanken und State Service sollen nicht asynchron an einen DR-Standort gespiegelt und dort aktiviert werden. Am DR-Standort wird für diese Bestandteile eine eigene, vorbereitete Farm hochgefahren, die die asynchron replizierten Inhalts- und Dienstanwendungsdatenbanken übernimmt. Die Suche wird dort neu aufgebaut oder aus einer Sicherung wiederhergestellt.

 

7.2 Inhaltsdatenbanken planen und aufteilen

Lege Inhaltsdatenbanken bewusst an, statt SharePoint die Websitesammlungen nach Gutdünken verteilen zu lassen. Mit –MaxSiteCount und –WarningSiteCount steuerst du, wohin neue Websitesammlungen wandern. Große oder besonders schutzbedürftige Bereiche, etwa ein Vertragsarchiv oder die Geschäftsführung, bekommen eine eigene Datenbank. Das erleichtert gezieltes Backup, eigene Restore-Prioritäten und spätere Verschiebungen.

PowerShell: Inhaltsdatenbanken steuern # Neue Inhaltsdatenbank mit TLS-Pflicht und Sammlungsgrenzen New-SPContentDatabase -Name "WSS_Content_Vertraege" -WebApplication "https://intranet.contoso.local" ` -DatabaseServer "SPSQL" -MaxSiteCount 1 -WarningSiteCount 0 ` -DatabaseConnectionEncryption Mandatory   # Websitesammlung in eine andere Datenbank verschieben (danach IIS-Reset auf den WFEs) Move-SPSite "https://intranet.contoso.local/sites/vertraege" –DestinationDatabase "WSS_Content_Vertraege"   # Überblick: Größe und Anzahl Sammlungen je Inhaltsdatenbank Get-SPContentDatabase | Select-Object Name, CurrentSiteCount, MaximumSiteCount, @{n="SizeGB";e={[math]::Round($_.DiskSizeRequired/1GB,1)}} | Sort-Object SizeGB –Descending

 

7.3 Dateigrößen und Wachstum

Autogrowth ist ein Notfallmechanismus, keine Kapazitätsplanung. Jeder Wachstumsschritt einer Logdatei blockiert Schreibvorgänge, bis der neue Bereich initialisiert ist, denn für Logdateien greift Instant File Initialization nur bis 64 MB. Prozentuale Wachstumsschritte werden bei großen Dateien absurd groß, winzige MB-Schritte erzeugen tausende Fragmente und Virtual Log Files. Daher: Dateien vorab auf die erwartete Jahresgröße bringen und feste Schritte setzen.

Datei	Wachstumsschritt	Vorab-Größe
Daten Inhaltsdatenbank	1 GB	erwartete Größe in 12 Monaten
Log Inhaltsdatenbank	512 MB bis 1 GB	ca. 25 % der Datendatei, nach Messung anpassen
Crawl Store / Analytics	1 GB	nach Indexgröße
Kleine Dienstanwendungs-DBs	256 MB	1 bis 5 GB
TempDB	1 GB (Daten), 2 GB (Log)	siehe Kapitel 4

Tabelle 9: Richtwerte für Dateigröße und Wachstum

T-SQL: Wachstumseinstellungen prüfen und korrigieren — Alle Dateien mit prozentualem oder winzigem Wachstum finden SELECT DB_NAME(database_id) AS db, name, type_desc, size/128 AS size_mb, CASE WHEN is_percent_growth = 1 THEN CONCAT(growth,' %') ELSE CONCAT(growth/128,' MB') END AS growth FROM sys.master_files WHERE database_id > 4 AND (is_percent_growth = 1 OR growth/128 < 256) ORDER BY db;   — Korrektur für eine Inhaltsdatenbank ALTER DATABASE [WSS_Content_Intranet] MODIFY FILE (NAME = N'WSS_Content_Intranet', FILEGROWTH = 1GB); ALTER DATABASE [WSS_Content_Intranet] MODIFY FILE (NAME = N'WSS_Content_Intranet_log', FILEGROWTH = 1GB);

 

8 Hochverfügbarkeit und Disaster Recovery

8.1 Die Optionen im Vergleich

Verfahren	Schützt vor	Failover	Edition	Bewertung für SharePoint
Always On Availability Groups	Server-, Storage- und Standortausfall	automatisch (sync), manuell (async)	Enterprise (Basic AG in Standard)	Erste Wahl für mittlere und große Farmen
Failover Cluster Instance	Serverausfall, nicht Storage-Ausfall	automatisch	Standard (2 Knoten) und Enterprise	Solide und günstig, Shared Storage ist Single Point of Failure
Log Shipping	Standortausfall	manuell, Minuten bis Stunden	Standard und Enterprise	Brauchbar für DR, nicht für HA
Datenbankspiegelung	Serverausfall	automatisch mit Zeugen	veraltet	Abgekündigt, nicht mehr neu einsetzen
VM-Replikation / Snapshots	Hostausfall	Hypervisor	egal	Nur crash-konsistent, kein Ersatz für SQL-Backups

Tabelle 10: HA- und DR-Verfahren

8.2 Availability Group für SharePoint aufbauen

Der Ablauf hat sich bewährt: Erst die Farm auf dem primären Knoten bzw. direkt über den Listener anlegen, dann die Datenbanken in die AG aufnehmen. Wichtig ist, dass alle Datenbanken im Recovery-Modell FULL stehen und mindestens einmal vollständig gesichert wurden, bevor sie in die AG dürfen.

Windows-Failovercluster über alle SQL-Knoten bilden, Quorum mit Datei- oder Cloud-Zeugen.

Auf allen Knoten SQL Server identisch installieren und konfigurieren (Kapitel 4 und 5), Always On in SQL Server Configuration Manager aktivieren.

AG mit Listener anlegen, Endpunkte verschlüsseln, Seeding-Modus festlegen (automatisches Seeding spart bei vielen Datenbanken viel Handarbeit).

Alias auf allen SharePoint-Servern auf den Listener zeigen lassen.

Farm anlegen bzw. bestehende Datenbanken auf FULL stellen, Vollbackup ziehen, dann der AG hinzufügen.

Logins auf alle Replikate übertragen, und zwar mit identischer SID. Sonst klappt das Failover technisch, aber SharePoint kann sich danach nicht mehr anmelden.

MultiSubnetFailover für alle Datenbankverbindungen aktivieren, wenn die Knoten in verschiedenen Subnetzen stehen.

Failover testen, und zwar mit laufender Farm und echtem Seitenaufruf, nicht nur im SQL Management Studio.

PowerShell: AG-Integration # SharePoint-Datenbanken der AG hinzufügen (SharePoint-Cmdlet, Freigabe für Seeding) Get-SPDatabase | ForEach-Object { Add-DatabaseToAvailabilityGroup –AGName "AG-SP" –DatabaseName $_.Name -FileShare "\\fs01\SQLSeed" }   # MultiSubnetFailover für alle Datenbanken einschalten Get-SPDatabase | ForEach-Object { $_.MultiSubnetFailover = $true; $_.Update() }   # Status der AG aus SharePoint-Sicht Get-AvailabilityGroupStatus -Identity "AG-SP"

 

PowerShell: Logins synchronisieren # Logins mit identischer SID auf das Sekundärreplikat kopieren (dbatools) Install-Module dbatools -Scope CurrentUser Copy-DbaLogin -Source sqlsp01 -Destination sqlsp02, sqlsp03 -Login "CONTOSO\sp_farm", "CONTOSO\sp_apppool", "CONTOSO\sp_services"

 

AUS DEM CONSULTANT-ALLTAG · Failover bestanden, Farm tot Bei einem Failover-Test meldete der DBA stolz: „AG ist umgeschwenkt, alle Datenbanken synchron.“ Die SharePoint-Startseite zeigte trotzdem nur einen Korrelations-Fehler. Ursache: Das App-Pool-Konto existierte auf dem zweiten Knoten nicht als Login. Die Datenbanken kannten den Benutzer noch, aber die Instanz kannte den Login nicht. Zehn Minuten Arbeit, die man beim Aufbau erledigt, statt mitten im Ernstfall.

 

8.3 Der DR-Standort

Ein asynchrones Replikat an einem entfernten Standort schützt die wertvollen Datenbanken, also Inhalt, Managed Metadata, Profile, Secure Store. Am DR-Standort steht eine eigenständige, minimal ausgestattete SharePoint-Farm mit eigener Konfigurationsdatenbank bereit. Im Katastrophenfall wird das asynchrone Replikat erzwungen aktiviert, die Inhaltsdatenbanken werden an die DR-Farm angehängt, Dienstanwendungen auf die übernommenen Datenbanken gezeigt und die Suche neu gecrawlt. Das ist kein Fünf-Minuten-Klick, sondern ein Runbook, das mindestens einmal im Jahr geübt werden muss.

9 Betrieb: Backup, Integrität, Wartung, Patchen

Abbildung 5: Wartungsrhythmus für die SharePoint-Datenbankschicht

9.1 Backup-Strategie

SharePoint bringt eine eigene Farmsicherung mit, die über SQL-Backups und Konfigurationsexporte arbeitet. Für den Produktivbetrieb ist sie als alleinige Strategie zu schwerfällig. In der Praxis hat sich durchgesetzt: SQL-native Sicherungen aller Datenbanken als Fundament, ergänzt um gelegentliche Exporte der Farmkonfiguration und um den Secure-Store-Hauptschlüssel, die Farm-Passphrase und die Zertifikate, die getrennt und sicher verwahrt werden.

Sicherungsart	Rhythmus	Gilt für	Bemerkung
Vollbackup	wöchentlich, große DBs ggf. gestaffelt	alle Datenbanken	Mit CHECKSUM und Kompression
Differenziell	täglich	Inhalt, MMS, Profile	Verkürzt den Restore-Weg
Transaktionsprotokoll	alle 15 Minuten	alle DBs im Modell FULL	Ohne Log-Backups wächst das Log unbegrenzt
Copy-only	vor Upgrades und Migrationen	betroffene DBs	Unterbricht die Sicherungskette nicht
Farmkonfiguration	nach Änderungen	Konfigurationsexport	Backup-SPConfigurationDatabase

Tabelle 11: Bewährtes Sicherungsschema

ACHTUNG · Das 400-GB-Log Recovery-Modell FULL ohne Log-Backups ist die häufigste Ursache für vollgelaufene Platten in SharePoint-Umgebungen. SharePoint legt viele Datenbanken mit FULL an, und das Backup-Team sichert „ja eh jede Nacht voll“. Ein Vollbackup kürzt das Log aber nicht. Prüfe mit log_reuse_wait_desc in sys.databases, warum ein Log nicht geleert wird. Steht dort LOG_BACKUP, fehlt genau das.

 

9.2 Integrität prüfen

DBCC CHECKDB gehört zwingend in den Wartungsplan. Korrupte Seiten fallen sonst erst auf, wenn ein Benutzer das betroffene Dokument öffnen will, und dann ist die letzte saubere Sicherung womöglich schon rotiert. Bei sehr großen Inhaltsdatenbanken kann man die Last verteilen: wöchentlich PHYSICAL_ONLY und rotierend pro Wochenende eine Datenbank vollständig. Bei einer AG lässt sich die Prüfung auf einem Sekundärreplikat ausführen, ersetzt aber keine regelmäßige Prüfung auf dem Primärreplikat, da beide Seiten eigene physische Dateien haben.

9.3 Index- und Statistikpflege

Hier unterscheidet sich SharePoint am stärksten von normalen Anwendungen. SharePoint pflegt Indizes und Statistiken über Integritätsanalyse-Regeln selbst. Die Regeln für fragmentierte Indizes und veraltete Statistiken laufen täglich über einen Zeitgeberauftrag und rufen SharePoint-eigene Prozeduren auf, die den Datenbankaufbau kennen.

Prüfe, ob diese Integritätsregeln aktiv sind und die zugehörigen Zeitgeberaufträge erfolgreich laufen. In vielen Farmen sind sie irgendwann abgeschaltet worden, weil sie „zur Unzeit“ liefen.

Eigene Wartungsjobs, etwa mit Ola Hallengrens Skripten, sind möglich und bei großen Farmen sogar sinnvoll, sollten aber nur ergänzen: moderate Schwellenwerte, Statistiken mit vollem Scan außerhalb der Geschäftszeit, keine Doppelarbeit zur gleichen Zeit.

Nie die Datenbankoption Auto Create Statistics einschalten, um vermeintlich fehlende Statistiken zu ersetzen.

T-SQL: ergänzende Indexpflege — Ergänzende Wartung mit Ola Hallengren (Beispielaufruf, wöchentlich nachts) EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 10, @FragmentationLevel2 = 40, @MinNumberOfPages = 1000, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 1;

 

9.4 Schrumpfen

Schrumpfen von Datenbanken fragmentiert Indizes vollständig und erzeugt danach sofort wieder Wachstum. In SharePoint-Umgebungen ist es nur in einer einzigen Situation vertretbar: wenn nach dem Löschen oder Verschieben großer Datenmengen dauerhaft viel Platz frei bleibt und dieser Platz anderweitig gebraucht wird. Dann einmalig, gezielt mit Zielgröße, außerhalb der Geschäftszeit und mit anschließender Indexpflege. Ein Schrumpf-Job im Wartungsplan ist dagegen eine Garantie für schlechte Performance.

9.5 Patchen

SQL Server und SharePoint haben getrennte Patchzyklen, die sich gut in einem gemeinsamen monatlichen Fenster zusammenfassen lassen. Die Reihenfolge ist entscheidend:

Vollbackup oder zumindest Copy-only-Backup aller Datenbanken prüfen.

SQL Server zuerst: Bei einer AG erst die Sekundärreplikate patchen, dann manuelles Failover, dann den ehemaligen Primärknoten.

Dann SharePoint: CU-Binärdateien auf allen Servern installieren, anschließend den Konfigurations-Assistenten bzw. PSConfig Server für Server.

Mit Get-SPDatabase prüfen, ob noch Datenbanken ein Upgrade benötigen, und Kompatibilitätsgrad 150 kontrollieren.

PowerShell: Nach dem Patchen # Datenbanken, die nach einem CU noch ein Upgrade brauchen Get-SPDatabase | Where-Object { $_.NeedsUpgrade } | Select-Object Name, Type   # Einzelne Inhaltsdatenbank aktualisieren Upgrade-SPContentDatabase -Identity "WSS_Content_Intranet" -Confirm:$false   # PSConfig nach CU-Installation (auf jedem Server nacheinander) PSConfig.exe –cmd upgrade –inplace b2b –wait –cmd applicationcontent –install –cmd installfeatures –cmd secureresources

 

10 Monitoring und Performance-Optimierung

10.1 Wo es typischerweise klemmt

Bevor du an Stellschrauben drehst, miss. Die meisten Performance-Probleme in SharePoint-Datenbankschichten fallen in eine von fünf Kategorien, und jede hat eine typische Signatur in den Wartestatistiken.

Symptom / Wartetyp	Bedeutung	Häufige Ursache	Gegenmaßnahme
PAGEIOLATCH_SH, PAGEIOLATCH_EX	Warten auf Lesen vom Datenträger	Zu wenig RAM, langsames Daten-Volume	Speicher erhöhen, Storage-Latenz prüfen, große Listen entschärfen
WRITELOG	Warten auf Log-Schreiben	Langsames Log-Volume, synchrone AG über weite Strecke	Log auf schnellen Datenträger, AG-Latenz prüfen
HADR_SYNC_COMMIT	Warten auf das synchrone Replikat	Netzwerk oder Storage am Sekundärknoten	Sekundärknoten gleich stark ausstatten
LCK_M_*	Sperrkonflikte	Große Listen, Massenoperationen, lang laufende Workflows	Schwellenwerte für Listenansichten, Massenvorgänge zeitlich entzerren
PAGELATCH_* in TempDB	Allokationskonflikt	Zu wenige TempDB-Dateien	Dateien ergänzen, alle gleich groß
SOS_SCHEDULER_YIELD, hohe CPU	CPU-Druck	Falscher Kompatibilitätsgrad, Energieplan, zu niedriger Takt	Grad 150 setzen, Höchstleistung, Pläne prüfen

Tabelle 12: Wartetypen und ihre übliche Bedeutung bei SharePoint

10.2 Die wichtigsten Diagnoseabfragen

T-SQL: Datei-Latenzen — 1) Latenz pro Datenbankdatei seit dem letzten Neustart SELECT DB_NAME(vfs.database_id) AS db, mf.type_desc, mf.physical_name, vfs.num_of_reads, vfs.num_of_writes, CAST(vfs.io_stall_read_ms * 1.0 / NULLIF(vfs.num_of_reads, 0) AS decimal(10,1)) AS avg_read_ms, CAST(vfs.io_stall_write_ms * 1.0 / NULLIF(vfs.num_of_writes, 0) AS decimal(10,1)) AS avg_write_ms FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs JOIN sys.master_files AS mf ON vfs.database_id = mf.database_id AND vfs.file_id = mf.file_id ORDER BY avg_read_ms DESC;

 

T-SQL: Wartestatistiken — 2) Top-Wartetypen ohne die harmlosen Hintergrundwartezeiten SELECT TOP (15) wait_type, CAST(wait_time_ms / 1000.0 AS decimal(12,1)) AS wait_s, CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER () AS decimal(5,2)) AS pct, waiting_tasks_count FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ('SLEEP_TASK','LAZYWRITER_SLEEP','SQLTRACE_BUFFER_FLUSH', 'XE_TIMER_EVENT','XE_DISPATCHER_WAIT','REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE','BROKER_TO_FLUSH','BROKER_TASK_STOP', 'SP_SERVER_DIAGNOSTICS_SLEEP','HADR_FILESTREAM_IOMGR_IOCOMPLETION', 'DIRTY_PAGE_POLL','WAITFOR','SLEEP_SYSTEMTASK','QDS_PERSIST_TASK_MAIN_LOOP_SLEEP') AND wait_type NOT LIKE 'BROKER_%' AND wait_type NOT LIKE 'PREEMPTIVE_%' ORDER BY wait_time_ms DESC;

 

T-SQL: Konformität, Speicher, VLFs, Blockaden — 3) Konformitätscheck aller SharePoint-Datenbanken SELECT name, compatibility_level, recovery_model_desc, collation_name, is_auto_create_stats_on, is_auto_shrink_on, page_verify_option_desc, log_reuse_wait_desc FROM sys.databases WHERE database_id > 4 ORDER BY name;   — 4) Page Life Expectancy und Buffer-Pool-Druck SELECT object_name, counter_name, cntr_value FROM sys.dm_os_performance_counters WHERE counter_name IN ('Page life expectancy', 'Memory Grants Pending');   — 5) Anzahl Virtual Log Files je Datenbank (über 1.000 ist ein Warnsignal) SELECT d.name, COUNT(*) AS vlf_count FROM sys.databases AS d CROSS APPLY sys.dm_db_log_info(d.database_id) GROUP BY d.name ORDER BY vlf_count DESC;   — 6) Aktuelle Blockaden SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time, DB_NAME(r.database_id) AS db, t.text FROM sys.dm_exec_requests AS r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t WHERE r.blocking_session_id <> 0;

 

10.3 Stellschrauben mit Hebelwirkung

Die folgenden Maßnahmen sind nach Wirkung sortiert. Fang oben an, und hör auf, wenn die Messwerte gut sind. Tuning ohne Messung ist Aberglaube mit Admin-Rechten.

Nr.	Maßnahme	Typischer Effekt
1	Kompatibilitätsgrad 150 auf allen SharePoint-Datenbanken	Oft drastisch weniger CPU nach Migration auf SQL 2022/2025
2	Energieplan Höchstleistung auf SQL- und SharePoint-Servern	10 bis 30 % kürzere Antwortzeiten bei CPU-gebundenen Abfragen
3	Ausreichend RAM und korrektes max server memory	Weniger PAGEIOLATCH, stabile Page Life Expectancy
4	Log und TempDB auf getrenntes, schnelles Storage	Weniger WRITELOG- und TempDB-Wartezeiten
5	Dateien vorab dimensionieren, feste Wachstumsschritte	Keine Hänger durch Autogrowth, wenige VLFs
6	Große Inhaltsdatenbanken aufteilen	Kürzere Wartung, schnellere Restores, weniger Sperrkonflikte
7	BLOB-Cache auf den Frontends aktivieren	Statische Dateien kommen nicht bei jedem Aufruf aus SQL
8	Schwellenwerte für Listenansichten respektieren, indizierte Spalten nutzen	Weniger Sperren und Scans auf AllUserData
9	Usage-Datenbank schlank halten, Aufbewahrung kürzen	Weniger Schreiblast und Log-Volumen
10	Wartungsjobs zeitlich entzerren (Backup, CHECKDB, Indexpflege, Crawl)	Keine nächtlichen I/O-Staus

Tabelle 13: Optimierungsmaßnahmen nach Hebelwirkung

PRAXISTIPP · Remote BLOB Storage? RBS klingt verlockend: Dateien raus aus SQL, Datenbanken bleiben klein. In der Praxis lohnt es sich selten. Backup und Restore müssen dann zwei konsistente Bestände zusammenhalten, die Komplexität steigt und die Performance wird meist nicht besser. Für die meisten Farmen ist schnelles Storage plus sauberes Datenbank-Sharding der bessere Weg.

 

10.4 Überwachung im Alltag

SQL Server Agent-Alerts für Schweregrade 19 bis 25 sowie die Fehler 823, 824 und 825, die auf I/O-Probleme und beschädigte Seiten hinweisen.

Füllstand aller Volumes, insbesondere Log- und TempDB-Volume, mit Warnschwelle bei 80 %.

AG-Dashboard: Synchronisationsstatus, Redo-Queue und Log-Send-Queue.

Zertifikatslaufzeiten des SQL-TLS-Zertifikats, besonders bei Mandatory und Strict.

SharePoint-Integritätsanalyse regelmäßig ansehen, viele Datenbankprobleme tauchen dort zuerst auf.

T-SQL: Agent-Alerts — Alerts für I/O-Fehler und schwere Fehler einrichten EXEC msdb.dbo.sp_add_alert @name = N'Fehler 823', @message_id = 823, @include_event_description_in = 1; EXEC msdb.dbo.sp_add_alert @name = N'Fehler 824', @message_id = 824, @include_event_description_in = 1; EXEC msdb.dbo.sp_add_alert @name = N'Fehler 825', @message_id = 825, @include_event_description_in = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 19+', @severity = 19, @include_event_description_in = 1; — danach je Alert: msdb.dbo.sp_add_notification mit dem passenden Operator

 

11 Sicherheit und Härtung

Die SharePoint-Datenbanken enthalten im Klartext so ziemlich alles, was ein Angreifer sich wünscht: Dokumente, Berechtigungen, Profildaten. Wer Zugriff auf die Instanz hat, braucht SharePoint nicht mehr zu überlisten. Die Härtung der SQL-Ebene ist deshalb kein Kür-Programm.

Maßnahme	Umsetzung	Priorität
Verbindungen verschlüsseln	Mandatory, Zielbild Strict mit TDS 8.0 (Kapitel 6)	hoch
Minimale Rechte	Kein SharePoint-Konto als sysadmin, Rollen wie in Tabelle 7	hoch
Windows-Authentifizierung	Gemischten Modus vermeiden, sa deaktivieren und umbenennen	hoch
Netzwerk	Nur SharePoint-Server und Admin-Jump-Hosts auf den SQL-Port, alles andere blockieren	hoch
Backups schützen	Backup-Verschlüsselung mit Zertifikat, Ablage außerhalb der Domäne bzw. unveränderlich	hoch
Transparent Data Encryption	Für SharePoint-Datenbanken unterstützt, schützt Dateien und Backups im Ruhezustand	mittel
Oberfläche verkleinern	xp_cmdshell, CLR, OLE-Automation aus, SQL Browser aus	mittel
Überwachung	SQL Server Audit für Login-Fehler und Rechteänderungen	mittel
Admin-Zugänge	Getrennte Admin-Konten, privilegierter Zugriff nur über PAW oder Jump-Host	mittel

Tabelle 14: Härtungsmaßnahmen für die Datenbankschicht

ACHTUNG · Secure Store und Passphrase Der Hauptschlüssel des Secure Store und die Farm-Passphrase stehen nicht in der SQL-Sicherung. Ohne sie ist eine wiederhergestellte Secure-Store-Datenbank ein hübscher, aber nutzloser Datenhaufen. Beides gehört verschlüsselt in den Tresor, und zwar dort, wo man auch im Katastrophenfall hinkommt.

 

12 Die zehn beliebtesten Fehler

Eine Hitliste aus vielen Jahren Analyse von SharePoint-Datenbankschichten. Wenn du drei oder mehr davon in deiner Umgebung wiedererkennst: herzlichen Glückwunsch, du hast gerade einen Projektplan.

Nr.	Fehler	Folge	Abhilfe
1	MAXDOP ungleich 1	Farm-Anlage oder Updates scheitern, unvorhersehbare Pläne	MAXDOP 1, SharePoint auf eigene Instanz
2	Recovery-Modell FULL ohne Log-Backups	Logdateien wachsen bis die Platte voll ist	Log-Backups alle 15 Minuten
3	Kompatibilitätsgrad 160 oder 170	Höhere CPU-Last, schlechtere Pläne	Grad 150, model ebenfalls
4	Schrumpf-Job im Wartungsplan	Fragmentierung und ständiges Nachwachsen	Job löschen, Dateien richtig dimensionieren
5	Autogrowth 10 % oder 1 MB	Hänger und tausende VLFs	Feste Schritte, Vorab-Größe
6	Eine TempDB-Datei	Allokationskonflikte unter Last	Mehrere gleich große Dateien
7	Kein SQL-Alias	Jeder Serverwechsel wird zur Farm-Operation	Alias auf allen SharePoint-Servern
8	SharePoint-Konten als sysadmin	Sicherheitsrisiko, Prüfungsbefunde	Rechte zurückbauen, testen
9	Logins nicht auf AG-Replikate übertragen	Failover klappt, Farm nicht	Logins mit SID kopieren
10	Nie ein Restore getestet	Böses Erwachen im Ernstfall	Monatlicher Restore-Test

Tabelle 15: Häufige Fehler und ihre Abhilfe

13 Checkliste für die Inbetriebnahme

Zum Abhaken vor dem Go-live, und gerne auch einmal im Jahr für die bestehende Farm. Die Spalte „Erledigt“ ist zum Ausdrucken gedacht.

Bereich	Prüfpunkt	Erledigt
Plattform	SQL Server 2022 oder neuer (mind. 2019 CU5), Standard oder Enterprise, aktuelles CU
Plattform	Eigene Instanz nur für SharePoint
Windows	Energieplan Höchstleistung, Virenscanner-Ausnahmen gesetzt
Storage	Getrennte Volumes für Daten, Log, TempDB, Backup, 64 KB Zuordnungseinheit
Setup	Kollation Latin1_General_CI_AS_KS_WS, Instant File Initialization aktiv
Instanz	MAXDOP 1, max/min server memory gesetzt, Backup-Kompression an
TempDB	Dateianzahl passend zu den Kernen, alle gleich groß, feste Wachstumsschritte
model	Kompatibilitätsgrad 150, sinnvolle Startgröße und Wachstum
Konten	gMSA für Dienste, SPN registriert, Setup- und Farmkonto ohne sysadmin
Anbindung	SQL-Alias auf allen SharePoint-Servern, fester Port
Verschlüsselung	Zertifikat mit passendem SAN, Mandatory oder Strict, Ablauf überwacht
Datenbanken	Alle auf Grad 150, Recovery-Modelle gemäß Tabelle 8, kein Auto Shrink
HA/DR	AG oder FCI getestet, Logins auf allen Replikaten, MultiSubnetFailover
Backup	Voll, Diff, Log eingeplant, Restore-Test erfolgreich, Schlüssel verwahrt
Wartung	CHECKDB eingeplant, SharePoint-Integritätsregeln aktiv, kein Schrumpf-Job
Monitoring	Agent-Alerts 823/824/825 und Severity 19+, Volume-Füllstand, AG-Status

Tabelle 16: Inbetriebnahme-Checkliste

14 Häufige Fragen (FAQ)

Die Fragen, die in Workshops und Projekten zuverlässig auftauchen, meist kurz nachdem jemand „Das haben wir schon immer so gemacht“ gesagt hat.

Läuft SharePoint SE auf SQL Server 2025?

Ja. Microsoft unterstützt jede Standard- oder Enterprise-Edition von SQL Server für Windows, die den Kompatibilitätsgrad 150 anbietet. SQL Server 2025 erfüllt das. Die SharePoint-Datenbanken laufen trotzdem auf Grad 150, nicht auf dem Standard der Instanz. Für eine Neuinstallation ist SQL Server 2022 weiterhin die ausgereiftere Wahl, ein Fehler ist 2025 aber nicht.

Darf ich SQL Server Express für ein kleines Team oder ein Testsystem nehmen?

Nein. SQL Server Express ist für SharePoint SE nicht unterstützt, auch nicht für Testfarmen. Für Labore und Entwicklungsumgebungen gibt es die kostenlose Developer-Edition, die funktional der Enterprise-Edition entspricht, aber nicht produktiv eingesetzt werden darf.

Warum muss MAXDOP unbedingt auf 1 stehen?

Weil SharePoint seine Abfragen auf serielle Ausführung ausgelegt hat und das beim Anlegen der Farm prüft. Parallele Pläne führen bei den typischen SharePoint-Abfragen eher zu Sperrkonflikten und schwankenden Antwortzeiten als zu Beschleunigung. Steht MAXDOP nicht auf 1, scheitert das Anlegen der Konfigurationsdatenbank. Der Wert gilt instanzweit, deshalb gehört SharePoint auf eine eigene Instanz.

Kann ich MAXDOP nur für die SharePoint-Datenbanken auf 1 setzen und die Instanz teilen?

Technisch gibt es seit SQL Server 2016 datenbankweite Konfigurationen für MAXDOP. SharePoint prüft aber die Instanzeinstellung, und Microsoft empfiehlt ausdrücklich eine dedizierte Instanz. Die geteilte Instanz bleibt eine Quelle für Konflikte bei Speicher, Patchfenstern und Wartung. Mein Rat: nicht tricksen, sondern trennen.

Muss ich den Kompatibilitätsgrad wirklich auf 150 zurückdrehen?

Ja. Microsoft empfiehlt das ausdrücklich, weil SharePoint SE gegen Grad 150 getestet und validiert ist. Auf höheren Graden arbeitet der Optimierer anders, was bei SharePoint zu höherer CPU-Last und schlechteren Abfrageplänen führen kann. Am bequemsten setzt du model auf 150, dann erben neue Datenbanken den richtigen Wert automatisch.

Brauche ich Enterprise oder reicht Standard?

Für eine Farm ohne Hochverfügbarkeit oder mit einer Zwei-Knoten-Failover-Cluster-Instanz reicht Standard. Sobald du Availability Groups mit vielen Datenbanken oder einen lesbaren bzw. dritten Knoten für DR willst, führt an Enterprise kein vernünftiger Weg vorbei. Basic Availability Groups in Standard funktionieren zwar, bedeuten aber eine AG samt Listener pro Datenbank.

Wie groß darf eine Inhaltsdatenbank werden?

Empfohlen sind bis zu 200 GB. Bis 4 TB sind bei Kollaborationsszenarien unterstützt, wenn das Storage mindestens 0,25 IOPS pro GB liefert und die Backup- und Restore-Strategie dazu passt. Die eigentliche Obergrenze setzt aber deine akzeptable Wiederherstellungszeit. Eine 3-TB-Datenbank, deren Restore zwölf Stunden dauert, ist für eine Fachabteilung keine Option, wenn sie nach vier Stunden wieder arbeiten muss.

Soll ich die Indexpflege SharePoint überlassen oder eigene Jobs bauen?

Beides, aber mit klarer Rollenverteilung. SharePoint pflegt Indizes und Statistiken über Integritätsanalyse-Regeln und eigene Prozeduren. Diese Regeln sollten aktiv sein. Ergänzende Wartungsjobs, etwa mit Ola Hallengrens Skripten, sind bei großen Farmen sinnvoll, wenn sie moderate Schwellenwerte nutzen und nicht zeitgleich mit den SharePoint-Zeitgeberaufträgen laufen. Tabu bleibt das Einschalten von Auto Create Statistics.

Welches Recovery-Modell ist richtig?

Für Inhaltsdatenbanken und alles, was in einer Availability Group liegt: FULL, und zwar zwingend mit regelmäßigen Log-Backups. Für Suchdatenbanken und die Usage-Datenbank ohne AG ist SIMPLE üblich. Die Kombination FULL ohne Log-Backups ist dagegen ein Klassiker für vollgelaufene Platten.

Bringt Strict-Verschlüsselung mit TDS 8.0 Performance-Nachteile?

Im Alltag kaum messbar. TLS-Aushandlungen fallen beim Verbindungsaufbau an, und SharePoint arbeitet mit Verbindungspooling. Der eigentliche Aufwand liegt im Betrieb: Zertifikat mit passendem Namen, vertrauenswürdige Zertifizierungsstelle, Überwachung des Ablaufdatums. Läuft das Zertifikat bei Strict ab, steht die Farm. Deshalb gehört Strict in eine Umgebung mit funktionierender PKI-Pflege.

Kann ich SharePoint-Datenbanken mit TDE verschlüsseln?

Ja. Transparent Data Encryption ist für SharePoint-Datenbanken unterstützt, da sie unterhalb der Anwendungsebene arbeitet. Wichtig ist die Sicherung des TDE-Zertifikats samt privatem Schlüssel. Ohne dieses Zertifikat ist jedes Backup wertlos, und ein Restore auf einem anderen Server scheitert.

Hilft Remote BLOB Storage gegen große Datenbanken?

Selten. RBS verschiebt Dateiinhalte aus SQL Server in einen externen Speicher, erhöht aber die Komplexität bei Backup, Restore und Konsistenz deutlich. Die Datenbankgrenzen bleiben im Wesentlichen gleich, weil die Metadaten weiter in SQL liegen. In den meisten Fällen ist eine sinnvolle Aufteilung auf mehrere Inhaltsdatenbanken die bessere Antwort.

Darf ich SharePoint-Datenbanken schrumpfen?

Einmalig und gezielt nach großen Lösch- oder Verschiebeaktionen ja, regelmäßig nein. Schrumpfen fragmentiert die Indizes und erzeugt danach sofort neues Wachstum. Auto Shrink und Schrumpf-Jobs im Wartungsplan gehören abgeschafft.

Wie oft sollte ich einen Restore testen?

Mindestens monatlich eine Inhaltsdatenbank auf ein Testsystem zurückspielen und an eine Testfarm anhängen, zusätzlich einmal im Jahr den vollständigen DR-Ablauf üben. Ein Backup, dessen Restore nie getestet wurde, ist nur eine Vermutung mit Dateiendung.

Anhang: Skriptsammlung

A.1 Schnell-Audit einer bestehenden Instanz

Dieses Skript liefert in einem Durchlauf die wichtigsten Abweichungen vom Sollzustand. Es ändert nichts und kann gefahrlos auf Produktivsystemen laufen.

T-SQL: Schnell-Audit SET NOCOUNT ON; — Instanzebene SELECT 'Instanz' AS ebene, name AS einstellung, CAST(value_in_use AS nvarchar(50)) AS ist, CASE name WHEN 'max degree of parallelism' THEN '1' WHEN 'backup compression default' THEN '1' WHEN 'remote admin connections' THEN '1' END AS soll FROM sys.configurations WHERE name IN ('max degree of parallelism','backup compression default','remote admin connections') UNION ALL SELECT 'Instanz', 'Kollation', CAST(SERVERPROPERTY('Collation') AS nvarchar(50)), 'Latin1_General_CI_AS_KS_WS' UNION ALL SELECT 'Instanz', 'TempDB-Datendateien', CAST(COUNT(*) AS nvarchar(50)), 'Kerne, max. 8' FROM tempdb.sys.database_files WHERE type = 0;   — Datenbankebene: nur Abweichungen SELECT name AS datenbank, IIF(compatibility_level <> 150, CONCAT('Grad ', compatibility_level), NULL) AS kompatibilitaet, IIF(is_auto_shrink_on = 1, 'Auto Shrink AN', NULL) AS shrink, IIF(is_auto_create_stats_on = 1, 'Auto Create Stats AN', NULL) AS stats, IIF(log_reuse_wait_desc = 'LOG_BACKUP', 'Log-Backup fehlt', NULL) AS logbackup FROM sys.databases WHERE database_id > 4 AND (compatibility_level <> 150 OR is_auto_shrink_on = 1 OR is_auto_create_stats_on = 1 OR log_reuse_wait_desc = 'LOG_BACKUP');

 

A.2 Alle SharePoint-Datenbanken auf Grad 150 setzen

T-SQL: Kompatibilitätsgrad in Serie DECLARE @sql nvarchar(max) = N''; SELECT @sql += N'ALTER DATABASE ' + QUOTENAME(name) + N' SET COMPATIBILITY_LEVEL = 150;' + CHAR(13) FROM sys.databases WHERE database_id > 4 AND compatibility_level <> 150 AND state_desc = 'ONLINE'; PRINT @sql; — erst prüfen … — EXEC sp_executesql @sql; — … dann ausführen

 

A.3 Datenbankübersicht aus SharePoint-Sicht

PowerShell: Farm-Datenbanken inventarisieren Get-SPDatabase | Sort-Object Type, Name | Select-Object Name, Type, @{n="Server";e={$_.NormalizedDataSource}}, @{n="SizeGB";e={[math]::Round($_.DiskSizeRequired/1GB,2)}}, NeedsUpgrade | Format-Table –AutoSize

 

A.4 Log-Backup für alle FULL-Datenbanken

T-SQL: Log-Sicherung, AG-tauglich über bevorzugtes Replikat DECLARE @db sysname, @file nvarchar(400), @ts char(15) = FORMAT(SYSDATETIME(), 'yyyyMMdd_HHmmss'); DECLARE c CURSOR LOCAL FAST_FORWARD FOR SELECT name FROM sys.databases WHERE recovery_model_desc = 'FULL' AND state_desc = 'ONLINE' AND database_id > 4 AND sys.fn_hadr_backup_is_preferred_replica(name) = 1; OPEN c; FETCH NEXT FROM c INTO @db; WHILE @@FETCH_STATUS = 0 BEGIN SET @file = N'B:\Backup\' + @db + N'_LOG_' + @ts + N'.trn'; BACKUP LOG @db TO DISK = @file WITH COMPRESSION, CHECKSUM; FETCH NEXT FROM c INTO @db; END CLOSE c; DEALLOCATE c;

 

MERKSATZ · Zum Schluss Ein SQL Server für SharePoint ist kein Hexenwerk. Er braucht eine eigene Instanz, MAXDOP 1, Grad 150, ordentliches Storage, lückenlose Backups mit getestetem Restore und jemanden, der regelmäßig hinschaut. Wer diese Hausaufgaben macht, hat eine Farm, über die im Unternehmen niemand redet. Und genau das ist das größte Kompliment für einen Administrator.

 

Quellen

Alle Angaben zu Supportstand, Grenzwerten und Konfigurationsvorgaben beruhen auf der Microsoft-Dokumentation. Stand der Prüfung: Oktober 2026.

Software requirements for database servers for SharePoint Server Subscription Edition · unterstützte SQL-Server- und Windows-Versionen, Ausschluss von Express und Azure SQL Database

Supported SQL Server database compatibility level for SharePoint Server installations · Empfehlung Kompatibilitätsgrad 150 für SharePoint SE

Best practices for SQL Server in a SharePoint Server farm · MAXDOP, dedizierte Instanz, Statistiken, Speicher und Wartung

Configure SQL Server Always On Availability Groups for SharePoint Server · Aufbau einer AG für SharePoint

Connect-SPConfigurationDatabase · Parameter DatabaseConnectionEncryption mit den Stufen Optional, Mandatory und Strict ab Version 24H2

New-SPConfigurationDatabase · Anlegen der Farm einschließlich Verschlüsselungsstufe

TDS 8.0 · Strict-Verschlüsselung, Kompatibilitätsmatrix zu TLS und Betriebssystem

Transport Layer Security (TLS) 1.3 Support · TLS 1.3 in SharePoint SE ab Windows Server 2022