Maximale Größe von SharePoint-Inhaltsdatenbanken

Eine weitere Frage aus dem Gespräch mit den SharePoint-Gurus, als ich gestern MCM unterrichtete. Die SharePoint-Richtlinien besagen, dass Inhaltsdatenbanken über 100 GB nicht unterstützt werden. Ohne auf die Gründe für diese Richtlinien einzugehen , bin ich an Inhaltsdatenbanken mit mehr als 100 GB und Ihren Erfahrungen damit interessiert (hauptsächlich in Bezug auf Leistung, Notfallwiederherstellung und HA-Bereitstellung).

Wie weit haben Sie es geschafft, Ihre SharePoint-Installation voranzutreiben? Ich habe gebrauchte Geschichten über Inhaltsdatenbanken mit> 1 TB gehört, würde aber gerne von den SharePoint-Administratoren selbst hören.

Vielen Dank für alle Informationen, die Sie haben.

Wir haben DBs mit 111 bzw. 102 GB, die in weniger als 30 Minuten in einem GigE-Netzwerk gesichert werden. Ich habe gehört, dass größere Datenbanken Probleme mit lang laufenden gespeicherten Prozeduren haben können, habe aber keine Demonstration davon gesehen.

Ein schönes Zitat aus dem Whitepaper "Skalieren von SharePoint 2007: Speicherarchitektur":

"... Dies wird allgemein als" Größenbeschränkung für 100 GB Inhaltsdatenbanken "bezeichnet. Tatsächlich handelt es sich nicht um eine echte Einschränkung, sondern um eine Empfehlung. SQL Server-Datenbanken werden seit Jahren weit über 100 GB hinaus skaliert Die Empfehlung basiert hauptsächlich auf zwei wesentlichen Faktoren:

1. Die SLA-Anforderungen (Service Level Agreement) für eine bestimmte Organisation können vorschreiben, dass Sicherungsvorgänge für die SharePoint-Datenbanken in einer begrenzten Zeit ausgeführt werden müssen. Die Größe der Inhaltsdatenbanken hat direkten Einfluss darauf, wie lange die Ausführung dieser Sicherung dauert.

2. Das Speichersubsystem muss robust genug sein, um die Festplatten-E / A-Anforderungen der von ihm bereitgestellten SharePoint-Lösung zu erfüllen.

Solange eine bestimmte Organisation in der Lage ist, diese beiden Überlegungen zu entschärfen, können die Inhaltsdatenbanken wachsen. Bei Implementierungen in der realen Welt wurden erfolgreiche SharePoint-Bereitstellungen durchgeführt, bei denen Datenbankgrößen von 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB und 400 GB implementiert wurden. "

Für den täglichen Gebrauch ist die Datenbankgröße nicht so wichtig - die meisten Abfragen geben die Elemente in einer Liste zurück und es spielt keine Rolle, was sich sonst noch in der Datenbank befindet. Vorgänge, die für die gesamte Datenbank ausgeführt werden, werden jedoch schwieriger. Backups sind das offensichtlichste Beispiel - sie dauern bei großen Datenbanken länger. Solange die Datenbank jedoch nicht über das hinausgeht, was über Nacht gesichert werden kann, sind Sie in Ordnung. Backups sind auf eine lange Laufzeit ausgelegt und ziemlich zuverlässig, solange Ihnen nicht der Speicherplatz ausgeht.

Bei weniger häufigen Problemen wie dem Verschieben oder Aktualisieren von Inhaltsdatenbanken treten echte Probleme auf. Diese können etwa das Fünffache der Datenbankgröße im freien Speicherplatz erfordern und werden mithilfe von Abfragen implementiert, die beispielsweise ein außer Kontrolle geratenes Autogrow auslösen können.

Wir haben eine Inhaltsdatenbank mit einer Größe von 300 GB. Keine Probleme mit Backups nach dem Wechsel zu Lite Speed. Vor dem Wechsel würden wir ernsthafte Leistungseinbußen bei Websites feststellen.

Für den Datensatz wollten wir KEINE so große Inhaltsdatenbank haben. Wir hatten spezielle Geschäftsanforderungen in Bezug auf das Teilen von Inhalten, die sehr schwierig zu implementieren gewesen wären, wenn wir den Inhalt in separate Websitesammlungen gestellt hätten.

Als wir das erste Mal live gingen, hatten wir während der Spitzenauslastung große Probleme mit der Sperrung der Datenbank. Wir haben dies auf die Verwendung des CrossListQueryCache-Objekts in SharePoint zurückgeführt. Wir haben diese API nicht mehr verwendet und sie hat einen großen Teil unserer Leistung beeinträchtigt.

Ich schrieb einen kleinen Blog - Artikel mit mehr Informationen nach oben hier .

Bei bestimmten Aktualisierungstypen (Löschen von Blobs> 20 MB) und beim Umbenennen von Websites treten immer noch Probleme beim Sperren auf (dies kann zu Aktualisierungen vieler Datensätze in der AllUserData-Tabelle führen. In bestimmten Fällen arbeiten wir mit dem MS-Support zusammen (z. B. Entfernen großer Elemente aus dem Papierkorb) Diese wurden auf die Art und Weise zurückgeführt, wie bestimmte gespeicherte Prozeduren in SharePoint Daten löschen, aber wir haben noch keine Lösung.

Persönlich denke ich, dass Probleme auftreten, nachdem Sie so viele Datensätze in der AllUserData-Tabelle erhalten haben. Die einfachste Möglichkeit für MS, dies den Menschen mitzuteilen, bestand darin, unter 100 GB zu bleiben.

Ich schlage vor, die Leute bei MS IT anzupingen ... Ich habe laut Aufzeichnungen gehört, dass sie eine SharePoint Content DB> 800 GB haben.

Unser Unternehmen verfügt derzeit über eine Datenbank mit 140 MB. In einer bestimmten Liste, die auf 1,5 GB anwachsen konnte und Anhänge enthält, einschließlich mehrerer Versionen von Anhängen, tritt eine langsame Leistung auf. (Ich war übrigens nur ungefähr 2 Monate dort). Wir planen jetzt eine Migration und es sieht so aus, als ob die Migration auf SP 2010 mit dem Metalogix-Tool aufgrund unserer Tests Tage dauern könnte. Unsere ist eine schlecht gestaltete Datenbank, ein schlecht gestaltetes Portal, das jetzt von uns mit echten Problemen verwaltet werden muss.

Wir haben eine Backup-Site, die wir verwenden und die eine exakte Kopie unserer Produktionsumgebung ist. Aber die Hardware ist unsere ALTE Hardware nach unserem letzten Hardware-Update - Alte Hardware für die Entwicklung, neue für die Produktion. Einige Bereiche unserer Entwicklungsumgebung sind jedoch aufgrund von Leistungsproblemen unbrauchbar, sodass einige Entwicklungen in großen Listen in der Produktion durchgeführt werden müssen. Autsch, autsch, autsch ....

Das ist falsch Der Größe sind keine Grenzen gesetzt. Sie empfehlen, keine großen Datenbanken zu haben, sondern nur die Datenbankverwaltung zu vereinfachen und die Sicherungs- / Wiederherstellungszeit zu minimieren. Wir können sagen, dass die Größenbeschränkung nur von Ihrer SQL-Infrastruktur abhängt.