Entwerfen umfangreicher Listen und Maximierung der Leistung von Listen (SharePoint Server 2010)

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Dieser Artikel bietet Informationen zur Leistung umfangreicher Dokumentbibliotheken und Listen. Die Empfehlungen in diesem Artikel sind das Ergebnis einer Reihe von Leistungstests, die mit Microsoft SharePoint Server 2010 erfolgt sind. Der Schwerpunkt dieses Artikels liegt auf den Leistungsmerkmalen umfangreicher Listen und darauf, wie unterschiedliche Konfigurationen sich auf die Leistung umfangreicher Listen und der Farm auswirken. SharePoint Server 2010 bietet verschiedene neue Verbesserungen, die das Erstellen und Nutzen umfangreicher Listen erleichtern. Dennoch erfordert deren Erstellung und Implementierung weiterhin eine sorgfältige Planung. Sie müssen zahlreiche Faktoren berücksichtigen, z. B. die Informationsarchitektur, Leistung, Notfallwiederherstellung sowie Unternehmensführung und -kontrolle. In diesem Artikel werden die Informationsarchitektur und die Features, die zum Implementieren umfangreicher Listen dienen, sowie die Auswirkungen behandelt, die bestimmte Konfigurationen auf die Leistung haben.

Darüber hinaus sind wichtige Entwurfsentscheidungen zu treffen, die sich auf die Leistung umfangreicher Listen auswirken können. Dazu zählen Berechtigungen, die Anzahl der der Liste hinzugefügten Spalten, die Anzahl der Nachschlagespalten in Ansichten sowie die Ordner und Indizes, die zum Organisieren einer Liste dienen. In diesem Artikel wird erläutert, wie sich unterschiedliche Entwurfsentscheidungen auf die Leistung umfangreicher Listen auswirken, sodass Sie diese Listen so entwerfen können, dass sowohl Leistungs- als auch Geschäftsanforderungen erfüllt werden und den Benutzern eine nutzbringende Umgebung zur Verfügung gestellt wird.

Wenngleich sich dieser Artikel auf SharePoint Server 2010 bezieht, gelten die Einschränkungen und Grenzwerte ebenso für Microsoft SharePoint Foundation. In diesem Artikel werden verschiedene Features vorgestellt, die das Arbeiten mit umfangreichen Listen erleichtern, jedoch nur in SharePoint Server 2010 zur Verfügung stehen. Zwischen SharePoint Foundation und SharePoint Server erfolgt keine Unterscheidung.

Inhalt dieses Artikels:

• Grundlegendes zu Abfragemethoden

• Beispielszenarien für umfangreiche Listen

• Umfangreiche Listen und SharePoint Server 2010

• Methoden für Leistungsmessungen und -tests

• Einschränkungen und Grenzwerte

• Weitere Grenzwerte

• Unterschiede zwischen normalen und umfangreichen Listen

• Planen des Entwurfs und der Implementierung umfangreicher Listen

• Schlussbemerkung

Grundlegendes zu Abfragemethoden

Es gibt drei Hauptmethoden für den Zugriff auf Listendaten: Listenansichten mit Metadatennavigation, das Webpart für Inhaltsabfragen und die Suchfunktion. Jede Methode weist Vor- und Nachteile sowie bestimmte Zwecke auf, für die sie besonders gut geeignet ist.

Listenansicht mit Metadatennavigation

Listenansichten greifen stets auf die Microsoft SQL Server-Datenbank zu. Dies führt zu einer langsameren Abfrageleistung und höheren Last der SQL Server-Ressourcen als bei anderen Methoden. Bei Listenansichten wird außerdem der meiste HTML-Code gerendert, was zu langsameren Seiteladezeiten als bei anderen Methoden führt. Listenansichten bieten Benutzern die beste Umgebung, um Ansichten zu konfigurieren, Daten dynamisch zu filtern und Aktionen auf Dokumente anzuwenden, z. B. Versionen verwalten und Eigenschaften bearbeiten. Mithilfe der Metadatennavigation können Listenansichtsergebnisse gefiltert werden. Sie sollten mit Listenansichten arbeiten, wenn Sie umfangreiche Spaltendaten benötigen und Aktionen ausführen möchten, die auf Listenelemente angewendet werden. In Szenarien mit hohem Aufkommen von Lese- und Abfragevorgängen sollten Sie andere Abfragemethoden erwägen.

Webpart für Inhaltsabfragen

Das Webpart für Inhaltsabfragen dient zum Anzeigen einer statisch konfigurierten Datenansicht, die zur Leistungsoptimierung mithilfe des Anbieters der Struktur der Portalwebsite in einem Cache zwischengespeichert wird. Das Webpart für Inhaltsabfragen rendert den wenigsten HTML-Code und wird zwischengespeichert, wodurch Seiten schneller geladen werden und es einfacher ist, mehrere Abfragen auf einer Seite zuzulassen. Dieses Webpart muss verwendet werden, um Links zu verwandten Listenelementen, Dokumenten oder Seiten anzuzeigen. Obwohl das Webpart für Inhaltsabfragen auch ohne Zwischenspeicherung konfiguriert werden kann, sollte diese Konfiguration nur für Seiten gewählt werden, für die niedrige Anforderungen an den Durchsatz gelten oder für die der Cache nicht sinnvoll ist, z. B. bei Abfragen, die basierend auf dem Benutzer geändert werden, der auf die Seite zugreift.

Suchwebparts

Suchwebparts dienen zum Abladen von Abfragen an ein System, das für das Auffinden von Inhalten optimiert ist (im Vergleich zum Bearbeiten von Eigenschaften und Anzeigen der Änderungen in Echtzeit). Suchwebparts können für die Verwendung statischer oder benutzerdefinierter Abfragen konfiguriert werden und bieten eine gute Leistung. Die Daten sind jedoch nur so aktuell wie zum Zeitpunkt der letzten Durchforstung, was bedeutet, dass die Ergebnisse älter sind als die von Listenansichten und Webparts für Inhaltsabfragen.

Beispielszenarien für umfangreiche Listen

Es gibt einige gängige Szenarien für umfangreiche Listen, und je nach Szenario müssen unterschiedliche Entwurfsentscheidungen getroffen werden. Benutzer in einem Szenario für umfangreiche Listen mit Schwerpunkt auf Zusammenarbeit fügen beispielsweise oft Inhalte hinzu und aktualisieren Eigenschaften. In einem solchen Szenario ist es nicht wünschenswert, dass die Liste auf Millionen von Elementen anwächst, da das Filtern von Inhalten erschwert wird und Inhalte häufig aktualisiert und geändert werden. Wenn Sie mit unstrukturierten Dokumentbibliotheken arbeiten, kann Ihnen dieser Artikel die Einschränkungen und Grenzwerte zum Sichern der Leistung von SQL Server veranschaulichen. In der folgenden Tabelle werden Aspekte von Szenarien mit umfangreichen Listen angesprochen.

Szenario	Listengröße	Verwaltung	Verhältnis von Lese-, Aktualisierung- und Hinzufügevorgängen	Neue Inhalte	Benutzer
Unstrukturierte Dokumentbibliothek	Im dreistelligen Bereich	Kein Verwalter	Viele Lesevorgänge, ausgeglichene Hinzufüge- und Aktualisierungsvorgänge	Manuelles Hochladen	Im zweistelligen Bereich
Umfangreiche Liste oder Bibliothek mit Schwerpunkt Zusammenarbeit	Im vierstellen Bereich	Informelle Inhaltszuständige	Viele Lesevorgänge, mehr Aktualisierungs- als Hinzufügevorgänge	Manuelles Hochladen	Im dreistelligen Bereich
Strukturiertes großes Repository	Im fünfstelligen Bereich	Fest zugeordnete Inhaltsverwalter	Sehr viele Lesevorgänge, weniger Hinzufügevorgänge und wesentlich weniger Aktualisierungsvorgänge	Einreichen und Hochladen	Im fünfstelligen Bereich
Riesiges Archiv	Im sechsstelligen Bereich	Team von Inhaltsverwaltern	Wenige Lese- und Aktualisierungsvorgänge, viele Hinzufügevorgänge	Einreichen	Im fünfstelligen Bereich

Unstrukturierte Dokumentbibliothek

Unstrukturierte Dokumentbibliotheken werden häufig von Teams und Arbeitsgruppen genutzt, die Anzahl der Dokumente liegt im zwei- bis dreistelligen Bereich. Diese Bibliotheken können ungeplant so anwachsen, dass der Schwellenwert für die Listenansicht überschritten wird, was sich auf Vorgänge wie das Hinzufügen von Spalten auswirken kann. Ein mögliches Problem ist, dass Benutzer Fehlermeldungen zum Schwellenwert für die Listenansicht erhalten, wenn Ansichten letztlich mehr als 5000 Elemente aufweisen. Dies kann durch Überwachen von Bibliotheken verhindert werden, die sich dem Schwellenwert für die Listenansicht nähern. (Auf der Einstellungsseite einer Dokumentbibliothek wird ein Zähler angezeigt, der angibt, ob sich die Dokumentbibliothek dem Schwellenwert für die Listenansicht nähert.)

Die Anzahl der Benutzer bei diesem Szenario liegt bei wenigen gleichzeitigen Benutzern im zwei- bis dreistelligen Bereich. Deshalb ist die Verarbeitungslast innerhalb einer einzelnen Bibliothek zumeist kein Problem. Allerdings kann es viele Bibliotheken dieser Art geben. Anstatt die Unterstützung bestimmter Instanzen zu planen, ist es wichtiger, den Fokus auf die Größe dieser Bibliotheken zu legen.

Umfangreiche Liste oder Bibliothek mit Schwerpunkt Zusammenarbeit

Die Anzahl der Elemente umfangreicher Listen mit Schwerpunkt Zusammenarbeit, die zur Speicherung großer Mengen aktiver Inhalte dienen, liegt im drei- bis vierstelligen Bereich. Diese Listen enthalten meist Wissensmanagementlösungen, technische Bibliotheken und Begleitmaterialien für Vertrieb und Marketing. Inhalte werden von Benutzern aktiv hinzugefügt und bearbeitet (viele Lese- und Schreibvorgänge). Durch eine geordnete Struktur und Verwaltung können Sie die Organisation der Bibliothek gewährleisten. Da jedoch viele Aktionen von Benutzern ausgeführt werden, können Ereignisse eintreten, auf die Administratoren keinen Einfluss haben. Dadurch kann die Liste schneller als erwartet anwachsen oder sogar die vorgesehenen Grenzwerte überschreiten. Die Anzahl der Benutzer dieser Art von Repository kann im drei- bis vierstelligen Bereich, die der gleichzeitigen Benutzer im zwei- bis dreistelligen Bereich liegen.

Im Vergleich zu einem strukturierten Repository oder Archiv erfolgen für eine umfangreiche Liste für die Zusammenarbeit zumeist mehr administrative Vorgänge wie das Hinzufügen und Löschen von Ordnern, Hinzufügen von Inhaltstypen und Spalten oder Neuorganisieren von Inhalten. Diese Aktionen können aufgrund der Listengröße durch den Schwellenwert für die Listenansicht verhindert werden.

Strukturiertes großes Repository

Die Anzahl der Elemente in einem strukturierten großen Repository liegt im vier- bis fünfstelligen Bereich. Die Inhalte sind in der Regel endgültig und werden von Benutzern oder Systemprozessen wie Workflows übermittelt. Strukturierte große Repositorys werden zumeist für Abteilungsarchive sowie die Speicherung wichtiger und fertig gestellter Dokumente verwendet, die auf Webseiten angezeigt werden. Die Inhalte sind im Allgemeinen strukturiert und unterliegen einer aufmerksamen Verwaltung, sodass das Anwachsen der Liste besser überwacht werden kann. Die Anzahl der gleichzeitigen Benutzer liegt im zwei- bis dreistelligen Bereich, die Gesamtanzahl der Benutzer im vierstelligen Bereich. Der prozentuale Anteil von Lesevorgängen ist wesentlich größer als der von Schreibvorgängen. Inhalte werden aber dennoch ggf. aktualisiert und regelmäßig hinzugefügt und gelöscht. Der Datenspeicher für das Wissensmanagement einer Abteilung oder Organisation ist in der Regel ein strukturiertes großes Repository.

Bei diesem Szenario müssen die Benutzeranforderungen gründlich untersucht und umfassende Tests durchgeführt werden, ehe die Lösung in der Produktionsumgebung eingeführt wird. Die Lösung ist also nahezu fertig, bevor sie mit einer großen Menge von Inhalten aufgefüllt wird. Anschließend ist ggf. die Konfiguration geeigneter Hierarchien und Filter für die Metadatennavigation erforderlich, um eine zweckdienliche Suchumgebung für Inhalte bereitzustellen.

Großarchiv

Die Anzahl der Elemente in einem Großarchiv liegt im vier- bis sechsstelligen Bereich, entweder in einer einzelnen Liste, verteilt auf mehrere Listen oder sogar in mehreren Websitesammlungen. Dieses Szenario weist zumeist wenige Lese- und Aktualisierungsvorgänge auf und dient im Allgemeinen als Langzeitspeicher für Dokumente, die u. a. aus Gründen der Vorschrifteneinhaltung einen längeren Zeitraum aufbewahrt werden müssen. Ein hoher Durchsatz beim Übermitteln und Löschen von Dokumenten ist in diesem Szenario wichtig. Die Suchfunktion ist die Hauptmethode zum Abrufen von Inhalten.

Umfangreiche Listen und SharePoint Server 2010

Die Features, die bei umfangreichen Listen in Office SharePoint Server 2007 hilfreich waren, sich auch in SharePoint Server 2010 nützlich, und viele wurden optimiert, um in großem Maß für eine bessere Leistung zu sorgen. SharePoint Server 2010 bietet zudem viele neue Features, die die Leistung umfangreicher Listen verbessern und Benutzer bei deren effektiver Nutzung unterstützen. In diesem Abschnitt werden die neuen und verbesserten Funktionen in SharePoint Server 2010 vorgestellt.

Verbesserte Features

In den folgenden Abschnitten werden die Features von Microsoft Office SharePoint Server 2007 behandelt, die in SharePoint Server 2010 verbessert wurden.

Webparts für Inhaltsabfragen

Sie können das Webpart für Inhaltsabfragen so konfigurieren, dass Ergebnisse nach Listen, Inhaltstypen und Spalten gefiltert angezeigt werden. Sie können Ergebnisse sortieren und anzuzeigende Spalte auswählen. Deshalb eignet sich dieses Webpart ideal für das Anzeigen des Inhalts umfangreicher Listen auf Webseiten. Webparts für Inhaltsabfragen werden im Allgemeinen zwischengespeichert, was schnellere Seitenladevorgänge und weniger Datenbanklast ermöglicht. Ein Zweck von Webparts für Inhaltsabfragen ist ihre Nutzung in Wissensmanagementszenarien auf Veröffentlichungsseiten zum Anzeigen von Links zu Dokumenten, die mit dem Inhalt der Webseite verwandt sind.

SharePoint Server 2010 bietet in den folgenden wichtigen Szenarien Leistungsverbesserungen:

• Optimierung von Abfragen einzelner Listen durch effektiveres Nutzen von Indizes

• Verbesserung von Invalidierungs- und Aktualisierungsalgorithmen sowie von Standardeinstellungen zur Optimierung der Cachenutzung bei Schreibvorgängen durch Benutzer

Suchfunktion

SharePoint Server 2010 bietet neue Suchfunktionen, z. B. ein Feld zur Suchbegriffseinschränkung und eine bessere Skalierbarkeit mit Unterstützung einer Abfragewartezeit von unter einer Sekunde bei 100 Mio. Dokumenten. Ferner wird Microsoft FAST Search Server 2010 for SharePoint geboten, womit größere Werte als mit der SharePoint Server 2010-Suchfunktion unterstützt werden können.

Zu den neuen Features zum besseren Auffinden von Inhalten in umfangreichen Listen zählen boolesche Operatoren in Freitextabfragen, eine verbesserte Operatorunterstützung (Gleich, Kleiner als und Größer als), Bereichseinschränkungen und Präfixabgleich für Stichwörter und Eigenschaften. Die Abfrage "Anteil*" findet beispielsweise Ergebnisse, die "Anteilseigner" enthalten. Die Suchfunktion bietet ferner Abfragevorschläge, die Empfehlungen basierend auf der Abfrageeingabe des Benutzers enthalten. Die Suchoberfläche bietet nun zudem Felder für verwandte Suchvorgänge, beste Suchergebnisse, verwandte Personen und Stichworteinschränkungen.

Die SharePoint Server 2010-Suchfunktion wurde hinsichtlich Skalierbarkeit verbessert und unterstützt das horizontale Skalieren von Index-, Durchforstungs- und Abfrageservern. Andere Verbesserungen sind aktuellere Indizes, höhere Zuverlässigkeit und bessere Verfügbarkeit. FAST Search Server 2010 for SharePoint bietet alle SharePoint Server 2010-Suchfunktionen und darüber hinaus Skalierungsmöglichkeiten bei extremen Anforderungen, Extrahierung von Entitäten, optimierbare Relevanzrangfolge, visuelle beste Suchergebnisse, Miniaturansichten und Vorschau.

Websitevorlagen für Dokumentcenter und Datenarchiv

Dokumentcenter und Datenarchiv sind SharePoint Server 2010-Websitevorlagen, mit deren Hilfe Sie strukturierte Repositorys erstellen können. Die Websitevorlage Dokumentcenter bietet Features wie vorkonfigurierte Webparts für Inhaltsabfragen für die Rückgabe relevanter Ergebnisse an angemeldete Benutzer und eine Dokumentbibliothek mit konfigurierter Metadatennavigation.

Die Websitevorlage Datenarchiv ähnelt der Websitevorlage Dokumentcenter, weist jedoch das aktivierte Feature Inhaltsorganisation für das Weiterleiten von Dokumenten sowie eine Archivbibliothek auf, in der hinzugefügte Elemente automatisch als Archiv deklariert werden und nicht gelöscht werden können. Die Websitevorlage Datenarchiv ist die einzige standardmäßige Websitevorlage, für die die Dokumentanalyse nicht aktiviert ist, wodurch die Unveränderlichkeit der übermittelten Inhalte gewährleistet wird. Die Deaktivierung der Dokumentanalyse hat Auswirkungen auf die Leistung bestimmter Vorgänge, weshalb diese Websitevorlage besser als andere für die umfassende Speicherung von Dokumenten (im achtstelligen Bereich) geeignet ist.

