Eine weitere Frage aus einem Gespräch mit den SharePoint-Gurus während der gestrigen MCM-Schulung. Die SharePoint-Richtlinien besagen, dass Inhaltsdatenbanken über 100 GB nicht unterstützt werden. Ohne auf die Gründe für diese Richtlinien einzugehen, würde ich gerne mehr über Inhaltsdatenbanken erfahren.größerals 100 GB und Ihre Erfahrungen damit (vor allem in Bezug auf Leistung, Notfallwiederherstellung und HA-Bereitstellung).
Wie weit haben Sie es geschafft, Ihre SharePoint-Installation voranzutreiben? Ich habe aus zweiter Hand Geschichten über Inhaltsdatenbanken mit mehr als 1 TB gehört, würde aber gerne von den SharePoint-Administratoren selbst hören.
Vielen Dank für alle Informationen, die Sie haben.
Antwort1
Wir haben Datenbanken 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 „Scaling SharePoint 2007: Storage Architecture“:
„...Dies wird allgemein als „Größenbeschränkung von 100 GB für Inhaltsdatenbanken“ bezeichnet. Tatsächlich handelt es sich dabei nicht um eine echte Beschränkung, sondern eher um eine Empfehlung. SQL Server-Datenbanken lassen sich seit Jahren weit über 100 GB hinaus skalieren. In der Praxis basiert die Empfehlung hauptsächlich auf zwei wesentlichen Faktoren:
Die Anforderungen an Service Level Agreements (SLAs) 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 direkte Auswirkungen darauf, wie lange die Ausführung dieser Sicherung dauert.
Das Speichersubsystem muss robust genug sein, um die Festplatten-E/A-Anforderungen der SharePoint-Lösung zu erfüllen, die es bedient.
Solange eine bestimmte Organisation diese beiden Aspekte berücksichtigen kann, kann das Wachstum der Inhaltsdatenbanken zugelassen werden. In der Praxis wurden SharePoint-Bereitstellungen erfolgreich durchgeführt, bei denen Datenbankgrößen von 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB und 400 GB implementiert wurden.“
Antwort2
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 sich auf die gesamte Datenbank beziehen, werden jedoch schwieriger. Backups sind das offensichtlichste Beispiel – sie dauern bei großen Datenbanken länger. Solange die Datenbank jedoch nicht größer ist als das, was über Nacht gesichert werden kann, ist alles in Ordnung – Backups sind auf lange Laufzeit ausgelegt und ziemlich zuverlässig, solange Ihnen der Speicherplatz nicht ausgeht.
Echte Probleme treten bei weniger häufigen Vorgängen auf, beispielsweise beim Verschieben oder Aktualisieren von Inhaltsdatenbanken. Diese Vorgänge können etwa das Fünffache der Datenbankgröße an freiem Speicherplatz erfordern und werden mithilfe von Abfragen implementiert, die beispielsweise ein außer Kontrolle geratenes automatisches Wachstum auslösen können.
Antwort3
Wir haben eine Inhaltsdatenbank mit einer Größe von 300 GB. Nach der Umstellung auf Lite Speed gab es keine Probleme mit Backups. Vor der Umstellung kam es bei Websites zu erheblichen Leistungseinbußen.
Um es klarzustellen: Wir wollten KEINE so große Inhaltsdatenbank. Wir hatten spezielle Geschäftsanforderungen im Zusammenhang mit der Inhaltsfreigabe, die sehr schwierig umzusetzen gewesen wären, wenn wir die Inhalte in separaten Site-Sammlungen abgelegt hätten.
Als wir das erste Mal live gingen, hatten wir bei Spitzenauslastung große Probleme mit der Datenbanksperre. Wir haben dies auf die Verwendung des CrossListQueryCache-Objekts in SharePoint zurückgeführt. Wir haben die Verwendung dieser API aufgegeben und dadurch unsere Leistung erheblich verbessert.
Ich habe einen kleinen Blog-Artikel mit weiteren Informationen geschriebenHier.
Bei bestimmten Arten von Updates (Löschen von Blobs > 20 MB) und Umbenennen von Webs treten immer noch Sperrprobleme auf (dies kann dazu führen, dass viele Datensätze in der AllUserData-Tabelle aktualisiert werden). Wir arbeiten mit dem MS-Support an bestimmten Fällen (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.
Ich persönlich glaube, dass Probleme auftreten, wenn man so viele Datensätze in der AllUserData-Tabelle hat, und die einfachste Möglichkeit für MS, den Leuten dies mitzuteilen, war, zu sagen, man solle unter 100 GB bleiben.
Ich schlage vor, die Leute bei MS IT anzupingen … Ich habe inoffiziell gehört, dass sie eine SharePoint-Inhaltsdatenbank mit > 800 GB haben.
Antwort4
Das ist falsch. Es gibt keine Größenbeschränkungen. Es wird empfohlen, keine großen Datenbanken zu haben, sondern nur, um die Datenbankverwaltung zu vereinfachen und die Backup-/Wiederherstellungszeit zu minimieren. Man könnte sagen, dass die Größenbeschränkung nur von Ihrer SQL-Infrastruktur abhängt.