Bewährte Methoden für SQL Server in einer SharePoint Server-Farm
GILT FÜR:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Wenn Sie relationale SharePoint Server 2016- und 2019-Datenbanken unter SQL Server 2014 mit Service Pack 1 (SP1), SQL Server 2016 oder SQL Server 2017 RTM konfigurieren und verwalten, müssen Sie Optionen auswählen, die die Leistung und Sicherheit erhöhen. Ebenso müssen Sie Optionen auswählen, mit denen Leistung und Sicherheit gesteigert werden können, wenn Sie relationale SharePoint Server 2013-Datenbanken auf SQL Server 2008 R2 mit Service Pack 1 (SP1), SQL Server 2012 und SQL Server 2014 konfigurieren und pflegen.
Die in diesem Artikel aufgeführten bewährten Methoden sind nach der Reihenfolge sortiert, in der Sie vorgenommen werden - von der Installation und Konfiguration von SQL Server über die Bereitstellung von SharePoint Server bis zur Wartung der Farm. Die meisten Methoden gelten für alle SQL Server-Versionen. Methoden, die nur für eine der SQL Server-Versionen gelten, sind in separaten Abschnitten aufgeführt.
Hinweis
[!HINWEIS] Wenn Sie SQL Server Business Intelligence-Komponenten in einer SharePoint Server 2016-Farm verwenden möchten, müssen Sie mit SQL Server 2016 CTP 3.1 oder höher arbeiten. Sie können SQL Server 2016 CTP 3.1 oder höher herunterladen, um das SQL Server PowerPivot für SharePoint-Add-In zu verwenden. Sie können auch Power View verwenden, indem Sie SQL Server Reporting Services (SSRS) im SharePoint-integrierten Modus und das SSRS-Front-End-Add-In von den SQL Server-Installationsmedien installieren.
Um weitere Informationen zu erhalten, laden Sie das neue Whitepaper Bereitstellen von SQL Server 2016 PowerPivot und Power View in SharePoint 2016 herunter. Um weitere Informationen zum Konfigurieren und Bereitstellen von Business Intelligence in einer SharePoint Server 2016-Farm mit mehreren Servern zu erhalten, laden Sie Bereitstellen von SQL Server 2016 PowerPivot und Power View in SharePoint 2016-Farm mit mehreren Ebenen herunter.
Hinweis
[!HINWEIS] Wenn Sie den Einsatz von SQL Server Business Intelligence-Komponenten in einer SharePoint Server 2013-Farm planen, müssen Sie SQL Server 2012 mit Service Pack 1 (SP1) oder SQL Server 2014 2013 verwenden. Informationen zu SQL Server 2012 mit SP1 BI und SharePoint Server 2013 finden Sie unter Installieren der BI-Funktionen von SQL Server mit SharePoint 2013 (SQL Server 2012 SP1). Weitere Informationen zu SQL Server 2014 und SharePoint Server 2013 finden Sie unter Installieren von SQL Server 2014 Business Intelligence-Funktionen.
Wichtig
Die in diesem Artikel aufgeführten bewährten Methoden gelten für das relationale Datenbankverwaltungssystem (Relational Database Management System, RDBMS) von SQL Server mit SharePoint Server.
Verwendung eines dedizierten Servers für SQL Server
Um eine optimale Leistung für Farmvorgänge sicherzustellen, wird empfohlen, SQL Server auf einem dedizierten Server zu installieren, auf dem keine anderen Farmrollen ausgeführt werden und keine Datenbanken für andere Anwendungen gehostet werden. Die einzige Ausnahme ist die Bereitstellung von SharePoint Server 2016 oder 2019 in einer Single-Server Farmrolle oder SharePoint 2013 auf einem eigenständigen Server, der für Entwicklung oder Tests bestimmt ist und nicht für die Produktion empfohlen wird. Weitere Informationen finden Sie unter Beschreibung von MinRole und den zugehörigen Diensten in SharePoint Server 2016 und 2019 und Installieren von SharePoint Server 2016 oder 2019 auf einem Server.
Hinweis
Die Empfehlung für den Einsatz eines dedizierten Servers für relationale Datenbanken gilt auch für die Bereitstellung von SQL Server in virtuellen Umgebungen.
Konfigurieren spezieller SQL Server-Einstellungen vor dem Bereitstellen von SharePoint Server
Zur Sicherstellung einer durchgängigen Arbeitsweise und Leistung sollten Sie vor dem Bereitstellen von SharePoint Server die folgenden Optionen und Einstellungen konfigurieren.
Aufgrund potenzieller Leistungsprobleme bei der Verwaltung mehrerer SQL-Instanzen wird empfohlen, pro bereitgestelltem Datenbankserver eine einzelne Instanz von SQL Server zu verwenden.
Aktivieren Sie bei SharePoint-Inhaltsdatenbanken nicht das automatische Erstellen von Statistiken. Automatisch erstellte Statistiken werden für SharePoint Server nicht unterstützt. SharePoint Server konfiguriert die erforderlichen Einstellungen während der Bereitstellung und des Upgrades. Wenn die automatische Erstellung von Statistiken bei einer SharePoint-Datenbank manuell aktiviert wird, kann sich dadurch der Ausführungsplan von Abfragen erheblich ändern. Die SharePoint-Datenbanken greifen entweder auf eine gespeicherte Prozedur zurück, die die Statistiken führt (proc_UpdateStatistics), oder verlassen sich zu diesem Zweck auf SQL Server.
Für SharePoint Server 2013 werden Wartungspläne von SharePoint verwaltet:
- SQL-Statistiken werden von der Integritätsregel "Von SharePoint verwendete Datenbanken verfügen über veraltete Indexstatistiken" verwaltet, die proc_updatestatics
- Für Inhaltsdatenbanken ist die Eigenschaft Statistik automatisch aktualisieren auf False festgelegt.
Für SharePoint Server 2016 und 2019 muss der SQL-Administrator Wartungspläne für SharePoint-Inhaltsdatenbanken erstellen:
- SQL-Statistiken werden nicht durch die Integritätsregel "Von SharePoint verwendete Datenbanken verfügen über veraltete Indexstatistiken" verwaltet.
- Für Inhaltsdatenbanken ist die Eigenschaft Statistik automatisch aktualisieren auf True festgelegt. `
Legen Sie für Instanzen von SQL Server, die SharePoint-Datenbanken hosten, einen MAXDOP-Wert (maximaler Grad an Parallelität) von 1 fest, um sicherzustellen, dass jede Anforderung von einem einzigen SQL Server-Prozess verarbeitet wird.
Wichtig
Ein anderer MAXDOP-Wert kann dazu führen, dass ein suboptimaler Abfrageplan verwendet wird, wodurch sich die Leistung von SharePoint Server verringert.
Zum Vereinfachen von Wartungsaufgaben (zum Beispiel, um das Verschieben von Datenbanken auf einen anderen Server zu erleichtern) erstellen Sie DNS-Aliase, die auf die IP-Adresse sämtlicher SQL Server-Instanzen zeigen. Weitere Informationen zu DNS- oder Hostnamen-Aliase finden Sie unter Hinzufügen eines Hostnamen-Alias für eine SQL Server Instanz.
Weitere Informationen zu diesen Einstellungen und Optionen von SQL Server finden Sie unter Festlegen von SQL Server-Optionen.
Verstärken der Sicherheit des Datenbankservers vor dem Bereitstellen von SharePoint Server
Es wird empfohlen, vor der Bereitstellung von SharePoint Server entsprechende Maßnahmen zu planen und durchzuführen, mit denen die Sicherheit des Datenbankservers verstärkt wird. Weitere Informationen dazu finden Sie unter:
Konfigurieren von SQL Server-Sicherheit für SharePoint Server
Sichern von SharePoint: Verstärken der Sicherheit von SQL Server in SharePoint-Umgebungen
Sicherheitscenter für SQL Server-Datenbankmodul und Azure SQL-Datenbank
Konfigurieren des Datenbankservers für Leistung und Verfügbarkeit
Wie bei Front-End-Servern und Anwendungsservern hat auch bei Datenbankservern die Konfiguration einen Einfluss darauf, wie gut die Leistung von SharePoint Server ist. Einige Datenbanken müssen sich auf dem gleichen Server wie andere Datenbanken befinden. Ebenso können manche Datenbanken nicht zusammen auf dem gleichen Server untergebracht werden. Weitere Informationen finden Sie unter Description of MinRole and associated services in SharePoint Servers 2016 and 2019 and Storage and SQL Server capacity planning and configuration (SharePoint Server).
Anleitungen für hochverfügbare, gespiegelte Datenbanken finden Sie unter Datenbankspiegelung (SQL Server).
Failoverclustering und AlwayOn-Verfügbarkeitsgruppen in SQL Server
IN SQL Server 2012 wurde das Feature Always On-Verfügbarkeitsgruppen eingeführt. Dieses Feature ist eine Lösung für hohe Verfügbarkeit und Notfallwiederherstellung und stellt eine Alternative zu Lösungen für Datenbankspiegelung und Protokollversand dar. Always On-Verfügbarkeitsgruppen unterstützen jetzt bis zu neun Verfügbarkeitsreplikate.
Hinweis
[!HINWEIS] Datenbankspiegelung wird in künftigen Versionen von SQL Server nicht mehr unterstützt. Es wird empfohlen, AlwaysOn-Verfügbarkeitsgruppen zu verwenden.
Always On-Verfügbarkeitsgruppen erfordern einen WSFC-Cluster (Windows Server Failover Clustering). Für jede Verfügbarkeitsgruppe, die erstellt wird, wird eine WSFC-Ressourcengruppe erstellt. Weitere Informationen finden Sie in den folgenden Ressourcen:
Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Konfigurieren von SQL Server Always On-Verfügbarkeitsgruppen für SharePoint Server
Auslegung des Speichers für maximalen Durchsatz und optimale Verwaltbarkeit
Es wird empfohlen, dass Sie Ihre Daten auf den Laufwerken im Datenbankserver verteilen und entsprechend priorisieren. Die beste Lösung wäre, die Datenbank "tempdb", die Inhaltsdatenbanken, Verwendungsdatenbank, Suchdatenbanken und die Transaktionsprotokolle auf unterschiedlichen physischen Festplatten unterzubringen. Die folgende Liste enthält einige Ratschläge dazu. Weitere Informationen finden Sie unter Konfigurieren von Datenbanken.
Bei Websites für Zusammenarbeitszwecke oder bei Websites, die häufig aktualisiert werden, gehen Sie bei der Speicherverteilung wie folgt vor.
Je höher ein Element in der Liste aufgeführt ist, umso schneller sollte das Laufwerk sein, auf dem Sie es unterbringen.
Rang Element 1 tempdb-Datendateien und Transaktionsprotokolle 2 Transaktionsprotokolldateien der Inhaltsdatenbank 3 Suchdatenbanken außer der Suchverwaltungsdatenbank 4 Inhaltsdatenbank-Datendateien Bei Portal-Websites, bei denen vor allem mit Lesezugriffen zu rechnen ist, sollten Daten- und Suchelemente vor Transaktionsprotokollen die Priorität haben:
Je höher ein Element in der Liste aufgeführt ist, umso schneller sollte das Laufwerk sein, auf dem Sie es unterbringen.
Rang Element 1 tempdb-Datendateien und Transaktionsprotokolle 2 Inhaltsdatenbank-Datendateien 3 Suchdatenbanken außer der Suchverwaltungsdatenbank 4 Transaktionsprotokolldateien der Inhaltsdatenbank Tests und Benutzerdaten haben gezeigt, dass eine unzureichende E/A-Leistung der tempdb-Festplatte die Gesamtleistung der Farm erheblich in Mitleidenschaft ziehen kann. Um dies zu vermeiden, sollten Sie für Dateien, in denen tempdb-Daten gespeichert werden, dedizierte Festplatten vorsehen.
Die beste Leistung erzielen Sie, wenn Sie für das Laufwerk, auf dem Dateien mit tempdb-Daten gespeichert werden, ein RAID 10-Array einsetzen. Die Anzahl der tempdb-Datendateien sollte mit der Anzahl der CPU-Kerne übereinstimmen, und für alle tempdb-Datendateien sollte die gleiche Größe festgelegt sein.
Teilen Sie die Dateien für Datenbankdaten und Transaktionsprotokolle auf unterschiedliche Festplatten auf. Wenn sich Daten- und Protokolldateien aufgrund von Speicherbeschränkungen Festplatten miteinander teilen müssen, sollten Sie auf einer Festplatte Dateien mit unterschiedlichen Nutzungsmustern platzieren, um zu vermeiden, dass auf alle Dateien auf der gleichen Festplatte gleichzeitig zugegriffen wird.
Verwendung mehrerer Dateien bei häufig genutzten Inhaltsdatenbanken, wobei die Dateien auf unterschiedlichen Festplatten platziert werden
Anstatt die Datenbankgröße zu begrenzen, sollten Sie Inhaltsdatenbanken überwachen und gegebenenfalls Anpassungen vornehmen, damit diese nicht größer als 200 GB werden. So können Inhaltsdatenbanken besser verwaltet werden.
Hinweis
Wenn Sie die Datenbankgröße in SQL Server begrenzen, können bei einem Überschreiten der Kapazität unerwartete Ausfallzeiten auftreten.
Eine korrekte Konfiguration der E/A-Subsysteme ist für eine optimale Leistung und einen dauerhaften Betrieb von SQL Server-Systemen überaus wichtig. Weitere Informationen dazu finden Sie unter Überwachen der Datenträgerverwendung.
Tipp
[!TIPP] Beachten Sie, dass die Laufwerksgeschwindigkeit bei Datendateien und Protokolldateien unterschiedlich ausfällt. Die schnellsten Laufwerke für Datenbankdateien müssen nicht auch die schnellsten für Protokolldateien sein. Bei diesem Punkt sind Nutzungsmuster, E/A-Vorgänge und Dateigrößen zu berücksichtigen.
Proaktive Verwaltung der Größenzunahme von Daten- und Protokolldateien
Für eine proaktive Verwaltung der Größenzunahme von Daten- und Protokolldateien gibt es die folgenden Empfehlungen:
Wenn möglich, sollten Sie alle Daten- und Protokolldateien auf ihre voraussichtliche Endgröße anwachsen lassen oder diese regelmäßig in festgelegten Abständen (z. B. jeden Monat oder alle sechs Monate) oder vor dem Rollout einer neuen speicherintensiven Website (z. B. während Dateimigrationen) anwachsen lassen.
Aktivieren Sie vorsichtshalber die automatische Vergrößerungsfunktion von Datenbanken, um sicherzustellen, dass für die Daten- und Protokolldateien nicht plötzlich kein freier Speicherplatz mehr vorhanden ist. Berücksichtigen Sie dabei Folgendes:
Wichtig
[!WICHTIGER HINWEIS] Bei Aktivierung der automatischen Vergrößerungsfunktion müssen Sie die damit verbundenen Auswirkungen auf Leistung und Betrieb mit in Betracht ziehen. Weitere Informationen dazu finden Sie unter Anmerkungen zu den Einstellungen „Automatische Vergrößerung" und „Automatische Verkleinerung" in SQL Server.
Laut den Standardeinstellungen für eine neue Datenbank ist eine Größenzunahme in Schritten von 1 MB erlaubt. Da diese Standardeinstellung bei aktivierter automatischer Vergrößerung zu einem Wachstum der Datenbank führen würde, sollten Sie sich nicht auf die Standardeinstellung verlassen. Richten Sie sich stattdessen nach den Richtlinien, die unter Festlegen von SQL Server-Optionen aufgeführt sind.
Legen Sie die automatische Vergrößerung nicht absolut in Megabyte, sondern in prozentualer Form fest. Je größer die Datenbank wird, umso größer sollte die Wachstumszunahme sein.
Hinweis
Gehen Sie beim Festlegen der automatischen Vergrößerungsfunktion für SharePoint-Datenbanken umsichtig vor. Wenn Sie die automatische Vergrößerung für eine Datenbank in prozentualer Form festlegen (z. B. 10 Prozent), wird eine 5 GB große Datenbank jedes Mal um 500 MB größer, wenn eine Datendatei erweitert werden muss. In solchen Fällen kann der freie Speicherplatz auf der Festplatte schnell aufgebraucht werden.
Werfen wir einen Blick auf das folgende Szenario: Eine Inhaltsdatenbank soll in Schritten von 100 MB wachsen, und für die automatische Vergrößerung ist ein Wert von 10 MB festgelegt. Dann wird plötzlich eine neue Dokumentverwaltungs-Website hinzugefügt, die sehr viel Speicherplatz benötigt (z. B. 50 GB zu Beginn). Bei solch einer großen Zunahme ist ein Wachstum in Schritten von 500 MB geeigneter als in Schritten von 10 MB Größe.
Bei einem verwalteten Produktionssystem sollten Sie die automatische Vergrößerung lediglich als Notfallreserve für unerwartete Größenzunahmen betrachten. Setzen Sie die automatische Vergrößerungsoption nicht zur täglichen Verwaltung der Größe Ihrer Daten- und Protokolldateien ein. Legen Sie die automatische Vergrößerung stattdessen so fest, dass sie für ein Jahr ausreicht, und fügen Sie dann sicherheitshalber noch einen Betrag von 20 Prozent hinzu. Stellen Sie außerdem einen Alarm ein, damit Sie benachrichtigt werden, falls der Speicherplatz für die Datenbank knapp wird oder die Datenbank sich ihrer maximalen Größe nähert.
Achten Sie darauf, dass für Größenzunahmen oder Spitzenlasten immer mindestens 25 Prozent an freiem Speicherplatz verfügbar sind. Wenn Sie einem RAID-Array Laufwerke hinzufügen oder mehr Speicher für die Verwaltung reservieren, müssen Sie die Kapazität genau überwachen, damit immer genügend Speicherplatz frei ist.
Permanente Überwachung von SQL Server-Speicher und -Leistung
Sie sollten den Speicherverbrauch und die Leistung von SQL Server permanent überwachen, um sicherzustellen, dass jeder im Produktionseinsatz befindliche Datenbankserver seine Arbeitslasten angemessen bewältigen kann. Außerdem erhalten Sie auf diese Weise Einblicke in die Leistung, die Sie bei Ihrer Ressourcenplanung nutzen können.
Verschaffen Sie sich einen umfassenden Überblick über alle Ressourcen. Beschränken Sie sich bei der Überwachung nicht auf Ressourcen, die speziell für SQL Server dienen. Genauso wichtig ist es, auf Computern mit SQL Server die folgenden Ressourcen zu überwachen: CPU, Arbeitsspeicher, Cachetrefferquote und E/A-Subsystem.
Wenn eine oder mehrere Serverressourcen zu niedrig oder überlastet sind, gehen Sie die folgenden Leistungsrichtlinien auf Grundlage der aktuellen und der veranschlagten Arbeitslasten durch.
Beschleunigen von Sicherungen und Reduzieren von Dateigrößen durch Einsatz von Sicherungskomprimierung
Durch die Sicherungskomprimierung können SharePoint-Sicherungsvorgänge beschleunigt werden. Dieses Feature ist in SQL Server Standard und Enterprise Edition verfügbar. Wenn Sie die Komprimierungsoption im Sicherungsskript festlegen oder den Server mit SQL Server so konfigurieren, dass die Komprimierung standardmäßig verwendet wird, können Sie die Größe der Datenbanksicherungen und der versendeten Protokolle erheblich reduzieren. Weitere Informationen finden Sie unter Sicherungskomprimierung (SQL Server) und Datenkomprimierung oder Aktivieren der Komprimierung für eine Tabelle oder einen Index
Danksagung
Das SharePoint Server Content Publishing-Team dankt den folgenden Autoren für Ihre Beiträge zu diesem Artikel:
Kay Unkroth, Senior Program Manager, SQL Server
Chuck Heinzelman, Senior Program Manager, SQL Server
Siehe auch
Konzepte
Übersicht über SQL Server in SharePoint Server 2016- und 2019-Umgebungen
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server)
Weitere Ressourcen
Sichern von SharePoint: Verstärken der Sicherheit von SQL Server in SharePoint-Umgebungen