Neue Features

In diesem Abschnitt werden die neuen Features in SharePoint Server 2010 zur Verwaltung umfangreicher Listen und ihrer Leistung beschrieben.

Inhaltsorganisation

Die Inhaltsorganisation kann in Websites zum Weiterleiten von Inhalten an bestimmte Dokumentbibliotheken, Ordner oder sogar andere Websites genutzt werden. Dieses Feature dient zum automatischen Erstellen von Ordnern für Inhalte basierend auf Metadateneigenschaften. Benutzer können Inhalte anderer Websites an die Inhaltsorganisation übermitteln, ohne sich Gedanken machen zu müssen, wo diese innerhalb des Dateiplans gespeichert sind. Die Inhaltsorganisation kann auch zum gleichmäßigen Verteilen von Inhalten auf verschiedene Ordner genutzt werden, um für jeden Ordner automatisch eine maximale Dateigröße beizubehalten. Bei Erreichen des vorgegebenen Grenzwerts wird eine neuer Unterordner zum Aufnehmen weiterer Elemente erstellt.

Metadatennavigation

Die Metadatennavigation ist ein neues SharePoint Server 2010-Feature, mit dem Benutzer Listen auf der Suche nach benötigen Informationen dynamisch filtern können. Dieses Feature ermöglicht Benutzer die Auswahl von Filteroptionen und führt anschließend die Abfrage so effizient wie möglich aus. Die Metadatennavigation besteht aus zwei Teilen. Der eine Teil ist eine Gruppe von Navigationssteuerelementen, über die ein Benutzer eine Liste filtern kann, die Navigationshierarchien und Schlüsselfilter aufweist. Der zweite Teil ist ein Mechanismus zum Neuanordnen und Wiederholen von Abfragen.

Zur Metadatennavigation gehört eine Wiederholungs- und Fallbacklogik, die versucht, Abfragen mithilfe von Indizes effizient auszuführen. Wenn eine Abfrage zu viele Ergebnisse zurückgibt, erfolgt eine sog. Fallbackabfrage, die zur Optimierung der Leistung eine Untermenge der Ergebnisse zurückgibt. Wenn keine geeignete Abfrage erfolgen kann, erfolgt eine Fallbackabfrage, und die Filter werden auf eine begrenzte Ergebnismenge angewendet. Bei der Metadatennavigation erfolgt automatisch eine Indexerstellung. Die Metadatennavigation mit ihrer Wiederholungs- und Fallbacklogik sowie der Indexverwaltung ist ein wichtiger Faktor für ein effektives Arbeiten mit umfangreichen Listen. Es gibt zwei Arten von Filtermechanismen: Navigationshierarchien und Schlüsselfilter.

Navigationshierarchien nutzen ein Struktursteuerelement, um in Hierarchien von Ordnern, Inhaltstypen, Auswahlfeldern oder verwalteten Metadaten-Ausdruckssätzen zu navigieren. Dadurch können Benutzer mithilfe eines Struktursteuerelements eine Metadatenhierarchie durchsuchen, wie sie es vom Navigieren in Ordnern gewohnt sind. Wenn Benutzer ein Element in einer Hierarchie für eine verwaltete Metadatenspalte auswählen, werden alle Elemente angezeigt, die dem angegebenen Begriff oder beliebigen seiner untergeordneten Begriffe entsprechen. Dies wird als Einschluss untergeordneter Elemente bezeichnet und kann auf Felder angewendet werden, die an einen verwalteten Metadaten-Ausdruckssatz gebunden sind. Benutzer können das Element erneut auswählen, um es nur anhand dieses speziellen Begriffs zu filtern, ohne die untergeordnete Begriffe einzuschließen. Sämtliche Metadatennavigationsabfragen sind rekursiv und geben Ergebnisse aus allen Ordnern in der Liste zurück.

Schlüsselfilter können für eine weitere Filterung von Ergebnissen in der Hierarchie konfiguriert werden. Beispielsweise können Sie die Spalte Geändert von als Schlüsselfilter hinzufügen und anschließend einen Benutzeranzeigenamen eingeben, um Ergebnisse anzuzeigen, bei denen der Wert der Spalte Geändert von mit dem eingegebenen Benutzer übereinstimmt. Weitere Informationen finden Sie unter Metadatennavigation und Filterung (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x407). Die folgende Abbildung zeigt ein Beispiel von Metadatennavigationshierarchien und Schlüsselfiltern.

Verwaltete Metadaten

Verwaltete Metadaten sind ein neues Feature, mit dem SharePoint Server weitere Informationsarchitekturfunktionen hinzugefügt werden. Zu den Features verwalteter Metadaten gehört ein gemeinsam genutzter Dienst, der verwalteter Metadatendienst heißt. Der verwaltete Metadatendienst dient zum Speichern von Ausdruckssätzen, die in einer gesamten SharePoint Server 2010-Bereitstellung wiederverwendet werden können. Zu den Features verwalteter Metadaten zählen u. a.:

• Ausdruckssätze, die flache oder tiefe Hierarchien unterstützen

• Ein verwalteter Metadatenspaltentyp, der Ausdruckssätze als verfügbare Eigenschaften verwendet

• Ausdruckssätze, denen alle Benutzer neue Ausdrücke hinzufügen dürfen oder deren Verwaltung auf bestimmte Benutzer begrenzt wird

Wenn Sie Inhalte mithilfe von verwalteten Metadatenspalten und Ausdruckssätzen organisieren, können Sie Features wie das Webpart für Inhaltsabfragen und die Metadatennavigation verwenden, um Benutzer beim Auffinden von Inhalten zu unterstützen. Verwaltete Metadaten sind auch bei herkömmlichen Suchabfragen hilfreich, da Stichwörter zum Klassifizieren von Dokumenten hinzugefügt werden. Verwaltete Metadaten können im Sucheinschränkungsfeld genutzt werden. Die folgende Abbildung zeigt ein Beispiel der verwalteten Metadatennavigation.

Einschränkungen und Grenzwerte

In SharePoint Server 2010 gibt es mehrere konfigurierbare Grenzwerte zur Gewährleistung der Farmleistung. Auf Webanwendungsebene stehen nun konfigurierbare Einschränkungen und Grenzwerte zur Verfügung, die hinzugefügt wurden, damit Vorgänge einzelner Benutzer oder Prozesse sich nicht negativ auf die Farmleistung auswirken. Der Schwellenwert für die Listenansicht ist beispielsweise ein Grenzwert, der Abfragen verhindert, die sich auf mehr als auf eine bestimmte Anzahl von Elementen beziehen.

Zusammengesetzte Indizes

Indizes sind für umfangreiche Listen wichtig. In SharePoint Server 2010 können nun zusammengesetzte Indizes erstellt werden, die nützlich sind, wenn Abfragen üblicherweise auf zwei Spalten angewendet werden, da eine Abfrage nur einer Spalte ggf. nicht selektiv genug ist. Zusammengesetzte Indizes werden nicht von Indizes, aber von der Metadatennavigation verwendet. Wenn eine einschränkende Bedingung vorliegt, kann die Logik der Metadatennavigation eine Wiederholung bewirken und zutreffende zusammengesetzte und Einzelindizes für die ausgewählten Filterbedingungen verwenden, um vollständige oder Teilergebnisse zu finden, die die Abfrage erfüllen.

Entwicklerdashboard

Im Entwicklerdashboard, das standardmäßig deaktiviert ist, werden zu jedem Seitenladevorgang detaillierte Diagnoseinformationen angezeigt. Sie können es nach Wunsch manuell aktivieren oder so konfigurieren, dass es stets aktiviert ist. Im aktivierten Entwicklerdashboard können Sie Informationen zu Datenbankabfragen, Ladezeiten und Fehlern abfragen. Es erleichtert die schnelle Analyse und Diagnose von Leistungsproblemen. Die folgende Abbildung zeigt das Entwicklerdashboard. Das Metadatennavigationsfeature wird im Entwicklerdashboard bei umfangreichen Listen und einschränkenden Bedingungen angezeigt, wobei die Liste der Indizes, die für Wiederholungen und Teilergebnisse verwendet werden, in der Vorgangsstruktur links und die verschiedenen indizierten SQL Server-Abfragen, die versucht werden, rechts in der Liste zu sehen sind.

Das Entwicklerdashboard ist auch nützlich für das Debuggen benutzerdefinierter Webparts und Abfragen. Weitere Informationen zum Aktivieren des Entwicklerdashboards finden Sie im englischsprachigen Blog: Enable the Developer Dashboard using the Object Model / Powershell (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x407).

Inhaltsiterator

Die Entwickler-API für den Inhaltsiterator vereinfacht das Schreiben von Code für umfangreiche Listen und ist beim neuen Schwellenwert für die Listenansicht besonders wichtig. Der Inhaltsiterator bietet eine Methode zum Abrufen von Inhalten, auf die Vorgänge in kleinen Gruppen angewendet werden, anstatt Vorgänge auf die gesamte Datenmenge anzuwenden. Dies verhindert, dass Vorgänge den Schwellenwert für die Listenansicht überschreiten.

Remote BLOB Storage

SharePoint Server 2010 speichert BLOB-Dateidaten (Binary Large Object) standardmäßig in SQL Server-Datenbanken. Der Großteil einer Inhaltsdatenbank besteht zumeist aus BLOB-Daten. Remote BLOB Storage (RBS) ermöglicht das Speichern dieser Daten außerhalb von SQL Server, wodurch sich kostengünstige Speicheroptionen ergeben und die Inhaltsdatenbank verkleinert wird. Remote BLOB Storage umfasst eine Gruppe von Bibliotheks-APIs, die als Add-On-Paket in SQL Server 2008 integriert sind. Ein Remote BLOB Storage-Anbieter eines Drittanbieters ist erforderlich, um die Remote BLOB Storage-API nutzen zu können.

Methoden für Leistungsmessungen und -tests

In diesem Abschnitt wird die Testmethodik erläutert, die für die in diesem Artikel behandelten Tests befolgt wurde. Abweichungen von dieser Methodik finden sich an den Stellen, an denen Daten präsentiert werden.

Hardware- und Farmkonfiguration

In den folgenden Abbildungen und der Tabelle finden Sie Angaben zur Konfiguration der Testfarm. Zwei Aspekte der Testkonfiguration waren verglichen mit den meisten tatsächlichen Bereitstellungen signifikant unterschiedlich:

• Die NTLM-Authentifizierung wurde verwendet, um zu vermeiden, dass der Domänencontroller zum Engpass wird. Dies führte zu einer kleinen Leistungsverbesserung.

• Der Anwendungsserver enthielt eine SQL Server-Instanz, die für die Protokollierungsdatenbank verwendet wurde. Dies erfolgte, um die Verarbeitungslast der SQL Server-Hauptinstanz zu verringern, da der Protokollierungsgrad wesentlich höher als in tatsächlichen Bereitstellungen war.

Computername	Zwei Webserver	Ein Anwendungsserver	Ein Datenbankserver
Rolle	Front-End-Webserver	Anwendungsserver	SQL Server-Instanz
Prozessor(en)	2px4c @ 2,33 GHz	2px4c @ 2,33 GHz	4px2c @ 3,19 GHz
Arbeitsspeicher (RAM)	8 GB	8 GB	32 GB
Betriebssystem	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
Speicherung und Geometrie (einschließlich Konfiguration der SQL Server-Datenträger)	50 + 18 + 205 GB	50 + 18 + 300 GB	Datenträgerarray – 15 Datenträger mit 450 GB und 15.000 Umdrehungen pro Minute
Anzahl der Netzwerkkarten	2	2	2
Netzwerkkartengeschwindigkeit	1 Gigabit	1 Gigabit	1 Gigabit
Authentifizierung	NTLM	NTLM	NTLM
Softwareversion	SharePoint Server 2010 (Vorabversion)	SharePoint Server 2010 (Vorabversion), SQL Server 2008 CTP 3	SQL Server 2008 CTP 3
Anzahl der SQL Server-Instanzen	–	1	1
Lastenausgleichstyp	Hardware	–	–
Einstellungen für den Ausgabecache
Einstellungen für den Objektcache
Einstellungen für den BLOB-Cache
Protokollierebene des vereinheitlichten Protokollierungsdiensts (ULS)	Mittel	Mittel	Mittel
Speicherort der Verwendungsdatenbank		X
Verwendungsdatenbankeinstellungen (was protokolliert wird)
IRM-Einstellungen	Keine	Keine	Keine
Antivireneinstellung	Keine	Keine	Keine

Datenbanktyp	Anzahl der Datenbanken	RAID-Konfiguration
Temporäre Datenbank	1	0
Konfigurationsdatenbank	1	0
Inhaltsdatenbank 1	1	0
Profildatenbank	1	0
Suchdatenbank	1	0
Taxonomiedatenbank	1	0

Testlast

Die Tests erfolgten bei einem optimalen Lastpunkt (bzw. im grünen Bereich) und einer allgemeinen Kombination von Vorgängen. Zum Messen bestimmter Änderungen wurden an jedem Punkt Tests ausgeführt, an dem eine Variable geändert wurde. Zum Ermitteln des optimalen Lastpunkts wurden zusätzliche Threads hinzugefügt, um die Umgebung auszulasten, wobei die folgenden Metriken eingehalten wurden:

• Das 75. Quantil Latenz ist kürzer als eine Sekunde

• Die Auslastung der CPU des Front-End-Webservers ist unter 50 %

• Die Auslastung der SQL Server-CPU ist unter 50 %

• Die Auslastung der CPU des Anwendungsservers ist unter 50 %

• Die Fehlerrate ist kleiner als 0,01 %

Testdefinitionen

Die folgende Tabelle, in der der Test definiert wird, bietet einen Überblick über den Prozess, der für die einzelnen Tests befolgt wurde.

Testname	Testbeschreibung
Hochladen eines Dokuments	Ein Dokument wird hochgeladen. Die Eigenschaften des Dokuments werden bearbeitet und aktualisiert.
Hochladen und Weiterleiten eines Dokuments	Ein Dokument wird hochgeladen. Die Eigenschaften des Dokuments werden bearbeitet und aktualisiert. Das Dokument wird entsprechend einer Weiterleitungsregel weitergeleitet.
Herunterladen eines Dokuments	Ein Dokument wird heruntergeladen.
Zugriff auf die Dokumentbibliothek	Auf eine Listenansichtsseite einer Dokumentbibliothek wird zugegriffen.
Zugriff auf die Homepage mit Webparts für Inhaltsabfragen	Auf die Homepage einer Website vom Typ Dokumentcenter, die drei Webparts für Inhaltsabfragen aufweist, wird zugegriffen. Zwischengespeichertes Webpart für Inhaltsabfragen gibt die 15 am höchsten eingestuften Dokumente zurück. Zwischengespeichertes Webpart für Inhaltsabfragen gibt die 15 neuesten Dokumente zurück. Nicht zwischengespeichertes Webpart für Inhaltsabfragen gibt die 15 neuesten Elemente zurück, die vom aktuellen Benutzer geändert wurden.
Fallbackabfrage verwalteter Metadaten	Eine Listenansichtsabfrage, die mehr als 5000 Ergebnisse zurückgibt, wobei eine Filterung anhand einer verwalteten Metadatenspalte mit einem Einzelwert erfolgt.
Selektive Abfrage verwalteter Metadaten	Eine Listenansichtsabfrage, die 1000 Ergebnisse zurückgibt, wobei eine Filterung anhand einer verwalteten Metadatenspalte mit einem Einzelwert erfolgt.
Fallbackabfrage für Inhaltstyp	Eine Listenansichtsabfrage, die mehr als 5000 Ergebnisse zurückgibt, wobei eine Filterung nach Inhaltstyp erfolgt.
Selektive Abfrage für Inhaltstyp	Eine Listenansichtsabfrage, die 1000 Ergebnisse zurückgibt, wobei eine Filterung nach Inhaltstyp erfolgt.

Testmischung

Der Aufbau der einzelnen Textmischungen war unterschiedlich. Die Tests erfolgen unter Verwendung eines Visual Studio-Testsystems. Bestimmte Datenpunkte wurden für jeden Test aufgefüllt. Anschließend wurde die Testmischung zwei Minuten zum Aufwärmen und zehn Minuten zum Erfassen von Daten ausgeführt. Die in diesem Artikel vorgestellten Ergebnisse stellen den Mittelwert dieser zehn Minuten dar. Die folgende Tabelle zeigt den Prozentsatz jeder Lösung bei einer bestimmten Testmischung.

Name der Lösung	Prozentsatz in der Mischung
Hochladen eines Dokuments (einschließlich Bearbeitung von Dokumenteigenschaften)	20
Herunterladen eines Dokuments	20
Zugreifen auf die Dokumentbibliothek	20
Zugreifen auf die Homepage mit Webparts für Inhaltsabfragen	10
Fallbackabfrage für verwaltete Metadaten (mehr als 5000 Ergebnisse)	5
Selektive Abfrage für verwaltete Metadaten (100 Ergebnisse)	10
Fallbackabfrage für Inhaltstyp (mehr als 5000 Ergebnisse)	5
Selektive Abfrage für Inhaltstyp (100 Ergebnisse)	10

Einschränkungen und Grenzwerte

Sorgfältig getestete und ausgewählte Grenzwerte dienen zum Verhindern von Vorgängen, die sich negativ auf die Farmleistung auswirken. Bei einigen Grenzwerten, z. B. Schwellenwert für die Listenansicht, wird ausdrücklich empfohlen, den Wert nicht zu ändern. Untersuchen Sie aufmerksam die Auswirkung einer Änderung dieser Grenzwerte. Wenn diese Grenzwerte die Ausführung eines Vorgangs verhindern, erwägen Sie zunächst eine Änderung der Ausführung des Vorgangs auf eine effizienter indizierte Weise, anstatt den Grenzwert zu ändern, um Vorgänge mit schwacher Ausführungsleistung zuzulassen. Die meisten in diesem Abschnitt behandelten Einschränkungen und Grenzwerte können in der Zentraladministration unter Webanwendungen verwalten konfiguriert werden, indem im Menüband einer bestimmten Webanwendung Allgemeine Einstellungen – Ressourcensteuerung ausgewählt wird.

Schwellenwert für die Listenansicht

