Teilen über


Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server)

GILT FÜR:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

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.

Erfahren Sie mehr über das Verwalten von Websitespeicherlimits für SharePoint in Microsoft 365.

Obwohl Tests nicht unter SQL Server 2014 (SP1), SQL Server 2016, SQL Server 2017 RTM oder SQL Server 2019 ausgeführt wurden, können Sie diese Testergebnisse als Leitfaden verwenden, um Die Speicher- und SQL Server-Datenbankebene in SharePoint Server-Abonnementedition, 2019- oder 2016-Umgebungen zu planen und zu konfigurieren. Weitere Informationen zur Schulung, wie SQL Server 2012 konfiguriert und eingestellt wird, finden Sie unter SQL Server 2012 für SharePoint Server 2013. Die Testergebnisse sind mit denen in SharePoint 2013 identisch.

Dieses Dokument ist für die gemeinsame Verwendung durch SharePoint Server-Farmimplementierer und SQL Server-Datenbankadministratoren vorgesehen, da SharePoint Server häufig in Umgebungen ausgeführt wird, in denen Datenbanken von separaten SQL Server-Datenbankadministratoren verwaltet werden. 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.

Entwurf und Konfigurationsprozess der Speicher- und Datenbankebene für SharePoint Server 2016 und höher

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:

  1. Erfassen von Speicherplatz, SQL Server-Speicher und E/A-Anforderungen

  2. Wählen der SQL Server-Version und -Edition

  3. Entwerfen der Speicherarchitektur basierend auf Kapazität und E/A-Anforderungen

  4. Abschätzen von Speicheranforderungen

  5. Netzwerktopologieanforderungen

  6. Konfigurieren von SQL Server

  7. Überprüfen und Überwachen der Speicher- und SQL Server-Leistung

Erfassen der Speicher- und SQL Server-Kapazität und der 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.

In diesem Abschnitt:

Von SharePoint Server verwendete Datenbanken

Die Datenbanken, die mit SharePoint Server (Abonnementedition, 2019 oder 2016) installiert werden, hängen von den Dienstanwendungen ab, die in der Umgebung verwendet werden. Alle SharePoint Server-Umgebungen basieren auf den SQL Server-Systemdatenbanken. Dieser Abschnitt enthält eine Zusammenfassung der mit SharePoint-Servern installierten Datenbanken. Weiterführende Informationen zu Datenbanken finden Sie in Datenbanktypen und -beschreibungen in SharePoint Server.

Für einige SharePoint Server-, SQL Server-Datenbank-Engine- und SQL Server Reporting Services-Datenbanken (SSRS) gelten bestimmte Standortempfehlungen oder -anforderungen. Informationen zu diesen Datenbankspeicherorten finden Sie unter Datenbanktypen und Beschreibungen in SharePoint Server. Die Kurzübersicht: SharePoint Server 2016- und 2019-Datenbanken steht als PDF - oder Visio-Datei zum Download zur Verfügung.

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

Wenn Sie sql Server weiter integrieren, enthält Ihre Umgebung möglicherweise auch mehr Datenbanken, wie im folgenden Szenario. SQL Server Power Pivot 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. Wenn sie verwendet wird, müssen Sie auch die Unterstützung der Power Pivot-Anwendungsdatenbank und der zusätzlichen Auslastung des Systems planen. 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.

Das SQL Server 2016 Reporting Services-Add-In (SSRS) kann mit jeder beliebigen SharePoint Server 2016-Umgebung verwendet werden. Wenn Sie das Add-In verwenden, planen Sie die Unterstützung der beiden SQL Server Reporting Services-Datenbanken und der zusätzlichen Last, 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. Wenn sie verwendet wird, müssen Sie auch die Unterstützung der Power Pivot-Anwendungsdatenbank und der zusätzlichen Auslastung des Systems planen. Weitere Informationen finden Sie unter Planen einer PowerPivot-Bereitstellung in einer SharePoint-Farm, Power Pivot – Übersicht und Lernen und Power View – Übersicht und Lernen.

  • Das SQL Server 2008 R2 Reporting Services (SSRS)-Plug-In kann mit jeder beliebigen SharePoint 2013-Umgebung verwendet werden. Wenn Sie das Plug-In verwenden, planen Sie die Unterstützung der beiden SQL Server 2008 R2 Reporting Services-Datenbanken und der zusätzlichen Last, die für SQL Server 2008 R2 Reporting Services erforderlich ist.

