Ressourcen zur SharePoint Datenbankkonfiguration

  • Article

Hier einige Ressourcen, die die Konfiguration von SQL Server Datenbanken für SharePoint bechreiben:

Und die Empfehlungen eines Consulting-Kollegen:

Datenbank-Konfiguration

TempDB

  • Von der Produktgruppe wird im allgemeinen empfohlen, dass die Anzahl der Dateien für TempDB gleich der Anzahl der CPUs (gemeint: Cores) ist. Darüber gibt es zwar auch einige Diskussionen, als erster Anhaltspunkt ist diese Zahl jedoch gut. Das sinnvolle Maximum liegt bei ca. 8 Dateien
  • Für hohe Performance: RAID 10 auf eigener Festplatte
  • Größenabschätzung: ca. 25% der größten Inhaltsdatenbank oder der Search DB
  • Automatische Vergrößerung um einen festen Betrag aktiviert. Später dann TempDB in dieser Größe erzeugen lassen
  • Wenn möglich jede Datendatei auf eigener Festplatte
  • Logdatei von Datendatei trennen

Inhaltsdatenbanken

  • Nur Dateien in der PRIMARY Dateigruppe erzeugen
  • Getestete Grenze: 100 Inhaltsdatenbanken pro Webanwendung
  • Empfohlene Grenze aus Managementgründen (vor allem: Backup/Restore-Zeiten): 100 GB. 
  • Aber: Es wurden bei Inhaltsdatenbankgrößen bis 500 GB keine Performanceprobleme festgestellt. Wie gesagt, es geht vor allem un Backup- und Restore-Zeiten
  • Verschiedene Arten von Sites führen zu unterschiedlichen Zugriffsmustern auf die Datenbanken. (z.B. größtenteils lesend, Lesen/Schreiben gemischt und intensive Zusammenarbeit) Das sollte ein Hauptkriterium für Größe und Festplattenlayout der Datenbanken sein
  • Erzeugen Sie die Inhaltsdatenbanken in der Zielgröße manuell (siehe How to make Windows SharePoint Services use a preexisting database - aber dabei bitte die Datenbank mit der vorberechneten Größe anlegen)
  • "Autogrow" sollte angeschaltet bleiben, allerdings sollte die Datenbankgröße proaktiv verwaltet werden und die Datenbanken bei Platzmangel jeweils um einen festen (großen) Betrag vergrößert werden.
  • Inhaltsdatenbanken sollten auf RAID 10, bei geringer Last auch auf RAID 5 Arrays gespeichert werden. RAID 10 ist teurer, aus Performancegründen aber die bessere Wahl, insbesondere wenn hohe Schreibperformance benötigt wird (Zusammenarbeits-Sites). RAID 5 ist für Sites geeignet, von denen vor allem gelesen wird.
  • Wie immer bei SQL Server gehören Datendateien und das Log auf getrennte Festplatten/Arrays/LUNs. Bei hoher Schreiblast ist es sinnvoll, auch die Log-Datei auf ein RAID 10 zu legen.

Suchdatenbank

  • Für Erstellung, manuelle Erzeugung in der Zielgröße, Trennung von Daten und Logs und Autogrow gilt das bei Inhaltsdatenbanken gesagte
  • De Suchdatenbank SEHR lese- und schreibintensiv
  • Verwenden Sie RAID10. Das ist für größere Installation faktisch immer notwendig. Verwenden Sie daher für die Suchdatenbank ein eigenes RAID, auf dem keine anderen Datenbanken liegen. Die vom RAID verwendeten Platten sollten dediziert und nicht mit anderen LUNs geteilt sein

Andere MOSS Datenbanken

  • Für die SSP, Konfigurations- und SharePoint Admin Datenbanken gelten neben den normalen SQL Server Regeln keine besonderen Anforderungen

Storage Management

Erstellen Sie separate LUNs (wenn möglich aus dedizierten Platten) für jedes der Folgenden

  • SQL TempDB Datendateien
  • Inhaltsdatenbank-Datendateien
  • Suchdatenbank-Datendateien
  • Inhaltsdatenbank-Transaktionslogs
  • Suchdatenbank-Transaktionslogs

Die Inhaltsdatenbank-Datenbankgröße liegt etwa beim 1,5fachen der reinen Datengröße

Für die Suchdatenbank gilt folgende Faustformel:

GB an erforderlichem Plattenplatz= Korpusgröße (in GB) x File_Size_Modifier x 4

wobei File_Size_Modifier durchschnittlichen Dateigröße im Korpus abhängig ist:

  • 1,0 wenn die Inhalte aus sehr kleinen Dateien bestehen (durchschnittliche Dateigröße 1 KB)
  • 0,12 wenn die Inhalte aus mittelkleinen Dateien bestehen (durchschnittliche Dateigröße 10KB).
  • 0,05 wenn die Inhalte aus größeren Dateien bestehen (durchschnittliche Dateigröße über 100KB)

Datenbankwartung

SQL Server SP 2 ist erforderlich, wenn Wartungspläne verwendet werden sollen (see KB 930887)

Defragmentierung der Datenbankdateien - sollte erfolgen und die LUNs sollten mindestens 20% (gern mehr) größer sein als die Datenbanken um Fragmentierung zu vermeiden und Defragmentierung zu ermöglichen

Custom indexes (psudo-indexes) auf Spalten in Dokumentbibliotheken - können der Ansicht-Performance in großen Dokumentbibliotheken erheblich helfen. Geeignete Spalten sollten durch Beobachtung der "where" Klausel in den CAML Queries der Ansichten ermittelt werden

PerfMon Counters

  • Average Disk Queue Length - möglichst einstellige Werte, ab und zu zweistellig

Gruß,
Steffen