SharePoint Server 2010 unterstützt Dokumentbibliotheken und Listen, deren Anzahl im achtstelligen Bereich liegen kann. Sie können unter Verwendung von Ordnern, Standardansichten, Websitehierarchien und Metadatennavigation sehr umfangreiche Dokumentbibliotheken erstellen. Zum Abrufen von Daten aus umfangreichen Listen mithilfe von Listenansichten oder CAML-Abfragen (Collaborative Application Markup Language) müssen die Daten mittels Ordnern, Indizes oder beidem partitioniert werden. Andernfalls ist die Suchfunktion die einzige Möglichkeit eines effizienten Zugriffs auf die Daten. Die Anzahl der Elemente, die eine einzelne Dokumentbibliothek unterstützt, kann variieren, was von der Organisation der Dokumente und Ordner, der Größe und dem Typ der gespeicherten Dokumente, der Verwendung der Dokumentbibliothek und der Anzahl ihrer Spalten abhängt.

Der Schwellenwert für die Listenansicht verhindert standardmäßig Vorgänge, die mehr als 5000 Elemente umfassen, z. B. Abfragen, die mehr als 5000 Elemente zurückgeben, oder das Hinzufügen einer Spalte zu einer Liste, die mehr als 5000 Elemente enthält. Wenngleich dieser Standardwert geändert werden kann, sollten Sie davon Abstand nehmen. Wenn Abfragen mit schwacher Leistung auf Listen mit mehr als 5000 Elementen angewendet werden, kann sich der Gesamtdurchsatz bei einer Erhöhung dieses Grenzwerts wesentlich verschlechtern.

Einige Vorgänge, z. B. nicht indizierte Abfragen oder Hinzufügen einer Spalte zu einer Liste, benötigen Zeit und Ressourcen proportional zur Anzahl der Elemente in der Liste. Bei einer kurzen Liste ist dies unerheblich, da die Anzahl der Elemente gering und der Vorgang deshalb schnell ist. Bei zunehmender Listengröße benötigen diese Vorgänge mehr Zeit und Ressourcen. Anstatt eine uneingeschränkte Ausführung dieser Vorgänge zuzulassen, werden sie durch den Schwellenwert für die Listenansicht blockiert. Sie können sich diesen Schwellenwert als Leitplanke an einer Autobahn vorstellen, die sie darauf hinweist, dass Sie die Abfrage oder den Zugriff auf die Daten ändern bzw. den Vorgang bei niedriger Farmauslastung durchführen sollten.

Der Schwellenwert für die Listenansicht gibt die maximale Anzahl von Listen- oder Bibliothekselementen vor, die ein Datenbankvorgang, z. B. eine Abfrage, gleichzeitig umfassen darf. Der Standardwert ist 5000. Dieser Grenzwert hat eine wesentliche Auswirkung auf umfangreiche Listen, da gemäß der Definition dieses Schwellenwerts eine umfangreiche Liste eine Liste mit mehr als 5000 Elementen ist. Vorgänge, die diesen Grenzwert überschreiten, werden eingeschränkt. Beispielsweise wird das Erstellen eines Index für eine Liste mit über 5000 Elementen verhindert. Dieser Grenzwert verhindert Abfragen mit einer Selektivität (Elemente, die mithilfe von Filterkriterien effizient gefiltert werden können) von mehr als 5000 Elementen. Dieser Grenzwert unterbindet ferner Abfragen, die eine Filterung nicht indizierter Spalten vorsehen. Der Grund ist, dass eine Abfrage, die eine Filterung (und mitunter Sortierung) anhand einer nicht indizierten Spalte durchführt, den Filter auf alle Elemente in der Liste anwenden muss, um das ordnungsgemäße Dataset abzurufen, und dabei auf mehr Elemente angewendet wird, als der Schwellenwert für die Listenansicht zulässt. Der Standardwert dieses Grenzwerts basiert auf der Farm- und Listenleistung und dem Sperrverhalten von SQL Server. Es wird empfohlen, diesen Grenzwert nicht zu ändern.

Zum Minimieren von Datenbankkonflikten arbeitet SQL Server mit Sperren auf Zeilenebene, um ordnungsgemäße Aktualisierungen zu gewährleisten, ohne dass Benutzer beeinträchtigt werden, die auf andere Zeile zugreifen. Wenn jedoch ein Lese- oder Schreibvorgang in einer Datenbank, z. B. eine Abfrage, bewirkt, dass mehr als 5000 Zeilen gleichzeitig gesperrt werden, erweitert SQL Server die Sperre aus Effizienzgründen auf die gesamte Tabelle, bis der Datenbankvorgang abgeschlossen ist. Wenn diese Sperrenausweitung erfolgt, können andere Benutzer nicht auf die Tabelle zugreifen. Weitere Informationen zu Sperren finden Sie unter Sperrenausweitung (Datenbankmodul) (https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x407).

Die folgende Abbildung zeigt den Durchsatz einer Palette von Abfragen einer umfangreichen Liste bei angepasstem Schwellenwert für die Listenansicht. Diese Palette von Abfragen umfasst Abfragen, die alle Elemente in der Liste zurückgeben, sodass bei angehobenem Schwellenwert für die Listenansicht mehr Elemente zurückgegeben werden. Sogar die Änderung des Grenzwerts von standardmäßig 5000 in 10.000 hat eine signifikante Auswirkung auf die Leistung. Doch anstatt den Schwellenwert für die Listenansicht zu erhöhen oder zu verringern, wird empfohlen, diesen Schwellenwert unangetastet zu lassen und den Schwerpunkt stattdessen auf die ordnungsgemäße Leistung von Abfragen zu legen.

Zu Ausnahmen beim Schwellenwert für die Listenansicht kommt es aufgrund einer schwachen Leistung von Vorgängen, die neu konfiguriert werden müssen. Anstatt den Grenzwert zu erhöhen, sollen Sie prüfen, warum ineffiziente Vorgänge erfolgen, und diese korrigieren. Im schlimmsten Fall können Sie die Einstellung EnableThrottling für eine bestimmte Liste auf False festlegen, um den Schwellenwert für die Listenansicht außer Kraft zu setzen. Dies kann allerdings nur auf Listen- und nicht auf Websiteebene erfolgen. Ziel ist es, den Listenzugriff nur so lange zuzulassen, bis Änderungen an leistungsschwachen Vorgängen erfolgt sind, die vom Schwellenwert für die Listenansicht blockiert werden. Anschließend muss die Einstellung EnableThrottling schnellstmöglich wieder auf True festgelegt werden.

Farmadministratoren und Administratoren lokaler Computer auf dem Front-End-Webserver, von dem eine Abfrage stammt, werden nicht vom Schwellenwert für die Listenansicht blockiert. Diese Benutzer müssen beim Durchsuchen umfangreicher Listen, die nicht ordnungsgemäß konfiguriert sind, und auch beim Ausführen von Tests überlegt vorgehen. Es kann den Anschein haben, als ob alles wie gewünscht funktioniert, doch die an Benutzer zurückgegebenen Daten können sich stark unterscheiden. Eine Auflistung der Vorgänge, die vom Schwellenwert für die Listenansicht verhindert werden, finden Sie weiter unten in diesem Artikel unter Vom Schwellenwert für die Listenansicht blockierte Vorgänge.

Zeitgeberdienste können ebenfalls mit einem Konto ausgeführt wird, das nicht vom Schwellenwert für die Listenansicht geschützt wird. Wenngleich hierdurch bestimmte Szenarien ermöglicht werden, z. B. eine verzögerte Erstellung eines Index für eine umfangreiche Liste, sollten Sie im Allgemeinen dafür sorgen, dass in Ihrem Code das Anwenden von Vorgängen auf umfangreiche Listen vermieden wird.

Schwellenwert für die Listenansicht

Standard: 5000	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: Zentraladministration, webanwendungsbezogen

Schwellenwert für die Listenansicht für Auditoren und Administratoren

Standard: 20.000	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: Zentraladministration, webanwendungsbezogen

Der Schwellenwert für die Listenansicht für Auditoren und Administratoren ist der für bestimmte Dienstkonten geltende Schwellenwert, z. B. für das Suchabfragekonto oder die Konten vom Typ super-reader und super-writer für den Objektcache. Das Webpart für Inhaltsabfragen verwendet beispielsweise automatisch diesen Grenzwert, um die Ergebnisse einer umfangreichen Abfrage zwischenzuspeichern und dadurch Serverressourcen einzusparen. Sie können mithilfe von benutzerdefiniertem Code die Verwendung dieses höheren Grenzwerts anfordern, wenn die Ausführung mit einem Konto vom Typ super-reader oder super-writer gemäß der Sicherheitsrichtlinie der Webanwendung erfolgt.

Außerkraftsetzung des Objektmodells zulassen

Standard: Ja	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: Zentraladministration, webanwendungsbezogen

Die Option Außerkraftsetzung des Objektmodells zulassen gibt an, ob Dienstkonten den Schwellenwert für die Listenansicht für Auditoren und Administratoren verwenden dürfen. Ein Farmadministrator muss die Außerkraftsetzung des Objektmodells aktivieren und programmgesteuert angeben, dass eine Liste eine Ausnahme darstellt. Anschließend können Programmierer mit der entsprechenden Berechtigung programmgesteuert anfordern, dass für ihre Abfrage oder Liste der höhere Schwellenwert für die Listenansicht für Auditoren und Administratoren gelten soll. Bei Ändern dieser Einstellung in Nein unterliegt benutzerdefinierter Code, der von Auditoren oder Administratoren ausgeführt ist, selbst wenn dieser eine Außerkraftsetzung anfordert, dem Schwellenwert für die Listenansicht und nicht dem höheren Schwellenwert für Auditoren oder Administratoren. Es wird empfohlen, die Standardeinstellung nicht zu ändern und den Schwellenwert für die Listenansicht für Auditoren oder Administratoren nur im Bedarfsfall zu konfigurieren.

Tägliches Zeitfenster für umfangreiche Abfragen

Standard: Aus	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: Zentraladministration, webanwendungsbezogen

Ein tägliches Zeitfenster kann festgelegt werden, in dem Vorgänge ausgeführt werden können, ohne dem Schwellenwert für die Listenansicht zu unterliegen. Das Zeitfenster kann in 15-Minuten-Schritten auf bis zu 24 Stunden festgelegt werden. Datenbankvorgänge oder Abfragen, die innerhalb des täglichen Zeitfensters gestartet wurden, werden bis zum Abschluss fortgesetzt, auch wenn dieser außerhalb des angegebenen Zeitfensters liegt. Das tägliche Zeitfenster ist nicht standardmäßig festgelegt, da die außerhalb der Spitzenzeiten liegenden Zeiten je nach Bereitstellung stark unterschiedlich sind. Deshalb muss der Administrator das Zeitfenster einrichten. Es wird empfohlen, ein tägliches Zeitfenster nur einzurichten, wenn es einen geeigneten Zeitraum außerhalb der Hauptnutzungszeiten gibt, in dem weniger Personen die Webanwendung nutzen. Dies ermöglicht Benutzern die Ausführung von Verwaltungsvorgängen für umfangreiche Listen, z. B. die Erstellung eines Index, wenn die Farmnutzung wesentlich niedriger ist.

Eindeutige Berechtigungen

Je mehr die Anzahl eindeutiger Berechtigungen in einer Liste zunimmt, desto stärker lässt die Leistung nach. Sie sollten Entwürfe überdenken, bei denen der gesamte oder Großteil des Inhalts einer umfangreichen Liste mit eindeutigen Berechtigungen geschützt werden muss. Der Unterschied beim Durchsatz von Vorgängen in einer Liste von 0 bis 1000 eindeutigen Berechtigungen liegt bei ca. 20 %. Es gibt einen konfigurierbaren Standardwert von 50.000 eindeutigen Berechtigungen pro Liste. Es wird jedoch empfohlen, diesen Grenzwert auf 5000 eindeutige Berechtigungen zu verringern und bei umfangreichen Listen einen Entwurf zu wählen, bei dem so wenig eindeutige Berechtigungen wie möglich verwendet werden. Dadurch wird nicht nur die Leistung verbessert, sondern auch die Verwaltung vereinfacht.

Folgendes wird empfohlen:

• Minimieren Sie eindeutige Berechtigungen für einzelne Elemente, und vereinfachen Sie Listenentwürfe, die für die meisten Elemente eindeutige Berechtigungen anfordern.

• Wenn eindeutige Berechtigungen benötigt werden, legen Sie diese nur auf Listen- oder Ordnerebene fest, und minimieren Sie die Anzahl einzelner Elemente, die eindeutige Berechtigungen erfordern.

• Überdenken Sie Ihren Entwurf, wenn für jedes Element individuelle Berechtigungen erforderlich sind. Untersuchen Sie die Aufteilung von Elementen auf mehrere Listen, oder organisieren Sie Elemente in Ordnern und Gruppen, sodass ein ordnungsgemäßer Zugriff gewährleistet werden kann, ohne eindeutige Berechtigungen für jedes Element festzulegen.

Abgestimmte Berechtigungen können die Leistung beeinträchtigen und sind zudem schwierig zu verwalten, wenn diese für viele einzelne Elemente unterschiedlich festgelegt werden. Wenn beim Festlegen abgestimmter Berechtigungen für Listen oder Ordner der Schwellenwert für die Listenansicht überschritten wird, erfolgt eine Blockierung, sobald zu viele einzelne Elemente aktualisiert werden müssen. Das Festlegen abgestimmter Berechtigungen wirkt sich jedoch auch auf andere Weisen auf die Leistung aus. Deshalb ist der konfigurierbare Standardgrenzwert 50.000 eindeutige Berechtigungen pro Liste. Wenn Sie versuchen, nach Erreichen dieses Grenzwerts eindeutige Berechtigungen zu deklarieren, werden Sie daran gehindert. Im Gegensatz zum Schwellenwert für die Listenansicht gilt dieser Grenzwert, wenn Sie eindeutige Berechtigungen für ein Element erstellen und nicht zum Abfragezeitpunkt.

Wenn die Vererbung von Berechtigungen für ein Element unterbrochen wird, z. B. für einen Ordner, wird dies für diesen Grenzwert als eindeutige Berechtigung gezählt. Bei jeder Unterbrechung der Berechtigungsvererbung wird eine neue Bereichs-ID erstellt. Bei jeder Abfrage einer Ansicht erfolgt ein Verknüpfungsvorgang mit der Bereichstabelle. Wenn anschließend eine Abfrage erfolgt, muss jede eindeutige Zugriffssteuerungsliste analysiert und verarbeitet werden. Eine große Anzahl eindeutiger Berechtigungen in einer Liste wirkt sich negativ auf die Leistung aus und wird deshalb nicht empfohlen. Sobald die Anzahl eindeutiger Berechtigungen in einer Liste zunimmt, lässt die Abfrageleistung nach. Wenngleich der Standardgrenzwert für eindeutige Berechtigungen 50.000 ist, sollten Sie erwägen, diesen Grenzwert auf 5000 zu senken.

Eindeutige Berechtigungen

Standard: 50.000	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: Zentraladministration, webanwendungsbezogen

Zeilenumbruch

Beim Hinzufügen von Spalten zu einer Liste werden diese Spalten einer SQL Server-Datenbanktabelle zugeordnet. Jede Zeile in der Datenbanktabelle unterstützt eine feste Anzahl der einzelnen verschiedenen Spaltentypen. Eine einzelne Zeile in einer Datenbanktabelle lässt beispielsweise acht Datum-/Uhrzeit-Spalten und zwölf Zahlenspalten zu. Wenn es mehr als acht Datum-/Uhrzeit-Spalten gibt, belegt jedes Listenelement zwei Zeilen der Datenbanktabelle.

Bei kleinen Listen kann die Auswirkung dieses Zeilenumbruchs auf die Leistung vernachlässigt werden, bei umfangreichen Listen hingegen nicht. Sie können für eine beliebige Anzahl von Spalten bis zum Grenzwert gehen, ehe ein Zeilenumbruch erfolgt, doch nur ein Spaltentyp muss den Grenzwert überschreiten, damit es zu einem Zeilenumbruch kommt.

Die folgende Tabelle enthält die Anzahl von Spalten spezifischer Datentypen, bevor es zum Zeilenumbruch kommt.

Spaltentyp	Anzahl der Spalten pro Tabellenzeile
Eine Textzeile oder Option und mehrere Textzeilen	64 32
Datum und Uhrzeit	8
Ja oder Nein	16
Zahl und Währung	12
Berechnet	8
Ganze Zahl, Nachschlagen eines Werts, Personen und Gruppe, verwaltete Metadaten	16
Eindeutige ID	1

Zeilenumbrüche bewirken bei den meisten Vorgängen ein Nachlassen des Durchsatzes um ca. 35 % für jede zusätzliche Zeile. Zum Überprüfen, wie viele Zeilen eine Liste nutzt, müssen Sie das Listenschema und die Spaltentypen der Felder in der Liste untersuchen.

Die folgende Abbildung zeigt die Leistung schreibgeschützter Abfragen bei ansteigender Anzahl von SQL Server-Datenbankzeilen in einer Liste zur Aufnahme weiterer Spalten mit verwalteten Metadaten. Um zur zweiten Zeile zu gelangen, wurden der Liste 15 Spalten mit verwalteten Metadaten hinzugefügt. Um zur dritten Zeile zu gelangen, wurden dieser Liste 31 Spalten mit verwalteten Metadaten hinzugefügt. Tests wurden nur unter Verwendung von Abfragen durchgeführt, die eine Filterung anhand von Elementen in der Liste vornahmen. Bei jeder zusätzlichen Zeile verringerte sich der Durchsatz um 35 %.

Zeilengrößengrenze

Standard: 6	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: nur Objektmodell, SPWebApplication.MaxListItemRowStorage

Die Zeilengrößengrenze gibt die maximale Anzahl datenbankinterner Tabellenzeilen an, die ein Listenelement belegen darf. Zum Aufnehmen breiter Listen mit vielen Spalten wird jedes Element über maximal sechs interne Tabellenzeilen umgebrochen. Wenn Sie eine Liste mit vielen kleinen Spalten haben, z. B. mit Hunderten von Ja/Nein-Spalten, kann dieser Grenzwert erreicht werden. In diesem Fall können Sie der Liste keine weiteren Ja/Nein-Spalten hinzufügen. Das Hinzufügen anderer Spaltentypen ist hingegen ggf. möglich. Da jede weitere Zeile den Verarbeitungsaufwand erhöht, sollten Sie bei einer umfangreichen Liste die Anzahl der Spalten desselben Datentyps minimieren, um Zeilenumbrüche zu vermeiden.