Hinweis

Die Integration von SQL Server Reporting Services in SharePoint Server 2019 wird nicht mehr unterstützt. Weitere Informationen finden Sie unter Reporting Services-Berichtsserver (SharePoint-Modus) und Unterstützte Kombinationen von SharePoint und Reporting Services-Server.

SQL Server und IOPS

Bei jedem Server, der eine SQL Server-Instanz hostet, ist es 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, wird empfohlen, ein Benchmark für das E/A-Subsystem mithilfe des Diskspd-Hilfsprogramms zu erstellen. Dieses Tool funktioniert auf allen Windows Server-Versionen mit allen Versionen von SQL Server. 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 Inhaltsdatenbank der Zentraladministration sind nicht groß. Es wird empfohlen, 2 GB für die Konfigurationsdatenbank und 1 GB für die Inhaltsdatenbank der Zentraladministration zuzuweisen. Im Laufe der Zeit kann die Konfigurationsdatenbank ü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. Es wird empfohlen, das Transaktionsprotokoll für die Konfigurationsdatenbank regelmäßig zu sichern, um das Kürzen der Datei zu erzwingen. Wenn Sie in SQL Server AlwaysOn-Verfügbarkeitsgruppen oder Datenbankspiegelung verwenden, sollten Sie auch die Datenbank im vollständigen Wiederherstellungsmodus ausführen lassen. Weitere Informationen finden Sie unter Das Transaktionsprotokoll (SQL Server).

Tipp

Wenn Sie keine SQL Server-Hochverfügbarkeitslösung verwenden, die die Verwendung des vollständigen Wiederherstellungsmodells erfordert, sollten Sie erwägen, die Konfigurationsdatenbank auf das einfache Wiederherstellungsmodell umzustellen.

