Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server)
**Gilt für:**SharePoint Server 2013, SharePoint Server 2016
**Letztes Änderungsdatum des Themas:**2018-03-09
Zusammenfassung: Erfahren Sie, wie Sie Speicher und Datenbankebene für SQL Server in SharePoint Server 2016 und SharePoint Server 2013 planen und konfigurieren.
Die von uns bereitgestellten Informationen zur Kapazitätsplanung enthalten Richtlinien, die Ihnen bei der Planung und Konfiguration des Speichers und der SQL Server-Datenbankebene in einer SharePoint Server-Umgebung helfen sollen. Diese Informationen stützen sich auf Tests, die bei Microsoft mit realen Ressourcen durchgeführt wurden. Ihre Ergebnisse können jedoch in Abhängigkeit von den verwendeten Anlagen und den Features und Funktionen variieren, die Sie für Ihre Websites implementieren möchten.
Hinweis
Leistungs- und Kapazitätstests in diesem Artikel beziehen sich auf Microsoft SQL Server 2014 mit Service Pack 1 (SP1), Microsoft SQL Server 2016, SQL Server 2017 RTM und SharePoint Server 2016. Die Testergebnisse sind dieselben wie in SharePoint Server 2013.
Auch wenn keine Tests mit SQL Server 2014 (SP1), SQL Server 2016 oder SQL Server 2017 RTM ausgeführt wurden, können Sie diese Testdaten als Richtlinie bei der Planung und Konfiguration von Speicher und SQL Server-Datenbankebene in einer SharePoint Server 2016-Umgebung verwenden. Weitere Informationen zur Schulung, wie SQL Server 2012 konfiguriert und eingestellt wird, finden Sie unter SQL Server 2012 für SharePoint Server 2013.
Da SharePoint Server häufig in Umgebungen ausgeführt wird, in denen Datenbanken durch separate SQL Server-Datenbankadministratoren verwaltet werden, richtet sich dieses Dokument gleichermaßen an Implementierer von SharePoint Server-Farmen und Administratoren von SQL Server-Datenbanken. Es setzt umfangreiche Kenntnisse in SharePoint Server und SQL Server voraus.
Dieser Artikel geht von der Annahme aus, dass Sie mit den Konzepten vertraut sind, die in Kapazitätsverwaltung und Dimensionierung für SharePoint Server 2013 dargelegt sind.
Entwurfs- und Konfigurationsprozess für SharePoint Server 2016-Speicher und -Datenbankebenen
Es wird empfohlen, den Entwurfsprozess für Speicher und Datenbankebenen in die nachfolgend genannten Schritte zu unterteilen. Jeder Abschnitt liefert detaillierte Informationen zu den einzelnen Entwurfsschritten mit den zugehörigen Speicheranforderungen und bewährten Methoden:
Erfassen von Speicherplatz, SQL Server-Speicher und E/A-Anforderungen
Auswählen von SQL Server-Version und -Edition
Entwerfen der Speicherarchitektur auf der Grundlage von Kapazität und E/A-Anforderungen
Abschätzen von Speicheranforderungen
Netzwerktopologieanforderungen
Konfigurieren von SQL Server
Überprüfen von Speicherleistung und -zuverlässigkeit
Erfassen von Speicherplatz, SQL Server-Speicher und E/A-Anforderungen
Mehrere architektonische SharePoint Server-Faktoren beeinflussen den Speicherentwurf. Die wichtigsten Faktoren sind dabei: Größe der Inhaltdatenbank, aktivierte Features, bereitgestellte Dienstanwendungen, Anzahl Farmen und Verfügbarkeitsanforderungen.
Bevor Sie mit dem Speicherentwurf beginnen, sollten Sie die Datenbanken kennen, die Sie mit SharePoint Server verwenden können.
Inhalt dieses Abschnitts:
Von SharePoint Server verwendete Datenbanken
SQL Server und IOPS
Abschätzen von Kernspeicher- und IOPS-Anforderungen
Festlegen von Dienstanwendungsspeicher- und IOPS-Anforderungen
Festlegen von Verfügbarkeitsanforderungen
Von SharePoint Server verwendete Datenbanken
Die mit SharePoint Server 2016 installierten Datenbanken sind von den Dienstanwendungen abhängig, die in der Umgebung verwendet werden. Alle SharePoint Server 2016-Umgebungen verwenden die SQL Server-Systemdatenbanken. Dieser Abschnitt stellt eine Übersicht über die mit SharePoint Server 2016 installierten Datenbanken bereit. Weiterführende Informationen zu Datenbanken finden Sie in Datenbanktypen und -beschreibungen in SharePoint Server.
Eine grafische Übersicht über die Datenbanken, die SharePoint Server 2016 unterstützen, finden Sie in der Kurzübersicht: SharePoint Server 2016-Datenbanken. Sie können auch dieses SharePoint Server 2016-Datenbankposter herunterladen, entweder als PDF-Datei oder als Visio-Datei.
Hinweis
Einige SharePoint Server, SQL Server-Datenbankmodule und SQL Server Reporting Services (SSRS)-Datenbanken haben spezifische Pfadempfehlungen bzw. -anforderungen. Informationen zu diesen Datenbankpfaden finden Sie in Datenbanktypen und -beschreibungen in SharePoint Server.
Die folgenden Datenbanken sind die SharePoint Server-Systemdatenbanken und werden automatisch installiert.
Konfiguration
Inhaltsdatenbank der Zentraladministration
Inhaltsdatenbank (mindestens eine)
In der folgenden Liste sind die SharePoint Server-Dienstanwendungen aufgeführt, die über Datenbanken verfügen:
App-Verwaltungsdienst
Apps für SharePoint
Business Data Connectivity
Verwaltete Metadaten
PerformancePoint-Dienste
Project Server (nur SharePoint Server 2013)
Suchdienst
Suchverwaltungsdatenbank
Analyseberichtsdatenbank
Durchforstungsdatenbank
Linkdatenbank
Secure Store Service
SharePoint-Übersetzungsdienst
SQL Server PowerPivot-Dienst
Statusdienst
Abonnementeinstellungendienst
Verwendungs- und Integritätsdatenerfassung
Benutzerprofildienst
Profil
Thematische Kategorien
Synchronisierung
Word Automation Services
Die folgende Liste zeigt die SharePoint Foundation 2013-Datenbanken:
Konfiguration
Inhaltsdatenbank der Zentraladministration
Inhaltsdatenbank (mindestens eine)
App-Verwaltungsdienst
Suchdienstanwendung:
Suchverwaltung
Analyseberichte (mindestens einer)
Crawl (mindestens einer)
Link (mindestens einer)
Secure Store Service
Anwendung für Abonnementeinstellungendienst (falls durch Windows PowerShell) aktiviert
Dienst für die Erfassung von Verwendungs- und Integritätsdaten
Word-Konvertierungsdienst
Falls Sie eine weiterführende Integration mit SQL Server möchten, kann Ihre Umgebung auch zusätzliche Datenbanken enthalten, wie es in dem folgenden Szenario dargestellt ist: SQL Server PowerPivot für SharePoint kann in einer SharePoint Server 2016-Umgebung nur verwendet werden, wenn Sie SQL Server 2016 RTM Enterprise Edition und SQL Server 2016 SQL Server Analysis Services (SSAS) verwenden. Falls Sie diese Umgebung nutzen, müssen Sie ebenfalls die PowerPivot-Anwendungsdatenbank mit berücksichtigen sowie auch die zusätzliche Systemlast. Weitere Informationen hierzu finden Sie im Whitepaper Bereitstellen von SQL Server 2016 PowerPivot und Power View in SharePoint 2016. 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.
Das SQL Server 2016 Reporting Services-Add-In (SSRS) kann mit jeder beliebigen SharePoint Server 2016-Umgebung verwendet werden. Falls Sie das Add-In verwenden, planen Sie auch den Support der beiden SQL Server Reporting Services-Datenbanken sowie die zusätzliche Last mit ein, die für SQL Server Reporting Services erforderlich ist.
SQL Server 2012 PowerPivot für SharePoint 2013 kann in einer SharePoint 2013-Umgebung mit SQL Server 2008 R2 Enterprise Edition und SQL ServerAnalysis Services verwendet werden. Falls Sie diese Umgebung nutzen, müssen Sie ebenfalls die PowerPivot-Anwendungsdatenbank mit berücksichtigen sowie auch die zusätzliche Systemlast. Weitere Informationen finden Sie unter Planen einer PowerPivot-Bereitstellung in einer SharePoint-Farm und im SQL Server PRO-Artikel PowerPivot und Power View in Microsoft Excel 2013.
Das SQL Server 2008 R2 Reporting Services (SSRS)-Plug-In kann mit jeder beliebigen SharePoint 2013-Umgebung verwendet werden. Falls Sie das Plug-In verwenden, planen Sie auch den Support der beiden SQL Server 2008 R2 Reporting Services-Datenbanken sowie die zusätzliche Last mit ein, die für SQL Server 2008 R2 Reporting Services erforderlich ist.
SQL Server und IOPS
Bei jedem Server, der eine SQL Server-Instanz hostet, ist es sehr wichtig, dass das E/A-Subsystem dem Server die schnellstmögliche Reaktionszeit liefert.
Mehr und schnellere Datenträger oder Arrays bieten ausreichend viele E/A-Vorgänge pro Sekunde (IOPS) bei kurzer Latenz und Queuing auf allen Datenträgern.
Sie können keine langsamen Reaktionszeiten des E/A-Subsystems durch andere Ressourcentypen, wie CPU oder Speicher, kompensieren. Diese können sogar Probleme in der Farm verursachen. Sorgen Sie vor Bereitstellung für eine minimale Latenz, und überwachen Sie das vorhandene System.
Bevor Sie eine neue Farm bereitstellen, sollten Sie das E/A-Subsystem mithilfe des Dienstprogramms „Diskspd“ einem Vergleichstest unterziehen. Dieses Tool funktioniert auf allen Windows Server-Versionen mit allen SQL Server-Versionen. Weitere Informationen finden Sie unter Dienstprogramm „„Diskspd“: Ein robustes Speichertesttool.
Belastungstests liefern auch wichtige Informationen für SQL Server. Informationen finden Sie unter Speicher-Vergleichstests mit DiskSpd.
Detaillierte Informationen zur Analyse von IOPS-Anforderungen aus der Sicht von SQL Server finden Sie in Analysieren von E/A-Kenndaten und Festlegen der Größe von Speichersystemen für SQL Server-Datenbankanwendungen.
Abschätzen von Kernspeicher- und IOPS-Anforderungen
Konfigurations- und Inhaltsspeicherung und IOPS sind von entscheidender Bedeutung und müssen bei jeder SharePoint Server-Bereitstellung berücksichtigt werden.
Konfigurationsspeicher und IOPS
Die Speicheranforderungen für die Konfigurationsdatenbank und die Zentraladministration-Inhaltsdatenbank sind nicht hoch. Sie sollten möglichst 2 GB für die Konfigurationsdatenbank und 1 GB für die Zentraladministration-Inhaltsdatenbank vorsehen. Im Laufe der Zeit kann die Konfigurationsdatenbank auf über 1 GB anwachsen. Sie wächst nur langsam, um ca. 40 MB pro Sammlung à 50.000 Websites.
Transaktionsprotokolle der Konfigurationsdatenbanken können sehr groß sein. Sie sollten daher das Wiederherstellungsmodell für die Datenbank von "Vollständig" auf "Einfach" ändern.
Hinweis
Falls Sie SQL Server-Datenbankspiegelung wählen, um Verfügbarkeit für die Konfigurationsdatenbank bereitzustellen, verwenden Sie das vollständige Wiederherstellungsmodell.
Die IOPS-Anforderungen für die Konfigurationsdatenbank und die Zentraladministration-Inhaltsdatenbank sind sehr gering.
Inhaltsspeicherung und IOPS
Der Speicherplatzbedarf und die IOPS-Anforderungen für Inhaltsdatenbanken können nur annäherungsweise geschätzt werden. Die folgenden Tests und Erläuterungen sollen Ihnen bei der Ermittlung helfen, wie viel Speicherplatz für die Bereitstellung anfänglich erforderlich ist. Wenn Ihre Umgebung in Betrieb gegangen ist, sollten Sie den Kapazitätsbedarf erneut auf der Grundlage der Daten aus der Live-Umgebung überprüfen.
Weitere Informationen zur Methodologie der Gesamtkapazitätsplanung finden Sie in Kapazitätsverwaltung und Dimensionierung für SharePoint Server 2013.
Formel zur Ermittlung des Inhaltsdatenbank-Speicherbedarfs
Nachfolgend wird beschrieben, wie Sie den Speicherplatzbedarf für Inhaltsdatenbanken ohne Berücksichtigung der Protokolldateien schätzen können:
Verwenden Sie die folgende Formel, um die Größe Ihrer Inhaltsdatenbanken zu berechnen:
Datenbankgröße = ((D × V) × S) + (10 KB × (L + (V × D)))
Hinweis
Der Formelwert von 10 KB ist eine Konstante, die die ungefähre Menge Metadaten angibt, welche von SharePoint Server benötigt wird. Falls Ihr System häufig auf Metadaten zugreift, können Sie diese Konstante erhöhen.
Berechnen Sie die erwartete Anzahl Dokumente. Dieser Wert ist in der Formel als D ausgedrückt.
Wie Sie die Anzahl Dokumente berechnen, hängt von den von Ihnen verwendeten Features ab. Ein Beispiel: Bei Meine Websites oder Websites zur Zusammenarbeit berechnen Sie vorzugsweise die erwartete Anzahl Dokumente pro Benutzer und multiplizieren diesen Wert mit der Anzahl der Benutzer. Bei Websites für die Datensatzverwaltung oder die Inhaltsveröffentlichung können Sie die Anzahl der Dokumente nehmen, die durch einen Prozess verwaltet und generiert werden.
Falls Sie von einem aktuellen System migrieren, extrapolieren Sie für eine einfachere Berechnung die aktuelle Wachstumsrate und Auslastung. Erstellen Sie jedoch ein neues System, dann prüfen Sie die vorhandenen Dateifreigaben oder sonstigen Repositorys und berechnen den Bedarf anhand dieser Auslastungsrate.
Schätzen Sie die durchschnittliche Größe der zu speichernden Dokumente. Dieser Wert ist in der Formel als S ausgedrückt. Es kann nützlich sein, die Mittelwerte für unterschiedliche Websitetypen oder -gruppen zu ermitteln. Die durchschnittliche Dateigröße für Meine Websites, Medienrepositorys und verschiedene Abteilungsportale kann beträchtlich variieren.
Berechnen Sie die Anzahl Listenelemente in der Umgebung. Dieser Wert ist in der Formel als L ausgedrückt.
Listenelemente sind schwieriger als Dokumente abzuschätzen. In der Regel wird die Anzahl der Dokumente (D) mit 3 multipliziert. Dieser Wert schwankt jedoch je nachdem, wie Sie Ihre Websites verwenden möchten.
Ermitteln Sie die ungefähre Anzahl Versionen. Berechnen Sie die durchschnittliche Anzahl Versionen, die ein jedes Dokument in der Bibliothek haben wird. Dieser Wert ist normalerweise kleiner als die maximal zulässige Anzahl Versionen. Dieser Wert ist in der Formel als V ausgedrückt.
Der Wert V muss größer null sein.
Verwenden Sie für eine Beispielberechnung diese Formel und die Metriken aus der folgenden Tabelle. Ermitteln Sie damit den erforderlichen Speicherplatzbedarf für Datendateien in einer Inhaltsdatenbank in einer Zusammenarbeitsumgebung. Als Ergebnis erhalten Sie einen Speicherplatzbedarf von ungefähr 105 GB.
| Eingabe | Wert |
|---|---|
Anzahl Dokumente (D) |
200.000 Berechnet unter der Hypothese von 10.000 Benutzern mal 20 Dokumente |
Durchschnittliche Dokumentgröße (S) |
250 KB |
Listenelemente (L) |
600.000 |
Anzahl nicht aktueller Versionen (V) |
2 Es wird angenommen, die maximal zulässige Anzahl Versionen sei 10 |
Datenbankgröße = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) = 110.000.000 KB oder 105 GB
Hinweis
Effiziente Datei-E/A-Vorgänge in SharePoint Server sind eine Speichermethode, bei der eine Datei aufgeteilt und jedes Teil separat gespeichert und aktualisiert wird. Diese Teile werden gemeinsam gestreamt, wenn die Datei von einem Benutzer angefordert wird.
Features mit Einfluss auf die Größe von Inhaltsdatenbanken
Die folgenden SharePoint Server-Features können beträchtliche Auswirkungen auf die Größe von Inhaltsdatenbanken haben:
Papierkorb Solange ein Dokument nicht vollständig aus dem vorläufigen und dem endgültigen Papierkorb gelöscht ist, belegt es Platz in der Inhaltsdatenbank. Ermitteln Sie, wie viele Dokumente jeden Monat gelöscht werden, um die Auswirkungen von Papierkörben auf die Größe von Inhaltsdatenbanken zu berechnen.
Überwachung Überwachungsdaten können schnell anwachsen und viel Speicherplatz in einer Inhaltsdatenbank belegen, insbesondere, wenn die Sichtprüfung aktiviert ist. Sie sollten die Überwachungsdaten nicht ungehindert anwachsen lassen, sondern dieses Feature nur dann aktivieren, wenn gesetzlichen Vorgaben oder internen Kontrollen Genüge getan werden muss. Anhand der folgenden Richtlinien können Sie den Speicherplatz ermitteln, den Sie für Überwachungsdaten reservieren müssen:
Schätzen Sie die Anzahl neuer Überwachungseinträge für eine Website, und multiplizieren Sie diesen Wert mit 2 KB (Einträge sind, bei einer durchschnittliche Größe von ca. 1 KB, in der Regel auf 4 KB begrenzt).
Berechnen Sie auf der Grundlage des zuzuweisenden Speicherplatzes die Anzahl der Tage, die Überwachungsprotokolle gespeichert werden sollen.
Hinweis
Office Online Server ist die nächste Version von Office Web Apps Server. Die Verwendung von Office Online Server mit SharePoint Server 2016 wirkt sich nicht auf die Größe der Inhaltsdatenbank aus. Informationen zur Bereitstellung von Office Online Server in Ihrer SharePoint Server 2016-Serverfarm finden Sie unter Bereitstellen von Office Online Server.
Ermitteln der IOPS-Anforderungen für Inhaltsdatenbanken
IOPS-Anforderungen für Inhaltsdatenbanken können je nach Nutzung Ihrer Umgebung, verfügbaren Speicherplatz und Anzahl Ihrer Server stark schwanken. Im Allgemeinen wird empfohlen, die zu erwartende Arbeitsauslastung in Ihrer Umgebung mit einer der getesteten Lösungen zu vergleichen. Weitere Informationen finden Sie in Ergebnisse und Empfehlungen zu Leistungs- und Kapazitätstests (SharePoint Server 2013).
In Tests hat Microsoft herausgefunden, dass Inhaltsdatenbanken 0,05 IOPS/GB bis ca. 0,2 IOPS/GB ausführen. Weiterhin stellte sich eine Anhebung des oberen Grenzwerts auf 0,5 IOPS/GB als bewährtes Verfahren heraus. Dies ist ein höherer Wert als benötigt, den Sie wahrscheinlich nicht in Ihrer Umgebung ausschöpfen werden. Beachten Sie bitte, dass bei Datenbankspiegelung viel mehr E/A-Vorgänge als bei der primären Inhaltsdatenbank anfallen werden. Bedenken Sie immer, dass gespiegelte Inhaltsdatenbanken sehr viel Speicherplatz benötigen.
Festlegen von Dienstanwendungsspeicher- und IOPS-Anforderungen
Nachdem Sie die Anforderungen für Inhaltsspeicherung und IOPS-Vorgänge geschätzt haben, müssen Sie den von den Dienstanwendungen geforderten Speicherplatz und die IOPS-Vorgänge für Ihre Umgebung festlegen.
Speicheranforderungen an SharePoint Server-Dienstanwendungen und IOPS-Vorgänge
Wenn Sie die Speicheranforderungen für Dienstanwendungen im System ermitteln möchten, müssen Sie zunächst die Dienstanwendungen und ihre Verwendung festlegen. Dienstanwendungen, die in SharePoint Server 2016 verfügbar sind und Datenbanken besitzen, sind nachfolgend aufgelistet. Die Speicherung und die IOPS-Daten für alle Dienstanwendungen in SharePoint Server 2016 entsprechen denen in SharePoint Server 2010 und SharePoint Server 2013.
Anforderungen an Suchdienstanwendungen und IOPS-Vorgänge
| Datenbank | Skalierung | Datenträger-IOPS | Datenträgergröße | 10 MBit Elemente | 100 MBit Elemente |
|---|---|---|---|---|---|
Durchforstungsdatenbank |
Eine DB pro 20 MBit Elementen SQL IOPS: 10 pro 1 DPS |
Medium/Hoch |
Medium |
15 GB 2 GB Protokoll |
110 GB 50 GB Protokoll |
Linkdatenbank |
Eine DB pro 60 MBit Elemente SQL IOPS: 10 pro 1 MBit Elemente |
Medium |
Medium |
10 GB 0,1 GB Protokoll |
80 GB 5 GB Protokoll |
Analyseberichtsdatenbank |
Aufteilen bei Erreichen von 100 - 300 GB |
Medium |
Medium |
Nutzungsabhängig |
Nutzungsabhängig |
Suchverwaltungsdatenbank |
Eine DB |
Niedrig |
Niedrig |
0,4 GB 1 GB Protokoll |
1 GB Daten 2 GB Protokoll |
Empfehlungen zu Dienstanwendungsspeicherungen und IOPS-Vorgängen
| Dienstanwendung | Empfehlung zur Größenschätzung |
|---|---|
Benutzerprofil |
Die Benutzerprofil-Dienstanwendung ist mit drei Datenbanken verknüpft: Profil, Synchronisierung und Communitytags. Hinweis Das Überprüfen der Anforderungen an die Benutzerprofil-Datenbankspeicherung und die IOPS-Empfehlungen ist noch nicht abgeschlossen. Suchen Sie regelmäßig nach neuen Informationen dazu. Weitere Informationen zur Benutzerprofil-Datenbank finden Sie in Datenbanktypen und -beschreibungen in SharePoint Server. |
Verwalteter Metadatendienst |
Zur verwalteten Metadaten-Dienstanwendung gehört eine Datenbank. Die Größe der Datenbank hängt von der Anzahl der im System verwendeten Inhaltstypen und Schlüsselwörter ab. Viele Umgebungen enthalten mehrere Instanzen dieser verwalteten Metadaten-Dienstanwendung. |
Secure Store Service |
Die Größe der Secure Store-Dienstanwendungs-Datenbank hängt von der Anzahl der Anmeldeinformationen im Speicher und der Anzahl der Einträge in der Überwachungstabelle ab. Microsoft empfiehlt eine Zuweisung von 5 MB pro 1.000 Anmeldeinformationen. Sie hat minimale IOPS-Vorgänge. |
Statusdienst |
Die Statusdienstanwendung hat eine Datenbank. Sie sollten dafür 1 GB vorsehen. Sie hat minimale IOPS-Vorgänge. |
Word Automation Services |
Die Word Automation-Dienstanwendung hat eine Datenbank. Sie sollten dafür 1 GB vorsehen. Sie hat minimale IOPS-Vorgänge. |
PerformancePoint-Dienste |
Die PerformancePoint-Dienstanwendung hat eine Datenbank. Sie sollten dafür 1 GB vorsehen. Sie hat minimale IOPS-Vorgänge. |
Business Data Connectivity Service |
Die Business Data Connectivity Service-Anwendung hat eine Datenbank. Diese ist klein und ein starker Zuwachs unwahrscheinlich. Sie hat minimale IOPS-Vorgänge. |
App-Verwaltung |
Die App-Verwaltungsdienstanwendung hat eine Datenbank. Diese ist klein und ein starker Zuwachs unwahrscheinlich. Sie hat minimale IOPS-Vorgänge. |
Word Automation Services |
Die Word Automation Services-Dienstanwendung hat eine Datenbank. Diese ist klein und ein starker Zuwachs unwahrscheinlich. Sie hat minimale IOPS-Vorgänge. |
PerformancePoint-Dienste |
Die PerformancePoint-Dienste-Anwendung hat eine Datenbank. Diese ist klein und ein starker Zuwachs unwahrscheinlich. Sie hat minimale IOPS-Vorgänge. |
PowerPivot |
Die PowerPivot-Dienstanwendung hat eine Datenbank. Diese ist klein und hat nur unbedeutende E/A-Auswirkungen. Sie sollten dieselben IOPS wie bei der SharePoint-Inhaltsdatenbank verwenden. Beachten Sie, dass Inhaltsdatenbanken beträchtliche höhere E/A-Anforderungen als die PowerPivot-Dienstanwendungs-Datenbank haben. |
Festlegen von Verfügbarkeitsanforderungen
Verfügbarkeit ist das Maß, wie sehr eine SharePoint Server 2016-Umgebung von Benutzern als verfügbar erachtet wird. Ein verfügbares System ist ein stabiles System, das heißt, Vorkommnisse, die den Dienst beeinträchtigen, treten selten auf und werden bei Auftreten zeitnah und wirksam behoben.
Verfügbarkeitsanforderungen können den Speicherplatzbedarf signifikant erhöhen. Weitere Informationen finden Sie in Erstellen einer Hochverfügbarkeitsarchitektur und -strategie für SharePoint Server. Lesen Sie auch das SQL Server 2012-Whitepaper AlwaysOn-Architekturleitfaden: Herstellen von hoher Verfügbarkeit und Wiederherstellungslösungen mit AlwaysOn-Verfügbarkeitsgruppen.
Wählen der SQL Server-Version und -Edition
Sie sollten Ihre Umgebung bei Verwendung von SharePoint Server 2016 vorzugsweise in der Enterprise Edition von SQL Server 2014 mit Service Pack 1 (SP1), SQL Server 2016 oder SQL Server 2017 RTM ausführen, um die zusätzliche Leistung, Verfügbarkeit, Sicherheit und Verwaltungsfunktionen dieser Versionen nutzen zu können. Weitere Informationen zu den Vorteilen dieser Versionen finden Sie unter Von den Editionen von SQL Server 2014 unterstützte Funktionen, Editionen und von SQL Server 2016 unterstützte Funktionen und Editionen und von SQL Server 2017 unterstützte Funktionen.
Sie sollten Ihre Umgebung bei Verwendung von SharePoint Server 2013 vorzugsweise in der Enterprise Edition von SQL Server 2008 R2 mit Service Pack 1 (SP1), SQL Server 2012 oder SQL Server 2014 ausführen, um die zusätzliche Leistung, Verfügbarkeit, Sicherheit und Verwaltungsfunktionen dieser Version nutzen zu können. Weitere Informationen zu den Vorteile von SQL Server 2008 R2 mit SP1, SQL Server 2012 und SQL Server 2014 Enterprise Edition finden Sie unter Von den SQL Server 2014-Editionen unterstützte Funktionen, Von den SQL Server 2012-Editionen unterstützte Funktionen und Von den Editionen von SQL Server 2008 R2 unterstützte Funktionen.
Sie sollten insbesondere auch Ihren Bedarf an den folgenden Features berücksichtigen:
Sicherungskomprimierung Die Sicherungskomprimierung kann SharePoint-Sicherungen beschleunigen und ist in allen Editionen von SQL Server 2008 und höher verfügbar. Indem 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) für SQL Server 2014 und Sicherungskomprimierung (SQL Server) für SQL Server 2016 und SQL Server 2017 RTM.
Hinweis
SQL Server-Datenkomprimierung wird nicht für SharePoint Server unterstützt, mit Ausnahme der Suchdienstanwendungs-Datenbanken.
Transparente Datenverschlüsselung Falls Ihre Sicherheitsanforderungen die Notwendigkeit einer transparenten Datenverschlüsselung vorsehen, müssen Sie SQL Server Enterprise Edition verwenden.
Inhaltsbereitstellung Falls Sie das Feature zur Inhaltsbereitstellung verwenden möchten, müssen Sie SQL Server Enterprise Edition installiert haben, damit das System von Datenbankmomentaufnahmen profitieren kann.
Hinweis
Falls Sie einen Remote-BLOB-Speicheranbieter verwenden, der keine Momentaufnahmen unterstützt, können Sie Datenbankmomentaufnahmen nicht für die Bereitstellung oder Sicherung von Inhalten nutzen.
Remote BLOB storage Falls Sie Remote BLOB Storage für eine Datenbank oder einen Pfad außerhalb der mit den einzelnen Inhaltsdatenbanken verbundenen Dateien verwenden möchten, müssen Sie SQL Server 2014 (SP1), SQL Server 2016, or SQL Server 2017 RTM Enterprise Edition for SharePoint Server 2016 and SQL Server 2008 R2 mit SP1 oder SQL Server 2012 Enterprise Edition for SharePoint Server 2013 verwenden.
Ressourcenkontrolle Die Ressourcenkontrolle ist eine in SQL Server 2008 eingeführte Technologie für die Verwaltung von SQL Server-Arbeitsauslastung und Ressourcen, indem Grenzwerte für den Ressourcenverbrauch durch eingehende Anforderungen festgelegt werden. Mit der Ressourcenkontrolle können Sie zwischen Arbeitsauslastungen diskriminieren und CPU und Speicher nach Bedarf auf Grundlage der von Ihnen festgelegten Grenzwerte zuweisen. Weitere Informationen zur Verwendung der Ressourcenkontrolle finden Sie unter Ressourcenkontrolle für SQL Server 2014 und Ressourcenkontrolle für SQL Server 2016.
Verwenden Sie die Ressourcenkontrolle vorzugsweise mit SharePoint Server, damit Ihnen folgende Optionen bereitstehen:
Begrenzen der Menge der SQL Server-Ressourcen, die die Webserver verbrauchen, die Ziel der Suchdurchforstungskomponente sind. Als bewährte Methode sollten Sie vorzugsweise die Durchforstungskomponenten auf 10 % der CPU-Leistung des ausgelasteten Systems einstellen.
Überwachen, wie viele Ressourcen von den einzelnen Datenbanken im System verbraucht werden. Beispiel: Über die Ressourcenkontrolle können Sie die beste Platzierung von Datenbanken auf Computern bestimmen, die SQL Server ausführen.
Microsoft PowerPivot für SharePoint Ermöglicht Benutzern, benutzergenerierte Datenmodelle und Analysen in Excel Online freizugeben, während diese Analysen automatisch aktualisiert werden. Sie benötigen Office Online um Excel Online mit PowerPivot für SharePoint und SharePoint Server 2016 zu verwenden. Sie können SQL Server 2014 (SP1) oder SQL Server 2016 RTM Enterprise Edition und SQL Server Analysis Services für Business Intelligence mit SharePoint Server 2016 verwenden. Sie können jedoch nur PowerPivot für SharePoint mit SQL Server 2016 RTM und nicht mit SQL Server 2014 (SP1) verwenden.
PowerPivot für SharePoint 2013 Ermöglicht Benutzern, benutzergenerierte Datenmodelle und Analysen in Excel und im Browser freizugeben und gemeinsam damit zu arbeiten, während diese Analysen automatisch aktualisiert werden. Dieses Feature ist Teil von UNRESOLVED_TOKEN_VAL(SSAS_1st_CurrentVer Datacenter) und Enterprise Edition, SQL Server 2012 SP1 Analysis Services (SSAS) Enterprise Edition sowie SQL Server 2014 Analysis Services (SSAS) Enterprise und Business Intelligence Edition.
Entwerfen der Speicherarchitektur basierend auf Kapazität und E/A-Anforderungen
Die für Ihre Umgebung gewählte Speicherarchitektur und die Datenträgertypen können die Systemleistung beeinflussen.
In diesem Abschnitt:
Wählen einer Speicherarchitektur
Wählen von Datenträgertypen
Wählen von RAID-Typen
Wählen einer Speicherarchitektur
SharePoint Server unterstützt die Speicherarchitekturen Direct Attached Storage (DAS), Storage Area Network (SAN) und Network Attached Storage (NAS), wobei NAS nur zusammen mit Inhaltsdatenbanken unterstützt wird, die für Remote BLOB Storage konfiguriert sind. Ihre Wahl ist von Aspekten Ihrer Geschäftslösung und von der vorhandenen Infrastruktur abhängig.
Jede Speicherarchitektur muss Ihren Verfügbarkeitsanforderungen genügen sowie IOPS-Vorgänge und Latenz entsprechend erfüllen. Die Unterstützung setzt voraus, dass das System konsistent das erste Datenbyte innerhalb von 20 Millisekunden (ms) zurückgibt.
Direct-Attached Storage (DAS)
DAS ist ein digitales Speichersystem, das direkt, ohne Zwischenschaltung eines Speichernetzwerks, mit einem Server oder einer Arbeitsstation verknüpft ist. Zu den physikalischen DAS-Datenträgertypen zählen Serial Attached SCSI (SAS) und Serial Attached ATA (SATA).
Allgemein gilt die Empfehlung für eine DAS-Architektur, wenn eine freigegebene Speicherplattform weder eine Antwortzeit von 20 ms noch ausreichende Kapazität für durchschnittliche und Spitzen-IOPS garantieren kann.
Storage Area Network (SAN)
SAN ist eine Architektur, mit der Sie Remote-Computer-Speichergeräte (wie Laufwerksgruppen und Bandbibliotheken) mit Servern verbinden können, sodass die Geräte als lokal mit dem Betriebssystem verbunden gesehen werden (beispielsweise Blockspeicherung).
SAN ist die Lösung der Wahl, wenn Ihrem Unternehmen die Vorteile freigegebener Speicher sehr wichtig sind.
Die Vorteile freigegebener Speicher sind folgende:
Leichtere Zuweisung von Datenspeicher zwischen Servern.
Verfügbarkeit für mehrere Server.
Keine Begrenzung der Anzahl Datenträger, auf die zugegriffen werden kann.
NAS (Network-Attached Storage)
Ein NAS-System ist ein eigenständiger Computer, der mit einem Netzwerk verbunden ist. Sein einziger Zweck ist die Bereitstellung von dateibasierten Datenspeicherdiensten für andere Geräte im Netzwerk. Das Betriebssystem und andere Software im NAS-System bieten Datenspeicherung, Dateisysteme und Dateizugriff sowie die Verwaltung dieser Funktionen (zum Beispiel Dateispeicherfunktion).
Hinweis
NAS wird nur zusammen mit Inhaltsdatenbanken verwendet, die für Remote BLOB Storage (RBS) konfiguriert sind. Jede Netzwerk-Speicherarchitektur muss einen Ping innerhalb von 1 ms beantworten und das erste Datenbyte innerhalb von 20 ms zurückgeben können. Diese Einschränkung gilt nicht für den lokalen SQL Server-FILESTREAM-Anbieter, da er Daten nur lokal auf demselben Server speichert.
Es besteht eine gewissen Verwirrung, wenn Sie die Internet Small Computer System Interface (iSCSI) verwenden und davon ausgehen, dass es sich um ein NAS-Protokoll handelt. Wenn Sie auf diesen iSCSI-Speicher über das Common Internet File System (CFIS) zugreifen, dann ist es ein NAS-Protokoll. Das bedeutet, Sie können diesen Speicher nicht zusammen mit Inhaltsdatenbanken verwenden, wenn diese nicht für RBS konfiguriert wurden. Falls Sie jedoch auf diesen iSCSI-Speicher über eine lokal verbundene Festplatte zugreifen, handelt es sich um eine SAN-Architektur, und Sie können sie zusammen mit NAS verwenden.
Wählen von Datenträgertypen
Die im System verwendeten Datenträgertypen können Zuverlässigkeit und Leistung beeinflussen. Wenn alle anderen Faktoren gleich bleiben, erhöhen größere Laufwerke die durchschnittliche Suchzeit. SharePoint Server unterstützt die folgenden Laufwerkstypen:
Small Computer System Interface (SCSI)
Serial Advanced Technology Attachment (SATA)
Serial-attached SCSI (SAS)
Fibre Channel (FC)
Integrated Device Electronics (IDE)
Solid State Drive (SSD) oder Flash Disk
Weitere Informationen zur Verwendung von Festkörperlaufwerken für die Speicherung finden Sie in SQL Server. Lesen Sie dazu auch den SQL Server PRO-Artikel Verwenden von Festkörperlaufwerken in SQL Server-Speicherlösungen.
Wählen von RAID-Typen
RAID (Redundant Array of Independent Disks) ist ein Mechanismus, der häufig eingesetzt wird, um die Leistungsmerkmale einzelner Datenträger zu verbessern (durch Entfernung von Daten aus mehreren Datenträgern) und um Schutz gegen individuelle Datenträgerfehler zu gewähren.
SharePoint Server unterstützt alle RAID-Typen. Empfehlenswert ist es jedoch, wenn Sie RAID 10 oder eine anbieterspezifische RAID-Lösung mit gleicher Leistung verwenden.
Stellen Sie bei der Konfiguration eines RAID-Arrays sicher, dass Sie das Dateisystem am Offset ausrichten, das vom Anbieter bereitgestellt wird.
Weitere Informationen zur RAID-Bereitstellung für SQL Server finden Sie in RAID.
Abschätzen von Speicheranforderungen
Der erforderliche Speicherplatz für SharePoint Server ist direkt von der Größe der Inhaltsdatenbanken abhängig, die Sie auf einem Server hosten, der SQL Server ausführt.
Durch das Hinzufügen von Dienstanwendungen und Features werden sich Ihre Anforderungen wahrscheinlich erhöhen. In der folgenden Tabelle finden Sie Richtlinien zur empfohlenen Speichergröße.
| Gesamtgröße von Inhaltsdatenbanken | Empfohlene RAM-Größe für Computer, die SQL Server ausführen |
|---|---|
Mindestgröße für kleine Produktionsbereitstellungen |
8 GB |
Mindestgröße für mittlere Produktionsbereitstellungen |
16 GB |
Empfehlung für bis zu 2 TB |
32 GB |
Empfehlung für 2 - 5 TB |
64 GB |
Empfehlung für mehr als 5 TB |
Zusätzlicher RAM von mehr als 64 GB kann die Geschwindigkeit des Zwischenspeicherns von SQL Server verbessern |
Hinweis
Diese Werte liegen aufgrund der für eine SharePoint Server-Umgebung erforderlichen Verteilung der Daten über den empfohlenen Mindestwerten für SQL Server. Weitere Informationen zu SQL Server-Systemanforderungen finden Sie unter Hardware- und Softwareanforderungen für die Installation von SQL Server 2014 und Hardware- und Softwareanforderungen für die Installation von SQL Server 2016.
Weitere Informationen zu SQL Server-Kapazitätsgrenzen und Spezifikationen finden Sie unter Rechenkapazitätsgrenzen nach SQL Server-Edition und Maximale Kapazitätsspezifikationen für SQL Server.
Weitere Faktoren, die die erforderliche Speichergröße beeinflussen können, sind folgende:
Die Verwendung von SQL Server-Spiegelung.
Die häufige Verwendung von Dateien größer 15 MB.
Netzwerktopologieanforderungen
Planen Sie die Netzwerkverbindungen innerhalb und zwischen den Farmen. Sie sollten ein Netzwerk mit geringer Latenz verwenden.
In der folgenden Liste finden Sie einige bewährte Methoden und Empfehlungen:
Alle Server der Farm sollten eine Verbindung mit LAN-Bandbreite und Latenz zum Server haben, auf dem SQL Server ausgeführt wird. Die Latenz darf 1 ms nicht überschreiten.
Microsoft empfiehlt keine WAN-Topologie (Wire Area Network), in der ein Server, der SQL Server ausführt und remote von anderen Komponenten der Farm über ein Netzwerk bereitgestellt wird, eine Latenz größer 1 ms hat, da eine solche Topologie nicht getestet wurde.
Sehen Sie ein passendes WAN-Netzwerk vor, falls Sie SQL Server mit der AlwaysOn-Bereitstellungssuite, Spiegelung, Protokollversand oder Failover-Clusterunterstützung verwenden möchten, um eine Remotesite aktuell zu halten.
Es werden Webserver und Anwendungsserver mit zwei Netzwerkadaptern empfohlen: einen Netzwerkadapter für den Benutzerdatenverkehr und einen zur Handhabung der Kommunikation mit den Servern, die SQL Server ausführen.
Hinweis
Falls Sie iSCSI verwenden, stellen Sie sicher, dass jeder Netzwerkadapter entweder der Netzwerkkommunikation oder iSCI zugewiesen ist, nicht aber beiden.
Konfigurieren von SQL Server
In den folgenden Abschnitten erfahren Sie, wie Sie die Konfiguration von SQL Server für SharePoint Server planen.
In diesem Abschnitt:
Ermitteln, wie viele Server erforderlich sind
Konfigurieren von Speichern
Festlegen von SQL Server-Optionen
Konfigurieren von Datenbanken
Ermitteln, wie viele Server erforderlich sind
Im Allgemeinen soll SharePoint Server die Vorteile der SQL Server-Skalierung nutzen. Beispiel: SharePoint Server kann eine bessere Leistung mit vielen mittelgroßen Servern liefern, die SQL Server ausführen, als mit weniger großen Servern.
Positionieren Sie SQL Server immer auf einem dedizierten Server, auf dem keine anderen Farmrollen ausgeführt oder Datenbanken für eine andere Anwendung gehostet werden. Die einzige Ausnahme dieser Empfehlung ist, wenn Sie das System auf einem eigenständigen Server für eine Entwicklung oder auf einer nicht auf Leistung ausgerichteten Testumgebung bereitstellen. SQL Server kann auf demselben Server wie SharePoint ausgeführt werden. Für eine bessere Leistung wird jedoch die Ausführung von SQL Server auf einem separaten Server empfohlen.
Es folgt ein allgemeiner Leitfaden für die Bereitstellung eines zusätzlichen Servers, der eine SQL Server-Instanz ausführt:
Fügen Sie einen zusätzlichen Datenbankserver hinzu, wenn Sie mehr als vier Webserver voll auslasten.
Fügen Sie einen zusätzlichen Datenbankserver hinzu, wenn Ihr aktueller Server seine Ressourcengrenzen bezüglich RAM, CPU oder Festplatten-E/A-Durchsatz, Datenträgerkapazität oder Netzwerkdurchsatz erreicht hat.
Weitere Informationen finden Sie unter Rechenkapazitätsgrenzen nach SQL Server-Edition und Maximale Kapazitätsspezifikationen für SQL Server.
Wenn Sie den Anmeldeinformationsspeicher auf Ihrer Secure Store-Dienstanwendung sicherer machen möchten, wird empfohlen, die Secure Store-Datenbank auf einer separaten Datenbankinstanz auszuführen, auf die lediglich der Administrator Zugriff hat.
Konfigurieren von Speichern
Auf dem Server, auf dem SQL Server ausgeführt wird, sollte vorzugsweise der L2-Cache einer jeden CPU mindestens 2 MB groß sein, um das Speichervermögen zu verbessern.
Befolgen der Anbieterempfehlungen zur Speicherkonfiguration
Optimale Leistung erzielen Sie, wenn Sie bei der Konfiguration eines physikalischen Speicherarrays die Hardwarekonfigurationsempfehlungen Ihres Speicheranbieters befolgen und nicht die Standardwerte des Betriebssystems zur Grundlage nehmen.
Wenn Sie nicht über eine Anleitung von Ihrem Anbieter verfügen, wird empfohlen, dass Sie die PowerShell-Speicher-Cmdlets verwenden, die für Windows Server 2012 R2 verfügbar sind. Weitere Informationen finden Sie unter Speicher-Cmdlets in Windows PowerShell.
Bereitstellen möglichst vieler Ressourcen
Stellen Sie sicher, dass die SQL Server-E/A-Kanäle zu den Datenträgern nicht für andere Anwendungen freigegeben sind, wie beispielsweise für Auslagerungsdateien und Internetinformationsdienste (IIS)-Protokolle.
Stellen Sie so viel Busbandbreite wie möglich bereit. Je mehr Busbandbreite verfügbar ist, desto mehr Zuverlässigkeit und Leistung bekommen Sie. Bedenken Sie, dass nicht nur der Datenträger Busbandbreite belegt. Sie müssen beispielsweise auch den Netzwerkzugriff berücksichtigen.
Festlegen von SQL Server-Optionen
Sie müssen die folgenden SQL Server-Einstellungen und -Optionen konfigurieren, bevor Sie SharePoint Server bereitstellen.
Aktivieren Sie keine selbsterstellenden Statistiken auf einem Server, der SQL Server hostet und SharePoint Server unterstützt. SharePoint Server konfiguriert die erforderlichen Einstellungen bei Bereitstellung und Upgrade. Die Funktion der selbsterstellenden Statistiken kann den Ausführungsplan einer Abfrage zwischen einer SQL Server-Instanz und einer anderen SQL Server-Instanz beträchtlich beeinflussen. Damit alle Kunden konsistenten Support erhalten, stellt SharePoint Server im Einzelfall codierte Hinweise für Abfragen bereit. Auf diese Weise wird optimale Leistung in allen Szenarios gewährleistet.
Um eine optimale Leistung sicherzustellen, wird empfohlen, die Option Max. Grad an Parallelität (MAXDOP) auf 1 SQL Server-Instanz festzulegen, die SharePoint Server-Datenbanken hostet. Weitere Informationen zum Festlegen von Max. Grad an Parallelität (MAXDOP) finden Sie unter Die Option „Max. Grad an Parallelität“.
Konfigurieren von Datenbanken
Im folgenden Leitfaden werden die bewährten Verfahren bei der Planung der Datenbankkonfiguration in Ihrer Umgebung beschrieben.
Aufteilen und Priorisieren der Daten auf Datenträgern
Idealerweise platzieren Sie die tempdb-Datenbank, die Inhaltsdatenbanken, die Verwendungsdatenbank, die Suchdatenbanken, die SQL Server 2014 (SP1)-, SQL Server 2016-, SQL Server 2017 RTM- und SQL Server 2008 R2 mit SP1 und SQL Server 2012-Transaktionsprotokolle auf unterschiedlichen physischen Festplatten.
In der folgenden Liste finden Sie einige der bewährten Verfahren und Empfehlungen für eine Datenpriorisierung:
Verwenden Sie bei der Datenpriorisierung auf schnelleren Datenträgern folgende Reihenfolge:
Tempdb-Datendateien und Transaktionsprotokolle
Datenbank-Transaktionsprotokolldateien
Suchdatenbanken außer der Suchverwaltungsdatenbank
Datenbank-Datendateien
Priorisieren Sie Daten in leseorientierten Portalwebsites anhand von Protokollen.
Tests und Kundendaten belegen, dass die SharePoint Server-Farmleistung aufgrund unzureichender Datenträger-E/A-Vorgänge für tempdb stark eingeschränkt werden kann. Um dieses Problem zu vermeiden, weisen Sie tempdb dedizierte Datenträger zu. Wird eine hohe Arbeitsauslastung geplant oder überwacht, das heißt, ein durchschnittlicher Lese- oder Schreibvorgang erfordert mehr als 20 ms, dann müssen Sie den Engpass beheben, indem Sie entweder die Dateien auf die Datenträger aufteilen oder die Datenträger durch schnellere Datenträger ersetzen.
Beste Leistung erzielen Sie, wenn Sie die tempdb-Datenbank auf einem RAID 10-Array platzieren. Die Anzahl der tempdb-Datendateien muss der Anzahl der Kern-CPUs entsprechen, und die tempdb-Datendateien müssen die gleiche Größe haben. Betrachten Sie in diesem Zusammenhang Doppelkernprozessoren als zwei CPUs. Jeder Prozessor, der Hyperthreading unterstützt, zählt als eine CPU. Weitere Informationen finden Sie in Optimieren der Leistung von "tempdb".
Verteilen von Datenbankdaten und Transaktionsprotokollen auf unterschiedliche Datenträger. Falls Dateien Datenträger gemeinsam nutzen müssen, weil die Dateien zu klein sind, um einen ganzen Datenträger oder ein ganzes Stripeset zu beanspruchen, oder falls Sie zu wenig Speicherplatz auf dem Datenträger haben, platzieren Sie Dateien mit unterschiedlichen Verwendungsmustern auf ein und demselben Datenträger, um gleichzeitige Zugriffsanforderungen zu minimieren.
Wenden Sie sich an Ihren Anbieter der Speicherhardware bezüglich Informationen zum Konfigurieren aller Protokolle und der Suchdatenbanken für eine Schreiboptimierung in Ihrer speziellen Speicherlösung.
Verwenden mehrerer Datendateien für Inhaltsdatenbanken
Befolgen Sie diese Empfehlungen für optimale Leistungen:
Erstellen Sie Dateien für die Datenbank nur in der PRIMARY-Dateigruppe.
Verteilen Sie die Dateien auf einzelne Datenträger.
Die Anzahl der Dateidateien muss kleiner oder gleich der Anzahl der Kern-CPUs sein. Doppelkernprozessoren gelten in diesem Fall als zwei CPUs. Jeder Prozessor, der Hyperthreading unterstützt, zählt als eine CPU.
Erstellen Sie Datendateien gleicher Größe.
Wichtig
Sie können zwar mit den in SharePoint Server integrierten Sicherungs- und Wiederherstellungstools mehrere Datendateien sichern und wiederherstellen, wenn Sie aber an demselben Speicherort überschreiben, können diese Tools die Datendateien nicht an einem anderen Speicherort wiederherstellen. Aus diesem Grund sollten unbedingt die SQL Server-Sicherungs- und Wiederherstellungstools genommen werden, wenn Sie mehrere Datendateien für eine Inhaltsdatenbank verwenden. Weitere Informationen zum Sichern und Wiederherstellen von SharePoint Server finden Sie in Planen der Sicherung und der Wiederherstellung in SharePoint Server.
Weitere Informationen zum Erstellen und Verwalten von Dateigruppen finden Sie unter Architektur von Dateien und Dateigruppen.
Begrenzen der Größe von Inhaltsdatenbanken, um die Verwaltbarkeit zu verbessern
Planen Sie eine Datenbankgröße, die Verwaltbarkeit, Leistung und einfaches Upgrading Ihrer Umgebung verbessert.
Für eine bessere Systemleistung, empfiehlt Microsoft eine Größenbegrenzung von Inhaltsdatenbanken auf 200 MB, sofern nicht spezielle Verwendungsszenarien und -bedingungen größere Datenbanken erlauben. Weitere Informationen zur Größenbegrenzung von Inhaltsdatenbanken finden Sie im Abschnitt „Grenzwerte für Inhaltsdatenbanken“ unter Softwarebeschränkungen und -grenzen für SharePoint Server 2016.
Laut Microsoft-Empfehlung sollte eine Websitesammlung eine Größe von 100 GB nicht überschreiten, sofern es nicht die einzige Websitesammlung in der Datenbank ist. Sie können dann die SharePoint Server-Tools für eine differenzierte Sicherung verwenden, um eine Websitesammlung bei Bedarf in eine andere Datenbank zu verschieben.
Proaktive Verwaltung der Daten- und Protokolldateivariation
Microsoft empfiehlt eine proaktive Verwaltung des Wachstums Ihrer Daten und Protokolldateien unter Berücksichtigung der folgenden Empfehlungen:
Variieren Sie schon im Vorwege soweit wie möglich alle Daten und Protokolldateien bis zu ihrer erwarteten Endgröße.
Die Empfehlung lautet, aus Sicherheitsgründen die automatische Vergrößerung zu aktivieren. Verlassen Sie sich nicht auf die standardmäßigen Einstellungen der automatischen Vergrößerung. Beachten Sie bei Konfiguration der automatischen Vergrößerung die folgenden Richtlinien:
Falls Sie eine Inhaltsdatenbank mit mehr als der empfohlenen Größe (200 MB) planen, setzen Sie den Wert für die automatische Vergrößerung auf eine festgelegte Anzahl Megabyte und nicht auf einen Prozentwert. So verringern Sie die Häufigkeit, mit der SQL Server die Größe einer Datei erhöht. Die Erhöhung der Dateigröße stellt eine Blockierung dar, die zur Füllung neuer Speicherplätze mit leeren Seiten führt.
Falls die errechnete Größe der Inhaltsdatenbank nicht innerhalb des nächsten Jahres die empfohlene maximale Größe von 200 GB erreicht, setzen Sie die maximale Größe auf den Wert, den die Datenbank innerhalb eines Jahres könnte, plus einer Fehlertoleranz von 20 %, über die Eigenschaft ALTER DATABASE MAXSIZE. Prüfen Sie diese Einstellung regelmäßig, um zu gewährleisten, dass dies, abhängig von vergangenen Wachstumsraten, ein angemessener Wert ist.
Sie sollten mindestens 25 Prozent verfügbaren Speicherplatz auf allen Datenträgern vorhalten, um Vergrößerung und Spitzenauslastungen aufzufangen. Falls Sie das Anwachsen der Datenmenge über das Hinzufügen von Datenträgern zu einem RAID-Array oder durch Zuweisen von mehr Speicherplatz organisieren, überwachen Sie die Datenträgergröße in kurzen Abständen, um Speicherplatzmangel vorzubeugen.
Überprüfen und Überwachen von Speicher- und SQL Server-Leistung
Überprüfen Sie, dass die Leistung und die Sicherungslösung Ihrer Hardware ausreichen, um die Vereinbarungen zum Servicelevel (SLA) zu erfüllen. Testen Sie insbesondere das E/A-Subsystem des Computers, der SQL Server ausführt, um sicherzustellen, dass die Leistung zufriedenstellend ist.
Testen Sie auch die verwendete Wiederherstellungslösung, um zu gewährleisten, dass sie das System innerhalb des verfügbaren Wartungsfensters wiederherstellen kann. Falls die Sicherungslösung nicht Ihre geschäftlich erforderlichen SLAs erfüllt, nehmen Sie gegebenenfalls eine inkrementelle Sicherungslösung wie Microsoft System Center Data Protection Manager.
Sie müssen unbedingt die folgenden Ressourcenkomponenten eines Servers verfolgen, der SQL Server ausführt: CPU, Speicher, Cache/Trefferquote und E/A-Subsystem. Wenn mindestens eine dieser Komponenten langsam oder überlastet erscheint, analysieren Sie die Strategie basierend auf der aktuellen und geplanten Arbeitsauslastung. Weitere Informationen finden Sie unter Überwachen und Optimieren der Leistung für SQL Server 2014 (SP1) und Überwachen und Optimieren der Leistung für SQL Server 2016 und SQL Server 2017 RTM.
Im folgenden Abschnitt werden die von Microsoft empfohlenen Leistungsindikatoren aufgelistet, die Sie zum Überwachen der Leistung von SQL Server-Datenbanken verwenden sollten, die in Ihrer SharePoint Server-Umgebung ausgeführt werden. Außerdem sind dort die ungefähren Integritätswerte für die einzelnen Indikatoren aufgeführt.
Weitere Details zur Überwachung von Leistung und Nutzungsleistungsindikatoren finden Sie in Windows-Leistungsüberwachung und Leistungsüberwachung.
SQL Server-Indikatoren zur Überwachung
Überwachen Sie die folgenden SQL Server-Indikatoren, um die Integrität Ihrer Server sicherzustellen:
Allgemeine Statistik Dieses Objekt stellt einen Indikator bereit für die Überwachung der allgemeinen serverweiten Aktivität, wie Anzahl aktueller Verbindungen und Anzahl der Benutzer, die sich pro Sekunden bei Computern, die SQL Server ausführen, an- und abmelden. Überwachen Sie außerdem gegebenenfalls auch die folgenden Indikatoren:
- Benutzerverbindungen Dieser Indikator zeigt die Anzahl Benutzerverbindungen auf Ihrem Computer an, der SQL Server ausführt. Falls diese Anzahl um 500 % über den Ausgangswert ansteigt, sollten Sie eine Leistungsreduzierung vorsehen.
Datenbanken Dieses Objekt stellt Indikatoren für die Überwachung von Massenkopiervorgängen, Sicherungs- und Wiederherstellung von Durchsatz sowie Transaktionsprotokollaktivitäten bereit. Überwachen Sie Transaktionen und das Transaktionsprotokoll, um zu ermitteln, wie viel Benutzeraktivität in der Datenbank stattfindet und wie voll das Transaktionsprotokoll wird. Die Höhe der Benutzeraktivität kann die Leistung der Datenbank bestimmen und Protokollgröße, Sperrung und Replikation beeinflussen. Eine Überwachung geringer Protokollaktivität zum Messen von Benutzeraktivität und Ressourcenauslastung hilft Ihnen, Leistungsengpässe zu erkennen. Überwachen Sie gegebenenfalls auch die folgenden Indikatoren:
- Transaktionen/s Dieser Indikator zeigt die Anzahl Transaktionen in einer gegebenen Datenbank bzw. auf dem gesamten Server pro Sekunde an. Diese Anzahl dient in erster Linie einem Abgleich mit dem Ausgangswert und hilft Ihnen bei der Fehlersuche.
Sperren Dieses Objekt liefert Informationen zu SQL Server-Sperren bei einzelnen Ressourcentypen. Überwachen Sie gegebenenfalls auch die folgenden Indikatoren:
Durchschnittliche Wartezeit (ms) Dieser Indikator zeigt die durchschnittliche Wartezeit bei den einzelnen Sperranforderungen an, die zu einer Wartezeit führen.
Wartezeit für Sperre (in Millisekunden) Dieser Indikator zeigt die Wartezeit bei Sperren in der letzten Sekunde an.
Sperrenwartevorgänge/s Dieser Indikator zeigt die Anzahl Speeren pro Sekunden an, die nicht unmittelbar aufgehoben werden konnten und Ressourcen bedürfen.
Anzahl der Deadlocks/s Dieser Indikator zeigt die Anzahl Deadlocks pro Sekunde auf dem Computer an, der SQL Server ausführt. Diese Anzahl darf 0 nicht überschreiten.
Latches Dieses Objekt stellt einen Indikator bereit, der die internen SQL Server-Ressourcensperren, die so genannten Latches, überwacht. Die Überwachung der Latches zur Ermittlung von Benutzeraktivität und Ressourcenauslastung hilft Ihnen, Leistungsengpässe zu erkennen. Überwachen Sie gegebenenfalls auch die folgenden Indikatoren:
Durchschnittliche Wartezeit für Latch (in Millisekunden) Dieser Indikator zeigt die durchschnittliche Latchwartezeit an, die Latchanforderungen warten müssen.
Latchwartevorgänge/Sekunde Dieser Indikator zeigt die Anzahl Latchanforderungen an, die nicht unmittelbar erteilt werden können.
SQL-Statistik Dieses Objekt stellt Indikatoren bereit, um Kompilation und Abfragetyp zu überwachen, der an eine SQL Server-Instanz gesendet wird. Die Überwachung der Anzahl von Abfragekompilierung und Neukompilierung sowie die Anzahl Batches, die eine SQL Server-Instanz empfängt, gibt Ihnen einen Hinweis darauf, wie schnell SQL Server Benutzerabfragen verarbeitet und wie effektiv der Abfrageoptimierer die Abfragen verarbeitet. Überwachen Sie gegebenenfalls auch die folgenden Indikatoren:
SQL-Kompilierungen/Sekunde Dieser Indikator zeigt an, wie oft der Kompilierungscodepfad pro Sekunde gewählt wird.
Erneute SQL-Kompilierungen/Sekunde Dieser Indikator zeigt die Anzahl der Neukompilierungen pro Sekunde von Anweisungen an.
Puffer-Manager Dieses Objekt stellt Indikatoren bereit, die überwachen, wie SQL Server Speicher zum Ablegen von Datenseiten, internen Datenstrukturen und des Prozedurcaches verwendet, sowie Indikatoren, die physische E/O überwachen, während SQL Server Datenbankseiten liest und schreibt. Überwachen Sie gegebenenfalls auch die folgenden Indikatoren:
Puffercache-Trefferquote
Dieser Indikator zeigt den Prozentsatz Seiten an, die im Puffercache gefunden wurden, ohne sie vom Datenträger auslesen zu müssen. Diese Quote ergibt sich aus der Gesamtanzahl Cachetreffern dividiert durch die Gesamtanzahl Cachesuchvorgängen bei den letzten tausend Seitenzugriffen. Da das Lesen aus dem Cache weniger aufwändig als das Lesen aus dem Datenträger ist, sollte diese Quote hoch sein. In der Regel können Sie die Puffercache-Trefferquote hochsetzen, indem Sie den verfügbaren Speicher für SQL Server vergrößern.
Plancache Dieses Objekt stellt Indikatoren bereit, die überwachen, wie SQL Server Speicher zum Ablegen von Objekten (das sind beispielsweise gespeicherte Prozeduren, vorbereitete und nicht vorbereitete Transaktions-SQL-Anweisungen und Trigger) verwendet. Überwachen Sie gegebenenfalls auch die folgenden Indikatoren:
Cachetrefferquote
Dieser Indikator gibt das Verhältnis von Cachetreffern zu Plansuchvorgängen an.
Physikalische Serverindikatoren für die Überwachung
Überwachen Sie die folgenden Indikatoren, um die Integrität Ihrer Computer sicherzustellen, die SQL Server ausführen:
Prozessor: Prozessorzeit (%): _Gesamt Diese Indikator zeigt die Zeit in Prozent, die der Prozessor Anwendungen ausführt bzw. die das Betriebssystem aktiv ist. Auf dem Rechner, der SQL Server ausführt, sollte der Indikator zwischen 50 und 70 Prozent anzeigen. Bei einer konstanten Überlastung, prüfen Sie, ob eine anormale Prozessaktivität vorliegt oder der Server zusätzliche CPUs benötigt.
System: Prozessor-Warteschlangenlänge Dieser Indikator zeigt die Anzahl Threads in der Prozessor-Warteschlange an. Eine Überwachung dieses Indikators stellt sicher, dass ein Wert höchstens halb so groß wie die Anzahl der Kern-CPUs angezeigt wird.
Speicher: Verfügbare MB Dieser Indikator zeigt den physikalischen Speicher in Megabyte an, der zum Ausführen von Prozessen auf dem Computer verfügbar ist. Eine Überwachung dieses Indikators stellt sicher, dass mindestens 20 % des insgesamt verfügbaren physikalischen RAM dafür reserviert bleibt.
Speicher: Seiten/s Dieser Indikator zeigt die Rate, mit der Seiten vom Datenträger gelesen bzw. auf ihn geschrieben werden, um Hardwareseitenfehler aufzuheben. Eine Überwachung dieses Indikators stellt sich, dass der Wert unter 100 bleibt.
Weitere Informationen und Beschreibungen von Methoden zum Beheben von Arbeitsspeicherproblemen finden Sie in den folgenden Ressourcen:
SQL Server 2014 (SP1) - Überwachen der Speicherauslastung
SQL Server 2016 und SQL Server 2017 – Überwachen der Speicherauslastung
Weitere Informationen sowie Methoden zur Fehlerbehebung finden Sie unter Überwachen der Arbeitsspeicherverwendung für SQL Server 2008 R2 mit SP1, Überwachen der Speicherauslastung für SQL Server 2012 und Überwachen der Speicherauslastung für SQL Server 2014.
Datenträgerindikator für die Überwachung
Überwachen Sie die folgenden Indikatoren, um die Integrität von Datenträgern sicherzustellen. Beachten Sie, dass die folgenden Werte Langzeitwerte darstellen und keine Spitzenwerte oder Einzelmesswerte.
Physikalischer Datenträger: Zeit (%): DataDrive Dieser Indikator zeigt den Prozentsatz der abgelaufenen Zeit an, die das gewählte Laufwerk mit dem Lesen und Schreiben von Anfragen ausgelastet ist. Es handelt sich hierbei um einen allgemeinen Indikator, der die Auslastung des Datenträgers misst. Falls der Indikator Physikalischer Datenträger: Zeit (%) einen hohen Wert (über 90 %) anzeigt, überprüfen Sie anhand des Indikators Physikalischer Datenträger: Aktuelle Warteschlangenlänge, wie viele Systemanfragen auf Datenträgerzugriff warten. Die Anzahl der wartenden E/A-Anforderungen darf nicht mehr als das 1,5- bis 2-Fache der Anzahl der Spindeln des physikalischen Datenträgers betragen.
Logischer Datenträger: Übertragungen/s Dieser Indikator zeigt die Rate an, mit der Lese- und Schreibvorgänge auf dem Datenträger ausgeführt werden. Dieser Indikator dient zum Überwachen von Wachstumstrends und Prognosen.
Logischer Datenträger: Bytes gelesen/s und Logischer Datenträger: Bytes geschrieben/s Diese Indikatoren zeigen die Rate an, mit der Bytes bei Lese- oder Schreibvorgängen vom Datenträger übertragen werden.
Logischer Datenträger: Mittlere Bytes/Lesevorgang Dieser Indikator zeigt die durchschnittliche Anzahl Bytes an, die bei Lesevorgängen vom Datenträger übertragen werden. Dieser Indikator spiegelt auch die Latenz des Datenträgers wider: längere Lesevorgänge können zu leicht höherer Latenz führen.
Logischer Datenträger: Mittlere Bytes/Schreibvorgang Dieser Indikator zeigt die durchschnittliche Anzahl Bytes an, die bei Schreibvorgängen vom Datenträger übertragen werden. Dieser Indikator spiegelt auch die Latenz des Datenträgers wider: längere Schreibvorgänge können zu leicht höherer Latenz führen.
Logischer Datenträger: Aktuelle Warteschlangenlänge Dieser Indikator zeigt die Anzahl ausstehender Anforderungen auf dem Datenträger zum Zeitpunkt der Leistungsdatenerfassung an. Bei diesem Indikator sind kleine Werte die besseren Werte. Werte größer 2 pro Datenträger können Anzeichen für einen Engpass sein und sollten untersucht werden. Das heißt, ein Wert bis zu 8 kann bei einer logischen Einheit (LUN), die aus vier Datenträgern besteht, akzeptabel sein. Engpässe können möglicherweise einen Backlog hervorrufen, der auch auf weitere Server übergreifen und damit zu langen Wartezeiten für den Benutzer führen kann. Engpässe können durch Hinzufügen von weiteren Datenträgern zum RAID-Array, durch Ersetzen der vorhandenen Datenträger durch schnellere oder durch Verschieben von Daten auf andere Datenträger vermieden werden.
Logischer Datenträger: Durchschnittl. Warteschlangenlänge des Datenträgers Dieser Indikator zeigt die durchschnittliche Anzahl Lese- und Schreibanforderungen an, die für den gewählten Datenträger während des Probenintervalls in die Warteschlange gestellt wurden. Die Regel lautet, nicht mehr als zwei ausstehende Lese- und Schreibanforderungen pro Spindel. Diese Vorgabe ist möglicherweise aufgrund von Speichervirtualisierung und unterschiedlichen RAID-Levels der einzelnen Konfigurationen schwer zu messen. Prüfen Sie daher auf überdurchschnittliche Warteschlangenlängen in Verbindung mit überdurchschnittlichen Datenträgerlatenzen. Diese Kombination kann darauf hinweisen, dass der Speicherarraycache mehr als ausgelastet ist oder dass eine Spindelfreigabe für andere Anwendungen die Leistung beeinträchtigt.
Logischer Datenträger: Mittlere Sek./Lesevorgänge und Logischer Datenträger: Mittlere Sek./Schreibvorgänge Diese Indikatoren zeigen die durchschnittliche Zeit für einen Lese- oder Schreibvorgang auf einem Datenträger in Sekunden an. Die Überwachung dieser Indikatoren stellt sicher, dass sie Werte unterhalb von 85 % der Datenträgerkapazität anzeigen. Die Zugriffszeit auf den Datenträger steigt exponentiell an, wenn die Lese- oder Schreibvorgänge mehr als 85 % der Datenträgerkapazität auslasten. Wenn Sie die Kapazität Ihrer speziellen Hardware ermitteln möchten, lesen Sie die Herstellerdokumentation oder berechnen Sie sie mit dem Speichertesttool „Diskspd“. Weitere Informationen finden Sie unter Dienstprogramm „Diskspd“: Ein robustes Speichertesttool (das SQLIO ersetzt).
Logischer Datenträger: Mittlere Sek./Lesevorgänge Dieser Indikator zeigt die durchschnittliche Zeit für einen Lesevorgang vom Datenträger in Sekunden an. In einem gut eingestellten System reichen die Werte von 1 bis 5 ms für Protokolle (idealerweise 1 ms bei einem gecachten Array) bzw. von 4 bis 20 ms (idealerweise weniger als 10 ms). Längere Latenzen können in Spitzenzeiten auftreten. Falls jedoch höhere Werte regelmäßig auftreten, sollten Sie nach der Ursache suchen.
Logischer Datenträger: Mittlere Sek./Schreibvorgänge Dieser Indikator zeigt die durchschnittliche Zeit für einen Schreibvorgang auf den Datenträger in Sekunden an. In einem gut eingestellten System reichen die Werte von 1 bis 5 ms für Protokolle (idealerweise 1 ms bei einem gecachten Array) bzw. von 4 bis 20 ms (idealerweise weniger als 10 ms). Längere Latenzen können in Spitzenzeiten auftreten. Falls jedoch höhere Werte regelmäßig auftreten, sollten Sie nach der Ursache suchen.
Wenn Sie RAID-Konfigurationen mit den Indikatoren **Logischer Datenträger: Mittlere Bytes/Lesevorgang ** oder Logischer Datenträger: Mittlere Bytes/Schreibvorgang verwenden Sie die Formeln aus der Tabelle unten, um die E/A-Rate des Datenträgers zu ermitteln.
RAID-Level Formel RAID 0
E/A pro Datenträger = (Lese- und Schreibvorgänge) / Anzahl Datenträger
RAID 1
E/A pro Datenträger = [Lesevorgänge + (2 × Schreibvorgänge)] / 2
RAID 5
E/A pro Datenträger = [Lesevorgänge + (4 × Schreibvorgänge)] / Anzahl Datenträger
RAID 10
E/A pro Datenträger = [Lesevorgänge + (2 × Schreibvorgänge)] / Anzahl Datenträger
Angenommen, Sie haben ein RAID 1-System mit zwei physikalischen Datenträgern und Ihre Indikatoren zeigen die Werte aus der folgenden Tabelle.
Indikator Wert Mittlere Sek./Lesevorgänge
80
Logischer Datenträger: Mittlere Sek./Schreibvorgänge
70
Durchschnittl. Warteschlangenlänge des Datenträgers
5
Der E/A-Wert pro Datenträger kann wie folgt berechnet werden: (80 + (2 × 70))/2 = 110
Die Warteschlangenlänge des Datenträgers kann wie folgt berechnet werden: 5/2 = 2,5
Sie haben jetzt einen grenzwertigen E/A-Engpass.
Weitere Überwachungstools
Für die Überwachung der Datenträgerwartezeit und die Trendanalyse können Sie auch die dynamische Verwaltungssicht „sys.dm_io_virtual_file_stats“ SQL Server 2008 verwenden. Weitere Informationen finden Sie unter sys.dm_io_virtual_file_stats (Transact-SQL).
SQL Server 2012 für SharePoint Server 2013
Unser Dank geht an Bill Baer, Microsoft Senior Product Marketing Manager, und an Brian Alderman, CEO und Gründer von SQL Server 2012-Schulungsmodulen. Besonders danken wir auch Channel 9 Microsoft, der diese Module hostet. In den folgenden Schulungsmodulen finden Sie Details zu Einstellungen der SQL Server 2012-Datenbanken, damit Sie die Leistung, die Verfügbarkeit und die Sicherheit von SharePoint Server 2016 optimieren können.
Optimieren von SQL Server 2012 für SharePoint 2013: (03) Servereinstellungen für SQL Server
Optimieren von SQL Server 2012 für SharePoint 2013: (04) Verfügbarkeit von SQL Server und SharePoint
See also
Übersicht über SQL Server in einer SharePoint Server 2016-Umgebung
Optimieren der Leistung für SharePoint Server 2013
Bewährte Methoden für SQL Server in einer SharePoint Server-Farm
Planen der Leistung in SharePoint Server 2013 Planung
Kapazitätsverwaltung und Dimensionierung für SharePoint Server 2013
Kapazitätsplanung für SharePoint Server 2013
Übersicht über SQL Server in einer SharePoint Server 2013-Umgebung