Nachschlagespalten und Listenansichten

Jede Nachschlagespalte in einer Listenansicht verursacht eine Verknüpfung mit einer anderen Tabelle. Durch jede zusätzliche Nachschlagespalte in einer Ansicht erhöht sich die Komplexität der Metadatennavigation und von Listenansichtsabfragen. Zusätzlich zu den standardmäßigen Nachschlagespalten zählen verwaltete Metadatenspalten mit einem oder mehreren Werten sowie Personen- und Gruppenspalten mit einem oder mehreren Werten als Nachschlagespalten. Das Hinzufügen von Nachschlagespalten zu einer Ansicht führt nicht zu einer allmählichen oder linearen Verschlechterung der Leistung, sondern nach acht Spalten mit stabiler Leistung verschlechtert sich diese rapide.

Die folgende Abbildung zeigt die Änderung beim Durchsatz bei stetig steigender Anzahl von Nachschlagespalten. Wie Sie sehen, ist die Leistung von 0 bis 8 recht stabil, doch bei zehn Nachschlagespalten lässt die Leistung stark nach. Dieser Test der Liste wurde nur mit einer Zeile durchgeführt. Wenn es in einer Liste zu Zeilenumbrüchen kommt, lässt die Leistung schneller nach.

Die folgende Abbildung zeigt die Auslastung der SQL Server-CPU bei stetigem Anstieg der Anzahl von Nachschlagespalten in einer Ansicht. Bei zehn Nachschlagespalten kommt es zu erkennbaren Änderungen. Bei einer Liste mit vielen Abfragen bewirkt das Vorhandensein von Ansichten mit mehr als acht Nachschlagespalten, dass die Abfragen einen unverhältnismäßig großen Anteil der SQL Server-Ressourcen beanspruchen. Es wird empfohlen, diesen Grenzwert auf nicht mehr als maximal 8 festzulegen.

Wenngleich diese Leistungsverschlechterung nicht für die Gesamtanzahl der Nachschlagespalten in einer Liste, sondern nur für die Anzahl der Nachschlagespalten in einer Ansicht oder Abfrage gilt, kann SharePoint-Arbeitsbereich keine Synchronisierung mit Listen durchführen, die mehr als acht Nachschlagespalten haben. Dies gilt unabhängig davon, ob die Spalten in einer Ansicht verwendet werden oder nicht.

Schwellenwert für den Listenansicht-Nachschlagevorgang

Standard: 8	In SharePoint Server 2007 vorhanden: Nein	Konfigurierbar: Ja
Konfigurationsspeicherort: Zentraladministration, webanwendungsbezogen

Weitere Grenzwerte

In diesem Abschnitt werden Grenzwerte beschrieben, die ansonsten nicht in diesem Artikel behandelt werden.

Indizes pro Liste

Standard: 20

In SharePoint Server 2007 vorhanden: Ja, mit dem Grenzwert 10

Konfigurierbar: Nein

Die vorherige Tabelle enthält den Grenzwert von Indizes, die pro Liste erstellt werden können, einschließlich zusammengesetzter und von SharePoint Server 2010 erstellter Indizes. Dieser Grenzwert kann nicht konfiguriert werden.

Datenblattansicht und "In Excel exportieren"

Standard: 50.000

In SharePoint Server 2007 vorhanden: Nein

Konfigurierbar: Nein

Diese Tabelle enthält die maximale Anzahl von Elementen, die mit In Microsoft Excel exportieren und der Datenblattansicht verwendet werden können. Die Datenblattansicht unterliegt allerdings dem Schwellenwert für die Listenansicht. Wenn dieser auf 5000 festgelegt ist und eine Listenansicht 5000 bis 50.000 Elemente enthält, erhalten Sie beim Versuch, die Datenblattansicht zu verwenden, eine Ausnahmemeldung zur Listenansicht, obwohl der Grenzwert für die Datenblattansicht höher ist.

SharePoint Workspace

Standard: 30.000 Elemente pro Liste

In SharePoint Server 2007 vorhanden: Nein

Konfigurierbar: Nein

Microsoft SharePoint Workspace hat einen nicht konfigurierbaren Grenzwert, der die Synchronisierung einer Liste mit mehr als 30.000 Elementen blockiert. Wenn eine Liste 30.000 Elemente enthält, können die Benutzer die Liste nicht mithilfe von SharePoint-Arbeitsbereich synchronisieren, und die Elemente können nicht selektiv synchronisiert werden.

Unterschiede zwischen normalen und umfangreichen Listen

Wenn eine Liste den Schwellenwert für die Listenansicht überschreitet, werden einige Vorgänge, die ggf. zuvor funktioniert haben, blockiert. Von größtem Interesse ist die Standardlistenansicht, da über sie am häufigsten auf eine Liste zugegriffen wird. Listenansichten müssen so konfiguriert werden, dass sie für eine umfangreiche Liste ordnungsgemäß funktionieren. Beispielsweise tritt ein Fehler bei einem Zugriff auf eine Liste auf, wenn der Stamm der Liste mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt. Bei aktivierter Metadatennavigation wird eine Untermenge der Ergebnisse anstelle eines Fehlers angezeigt.

Der Schwellenwert für die Listenansicht blockiert alle Datenbankvorgänge, die mehr Elemente betreffen, als dieser Schwellenwert zulässt. Dieser Schwellenwert blockiert nicht nur die Anzahl der zurückgegebenen oder geänderten Elemente. Wenn Sie über einen Filter für eine nicht indizierte Spalte verfügen, der 100 Ergebnisse zurückgibt, und die Liste 10.000 Elemente enthält, misslingt die Abfrage, da die gesamten 10.000 Elemente durchsucht werden müssen. Wenn Sie dieser Spalte einen Index hinzufügen, wird der Vorgang auf nur 100 Elemente begrenzt und hat Erfolg.

Auf umfangreiche Listen angewendete Vorgänge können in die beiden folgenden Gruppen unterteilt werden:

• Liste überschreitet den Schwellenwert für die Listenansicht Verschiedene Vorgänge werden verhindert, wenn die Größe der gesamten Liste den Schwellenwert für die Listenansicht überschreitet, selbst wenn Elemente auf Ordner aufgeteilt sind. Zu diesen Vorgängen zählen rekursive Abfragen, z. B. beim Verwalten ausgecheckter Versionen, die sich auf alle Elemente unabhängig davon beziehen, in welchem Ordner sie sich befinden. Ansichten, die alle Elemente ohne Ordner zurückgeben, werden ebenfalls verhindert. Darüber hinaus werden Vorgänge, die sich auf die gesamte Liste beziehen, z. B. das Hinzufügen einer Spalte und Erstellen oder Löschen von Indizes, blockiert.

• Container überschreitet den Schwellenwert für die Listenansicht Verschiedene Vorgänge werden verhindert, da ein Ordner oder der Stamm der Liste mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt. Wenn beispielsweise eine Liste 10.000 Elemente und ein Ordner 3000 Elemente enthält, können Sie den Ordner umbenennen oder löschen. Wenn der Ordner hingegen 6000 Elemente enthält (wodurch der Schwellenwert für die Listenansicht überschritten wird), können Sie den Ordner nicht löschen, da der Vorgang den Schwellenwert für die Listenansicht überschreitet.

Wenn eine Liste den Schwellenwert für die Listenansicht überschreitet, müssen Sie Ansichten und andere Navigationsoptionen ordnungsgemäß konfigurieren. Im Idealfall werden Ansichten und andere Navigationsoptionen im Vorfeld konfiguriert, doch häufig wachsen Listen über den Schwellenwert für die Listenansicht hinaus, was Maßnahmen erfordert. Einige Vorgänge wie das Erstellen oder Indizieren einer Spalte in einer Liste mit vielen Elementen dauern sehr lange. Diese Vorgänge werden durch den Schwellenwert für die Listenansicht verhindert, können jedoch im täglichen Zeitfenster oder von Farm- oder Computeradministratoren ausgeführt werden. Sie müssen diese Vorgänge vor ihrer Durchführung sorgfältig planen. Wenn die Liste zu groß ist, nutzen Sie das tägliche Zeitfenster oder Administratorberechtigungen zum Durchführen dieser Vorgänge.

Eine Liste kann so lang werden, dass bei einigen Vorgängen ggf. das Zeitlimit überschritten wird, wenn sie in einem Webbrowser ausgeführt werden. Wenn eine Liste beispielsweise Millionen von Dokumenten enthält, kann das Hinzufügen einer neuen Spalte sehr lange dauern. Für diesen Schritt müssen Sie Windows PowerShell verwenden und sicherstellen, dass die Ausführung außerhalb der Spitzennutzungszeiten erfolgt, da ansonsten Vorgänge anderer Benutzer blockiert werden.

Vom Schwellenwert für die Listenansicht blockierte Vorgänge

Die folgenden Tabellen enthalten Vorgänge, die vom Schwellenwert für die Listenansicht blockiert werden.

Blockierte Vorgänge, wenn die Liste den Schwellenwert für die Listenansicht überschreitet

Vorgang	Beschreibung
Hinzufügen/Entfernen/Aktualisieren einer Listenspalte	Alle Spalten samt Nachschlage- und berechneter Spalten zusätzlich zu vielen Arten von Aktualisierungen, z. B. Änderung des Typs oder der Eindeutigkeit. Einige Aktualisierungen, z. B. Namensänderungen, werden nicht blockiert, da sie sich nicht auf alle Elemente in der Liste auswirken.
Hinzufügen/Entfernen/Aktualisieren eines Listeninhaltstyps	Wirkt sich auf alle Elemente in der Liste aus und wird deshalb für alle Listen blockiert, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.
Erstellen/Entfernen eines Index	Wirkt sich auf alle Elemente in der Liste aus und wird deshalb für alle Listen blockiert, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.
Verwalten von Dateien ohne eingecheckte Version	Eine nicht indizierte rekursive Abfrage, die bei allen Listen misslingt, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.
Nicht indizierte rekursive Abfragen	Schließt Filter- und einige Sortiervorgänge ein. Dieser Vorgang misslingt, wenn die Größe der Liste den Schwellenwert für die Listenansicht überschreitet. Da kein Index vorhanden ist, erfolgt eine vollständige Durchsuchung der gesamten Liste. Ferner werden alle Elemente zurückgegeben und Ordner ignoriert.
Listenübergreifende Abfrage	Umfasst Abfragen mithilfe des Webparts für Inhaltsabfragen und befolgt den Schwellenwert für die Listenansicht für Auditoren und Administratoren, der standardmäßig auf 20.000 Elemente festgelegt ist. Sollte ein Vorgang mehr als 20.000 Elemente einbeziehen, misslingt die Abfrage.
Nachschlagespalten, die ein Beziehungsverhalten erzwingen	Sie können keine Nachschlagespalten erstellen, die ein Beziehungsverhalten erzwingen, wenn die Liste, auf die verwiesen wird, mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt.
Löschen einer Liste	Wirkt sich auf alle Elemente in der Liste aus und wird deshalb für alle Listen blockiert, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.
Löschen einer Website	Wenn die Gesamtanzahl aller Elemente in einer Website den Schwellenwert für die Listenansicht überschreitet, wird das Löschen der Website verhindert, da zu viele Elemente betroffen sind.
Speichern einer Liste als Vorlage mit Daten	Wirkt sich auf alle Elemente in der Liste aus und wird deshalb für alle Listen blockiert, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.
Anzeigen der Gesamtanzahl in Listenansichten	Wendet eine Abfrage auf alle Elemente in der Liste an und wird deshalb für alle Listen blockiert, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.
Aktivieren/Deaktivieren von Anlagen in einer Liste	Wirkt sich auf alle Elemente in der Liste aus und wird deshalb für alle Listen blockiert, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.

Blockierte Vorgänge, wenn der Container den Schwellenwert für die Listenansicht überschreitet

Vorgang	Beschreibung
Löschen/Kopieren/Umbenennen eines Ordners	Fehler, wenn der Ordner mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt, da zu viele Zeilen betroffen sind.
Abfragen zum Filtern anhand nicht indizierter Spalten	Fehler, wenn der Container (Ordner oder Liste) mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt. Da ein Index fehlt, wird bei diesem Vorgang der Ordner vollständig durchsucht.
Festlegen abgestimmter Sicherheitsberechtigungen	Fehler, wenn die Liste oder der Ordner mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt, da zu viele Zeilen betroffen sind. Sie können in einer umfangreichen Liste weiter abgestimmte Berechtigungen für untergeordnete Elemente, z. B. Dokumente, festlegen. Sie können aber die Berechtigungen nicht für die Liste selbst oder Ordner festlegen, die mehr Elemente enthalten, als der Schwellenwert für die Listenansicht zulässt.
Mit Explorer öffnen	Zeigt keine Elemente an, wenn ein Container mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt (ausgenommen Elemente in Unterordnern). Wenn ein Ordner 8000 Elemente enthält, jedoch einen Unterordner mit 4000 Elementen und nur 4000 Elemente im Stamm aufweist, funktioniert Mit Explorer öffnen. Wenn der Stamm einer Liste mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt, wird bei Verwenden von Mit Explorer öffnen nichts angezeigt. Damit Mit Explorer öffnen verwendet werden kann, muss die Liste in Ordnern organisierte Elemente mit einer Größe unter dem Schwellenwert für die Listenansicht am Stamm sämtlicher Container aufweisen.

Verfügbare Features, die ggf. nicht wie erwartet funktionieren

Dieser Abschnitt enthält Informationen zu Features, die ggf. im Zusammenhang mit umfangreichen Listen nicht wie erwartet funktionieren.

Datenblattansicht

Die Schaltfläche Datenblattansicht im Menüband Bibliothek einer Dokumentbibliothek ist nicht deaktiviert, wenn die Liste den Schwellenwert für die Listenansicht überschreitet. Sobald dies der Fall sein sollte, kann die Liste einige Elemente laden, wobei jedoch folgende Meldung eingeblendet wird: "Sie haben nicht die Berechtigung, die gesamte Liste anzuzeigen, weil die Liste mehr Einträge enthält, als der Schwellenwert für die Listenanzeige angibt, den der Administrator festgelegt hat." In den Einstellungen für die Liste können Sie die Option Datenblattansicht im Menüband deaktivieren. Ferner gilt ein fester Grenzwerte von 50.000 Elementen, weshalb diese Ansicht auch blockiert wird, wenn der Schwellenwert für die Listenansicht höher als 50.000 Elemente ist.

Planen des Entwurfs und der Implementierung umfangreicher Listen

Untersuchen Sie vor der Implementierung einer umfangreichen Liste unbedingt die geschäftlichen Anforderungen, zu denen Vereinbarungen zum Servicelevel (SLAs), die Zeit für die Sicherung und Wiederherstellung, der Umfang der Inhalte, die Anzahl der Elemente und die Zugriffszeiten zählen. Je nach Größe und Bedarf der Anwendung müssen auf mehreren Ebenen wichtigen Entscheidungen getroffen werden, z. B. Hardware, Inhaltsspeicherung und SharePoint Server 2010-Informationsarchitektur. Eine große Anwendung mit Millionen von Elementen und Hunderten gleichzeitiger Benutzer benötigt ggf. eigenständige Hardware für das jeweilige Projekt, während ein Dokumentrepository mit einer Anzahl gleichzeitiger Benutzer im zweistelligen Bereich und Zehntausenden von Dokumenten problemlos mit vorhandener gemeinsam genutzter Hardware und einer einzelnen Dokumentbibliothek in einer vorhandenen Website funktionieren kann.

Das Endergebnis der Planung muss eine Aufstellung mit folgendem Inhalt sein. Spaltentypen (Name, Datentyp und Zweck), Indizes, Ordnerstruktur, Seitenverwendung und Links zur Navigation, geplante Berechtigungsstruktur, geschätzte Anzahl von Elementen und Gesamtdatengröße. Zu den Einzelheiten müssen beispielsweise die Art der Abfragen, die ausgeführt werden, sowie Informationen zu Datenzugriff, -erstellung und -aktualisierung gehören.

Nach der Planung des Entwurfs und der Implementierung einer umfangreichen Liste ist der nächste Schritt das Entwerfen und Erstellen eines Prototyps. In dieser Planungsphase geht es um das Entwerfen der umfangreichen Liste, das Erbringen eines Machbarkeitsnachweises und das Überprüfen der Funktionsfähigkeit. In dieser Phase ist es ggf. hilfreich, eine Testumgebung mit einer großen Menge von Inhalten aufzufüllen, um Annahmen hinsichtlich Datenzugriff und Leistung zu überprüfen. Das Endergebnis des Entwurfsprozesses muss ein Machbarkeitsnachweis für die beabsichtigte Liste sowie eine Dokumentation der Spalten, Inhaltstypen, Ordnerstruktur, Ansichten, Indizes, der für die Metadatennavigation und andere Abrufmethoden verwendeten Spalten, verwendeten Taxonomien, Verwendung verschiedener Webparts sowie etwaiger anderer Features wie der Inhaltsorganisation sein.

Schätzen des Inhaltsvolumens

Bei umfangreichen Listen ist es für die Kapazitätsplanung und Entscheidungen zum Entwurf wichtig, verschiedene Werte zu schätzen. Es gibt einige wichtige Werte, die berücksichtigt werden müssen, zu denen die folgenden zählen:

• Gesamtgröße der Inhaltsdatenbank

• Durchschnittliche und maximale Dateigröße

• Anzahl der Versionen

• Inhaltsvolumen – Gesamtanzahl der Elemente in einer Liste

Inhaltsdatenbankgröße

Die Gesamtgröße der Inhaltsdatenbank ist wichtig für die Planung der benötigten Datenträger und Hardware. Außerdem muss bestimmt werden, was hinsichtlich Sicherung, Wiederherstellung und Vereinbarung zum Servicelevel unterstützt werden kann. Die Gesamtgröße der Inhaltsdatenbank ist außerdem ein wichtiger Faktor beim Ermitteln der für Sicherung und Wiederherstellung benötigten Ausfallzeit.