Die IOPS-Anforderungen für die Konfigurationsdatenbank und die Inhaltsdatenbank der Zentraladministration sind minimal.

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:

  1. Verwenden Sie die folgende Formel, um die Größe Ihrer Inhaltsdatenbanken zu berechnen:

    Datenbankgröße = ((D × V) × S) + (10 KB × (L + (V × D)))

    Hinweis

    [!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.

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

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

  4. Berechnen Sie die Anzahl Listenelemente in der Umgebung. Dieser Wert ist in der Formel als L ausgedrückt.

    Listenelemente sind schwieriger einzuschätzen als Dokumente. Wir verwenden im Allgemeinen eine Schätzung von dreimal der Anzahl von Dokumenten (D), aber die Schätzungsformel variiert je nachdem, wie Sie Ihre Websites verwenden möchten.

  5. 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 beispielsweise diese Formel und die Merkmale in der folgenden Tabelle, um den erforderlichen Speicherplatz für Datendateien in einer Inhaltsdatenbank für eine Zusammenarbeitsumgebung zu schätzen. Das Ergebnis ist, dass Sie ungefähr 105 GB benötigen.

Input Value
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 in SharePoint Server ist eine Speichermethode, bei der eine Datei in Teile aufgeteilt wird, die separat gespeichert und aktualisiert werden. Diese Teile werden zusammen gestreamt, wenn ein Benutzer die Datei anfordert. Dadurch wird die E/A-Leistung erhöht, die Dateigröße wird jedoch normalerweise nicht erhöht. Bei kleinen Dateien kann sich der erforderliche Datenträgerspeicher jedoch geringfügig erhöhen.

Features mit Einfluss auf die Größe von Inhaltsdatenbanken

Die folgenden SharePoint Server-Features können 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, 2019, Subscription Edition 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 Deploy Office Online Server.

Ermitteln der IOPS-Anforderungen für Inhaltsdatenbanken

Die IOPS-Anforderungen für Inhaltsdatenbanken variieren je nachdem, wie Ihre Umgebung verwendet wird, je nachdem, wie viel Speicherplatz verfügbar ist und wie viele Server Sie haben. Im Allgemeinen wird empfohlen, die zu erwartende Arbeitsauslastung in Ihrer Umgebung mit einer der getesteten Lösungen zu vergleichen. Weitere Informationen, die auf eine neuere Version von SharePoint angewendet werden können, finden Sie unter Leistungs- und Kapazitätstestergebnisse und -empfehlungen (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. Dieser erhöhte Anteil ist mehr als nötig und kann viel mehr sein, als Sie in Ihrer Umgebung benötigen. Wenn Sie die Spiegelung verwenden, führt dieser erhöhte Anteil zu wesentlich mehr E/A als die primären Inhaltsdatenbanken. Beachten Sie, dass die gespiegelten Inhaltsdatenbanken niemals einfach sind.

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 Speicher- und IOPS-Daten für alle Dienstanwendungen in der SharePoint Server-Abonnementedition, 2019 oder 2016 bleiben identisch mit den In SharePoint Server 2010 und 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
Protokoll mit 50 GB
Linkdatenbank Eine DB pro 60 MBit Elemente
SQL IOPS: 10 pro 1 MBit Elemente
Medium Medium 10 GB
Protokoll mit 0,1 GB
80 GB
5 GB Protokoll
Analyseberichtsdatenbank Teilen 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: Die Tests für die Speicheranforderungen für die Benutzerprofildatenbank und die IOPS-Empfehlungen sind 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. Es wird empfohlen, 5 MB pro 1.000 Anmeldeinformationen dafür zuzuweisen. 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-Dienst Die Business Data Connectivity Service-Anwendung hat eine Datenbank. Diese ist klein und ein starker Zuwachs unwahrscheinlich. Sie hat minimale IOPS-Vorgänge. Die PerformancePoint-Dienste gelten nicht für die Abonnementedition.
App-Verwaltung Die App-Verwaltungsdienstanwendung 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. Inhaltsdatenbanken haben deutlich höhere E/A-Anforderungen als die Power Pivot-Dienstanwendungsdatenbank.

Festlegen von Verfügbarkeitsanforderungen

Verfügbarkeit gibt an, wie stark eine SharePoint Server-Umgebung von Benutzern als verfügbar wahrgenommen 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 Always On-Architekturleitfaden: Herstellen von hoher Verfügbarkeit und Wiederherstellungslösungen mit Always On-Verfügbarkeitsgruppen.

Auswählen der SQL Server-Version und -Edition

Sie sollten Ihre Umgebung bei Verwendung von SharePoint Server Subscription Edition, 2019 oder 2016 vorzugsweise in der Enterprise Edition der folgenden SQL Server ausführen, um die anderen Leistungs-, Verfügbarkeits-, Sicherheits und Verwaltungsfunktionen dieser Versionen nutzen zu können.

  • SQL Server 2019 (SharePoint Subscription Edition, 2019, und 2016)

  • SQL Server 2017 RTM (SharePoint Server 2016 and 2019)

  • SQL Server 2016 (SharePoint Server 2016 und 2019)

  • SQL Server 2014 mit Service Pack 1 (SP1) (nur SharePoint Server 2016)

Weitere Informationen zu den Vorteilen dieser Versionen finden Sie unter Von den Editionen von SQL Server 2014 unterstützte Features, Editionen und unterstützte Features von SQL Server 2016, Editionen und unterstützte Features von SQL Server 2017 und Editionen und unterstützte Features von SQL Server 2019 (15.x)).

Es wird empfohlen, für SharePoint Server 2013 die Ausführung Ihrer Umgebung unter der Enterprise Edition von SQL Server 2008 R2 mit Service Pack 1 (SP1), SQL Server 2012 oder SQL Server 2014 in Erwägung zu ziehen, um von den anderen Leistungs-, Verfügbarkeits-, Sicherheits- und Verwaltungsfunktionen zu profitieren, die diese Versionen bieten. 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).

    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 die Enterprise Edition von Folgendem installiert haben:

    SharePoint Server-Abonnementedition:

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint Server 2019:

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint Server 2016:

    • SQL Server 2014 (SP1)

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint 2013:

    • SQL Server 2008 R2 mit SP1

    • SQL Server 2012 Enterprise Edition

  • 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 Resource Governor.

    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 Power Pivot für SharePoint Ermöglicht Benutzern das Freigeben und Zusammenarbeiten an benutzergenerierten Datenmodellen und Analysen in Excel im Web, während diese Analysen automatisch aktualisiert werden. Sie benötigen Office im Web, um Excel im Web mit Power Pivot für SharePoint und SharePoint Server 2016 verwenden zu können. 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 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

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, die Remotespeichergeräte für Computer (z. B. Datenträgerarrays und Bandarchive) derart an Server anschließt, dass die Geräte dem Betriebssystem als lokal angeschlossen angezeigt werden (z. B. Blockspeicher).