Die geschätzte Größe der Inhaltsdatenbank kann wie folgt berechnet werden: durchschnittliche Dokumentgröße multipliziert mit der durchschnittlichen Anzahl von Versionen pro Dokument multipliziert mit der erwarteten Anzahl von Dokumenten. Addieren Sie zusätzlich zu den Dateien weitere 20 % für die Inhaltsdatenbankdaten. Dieser Wert ist hoch, da die Größe von Versionen im Allgemeinen mit der Zeit zunimmt, sodass die durchschnittliche Dateigröße eingecheckter Dokumente meist einen höheren Wert als die durchschnittliche Dateigröße aller Versionen hat. Sie müssen einen groß dimensionierten Puffer für den Fall einrichten, dass die Liste größer als erwartet wird, es sei denn, Sie verfügen über Mechanismen zum effektiven Steuern des Inhaltsvolumens.

Durchschnittliche und maximale Dateigröße

Die maximale Dateigröße wird benötigt, um sicherzustellen, dass die ordnungsgemäße Webanwendungseinstellung für Dateien angegeben wird, die hochgeladen werden können (der Standardwert ist 50 MB, maximal sind 2 GB möglich). Die durchschnittliche Dateigröße dient zum Veranschaulichen der Rate, mit der Inhalte anwachsen können, und zum Schätzen der Gesamtgröße des Inhalts. Die durchschnittliche Dateigröße kann geschätzt werden, indem Dateien in Systemen überprüft werden, die augenblicklich die Rolle des geplanten Systems ausfüllen.

Durchschnittliche Anzahl der Versionen

Sie müssen die Versionsverwaltung einkalkulieren, da sie das Inhaltsvolumen beträchtlich vergrößern kann. Es gibt Möglichkeiten, Versionen einzuschränken. Sie können beispielsweise mit Aufbewahrungsrichtlinien für die Informationsverwaltung arbeiten, um alle vorherigen Versionen nach einem bestimmten Zeitraum zu löschen, oder Sie können die Anzahl der zu speichernden Versionen begrenzen. Es gibt noch weitere Faktoren, die sich auf Versionen auswirken. Wenn beispielsweise Ihrem Repository sämtliche Inhalte mithilfe der Inhaltsorganisationsfunktion hinzugefügt werden, gibt es ggf. gar keine Versionen, da diese Funktion nur die letzte eingecheckte Version kopiert. Wenn Dokumente in Ihrem Repository von Benutzern aktiv bearbeitet werden, müssen Sie ggf. die gemeinsame Dokumenterstellung berücksichtigen, denn bei jeder gemeinsamen Dokumenterstellungssitzung wird automatisch eine Version erstellt. Überprüfen Sie die Verwendung des Repositorys sowie vorhandener Lösungen, um die durchschnittliche Anzahl von Versionen zu bestimmen, die für ein Dokument erstellt werden.

Inhaltsvolumen

Das Inhaltsvolumen ist die Gesamtanzahl der Elemente in einer einzelnen Liste. Zum Schätzen des Inhaltsvolumens müssen Sie die vorhandenen Inhaltsquellen und die in das neue System zu verschiebenden Elemente überprüfen oder bestimmen, wie viele Benutzer das System nutzen werden und was sei Zweck ist. Es gibt einige andere zu berücksichtigende Werte, zu denen die Anzahl der Elemente pro Container und der Elemente pro Pivot- oder Indexfilter für Metadatendaten zählen. Diese Werte sind auch bei der Planung von Ansichten und der Metadatennavigation von Bedeutung.

Remote BLOB Storage

Listen mit hohen Speicheranforderungen können eine grundlegende Entscheidung zur Speicherung der Dokumente erforderlich machen. Standardmäßig werden von SharePoint Server 2010 alle Dokumente als BLOB-Dateien in der SQL Server-Datenbank gespeichert. SharePoint Server 2010 und SQL Server 2008 bieten eine Remote BLOB Storage-API, die das Speichern von Dokumenten außerhalb der SQL Server-Datenbank ermöglicht, wodurch die Datenbank verkleinert wird. Die Entscheidung für den Einsatz von Remote BLOB Storage ist stark von Kostenüberlegungen geprägt.

Aktuelle Tests von Microsoft haben ergeben, dass Remote BLOB Storage eine 5-10 %-ige Verschlechterung des Durchsatzes und bei großen Dateien keine spürbaren Unterschiede bei der Wartezeit verursacht. Doch je nach verwendetem Remote BLOB Storage-Anbieter kann die Leistung unterschiedlich sein. Durch Verwenden von Remote BLOB Storage wird die Datenbank verkleinert. Dies bedeutet aber nicht unbedingt, dass Sie in einer Inhaltsdatenbank mehr Elemente speichern können, denn die Leistung wird von der Anzahl der Elemente in Listen in der SQL Server-Datenbank beeinflusst. Selbst wenn BLOB-Dateien entfernt werden, ändert sich die Listengröße nicht. Es gibt Szenarien, bei denen die Kostenvorteile die Bedenken hinsichtlich der Leistung aufwiegen:

• Nicht für die Zusammenarbeit bestimmte Archivdaten

• Die Speicherung sehr großer BLOB-Dateien, z. B. Videos und Bilder, die nur selten aktualisiert werden

Remote BLOB Storage kann weitere Server und Technologien in Ihrer Farm sowie das Hinzufügen eines Remote BLOB Storage-Anbieters erforderlich machen. Ein Remote BLOB Storage-Anbieter ermöglicht die Speicherung von BLOB-Dateien auf kostengünstigeren Datenträgern außerhalb der SQL Server-Datenbank. Zum Verwenden der Remote BLOB Storage-API ist SQL Server Enterprise erforderlich.

Der Scheidepunkt, an dem Remote BLOB Storage sich rechnet, liegt möglicherweise im Terabytebereich von Daten. Nur weil Ihre Inhaltsdatenbanken Terabytegröße haben, müssen Sie nicht auf Remote BLOB Storage umsatteln. Außerdem müssen Sie die Sicherung und Wiederherstellung sowie Vereinbarungen zum Servicelevel sorgfältig prüfen. Remote BLOB Storage erschwert die Wiederherstellung nach einem Notfall, da zwei Technologien synchronisiert werden müssen. Der Knackpunkt ist die Zeit, die zum Wiederherstellen des Systems nach einem Notfall erforderlich ist und die Verarbeitung der gesicherten und wiederherzustellenden BLOB-Dateien. Weitere Informationen finden Sie unter RBS (Übersicht) (SharePoint Server 2010).

Listenarchitektur

Die Auswahl der geeigneten Architektur für ein Projekt zum Entwickeln einer umfangreichen Liste ist wichtig, da einmal getroffene Entscheidungen nach ihrer Umsetzung nicht einfach geändert werden können. Planen Sie mit Weitsicht, und berücksichtigen Sie die Größe und Menge von Inhalten, die Verwendung des Repositorys, wie Inhalte hinzugefügt und aktualisiert werden und wie der Zugriff auf Inhalte erfolgt. Alle diese Faktoren haben Einfluss darauf, wie Inhalte organisiert werden (in einer Liste, mehreren Listen oder sogar mehreren Websitesammlungen), welche Metadaten verwendet und wie Inhalte abgerufen werden.

Eine Liste, mehrere Listen oder mehrere Websitesammlungen

Beim Entwerfen einer Lösung für eine umfangreiche Liste sollte geprüft werden, ob eine Architektur mit einer Liste sich eignet. Die Entscheidung, Inhalte in einer Liste abzulegen, muss auf Geschäftsanforderungen basieren, z. B. Benutzerfreundlichkeit beim Arbeiten mit und Auffinden von Inhalten. In vielen Fällen ist es ggf. sinnvoller, mit mehreren Listen zu arbeiten. Ihre oberste Priorität sollte allerdings sein, mithilfe der Funktionsmöglichkeiten von SharePoint Server 2010 und verfügbarer Ressourcen eine erfolgreiche Implementierung mit hohem Nutzwert und überzeugender Benutzerumgebung zu schaffen.

Das Beschränken auf eine Liste erleichtert Benutzern das Auffinden von und Arbeiten mit Inhalten, sodass sie nicht entscheiden müssen, wo sie ihre Inhalte ablegen sollen oder auf welche Liste sie zugreifen müssen, um zu finden, was sie suchen. Doch mit zunehmendem Inhaltsvolumen kann das Auffinden von Inhalten auch schwieriger werden, insbesondere mithilfe von Methoden wie dem Filtern von Ansichten oder Navigieren durch Ordner. Wenn die Anzahl der Elemente in einer Liste im hohen sechsstelligen Bereich liegt, kann die Metadatennavigation schwierig werden. Auf Abfragen werden Hunderte oder Tausende von Ergebnissen zurückgegeben, da sie nicht spezifisch genug sind.

Beispiel: Wenn im Bereich eines Index 5000 Ausdrücke vorhanden sind und jeder Ausdruck eine identische Menge von Elementen aufweist, die dem Filter entsprechen, führt das Filtern anhand eines Ausdrucks bei einer Liste mit 100.000 Elementen zu 20 Ergebnissen und bei einer Liste mit 1.000.000 Elementen zu 200 Ergebnissen. Wenn die Liste zu umfangreich ist, geben viele von den Benutzern ausgewählte Filter bei der Suche nach den gewünschten Informationen keine vernünftigen Resultsets zurück. Wenn ein Projekt mehrere Arten merklich unterschiedlicher Inhalte aufweist, die die Benutzer differenzieren können, sollten Sie das Arbeiten mit mehreren Listen erwägen.

Bei sehr großen Archivierungsszenarien kann es sich lohnen, eine Architektur mit mehreren Websitesammlungen zu prüfen. Ein neues SharePoint Server 2010-Feature ermöglich, dass Websitesammlungen zum Lastenausgleich bei Dokumenten in Gruppen zusammengefasst werden. Das Feature Inhaltsorganisation dient zum Weiterleiten von Dokumenten zwischen mehreren Websitesammlungen. Zum Auffinden der Dokumente muss die Suchfunktion genutzt werden. Dies ist eine empfehlenswerte Lösung für die Langzeitspeicherung, da Inhalte gleichmäßig auf mehrere Websitesammlungen aufgeteilt werden können und aufgrund der Skalierbarkeit wesentlich mehr Dokumente als in einer einzelnen Liste unterstützt werden können.

Zusammenfassung der Empfehlungen für Listen

• Wählen Sie Einzellisten für große Anzahlen von Elementen, wenn:

  • es nicht logisch ist, Elemente in getrennten Listen abzulegen.

  • eine bessere Benutzerumgebung bereitgestellt wird.

• Wählen Sie mehrere Listen für große Anzahlen von Elementen, wenn:

  • es logisch ist, Elemente in mehreren Listen zu gruppieren.

  • eine bessere Benutzerumgebung bereitgestellt wird.

  • für die Benutzer klar erkennbar ist, in welchen Listen sie Inhalte finden oder ergänzen können.

• Wählen Sie eine Architektur mit mehreren Websitesammlungen, wenn:

  • in einem einzelnen Repository mehr als 10.000.000 Elemente unterstützt werden müssen.

  • es logisch ist, Elemente in mehreren Websitesammlungen zu gruppieren, um Daten beispielsweise jahrweise zu unterteilen.

Metadaten

In SharePoint Server 2010 bieten sich Metadaten und Inhaltstypen zum Erstellen einer Informationsarchitektur an. Durch neue Features wie verwaltete Metadaten, Ausdruckssätze und Metadatennavigation werden Metadaten sehr nützlich und wichtig für das Abrufen von Inhalten. Da Vorgänge wie das Ändern von Inhaltstypen und Spalten bei umfangreichen Listen blockiert werden, ist es besonders wichtig bei der Planung, die Anforderungen für Metadaten zu berücksichtigen. Wenn Sie vorhaben, zum Abrufen von Inhalten mithilfe von Metadaten und der Metadatennavigation oder einer anderen Methode zu arbeiten, müssen Sie sich in der Entwurfsphase Inhaltstypen und deren Spalten widmen.

In den meisten Szenarien mit umfangreichen Listen sind Metadaten nicht nur nützlich, sondern eine Voraussetzung für die Nutzung des Systems. Es gibt drei Hauptmöglichkeiten, Metadaten zuzuweisen: über vordefinierte Systemprozesse, benutzerdefinierte Konfigurationen und Code sowie manuell durch Benutzer. Um Inhalte mithilfe von Spalten abzurufen, muss bei den meisten Elementen der Spalte ein Wert zugewiesen werden. Deshalb muss geplant werden, welche Spalten für die Navigation verwendet und wie die Metadaten aufgefüllt werden sollen. Die einzige Möglichkeit zu gewährleisten, dass die ordnungsgemäßen Metadaten zugeordnet werden, bietet das Verwenden von vordefinierten Prozessen und Anpassungen. Da beispielsweise jedes Element einen Inhaltstyp aufweist, werden bei Verwenden von Inhaltstypen zum Klassifizieren von Dokumenten jedem Inhaltstyp diese Metadaten zugewiesen, was das Filtern anhand des Inhaltstyps vereinfacht.

Inhaltstypen

Die einfachste Kategorisierungsmöglichkeit stellen Inhaltstypen dar. Wenn Sie über Metadaten zum Klassifizieren von Inhalten verfügen, z. B. Dokument- oder Elementtyp, sollten Sie diese Klassifizierung für Ihre Inhaltstypen übernehmen. Inhaltstypen ermöglichen die Definition der Spalten, die einer Inhaltsart zugewiesen sind, und die Zuordnung zu Workflows und der Vorlage. Einem Inhaltstyp kann nur eine Vorlage zugeordnet werden. Dabei handelt es sich um die Vorlage, mit der Sie in einer Dokumentbibliothek im Menü Neues Dokument eine neue Instanz des Inhaltstyps erstellen.

Sie können Vorlagen für Dateiformate in Microsoft Word, Microsoft PowerPoint und Excel sowie anderen Produkten verwenden. Wenn Benutzer neue Instanzen des Inhaltstyps erstellen, wird die dazugehörige Clientanwendung verwendet, um mit der Dokumenterstellung mithilfe der Vorlage zu beginnen. Wird Inhalt hochgeladen, können Benutzer unter den verfügbaren Inhaltstypen eine Auswahl treffen. Inhaltstypen müssen eindeutig und spezifisch sein. Außerdem sollte es pro Liste eine überschaubare Anzahl von Inhaltstypen geben, damit die Benutzer keine Schwierigkeiten bei der Auswahl des zu verwendenden Inhaltstyps haben.

Da mit Inhaltstypen die Metadaten gesteuert werden, die Benutzer beim Erstellen oder Hochladen eines Elements ausfüllen müssen, bestimmen Sie die Spalten, die für das Erfüllen von Geschäftsanforderungen erforderlich sind, und bauen Sie ferner Hürden für die Übermittlung von Inhalten ab. Die Auswahl einer überlegten Menge von Inhaltstypen zum Klassifizieren von Inhalten auf der primären Stufe unterstützt automatisch die Navigation. Da jedes Element einen Inhaltstyp hat, gibt es ein Filterkriterium, das bei jedem Element funktioniert.

Zusammenfassung der Empfehlungen für Inhaltstypen

• Wählen Sie Inhaltstypen als grundlegendstes Instrument zum Organisieren von Inhalten.

• Verwenden Sie Inhaltstypen zum Auswählen der spezifischen Spalten, die für die jeweilige Art von Inhalt erforderlich sind.

• Inhaltstypen, deren Anzahl pro Liste 10 nicht überschreiten sollte, sollten so verschieden sein, dass die Benutzer problemlos den zu verwendenden Inhaltstyp auswählen können.

• Inhaltstypen verfügen über eine vordefinierte Spalte, für die jedes Element einen Wert aufweist, der zum Filtern und die Metadatennavigation verwendet werden kann.

Beispiel einer umfangreichen Liste mit Schwerpunkt auf Zusammenarbeit und von Inhaltstypen: Bibliothek mit Produktspezifikationen

Eine Bibliothek mit Produktspezifikationen wird von Produktentwicklungsteams zum Speichern von Entwurfsspezifikationen, Testplänen und anderen Produktentwicklungselementen genutzt. In diesem Beispiel werden die sechs folgenden Inhaltstypen verwendet, die alle über Spalten für Projektstartdatum, Projektenddatum, Budget, Mitglieder des Entwicklungsteams, Produktname und Produkttyp verfügen.

• Produktspezifikation – Eine Word-Datei enthält die Details zur Entwicklung eines Produkts. Zu den weiteren Metadaten gehören der Entwickler und das Datum der letzten Überprüfung.

• Testspezifikation – Eine Word-Datei enthält den Testplan eines Produkts. Zu den weiteren Metadaten gehören der Tester und der Testabschlussstatus.

• Entwicklungsplan – Eine Word-Datei enthält den Entwicklungsplan des Produkts.

• Präsentation – Eine PowerPoint-Präsentation, die zum Präsentieren der Modelle der Entwicklung dient.

• Kostenanalyse – Eine Excel-Kalkulationstabelle zum Analysieren der Kosten zum Entwickeln des Produkts und der potenziellen Marktchancen.

• Zeitachse – Eine Excel-Kalkulationstabelle mit Details zum Zeitplan der Entwicklung des Produkts.

In diesem Beispiel können Benutzer eine Filterung anhand des Inhaltstyps durchführen, um eine Produktspezifikation oder -präsentation zu finden. Die benutzerdefinierten Vorlagen unterstützen zudem die Strukturierung der Arbeit des Benutzers. Die Anzahl der Spalten und Inhaltstypen ist so überschaubar, dass Benutzer mühelos die gewünschten Optionen für ihre Arbeit finden können, denn durch das Eingeben von Metadaten ist das Filtern und Auffinden von Inhalten einfach.

Spalten

Anzahl der Spalten und erforderliche Spalten

Sie können mithilfe von Spalten die Art von Metadaten eines Elements angeben und diese als ausgeblendet, optional oder erforderlich markieren. Wählen Sie ausgeblendete Spalten für automatisierte Aufgaben, z. B. Workflows, damit Benutzer sie nicht ändern können. Arbeiten Sie mit erforderlichen Spalten nur dann, wenn dies unbedingt nötig ist. Eine Metadateneigenschaft kann beispielsweise nötig sein, um ein Element zu einem geeigneten Speicherort weiterzuleiten, oder es kann für die Navigation benötigt werden. In diesen Fällen sollten Benutzer den Wert nicht leer lassen. Je weniger Elemente es gibt, bei denen Metadaten für eine Spalte eingegeben wurden, die als Navigationsfilter dient, desto weniger nützlich ist die Navigation, da viele Elemente nie von einer Abfrage zurückgegeben werden.

Je mehr die Anzahl der Metadatenspalten zunimmt, desto weniger wahrscheinlich wird es, dass Benutzer Metadaten eingeben, und zwar aufgrund des Aufwands zu bestimmen, welche Spalten gelten, und anschließend einen Wert anzugeben. Wenn Sie mit vielen erforderlichen Spalten arbeiten, lässt die Benutzerakzeptanz ggf. nach, da es sehr lange dauert, Inhalte hochzuladen. In einem sehr offenen und zusammenarbeitsorientierten Umfeld kann dies von Nachteil sein. Doch je mehr der Nutzen der Inhalte und der Aufwand zunimmt, diese Inhalte zu erstellen, wird es wahrscheinlicher, dass Benutzer sich die Zeit nehmen, die entsprechenden Felder auszufüllen, insbesondere wenn dieser Vorgang eher selten ist.

In der Entwurfsphase sollten Sie prüfen, welche Metadaten für verbindliche Vorgänge und zum Abrufen von Daten erforderlich sind, ermitteln, wie lange Benutzer für das Eingeben dieser Metadaten brauchen, und die Auswirkung auf die Benutzer bestimmen. Wenn die Benutzer das System aufgrund des hohen Aufwands für das Erstellen von Inhalten nicht annehmen, kann es später schwierig werden, das System neu zu strukturieren.

Feldtypen und Vergleich zwischen Feldern mit einem und mehreren Werten

Ein Aspekt bei der Wahl der Spalten ist der Spaltentyp und ob dieser mehrere Werte haben soll. Abfragen anhand verwalteter Metadatenfelder sind effizienter als Abfragen anhand von Auswahlspalten, weshalb Sie erwägen sollten, verwaltete Metadatenfelder anstelle von Auswahlfeldern zu verwenden. Spalten, z. B. verwaltete Metadaten und Personen oder Gruppen, können mehrere Werte enthalten. Abfragen anhand von Spalten mit mehreren Werten sind nicht so effizient wie Abfragen anhand von Spalten mit einem Wert.

Spalten und Inhaltstypen sind meist die zentralen Komponenten zum Klassifizieren und Abfragen von Inhalten in einer umfangreichen Liste. Während des Planungsprozesses sollte eine Liste mit Spalten und Inhaltstypen bereits vorbereitet worden sein. Die Anzahl der Spalten und Inhaltstypen, die einer Liste hinzugefügt werden, kann sich auf schleichende Weise auf die Leistung auswirken. Die Anzahl von Spalten eines bestimmten Typs, die einer einzelnen Liste hinzugefügt werden, kann für einen Zeilenumbruch sorgen. Weitere Informationen finden Sie unter Zeilenumbrüche weiter oben in diesem Artikel.

Beispiel einer umfangreichen Liste und von Spalten: Bibliothek mit Produktspezifikationen

In diesem Abschnitt werden die Spalten beschrieben, die im folgenden Beispiel verwendet werden:

• Von SharePoint Server 2010 automatisch verwaltete Spalten: ID, Inhaltstyp, Geändert, Erstellt, Geändert von, Erstellt von, Dokument-ID

• Nach Anpassungen verwaltete Spalten:

  • Metadatenstandardwerte nach Ordner für Produkttyp und Produktteam (für jeden Produkttyp gibt es einen Ordner, und jeder Produkttypordner enthält mehrere Produktteamordner)

  • Workflowaktualisierung: Genehmigungsstatus, Projektabschlussdatum

• Von Benutzern verwaltete Spalten: Entwickler, Tester, Datum der letzten Überprüfung

• Für Navigationszwecke geeignete Spalten: Inhaltstyp, Produkttyp, Produktteam

• Für die Nachverfolgung des Status und auch für Navigationszwecke geeignete Spalten: Datum der letzten Überprüfung, Genehmigungsstatus, Projektabschlussdatum

• Für Navigationszwecke geeignete Spalten: Entwickler, Tester, Produktname, Geändert, Geändert von

Zusammenfassung der Empfehlungen für Spalten

• Minimieren Sie die Anzahl verfügbarer auszufüllender Spalten.

• Wählen Sie sorgfältig die Spalten aus, die für Systemprozesse und Navigation verwendet werden. Prüfen Sie, welche Felder erforderlich sein sollen, und minimieren Sie die Anzahl der Pflichtfelder.

• Pflichtfelder müssen verwendet werden, wenn sie für die Navigation benötigt werden, z. B. beim Verwenden von Webparts für Inhaltsabfragen für ein bestimmtes Feld. Sie müssen ebenfalls für Verwaltungszwecke verwendet werden, z. B. zum Angeben von Aufbewahrungsaktionen für ein Datumsfeld, das Benutzer bestimmen müssen.

• Da Abfragen anhand von Spalten mit einem Wert schneller als anhand von Spalten mit mehreren Werten sind, versehen Sie Spalten nach Möglichkeit mit einem Wert, es sei denn, mehrere Werte sind nötig.

Die Gesamtanzahl bestimmter Spalten in einer Liste kann einen Zeilenumbruch bewirken, was die Leistung mindert. Minimieren Sie nach Möglichkeit die Anzahl der Spalten für eine umfangreiche Liste, und vermeiden Sie Zeilenumbrüche.

Ordner

Das Organisieren von Inhalten in Ordnern, wofür es die drei folgenden primären Zwecke gibt, muss sorgfältig untersucht werden:

• Inhalte logisch in Ordnern organisieren. Sie können beispielsweise Verträge ausgehend vom Monat oder Jahr der Vertragsunterzeichnung oder Rechnungen anhand des Datums ihrer Ausstellung organisieren. In diesem Szenario können Benutzer einfach durch die Ordnerstruktur navigieren oder Dokumente mithilfe von Metadaten finden. Zudem wird die automatische Weiterleitung von Dokumenten in den ordnungsgemäßen Ordner vereinfacht. Die Inhaltsorganisation bietet Möglichkeiten zum Einschränken der Anzahl von Elementen in einem einzelnen Ordner, indem Unterordner erstellt werden, sobald beim Hinzufügen von Elementen ein bestimmter Grenzwert überschritten wird.

• Inhalte zu Aufbewahrungs-, Berechtigungs- oder anderen Verwaltungszwecken in Ordnern organisieren. Sie können beispielsweise einen Ordner für vertrauliche Dokumente, auf den nur wenige Benutzer Zugriff haben, oder für standortbasierte Aufbewahrungszwecke erstellen, damit Dokumente basierend auf ihrem Ordner einen unterschiedlichen Aufbewahrungszeitplan aufweisen. In diesem Szenario kann die Benutzernavigation schwieriger sein, da es die Benutzer ggf. nicht kümmert, wo ein Dokument sich befindet, solange sie Zugriff darauf haben. Die Metadatennavigation und Suchfunktion sind die Hauptmethoden zum Auffinden von Dokumenten und nicht so sehr die Ordnerstruktur.

• Inhalte zum Unterstützen der Benutzernavigation anhand von Themen oder Kategorien organisieren. Viele Benutzer sind gewohnt, durch Ordner zu navigieren. Bei bestimmten Anwendungen ist es ggf. wichtig, eine Ordnerstruktur beizubehalten, durch die die Benutzer einfach navigieren können. In diesem Szenario kennen Benutzer meist die Ordnerstruktur und wissen, wo Dokumente zu suchen und abzulegen sind. Die Metadatennavigation und Suchfunktion kann in Kombination mit dieser Methode verwendet werden.

Verbesserungen in SharePoint Server 2010 ermöglichen Ihnen beim Arbeiten mit Ordnern mehr Flexibilität und weniger Abhängigkeit von Leistungsaspekten. Unter Verwendung verwalteter Metadaten und der Metadatennavigation können Benutzer mühelos eine Filterung anhand von Metadaten durchführen, anstatt durch Ordner navigieren zu müssen. Dadurch können Sie Inhalte für Verwaltungszwecke, z. B. Berechtigungen und Richtlinien, anstatt nur für die Benutzernavigation organisieren. Sie können beispielsweise einen Ordner mit vertraulichem Inhalt einrichten, auf den nur bestimmten Mitarbeiter zugreifen dürfen, und einen anderen Ordner erstellen, auf den alle Mitarbeiter Zugriff haben. Sie können unterschiedliche Berechtigungen für die Ordner angeben und anschließend mithilfe der Inhaltsorganisation Inhalte basierend auf Metadaten automatisch in den entsprechenden Ordner verschieben. Neben der Metadatennavigation können Sie auch weiterhin Ordner für Navigationszwecke einsetzen.

Mithilfe der Inhaltsorganisation können Inhalte basierend auf Inhaltstypen und Metadaten automatisch in Ordner verschoben werden, ohne dass Benutzer festlegen müssen, wo Inhalte abgelegt werden sollen. Darüber hinaus ermöglicht diese Funktion auch das automatische Erstellen von Ordnern, wenn ein Ordner einen angegebenen Elementgrenzwert erreicht hat. Sie müssen berücksichtigen, dass Mit Explorer öffnen (WebDAV) bei umfangreichen Listen nicht funktioniert, wenn Elemente nicht in Ordnern organisiert sind, bei denen der Schwellenwert für die Listenansicht im Stamm eines beliebigen Ordners unterschritten wird.

Aus Leistungssicht sind ordner- und metadatenbasierte Ansichten vergleichbar. Aus logischer und Benutzersicht ist es sinnvoll, mit Ordnern zum Unterteilen von Inhalten zu arbeiten. Bei der Metadatennavigation erfolgen rekursive Abfragen, sodass alle Elemente außerhalb von Ordnern zurückgegeben werden. Wenn dies die Hauptmethode zum Abrufen von Inhalten sein sollte, ist die Ordnerstruktur ggf. nicht von Bedeutung.

Die folgende Abbildung zeigt die Ergebnisse eines Tests, bei dem verschiedene Ansichten für den Zugriff auf dieselbe Anzahl von Elementen verwendet wurden. Alle Ansichten gaben 1000 Ergebnisse zurück. In dieser Abbildung wird die Anzahl der Anforderungen pro Sekunde dieser Ansichten bei zunehmender Listengröße einzeln gezeigt. Die Ergebnisse verdeutlichen, dass die Leistungskurve der Ordner und indizierten Ansichten bei zunehmender Listengröße relativ flach bleibt, wenngleich Ordner bei kleineren Listengrößen eine bessere Leistung bieten. Bei den meisten umfangreichen Listen wird eine Kombination von Ordnern und indizierten Ansichten verwendet, sodass Leistungsunterschiede nicht diktieren, ob Ordner oder Indizes zum Abrufen von Daten verwendet werden.

Zusammenfassung der Empfehlungen für Ordner

• Planen Sie, wie Elemente in Ordnern organisiert werden sollen. Elemente können automatisch oder manuell verschoben werden.

• Features wie die Metadatennavigation machen es weniger erforderlich, die Menge von Elementen in Ordnern zu begrenzen.

• Verwenden Sie die Metadatennavigation in Kombination mit der Ordnernavigation. Dadurch können Ordner zum Verwalten von Richtlinien und der Aufbewahrung anstatt nur für die Organisation von Inhalten für den Abruf genutzt werden.

• Falls dadurch die beste Benutzerumgebung ermöglicht wird, erwägen Sie das Organisieren von Inhalten in Ordnern zur Unterstützung der Navigation, auch in Kombination mit anderen Navigationsoptionen.

• Erwägen Sie bei Verwenden der Inhaltsorganisation zum automatischen auf Metadaten basierenden Verschieben von Dokumenten in Ordner das Erstellen zusätzlicher Elemente in Unterordnern, wenn ein bestimmter Grenzwert erreicht ist.

• Wenn Sie vorhaben, Mit Explorer öffnen (WebDAV) zu verwenden, müssen Sie Elemente in Ordnern organisieren, deren Anzahl (auch bei Unterordnern) den Schwellenwert für die Listenansicht unterschreitet.

• Zum Abrufen von Inhalten in Listenansichten müssen Sie mit der Metadatennavigation und Indizes arbeiten, wenn Sie keine Ordner verwenden.

Beispiel einer umfangreichen Liste und von Ordnern: Bibliothek mit Produktspezifikationen

In der Bibliothek mit Produktspezifikationen dienen Ordner zur Unterstützung der Navigation und zum logischen Ablegen von Inhalten. Wenn Benutzer eine neue Produktspezifikation erstellen, wissen sie, welcher Ordner zu verwenden ist. Für jeden Produkttyp gibt es einen Ordner, und jeder Produkttyp weist mehrere Ordner für die einzelnen Produktteams auf. Jedes Produktteam hat einen Dokumentsatz für jedes zu entwickelnde Produkt, und die für ein Produkt spezifischen Dokumente werden im Dokumentsatz gespeichert. Dadurch entsteht eine Struktur, die wie folgt aussieht:

• Abfahrtsski – Produkttyp (Ordner)

  • Rennski – Produktteam (Ordner)

    Superschneller Downhill Racer X – Produkt (Dokumentsatz)

Sie können für jeden Ordner Metadatenstandards konfigurieren, sodass es für Benutzer der Bibliothek einfach ist, Inhalte mithilfe von Ordnern zu finden.

Beispiel eines Großarchivs und von Ordnern: Datenarchiv

Die Website Datenarchiv dient zum langfristigen Speichern von Elementen, die zur Vorschrifteneinhaltung aufbewahrt werden müssen, ohne dass ihr Inhalt aktiv geändert wird. In diesem Szenario werden Elemente automatisch in zwei Ordner geleitet: Eingeschränkt und Vertraulich. Der Ordner Eingeschränkt weist strenge Zugriffsbeschränkungen für eine kleine Anzahl von Personen und eine Aufbewahrungsdauer für Dokumente von zehn Jahren auf. Auf den Ordner Vertraulich dürfen mehr Benutzer zugreifen, und die Dokumente müssen sieben Jahre aufbewahrt werden. Dadurch kann die Anzahl eindeutiger Berechtigungen verringert und die Verwaltung von Berechtigungen vereinfacht werden, da für Elemente die Berechtigungen des entsprechenden Ordners gelten. Alle Elemente, die in die Website Datenarchiv gelangen, werden basieren auf Metadaten in den Stammordner bzw. die Ordner Eingeschränkt oder Vertraulich geleitet.

Indizes

Für eine Liste können einschließlich zusammengesetzter Indizes und SharePoint Server 2010-Features, mit denen Spalten anhand der Standardeinstellung indiziert werden, maximal 20 Indizes eingerichtet werden. Das Hinzufügen von Indizes zu einer Liste hat kaum Auswirkungen auf die Leistung, beeinflusst jedoch Hinzufüge- und Aktualisierungsvorgänge. Sie sollten nur so viele Indizes wie unbedingt nötig verwenden, da nicht verwendete Indizes die Leistung geringfügig beeinträchtigen, und einige SharePoint Server 2010-Features Indizes bei ihrer Aktivierung hinzufügen. Bei Verwenden der Ablauf- und eDiscovery-Features benötigt SharePoint Server 2010 mindestens drei der maximal 20 Indizes. Lassen Sie drei Indexpositionen für den Fall frei, dass Sie später neue Indizes erstellen müssen.

SharePoint Server 2010 nutzt beim Arbeiten mit der eigenen Datenbanktabellenstruktur eigene Indizierungsmechanismen. Erstellen Sie Indizes in SharePoint Server, indem Sie die Einstellungen für die Liste ändern.

Berücksichtigen Sie beim Planen von Indizes Folgendes:

• Indizes werden benötigt, um Listen zu filtern, deren Elementanzahl den Schwellenwert für die Listenansicht überschreitet.

• Beachten Sie beim Erstellen einzelner und zusammengesetzter Indizes den Grenzwert von 20 Indizes.

• Reservieren Sie Indexpositionen für SharePoint Server 2010-Features, die ggf. Spalten erstellen müssen, z. B. eDiscovery und Aufbewahrungszeiten im Rahmen der Informationsverwaltungsrichtlinie.

• Erstellen Sie Einzelindizes, wenn Sie ein einzelnes Feld zum Filtern mithilfe von Webparts für Inhaltsabfragen, Ansichten mit Filtern oder Metadatennavigationshierarchien und Filter verwenden, die häufig als Einzelfilter verwendet werden.

• Erstellen Sie zusammengesetzte Indizes für Abfragen, die eine Filterung mithilfe zweier Spalten durchführen und in der Regel einzeln mehr Elemente zurückgeben, als der Schwellenwert für die Listenansicht zulässt, aber gemeinsam selektiv sind.

• Indizes können sich negativ auf Vorgänge wie das Hinzufügen von Dokumenten oder Bearbeiten ihrer Eigenschaften auswirken. Erstellen Sie deshalb nur Indizes, sofern dies erforderlich ist.

Überlegtes Planen von Indizes

Für Listen gilt ein fester Grenzwert von 20 Indizes, und für umfangreiche Listen sind indizierte Spalten sehr wichtig. Aus diesem Grund müssen Sie einzelne und zusammengesetzte Indizes überlegt auswählen. Indizes werden von verschiedenen Features verwendet. Das Feature für die Metadatennavigation erstellt beispielsweise automatisch Indizes für konfigurierte Navigationshierarchien und Schlüsselfilter. Sie sollten Indizes für Spalten erstellen, die für Filtervorgänge in der Navigations- und Informationsinfrastruktur wichtig sind.

Automatisch erstellte Indizes

Von SharePoint Server-Features können Indizes erstellt werden, die für den Grenzwert von Listenindizes mitgezählt werden. Die folgende Tabelle enthält eine Liste mit in Dokumentbibliotheken gängigen SharePoint Server 2010-Features, die indizierte Spalten hinzufügen.

Spalte	Feature	Zweck
Halte- und Datensatzstatus	Direkte Datensatzverwaltung oder Haltebereichstatus und eDiscovery	Diese Spalte wird hinzugefügt und indiziert, wenn das Websitesammlungs-Feature Direkte Datensatzverwaltung oder das Feature Haltebereichstatus und eDiscovery aktiviert wird und ein Element als Datensatz deklariert oder in einer Liste mit einem Haltestatus versehen wird.
Ablaufdatum, Inhaltstyp	Informationsverwaltungsrichtlinie	Diese beiden Spalten werden hinzugefügt und indiziert, wenn die Informationsverwaltungsrichtlinie für die Aufbewahrung für einen Inhaltstyp aktiviert wurde, der der Liste hinzugefügt wurde, oder wenn die standortabhängige Aufbewahrung für eine Liste aktiviert wurde.