SAN ist die Lösung der Wahl, wenn Ihrem Unternehmen die Vorteile freigegebener Speicher sehr wichtig sind.

Die Vorteile freigegebener Speicher:

  • 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

[!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.

Hinweis

Es besteht einige Verwirrung darüber, ob Sie die Internet Small Computer System Interface (iSCSI) verwenden und davon ausgehen, dass es sich um ein NAS-Protokoll handelt. Wenn Sie über das Common Internet File System (CFIS) auf diesen iSCSI-Speicher zugreifen, handelt es sich um ein NAS-Protokoll. Dies bedeutet, dass Sie diesen Speicher nicht mit Inhaltsdatenbanken verwenden können, wenn diese nicht für die Verwendung von RBS konfiguriert sind. Wenn Sie jedoch über eine lokal angefügte Festplatte auf diesen iSCSI-Speicher zugreifen, wird dies als SAN-Architektur betrachtet. Dies bedeutet, dass Sie es mit NAS verwenden können.

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

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 Extra RAM von mehr als 64 GB kann die Geschwindigkeit des Zwischenspeicherns von SQL Server verbessern

Hinweis

[!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 den 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 für SQL Server 2016 und 2017.

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:

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

  • Planen Sie ein angemessenes WAN-Netzwerk, wenn Sie SQL Server Always On-Implementierungssuite, Spiegelung, Protokollversand oder Failoverclustering verwenden möchten, um einen Remotestandort auf dem neuesten Stand 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

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.

Platzieren Sie SQL Server immer auf einem dedizierten Server, auf dem keine anderen Farmrollen ausgeführt werden oder Datenbanken für andere Anwendungen hosten. Die einzige Ausnahme von dieser Empfehlung ist, wenn Sie das System auf einem eigenständigen Server für eine Entwicklungsumgebung oder eine nicht leistungsorientierte Testumgebung bereitstellen. Obwohl SQL Server auf demselben Server wie SharePoint ausgeführt werden kann, wird empfohlen, SQL Server auf einem separaten Server auszuführen, um die Leistung zu verbessern.

Es folgt ein allgemeiner Anweisungen für die Bereitstellung eines extra 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. Eine größere Busbandbreite trägt dazu bei, die Zuverlässigkeit und Leistung zu verbessern. Bedenken Sie, dass der Datenträger nicht der einzige Nutzer der Busbandbreite ist: So ist z. B. auch der Netzwerkzugriff zu 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 das automatische Erstellen von Statistiken nicht auf einem Server, der SQL Server hostet und SharePoint Server unterstützt. SharePoint Server konfiguriert die erforderlichen Einstellungen bei der Bereitstellung und dem Upgrade. Durch automatisches Erstellen von Statistiken kann der Ausführungsplan einer Abfrage von einer Instanz von SQL Server in eine andere Instanz von SQL Server geändert werden. Um konsistenten Support für alle Kunden bereitzustellen, stellt SharePoint Server daher bei Bedarf codierte Hinweise für Abfragen bereit, um die beste Leistung in allen Szenarien zu erzielen.

  • 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

Im Idealfall sollten Sie die tempdb-Datenbank, Inhaltsdatenbanken, Verwendungsdatenbank, Suchdatenbanken und SQL Server 2019, SQL Server 2017 RTM, SQL Server 2016, SQL Server 2014 (SP1), SQL Server 2012 und SQL Server 2008 R2 mit SP1-Transaktionsprotokollen auf separaten physischen Festplatten platzieren.

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 zeigen, dass die Leistung der SharePoint Server-Farm durch unzureichende Datenträger-E/A für tempdb beeinträchtigt 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

[!WICHTIGER HINWEIS] 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 zu Größenbeschränkungen für Inhaltsdatenbanken finden Sie im Abschnitt "Grenzwerte für Inhaltsdatenbanken" unter Softwaregrenzen und -grenzwerte für SharePoint Server 2016 und 2019.

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 Größenzunahme von Daten- und Protokolldateien

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. Diese Einstellung reduziert 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.

    • Wenn nicht erwartet wird, dass die berechnete Größe der Inhaltsdatenbank die empfohlene maximale Größe von 200 GB innerhalb des nächsten Jahres erreicht, legen Sie sie mithilfe der ALTER DATABASE MAXSIZE-Eigenschaft auf die maximale Größe fest, die die Datenbank in einem Jahr erreichen wird – mit 20 Prozent mehr Fehlerspanne. 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 Abstimmen der Leistung.

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.

Zu überwachende SQL Server-Leistungsindikatoren

Ü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/Sekunde Dieser Leistungsindikator zeigt die Anzahl der Transaktionen in einer bestimmten Datenbank oder auf dem gesamten Server pro Sekunde an. Diese Zahl ist mehr für Ihre Baseline und als Hilfe bei der Problembehandlung.
  • 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 Zahl sollte nicht über 0 steigen.

  • 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: _Total Dieser Leistungsindikator zeigt den Prozentsatz der Zeit an, in der der Prozessor andere Anwendungs- oder Betriebssystemprozesse als Leerlauf ausführt. Auf dem Computer, auf dem SQL Server ausgeführt wird, sollte dieser Zähler zwischen 50 % und 75 % beibehalten werden. Untersuchen Sie bei konstanter Überladung, ob eine ungewöhnliche Prozessaktivität vorliegt oder ob der Server mehr 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.

  • Arbeitsspeicher: Seiten/Sekunde Dieser Leistungsindikator zeigt die Rate an, mit der Seiten vom Datenträger gelesen oder auf den Datenträger geschrieben werden, um fehlerbehaftete Seiten zu beheben. Überwachen Sie diesen Zähler, um sicherzustellen, dass er unter 100 bleibt.

Weitere Informationen und Beschreibungen von Methoden zum Beheben von Arbeitsspeicherproblemen finden Sie in den folgenden Ressourcen:

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. Die folgenden Werte stellen Werte dar, die im Laufe der Zeit gemessen werden , nicht Werte, die während einer plötzlichen Spitze auftreten, und nicht Werte, die auf einer einzelnen Messung basieren.

  • Physischer Datenträger: % Datenträgerzeit: DataDrive Dieser Leistungsindikator zeigt den Prozentsatz der verstrichenen Zeit an, in der das ausgewählte Laufwerk ausgelastet ist, um Lese- oder Schreibanforderungen zu warten. Er ist ein allgemeiner Indikator dafür, wie ausgelastet der Datenträger ist. Wenn der Zähler PhysicalDisk: % Datenträgerzeit hoch (mehr als 90 Prozent) ist, überprüfen Sie den Zähler PhysicalDisk: Current Disk Queue Length ,um zu sehen, wie viele Systemanforderungen auf den Datenträgerzugriff warten. Die Anzahl der wartenden E/A-Anforderungen sollte nicht mehr als das 1,5- bis 2-fache der Anzahl der Spindeln bestehen, aus denen der physische Datenträger besteht.

  • 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. Daher ist ein Wert von bis zu 8 für eine logische Einheit (LUN) zulässig, die aus vier Datenträgern besteht. 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. Aufgrund der Speichervirtualisierung und der Unterschiede bei den RAID-Ebenen zwischen konfigurationen kann diese Anforderungsanzahl jedoch schwierig zu messen sein. 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 Diskspd: A Robust Storage Performance Tool.For more information, see Diskspd: A Robust Storage Performance Tool.For more information, see Diskspd: A Robust Storage Performance Tool.

    • Logischer Datenträger: Durchschn. Datenträger in Sekunde/Lesevorgang Dieser Leistungsindikator zeigt die durchschnittliche Zeit (in Sekunden) eines Lesevorgangs vom Datenträger an. Auf einem gut abgestimmten System liegen die idealen Werte zwischen 1 und 5 ms für Protokolle (idealerweise 1 ms in einem zwischengespeicherten Array) und zwischen 4 und 20 ms für Daten (idealerweise weniger als 10 ms). In Spitzenzeiten können höhere Latenzen auftreten. Wenn jedoch regelmäßig hohe Werte auftreten, sollten Sie die Ursache untersuchen.

    • Logischer Datenträger: Durchschn. Datenträger in Sekunde/Schreibzugriff Dieser Leistungsindikator zeigt die durchschnittliche Zeit (in Sekunden) eines Schreibvorgangs auf dem Datenträger an. Auf einem gut abgestimmten System liegen die idealen Werte zwischen 1 und 5 ms für Protokolle (idealerweise 1 ms in einem zwischengespeicherten Array) und zwischen 4 und 20 ms für Daten (idealerweise weniger als 10 ms). In Spitzenzeiten können höhere Latenzen auftreten. Wenn jedoch regelmäßig hohe Werte auftreten, sollten Sie die Ursache untersuchen.

      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 I/Os pro Festplatte = [Lesevorgänge + (2 x Schreibvorgänge)] / 2
RAID 5 I/Os pro Datenträger = [Lesevorgänge + (4 x Schreibvorgänge)] / Anzahl der Datenträger
RAID 10 I/Os pro Datenträger = [Lesevorgänge + (2 x Schreibvorgänge)] / Anzahl der Datenträger

Angenommen, Sie haben ein RAID 1-System mit zwei physikalischen Datenträgern und Ihre Indikatoren zeigen die Werte aus der folgenden Tabelle.

Leistungsindikator Value
Durchschn. Festplattensek./Lesen** 80
Logisches Laufwerk: Durchschn. Festplattensek./Schreiben** 70
Durchschn. Länge der Festplattenwarteschlange** 5
  • Der I/O-Wert pro Platte errechnet sich wie folgt: (80 + (2 x 70))/2 = 110

  • disk queue length 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.

Siehe auch

Konzepte

Übersicht über SQL Server in SharePoint Server 2016- und 2019-Umgebungen

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

Kapazitätsverwaltung und Dimensionierung für SharePoint Server 2013

Kapazitätsplanung für SharePoint Server 2013

Weitere Ressourcen

Übersicht über SQL Server in einer SharePoint Server 2013-Umgebung