Gründe für das Erstellen einzelner und zusammengesetzter Indizes

Die Metadatennavigationsfunktion erstellt automatisch geeignete Indizes für die Hierarchie- und Schlüsselfilterspalten, die auf der Seite mit den Einstellungen für die Metadatennavigation ausgewählt werden. Einzelindizes werden für alle Hierarchiestrukturfelder und für einige der selektiveren Schlüsselfiltertypen erstellt, damit indizierte und Teilergebnisse zurückgegeben werden können, falls diese allein verwendet werden. Zusammengesetzte Indizes werden für alle unterstützten Kombinationen von Hierarchien und Schlüsselfilter gemeinsam unterstützt, um die Selektivität zu maximieren, wenn sowohl ein Strukturfilter- als auch ein Schlüsselfilterwert verwendet werden.

Wenn es in einer Liste zahlreiche Spalten gibt, anhand derer eine Filterung erfolgen soll, müssen Sie Indizes ggf. manuell verwalten, um das Erreichen des Indexgrenzwerts zu verhindern. Wenn besondere Kombinationen von Navigationshierarchien und Schlüsselfiltern nie verwendet werden, sollten Sie u. U. keine zusammengesetzten Indizes erstellen, um die Anzahl der Indizes zu verringern. Beim Erstellen dieser Indizes sollten Sie eine Einzelindizierung für Spalten auswählen, die selektiv sind und in der Listenansicht allein verwendet werden können, entweder als einziger Filter oder als erster Filter, der angewendet wird, bevor ein weiterer ausgewählt wird. Zusammengesetzte Indizes sollten eingesetzt werden, wenn zwei Filter zumeist gemeinsam für die Metadatennavigation oder benutzerdefinierte Abfragen verwendet werden und wenn ein Index allein nicht selektiv genug ist. Erstellen Sie Indizes für Spalten, die zum Filtern mithilfe von Listenansichten, Webparts und anderer Datenzugriffsmethoden verwendet werden.

Es kann vorkommen, dass mehrere Indizes nicht von Nutzen sind. Angenommen, Sie führen anhand der beiden Spalten "Abteilung" und "Inhaltstyp" einen Filtervorgang durch. Da dies ein Vorgang mit dem Operator UND ist, wird nur die Schnittmenge der Übereinstimmungen für "Abteilung" und "Inhaltstyp" zurückgegeben. Wenn diese Abfrage erfolgt, werden zunächst alle Elemente zurückgegeben, die dem Filter "Abteilung" entsprechen. Anschließend werden diese Elemente anhand von "Inhaltstyp" gefiltert. Wenn es für eine bestimmte Abteilung nur zehn übereinstimmende Elemente gibt, ist die Datenmenge ausreichend klein genug, weshalb ein Index für "Inhaltstyp" nicht erforderlich ist. Wenn es allerdings Tausende von Elementen gibt, die dem Wert für "Abteilung" entsprechen, muss ein zusammengesetzter Index verwendet werden.

Zusammengesetzte Indizes ermöglichen das Erstellen eines Index für zwei Spalten, wodurch effizientere Abfragen ermöglicht werden. Zusammengesetzte Indizes sollten verwendet werden, wenn ein Vorgang vom Typ UND auf zwei Spalten angewendet wird. Die Metadatennavigation ist das einzige SharePoint Server-Standardfeature, das mit zusammengesetzten Indizes arbeitet. Bei Aktivierung der Metadatennavigation wird Wiederholungs- und Fallbacklogik verwendet, auch wenn keine Metadatennavigations-Steuerelemente für die Liste konfiguriert sind. Zusammengesetzte Indizes werden von Ansichten nur verwendet, wenn es sich um eine Metadatennavigationsabfrage handelt.

Auswirkungen von Indizes auf die Leistung

Indizes werden benötigt, um Listen abzufragen, deren Elementanzahl den Schwellenwert für die Listenansicht in einem einzelnen Container überschreitet, und können außerdem für eine signifikante Leistungsverbesserung sorgen. Wenngleich Indizes für effiziente Abfragen umfangreicher Listen erforderlich sind und die Abfrageleistung steigern, können sie auf andere Vorgänge nachteilige Auswirkungen haben, da der Index gepflegt werden muss. Wenn Elemente erstellt, aktualisiert oder gelöscht werden, müssen die Indizes, zu denen das Element gehört, ebenfalls aktualisiert werden. Für eine Liste mit 10.000 Elementen wurden Hochlade-, Aktualisierungs- und Löschvorgänge durchgeführt. Die Ergebnisse zeigten, dass die Auswirkungen von 0 bis 20 Indizes weniger als 10 % betrugen.

Indexerstellung

Die Metadatennavigationsfunktion erstellt standardmäßig einzelne und zusammengesetzte Indizes. Auf der Seite mit den Einstellungen für die Metadatennavigation können Sie diese Option deaktivieren. Die Metadatennavigationsfunktion erstellt automatisch einen Einzelindex für jeden unterstützten Spaltentyp und zusammengesetzte Indizes für jede unterstützte Kombination von Navigationshierarchien und Schlüsselfiltern. Zusammengesetzte Indizes werden nicht automatisch für Kombinationen von zwei Schlüsselfiltern erstellt, wenngleich diese manuell erstellt werden können. Die Metadatennavigationsfunktion erstellt auch automatisch einzelne und zusammengesetzte Indizes für die meisten Spaltentypen, die Indizes unterstützen. Einzelindizes werden nicht automatisch für Schlüsselfiltertypen erstellt, die weniger Werte haben und ggf. allein nicht selektiv genug sind. Dazu zählen Ja/Nein-Spalten, Optionen mit einem Wert und Inhaltstypspalten. Indizes werden jedoch unterstützt und können manuell erstellt werden.

Unterstützte Spalten für Einzelindizes

Die folgende Tabelle enthält Informationen zu Indizes, die von der Metadatennavigationsfunktion automatisch erstellt werden. Diese Funktion erstellt Einzelwertindizes für alle Spalten, die das Erstellen eines Index unterstützen.

Spaltentyp	Index erstellt?
Navigationshierarchien
Verwaltete Metadaten mit einem Wert	Ja
Verwaltete Metadaten mit mehreren Werten	Nein (vom System als mehrere Werte indiziert)
Inhaltstyp-ID	Ja
Einzelwertoption	Ja
Ordner	Nein (vom System nach Ordner indiziert)
Schlüsselfilter
Verwaltete Metadaten mit einem Wert	Ja
Verwaltete Metadaten mit mehreren Werten	Nein (vom System als mehrere Werte indiziert)
Inhaltstyp-ID	Nein (kann manuell erstellt werden)
Einzelwertoption	Nein (kann manuell erstellt werden)
Option mit mehreren Werten	Nein (wird nicht als indiziert unterstützt)
Zahl	Ja
Datum	Ja
Ja/Nein	Nein (kann manuell erstellt werden)
Währung	Ja
Benutzer (Einzelwert)	Ja
Benutzer (mehrere Werte)*	Nein (vom System als mehrere Werte indiziert)
Alle Tags	Nein (vom System als mehrere Werte indiziert. Spezialfilter für alle verwalteten Metadatenwerte im Element)

Zusammengesetzte Indizes, die automatisch erstellt werden

Mithilfe der Metadatennavigationsfunktion können Benutzer eine Navigationshierarchie und einen Schlüsselfilter gemeinsam auswählen. Die Metadatennavigationsfunktion erstellt automatisch zusammengesetzte Indizes für alle unterstützten Kombinationen von Navigationshierarchien und Schlüsselfiltern. Die folgende Tabelle enthält die unterstützten Kombinationen.

Navigationshierarchien	Verwaltete Metadaten mit einem Wert	Verwaltete Metadaten mit mehreren Werten	Inhaltstyp-ID	Einzelwertoption	Ordner
Schlüsselfilter
Verwaltete Metadaten mit einem Wert	Ja	Nein	Ja	Nein	Nein
Verwaltete Metadaten mit mehreren Werten	Nein	Nein	Nein	Nein	Nein
Inhaltstyp-ID	Ja	Nein	Nein	Nein	Nein
Einzelwertoption	Nein	Nein	Nein	Nein	Nein
Option mit mehreren Werten	Nein	Nein	Nein	Nein	Nein
Zahl	Ja	Nein	Ja	Nein	Nein
Datum	Ja	Nein	Ja	Nein	Nein
Benutzer (Einzelwert)	Ja	Nein	Ja	Nein	Nein
Alle Tags	Nein	Nein	Nein	Nein	Nein
Ja/Nein	Ja	Nein	Ja	Nein	Nein
Währung	Ja	Nein	Ja	Nein	Nein
Benutzer (mehrere Werte)*	Nein	Nein	Nein	Nein	Nein

Metadatenselektivität

Mit zunehmender Listengröße gewinnt die Selektivität der Metadaten an Bedeutung. Die folgenden Empfehlungen gelten für alle Listengrößen, sind bei kleineren Listen jedoch nicht so entscheidend.

Unter Selektivität ist die Menge von Elementen zu verstehen, die für die Rückgabe von Ergebnissen auf eine Abfrage berücksichtigt werden müssen. Hierbei wird unterschieden zwischen der tatsächlichen Selektivität (der Gesamtanzahl von Ergebnissen, die mit der Suchbedingung einer Abfrage übereinstimmen) und der eingeschränkten Selektivität (der Anzahl von Ergebnissen, die berücksichtigt werden müssen, nachdem Bedingungen angewendet wurden, die für indizierte Spalten gelten). Die tatsächliche Selektivität ist der Hauptaspekt hinsichtlich der Benutzerumgebung. Die eingeschränkte Selektivität ist der Hauptaspekt in Bezug auf die Auswirkung auf die Instanz von SQL Server.

Für eine effektive Nutzung der Metadatennavigation und anderer Listenfiltermechanismen müssen die für die Filterung verwendeten Metadaten selektiv sein. In der Listenansicht werden standardmäßig 30 Elemente angezeigt, sodass Benutzer die Ergebnisse schnell durchsuchen können, um das Gesuchte zu finden. Wenn Abfragen mehr als 30 Ergebnisse liefern, muss der Benutzer mehrere Seiten nach Ergebnissen durchsuchen. Bei Verwenden eines Webparts für Inhaltsabfragen werden meist 10 bis 15 Ergebnisse zurückgegeben. Gibt es mehr Ergebnisse, werden die weiteren Ergebnisse nicht angezeigt. Wenn eine Abfrage Hunderte von Ergebnissen zurückgibt, wird es schwierig, das Gesuchte zu finden. Die Selektivität ist ferner wichtig zum Verhindern von Vorgängen, bei denen der Schwellenwert für die Listenansicht überschritten wird, was bei der Metadatennavigation zu Fallbackabfragen und zur nicht vollständigen Rückgabe von Ergebnissen führt.

Inhaltsorganisation und automatisches Ausgleichen

Die Inhaltsorganisationsfunktion kann als zentrale Komponente zum Organisieren von Inhalten in einem Dokumentrepository dienen. Mit der Inhaltsorganisation arbeitende Repositorys verfügen über eine Übermittlungsumgebung, in die Benutzer fertig gestellte Dokumente hochladen. Es folgen Beispielszenarien, in denen die Inhaltsorganisation zum Einsatz kommen kann:

• Automatisches Weiterleiten von Dokumenten zwischen und innerhalb von Websites basierend auf Metadaten

• Automatisches Weiterleiten von Dokumenten und Erstellen neuer Ordner, z. B. basierend auf Tag, Monat oder Jahr

• Automatisches Ausgleichen der Anzahl von Elementen in Ordnern

Datenzugriff und -abruf

Der Hauptzweck umfangreicher Listen ist das Speichern abrufbarer Inhalte. Zunächst muss bestimmt werden, wie Benutzer Inhalte abrufen werden, da dies die weitreichendsten Auswirkungen auf die Leistung und den Erfolg der Implementierung umfangreicher Listen hat. Mehrere Features wie die Suchfunktion, Metadatennavigation, Webparts für Inhaltsabfragen und Ansichten können zum Abrufen von Inhalten genutzt werden. Benutzerdefinierte Lösungen, z. B. benutzerdefinierte Webparts zum Abfragen von Daten, kommen ebenfalls häufig zum Einsatz. Planen Sie vorausschauend, wie die Website organisiert sein soll. Sie können mit einer zentralen Angebotsseite arbeiten, z. B. der Startseite der Website Dokumentcenter, um Inhalte zu präsentieren und Einstiegspunkte in die umfangreiche Liste bereitzustellen. Sie können auch Veröffentlichungsseiten verwenden, um eine Website zu erstellen, auf der verschiedene Themen auf den jeweiligen Seiten behandelt werden, und dann mithilfe von Webparts verwandte Dokumente oder Elemente aus der umfangreichen Liste zu extrahieren. Für den Datenzugriff und -abruf müssen u. a. die folgenden Aspekte berücksichtigt werden:

• Beliebige Kombinationen aus Suchfunktion, Webparts für Inhaltsabfragen, Metadatennavigation, Listenansichten und benutzerdefinierten Webparts können verwendet werden.

• Planen Sie vorausschauend, wie Inhalte abgerufen werden und welche Spalten zum Filtern und Sortieren verwendet werden sollen.

• Planen Sie überlegt das grundlegende Seitenmodell. Überlegen Sie, ob die gesamte Arbeit in der Dokumentbibliothek erfolgt oder ob es eine Angebotsseite oder ein mehrseitiges Modell geben soll, das Verknüpfungen mit verwandten Inhalten herstellt.

Datenzugriffsmethoden

Es gibt drei SharePoint Server 2010-Hauptfeatures, mit deren Hilfe Listendaten bei einfacher Konfiguration abgefragt und gefiltert werden können: Listenansicht mit Metadatennavigation, Webpart für Inhaltsabfragen und Suchfunktion. Es gibt noch weitere Möglichkeiten zum Arbeiten mit benutzerdefiniertem Code zum Abfragen einer Liste, die aber in diesem Artikel nicht behandelt werden.

• Für Listendaten gibt es verschiedene Anzeigemethoden. Ansichten ermöglichen das Konfigurieren der anzuzeigenden Spalten, und Ansichten können zum Filtern und Sortieren von Ergebnissen basierend auf Spalten konfiguriert werden.

  • Die Metadatennavigation ist eine Filterungssteuerung für SharePoint Server 2010-Listenansichten. Bei konfigurierter Metadatennavigation können Sie Metadatenhierarchien und Schlüsselfilter auswählen, um die in einer Listenansicht angezeigten Ergebnisse dynamisch zu filtern.

• Mithilfe des Webparts für Inhaltsabfragen können SharePoint Server 2010-Listendaten angezeigt werden. Sie können Abfragen konfigurieren, die Ergebnisse aus einer oder mehreren Listen zurückgeben. Das Webpart für Inhaltsabfragen arbeitet standardmäßig mit einer Zwischenspeicherung, die aber deaktiviert werden kann.

• Suchfelder oder Webparts für Suchergebnisse dienen zum Zurückgeben von Suchergebnissen. Sie können diese Ergebnisse auf eine bestimmte Liste beschränken und mithilfe von Suchsteuerelementen für die Metadatenoptimierung eine geführte Suche durchführen.

In der folgenden Tabelle werden Abfragemethoden und ihre Zwecke vorgestellt.

Abfragemethode	Zweck
Listenansicht und Metadatennavigation	Listenansichten greifen stets auf die SQL Server-Back-End-Datenbank zu, was zu Abfragen mit den größten Leistungsbeeinträchtigungen und einer höheren SQL Server-Verarbeitungslast führt. Verwenden Sie Listenansichten, um mehr Optionen für die Interaktion mit Dokumenten (Einchecken, Auschecken, Bearbeitungseigenschaften) und einen Echtzeitzugriff auf Daten bereitzustellen.
Webpart für Inhaltsabfragen	Webparts für Inhaltsabfragen verwenden zum Zwischenspeichern von Abfragen den Anbieter der Struktur der Portalwebsite und rendern den wenigsten HTML-Code, was zu schnelleren Abfrage- und Renderzeiten führt. Setzen Sie Webparts für Inhaltsabfragen für eine dynamische Navigation und die Ausführung mehrerer Abfragen auf einer einzelnen Seite ein.
Webpart für Inhaltsabfragen (ohne Zwischenspeicherung)	Für einen Zugriff auf Daten in Echtzeit kann das Webpart für Inhaltsabfragen die Datenbank direkt abfragen. Wählen Sie diese Konfiguration, wenn die Abfrage nicht zwischengespeichert werden kann, wenn Aktualisierungen in Echtzeit erforderlich sind, und für Seiten, auf die weniger als einmal pro Stunde zugegriffen wird, sodass der Cache nie aufgefüllt wird. Die anfängliche Verarbeitungslast eines zwischengespeicherten Webparts für Inhaltsabfragen erzeugt zusätzlichen Verarbeitungsaufwand.
Suchfunktion	Arbeiten Sie mit Suchabfragen, um Lesevorgänge in eine Serverinfrastruktur abzuladen, die einfacher zu skalieren und für Leseleistung optimiert ist. Suchabfragen können als statisch konfiguriert werden. Sie können aber auch den Benutzern erlauben, Suchabfragen anzugeben.

Webparts für Inhaltsabfragen

In der folgenden Tabelle werden die Vor- und Nachteile von Webparts für Inhaltsabfragen vorgestellt.

Vorteile

Nachteile

Gute Eignung als Navigationskomponente, z. B. als Verknüpfung zu verwandten Dokumenten oder Seiten. Einfache Konfiguration zum Anzeigen verschiedener Spalten. Mehrere Webparts für Inhaltsabfragen können problemlos auf einer Seite verwendet werden. Schnellste Renderzeit im Vergleich zu Suchfunktion und Listenansichten. Standardmäßige Zwischenspeicherung zur Reduzierung der SQL Server-Verarbeitungslast.

Nur eine begrenzte Anzahl von Eigenschaften kann angezeigt werden. Verknüpfungen führen direkt nur zu Elementen wie dem Dokument, der Seite oder dem Listenelement selbst. Es können keine Aktionen auf die Liste angewendet werden.

Das Webpart für Inhaltsabfragen dient zum Abrufen von Inhalten aus Listen und kann für Seiten, Dokumente und Listenelemente verwendet werden. Webparts für Inhaltsabfragen werden zwischengespeichert, was zu einer besseren Leistung und weniger Belastung von SQL Server-Ressourcen führt. Die standardmäßige Cacheeinstellung ist 30 Minuten, weshalb Daten relativ aktuell bleiben. Dies bedeutet allerdings auch, dass das Webpart für Inhaltsabfragen mehr SQL Server-Ressourcen als Suchabfragen benötigt. Da Webparts für Inhaltsabfragen den wenigsten HTML-Code rendern, werden Seiten schneller gerendert, und mehrere Webparts für Inhaltsabfragen können auf einer einzelnen Seite konfiguriert werden. Bei zunehmender Listengröße bieten zwischengespeicherte Webparts für Inhaltsabfragen einen schnellen Datenzugriff.

Webparts für Inhaltsabfragen sollten als Navigationskomponenten und zum Bereitstellen von Inhaltsrollups auf Seiten verwendet werden. Sie können beispielsweise mithilfe von Seiten Übersichten zu Inhalten in einer Dokumentbibliothek bieten und anschließend mit Webparts für Inhaltsabfragen verwandte Seiten und Dokumente zurückgeben. Andere Beispiele sind Elemente, die vom aktuellen Benutzer geändert wurden, die neuesten Elemente und die am höchsten eingestuften Elemente. Das Webpart für Inhaltsabfragen kann in Szenarien mit vielen Lesevorgängen verwendet werden, in denen die meisten Benutzer keine Aktionen wie Einchecken, Auschecken und Versionsverwaltung auf Listen anwenden. Die folgende Abbildung zeigt ein Webpart für Inhaltsabfragen, das die am höchsten eingestuften Dokumente zeigt.

Das Webpart für Inhaltsabfragen dient für den Zugriff auf Inhalte, ohne eine Listenansicht zu öffnen, wenn Benutzer beispielsweise eine kleine Menge von Inhalten, auf die sie oft zugreifen, oder Elemente haben, die sie nachverfolgen möchten. Für die Websitevorlage Dokumentcenter werden drei Webparts für Inhaltsabfragen standardmäßig verwendet: eines, das vom angemeldeten Benutzer geänderte Elemente zurückgibt, ein zweites für die am höchsten eingestuften Dokumente und ein drittes für die neuesten Dokumente. In Kombination stellen diese drei Webparts für Inhaltsabfragen eine Angebotsseite mit Inhalten bereit, auf die Benutzer ggf. häufig zugreifen bzw. an denen sie am meisten interessiert sind. Dies fördert das Auffinden neuer Inhalte und den schnellen Zugriff auf häufig verwendete Dokumente. Ein weiteres Beispiel ist das Erstellen einer Favoritenliste, mit deren Hilfe Benutzer nachzuverfolgende Inhalte markieren können, und das anschließende Verwenden eines Webparts für Inhaltsabfragen zum Zurückgeben der Favoritenliste, damit Benutzer schnell auf häufig verwendete Inhalte zugreifen können, ohne auf die Liste selbst zugreifen zu müssen.

Bei Verwenden eines Webparts für Inhaltsabfragen mit einer umfangreichen Liste müssen verschiedene Aspekte beachtet werden, damit Ergebnisse ordnungsgemäß zurückgegeben und nicht vom Schwellenwert für die Listenansicht blockiert werden. Mittels einer indizierten Spalte müssen Elemente zu einer Menge gefiltert werden, die kleiner als der Schwellenwert für die Listenansicht ist. Listenübergreifende Abfragen werden nicht empfohlen, wenn eine der Listen eine umfangreiche Liste ist. Wenn die Gesamtanzahl der in der listenübergreifenden Abfrage berücksichtigten Elemente den Schwellenwert für die Listenansicht für Auditoren und Administratoren überschreitet (standardmäßig 20.000), wird der Vorgang blockiert.

Zusammenfassung der Empfehlungen für Webparts für Inhaltsabfragen

• Wählen Sie Webparts für Inhaltsabfragen, um Elemente zurückzugeben, auf die Benutzer häufig zugreifen, an denen sie interessiert sein könnten oder die Benutzer beim Entdecken von Inhalten helfen können.

• Wenn Sie ein Webpart für Inhaltsabfragen auf eine umfangreiche Liste anwenden, müssen Sie Elemente filtern, damit die Abfrage nicht den Schwellenwert für die Listenansicht überschreitet.

• Sie dürfen nur Spalten mit Indizes für die Filterung verwenden.

• Verwenden Sie das Webpart für Inhaltsabfragen nicht, um mehrere Listen abzufragen, wenn die Gesamtanzahl der Elemente den Schwellenwert für die Listenansicht für Auditoren und Administratoren (standardmäßig 20.000) überschreitet.

• Arbeiten Sie mit Zwischenspeicherung, um Ladezeiten zu beschleunigen und die SQL Server-Verarbeitungslast zu verringern.

Suchwebparts

In der folgenden Tabelle werden die Vor- und Nachteile von Suchwebparts vorgestellt.

Vorteile

Nachteile

Abladung von Abfragen von Computern mit SQL Server auf Suchserver, die einfacher zu skalieren sind. Suchabfrage- und Indexserver sind besser skalierbar und bieten eine bessere Leistung als das direkte Abfragen von SQL Server. Ergebnisse basieren auf einer Volltextsuche von Dokumenten anstatt nur auf Metadaten. Textzusammenfassungen liefern mehr Informationen zu Ergebnissen als Webparts für Inhaltsabfragen.

Ergebnisse sind am wenigsten aktuell (nur bis zum Datum der letzten Durchforstung). In den Ergebnissen werden keine Spaltenwerte angezeigt. Es können keine Aktionen auf Listen angewendet werden.

Suchabfragen bieten eine bessere Skalierbarkeit als Direktzugriffe auf SQL Server-Ressourcen, da die Suchfunktion für Szenarien mit zahlreichen Lesevorgängen optimiert ist. Es ist einfacher, mehrere Suchindex- und Abfrageserver horizontal als SQL Server-Instanzen vertikal zu skalieren. Um Benutzer bei der Inhaltsabfrage zu unterstützen, können Sie vorkonfigurierte Suchwebparts, Suchfelder oder eine Kombination davon verwenden. Suchabfragen bieten eine Möglichkeit zum Abladen von Abfragen an Suchindizes, wodurch die SQL Server-Verarbeitungslast gesenkt wird. Suchabfragen sind im Vergleich zu Webparts für Inhaltsabfragen oder Listenansichtsabfragen weniger von der Listengröße betroffen.

Sie können die Suchfunktion in beliebigen Szenarien verwenden, um Ergebnisse vorkonfigurierter oder vom Benutzer angegebener Abfragen anzuzeigen. Die Suchfunktion bietet die beste Leistung in großen Szenarien. Sie sollte nicht verwendet werden, wenn Listenaktionen auf Elemente angewendet oder Daten in Echtzeit angezeigt werden müssen, da die Ergebnisse immer nur so aktuell wie zum Zeitpunkt der letzten Durchforstung sind. Die folgende Tabelle enthält die drei zur Verfügung stehenden Suchwebparts.

Suchwebpart	Beschreibung
Webpart "Kernergebnisse der Suche"	Das umfassendste Webpart mit vollständigen Ergebnissen mit Seitenzahlen, das für vom System oder Benutzer angegebene Abfragen verwendet werden kann.
Webpart "Ergebnisse der Partnersuche"	Eine kleine Ergebnismenge mit einem optionalen Link für den Zugriff auf die vollständigen Ergebnisse.
Suchfeld-Webpart	Ein Webpart, das Benutzereingaben für eine Abfrage verwendet.

Listenansichten

In der folgenden Tabelle werden die Vor- und Nachteile von Listenansichten vorgestellt.

Vorteile	Nachteile
Aktionen in Listenansichten wie Einchecken, Auschecken und Bearbeiten von Eigenschaften können zur Interaktion mit Dokumenten verwendet werden. Einfaches Anpassen von Ansichten und Anzeigen verschiedener Spalten. Überaus interaktive Umgebung für eine dynamische Filterung und Sortierung von Ergebnissen in Echtzeit.	Die größten negativen Auswirkungen auf die Leistung (längere Wartezeiten, niedrigerer Durchsatz). Langsamste Renderzeit Die beste Benutzerumgebung liegt bei nur einem Listenansichts-Webpart pro Seite vor.

Listenansichten und Metadatennavigation können den Abruf von Inhalten in umfangreichen Dokumentbibliotheken unterstützen, die Ordner und Indizes oder beides aufweisen. Das Abfragen mithilfe einer Listenansicht erfolgt in Echtzeit. Dabei wird die SQL Server-Datenbank direkt abgefragt. Dies liefert die neuesten Ergebnisse, hat aber die negativste Auswirkung auf die Leistung. Bei umfangreichen Listen nimmt der Durchsatz von Vorgängen ab und die Wartezeit zu. Listenansichten rendern außerdem den meisten zu ladenden Inhalt für eine Seite. Deshalb ist die Seitenrenderzeit bei einer Listeansicht häufig länger.

Sie sollten mit Metadatennavigation und Listenansichten arbeiten, wenn Sie Listenansichtsaktionen auf Elemente anwenden können müssen. Bei einem Szenario mit wenigen Lesevorgängen können Listenansichten die Hauptmethode für das Arbeiten mit einer Liste darstellen. In Szenarien mit zahlreichen Lesevorgängen sollten Sie ggf. andere Abfragemethoden als Hauptmethode für den Zugriff auf Listendaten erwägen.

Ansichtskonfiguration

Zusammenfassung der Empfehlungen für die Ansichtskonfiguration

• Wählen Sie die Spalten in Ansichten überlegt aus. Je mehr Spalten, desto mehr zu rendernde Daten, wodurch sich die Seitenladezeit verlängert. Zwischen der Seitenladezeit und optimalen Benutzerumgebung muss ein Kompromiss gefunden werden.

• Minimieren Sie die Anzahl von Nachschlagespalten, z. B. verwaltete Metadaten und Personen und Gruppen in Ansichten, da dies zu Verknüpfungen mit anderen Datenbanktabellen führt und die Datenbanklast erhöht.

• Verwenden Sie in Spalten keine Gesamtanzahlen.

• Wenn Elemente nicht mithilfe indizierter Spalten gefiltert werden, wählen Sie die Option Alle Elemente in Ordnern anzeigen aus, und vergewissern Sie sich, dass die Anzahl der Elemente in den einzelnen Ordnern den Schwellenwert für die Listenansicht nicht überschreitet.

• Ansichten müssen anhand indizierter Spalten gefiltert werden, um die Anzahl der zurückgegebenen Elemente so zu verringern, dass die Anzahl unter dem Schwellenwert für die Listenansicht liegt (insbesondere, wenn keine Unterordner vorhanden sind oder Ordner mehr Elemente enthalten, als der Schwellenwert für die Listenansicht zulässt).

• Aktivieren Sie die Metadatennavigationsfunktion, um die neuesten Ergebnisse für Abfragen zurückzugeben, die andernfalls durch den Schwellenwert für die Listenansicht blockiert würden. Diese Funktion ist standardmäßig für nahezu alle Websites aktiviert.

• Wenn Sie gefilterte Ansichten in Kombination mit der Metadatennavigation nutzen, erwägen Sie standortbezogene Ansichten, um ungefilterte Ansichten für Metadatennavigationskriterien zu erstellen, damit alle Ergebnisse zurückgegeben werden.

Anzahl der Spalten und Nachschlagespalten

Ansichten sind die gängigste Methode für den Zugriff auf Listendaten und sollten überlegt ausgewählt werden, um das Auffinden von Informationen für die Benutzer zu optimieren und Leistungsanforderungen zu erfüllen. Widmen Sie bei einer umfangreichen Liste der Konfiguration von Ansichten besondere Aufmerksamkeit. Empfohlen werden ausschließlich Standard- und benutzerdefinierte Ansichten. Datenblatt-, Gantt- und Kalenderansichten werden nicht für Listen empfohlen, da sie vom Schwellenwert für die Listenansicht blockiert werden können. Ansichten sollten so wenige Spalten wie möglich aufweisen. Achten Sie besonders auf die Anzahl von Nachschlagespalten (verwaltete Metadaten, Personen und Gruppen sowie Nachschlagetypen), da bei Nachschlagevorgängen Verknüpfungen mit anderen Tabellen erfolgen, was die Leistung mindert.

Spaltenfilterung und Gesamtanzahlen

Der neue Schwellenwert für die Listenansicht in SharePoint Server 2010 stellt für die Verwendung von Ansichten mit umfangreichen Listen eine wichtige Veränderung dar. Benutzer erhalten eine Fehlermeldung, wenn in Ansichten versucht wird, mehr Ergebnisse zurückzugeben, als der Schwellenwert für die Listenansicht zulässt. Gesamtanzahlen in einer umfangreichen Liste werden stets vom Schwellenwert für die Listenansicht blockiert, weshalb Sie darauf verzichten sollten. Wichtig ist die Anzahl der zu durchsuchenden Elemente, nicht unbedingt die Anzahl der zurückgegebenen Zeilen. Wenn eine Ansicht einen Filter aufweist, bei dem die Farbe "Rot" ist und "Farbe" keine indizierte Spalte ist, kann dieser Vorgang verhindert werden. Selbst wenn es nur 100 Elemente gibt, die dieser Abfrage entsprechen, muss die Abfrage bei 10.000 Listenelementen 10.000 Elemente durchsuchen. In diesem Fall erhalten Benutzer eine Fehlermeldung, wenn sie versuchen, auf die Ansicht zuzugreifen. Zum Vermeiden dieses Problems können Sie auf Ordner, Filter und die Indizierung sowie die Metadatennavigation zurückgreifen.

Ordner

Wenn eine Liste so organisiert ist, dass kein Ordner mehr Elemente enthält, als der Schwellenwert für die Listenansicht zulässt, können Sie die Option Alle Elemente in Ordnern anzeigen auswählen. Das Anzeigen aller Elemente außerhalb von Ordnern sollte vermieden werden, es sein denn, es gibt Vorkehrungen, die bewirken, dass die Ergebnisse auf eine Größe gefiltert wird, die den Schwellenwert für die Listenansicht unterschreitet.

Indizierung

In einem früheren Beispiel trat beim Abfragen der Spalte "Farbe" ein Fehler auf, da sie nicht indiziert war. Zum Beheben dieses Problems kann die Spalte "Farbe" indiziert werden, woraufhin Abfragen funktionieren, da die Werte eindeutig genug sind. Bei nur 100 roten Elementen, funktioniert der Vorgang. Wenn es jedoch mehr übereinstimmende Elemente gibt, als der Schwellenwert für die Listenansicht zulässt, erfolgt selbst bei einer Indizierung eine Blockierung. Standardmäßig werden im System das Feld ID, die Ordnerstruktur und Nachschlagevorgänge mit mehreren Werten indiziert. Neu erstellte Spalten, die für die Filterung verwendet werden, benötigen manuell erstellte Indizes.

Beispielansichten

Kürzlich geänderte Dateien

Die Ansicht Kürzlich geänderte Dateien dient zum Anzeigen der zuletzt geänderten Elemente und kann für die Standardansicht verwendet werden, wenn Benutzer häufig auf Inhalte aus einer Vielzahl von Quellen zugreifen, die kürzlich geändert wurden. Diese Ansicht kann einfach konfiguriert werden, da sie mit Systemmetadaten arbeitet, die stets für jedes Element festgelegt werden. Bei einer umfangreichen Liste müssen Sie entweder den Elementgrenzwert auf einen Wert unter dem Schwellenwert für die Listenansicht festlegen oder die Ergebnisse auf einen Wert filtern, der kleiner als der Schwellenwert für die Listenansicht ist. Zum Erstellen dieser Ansicht müssen Sie das geänderte Feld indizieren und in absteigender Reihenfolge sortieren. Geben Sie einen Filter für die Spalte Geändert an, und verwenden Sie die Formel [Heute-x], wobei x die Daten der gewünschten Anzahl von Tagen ist. Wählen Sie die Option Größer oder gleich. Die Formel [Heute-x] muss eine Elementanzahl zurückgeben, die unter dem Schwellenwert für die Listenansicht liegt.

Meine Elemente

Die Ansicht Meine Elemente kann in Repositorys verwendet werden, in denen Benutzer häufig auf ihre eigenen Dokumente zugreifen. Diese Ansicht kann einfach konfiguriert werden, da sie mit Systemmetadaten arbeitet, die stets für jedes Element festgelegt werden. In dieser Ansicht erfolgt eine Filterung nach der Spalte Geändert von oder Erstellt von oder nach beiden Spalten. Wählen Sie zum Erstellen dieser Ansicht in den Filter die Spalte Geändert von aus, legen Sie den Wert auf [ICH] fest, und legen Sie anschließend einen zweiten Filter mit ODER für die Spalte Erstellt von ebenfalls mit dem Wert [ICH] fest. Die Spalte Erstellt von muss zusätzlich zur Spalte Geändert von verwendet werden, wenn mehrere Benutzer dieselben Dokumente bearbeiten. Geändert von ist keine Spalte für mehrere Benutzer. Demzufolge werden in dieser Ansicht nicht alle Dokumente angezeigt, die ein Benutzer jemals bearbeitet hat. In diesem Beispiel müssen beide Spalten indiziert werden, da es sich um einen Vorgang vom Typ ODER handelt.

Schlussbemerkung

SharePoint Server 2010 bietet neue und verbesserte Features zur Optimierung der Benutzerumgebung und Leistung beim Arbeiten mit umfangreichen Listen. Die Leistung der Farm wird mithilfe von Einschränkungen und Grenzwerten gesichert. Außerdem werden Vorgänge verhindert, die übermäßig viele SQL Server-Ressourcen in Anspruch nehmen. Verbesserungen bei Metadaten und Metadatennavigation ermöglichen ein besseres Umfeld zum Abrufen von Listendaten, und Webparts für Inhaltsabfragen, die Suchfunktion und Listenansichten können für das Arbeiten mit umfangreichen Listen konfiguriert werden. Eine sorgfältige Planung ist weiterhin erforderlich, um die gewünschten Lösung für Ihre Anforderungen zu erstellen. Umfangreiche Listen können jedoch mithilfe von Standardlösungen, die sich durch eine überzeugende Leistung auszeichnen, rasch entwickelt werden.

See Also

Other Resources

Ressourcencenter: Kapazitätsverwaltung für SharePoint Server 2010