Defragmentieren von Indizes für Project Server 2010-Datenbanken
Gilt für: Project Server 2010
Letztes Änderungsdatum des Themas: 2016-11-30
Datenbankwartungsaufgaben können entweder mit Transact-SQL-Befehlen oder mit dem Datenbankwartungs-Assistent ausgeführt werden. Dieser Artikel enthält Details zu beiden Methoden.
Die empfohlenen Datenbankwartungsaufgaben für Microsoft Project Server 2010-Datenbanken umfassen Folgendes:
Überprüfen der Datenbankintegrität
Defragmentieren von Indizes durch Neuorganisieren oder Neuerstellen
Festlegen des Füllfaktors für einen Server
Überwachen der Datenbankgröße für die Vorabvergrößerung oder Verkleinerung von Datenbanken
Bereinigen des Verlaufs
Aktualisieren der Statistiken
Defragmentieren von Indizes durch Neuorganisieren oder Neuerstellen
Zur Fragmentierung kommt es, wenn die logische und physische Speicherzuordnung einer Datenbank viele verstreute Speicherbereiche enthält, die unzureichend sind, physisch nicht zusammenhängend sind oder für eine effiziente Verwendung zu fragmentiert sind. Die Fragmentierung kann das Ergebnis Einfüge-, Aktualisierungs- oder Löschvorgänge in einer Tabelle sein. Wenn eine Tabelle fragmentiert wird, werden auch die in der Tabelle definierten Indizes fragmentiert.
Von Project Server 2010 werden GUID-Typen als Clusterschlüssel verwendet. Dadurch werden gleichzeitige Einfügungen vermieden, die Anspruch auf dieselben Datenseiten erheben (Einfügen von Hotspots), was jedoch eine Ursache der Tabellen- und Indexfragmentierung sein kann. Eine Fragmentierung kann auftreten, weil neue Datensätze anstatt am Ende an einer beliebigen Stelle in der B-Struktur eingefügt werden können, was zu einer größeren Neigung zur Seitenteilung (Index und Daten) und damit Fragmentierung führt. Dieses Risiko wird durch das Clustering mit zusammengesetzten Schlüsseln reduziert, die mithilfe der Projekt-UID sicherstellen, dass Datenseiten verwandte Daten enthalten. Durch eine regelmäßige Defragmentierung von großen Tabellen kann die Leistung jedoch verbessert werden, besonders in umfangreichen Bereitstellungen von Project Server 2010.
Im Laufe der Zeit kann die Datenbankfragmentierung zu Leistungseinbußen (unnötiger Datenträgeraktivität) und ineffizienter Speicherplatznutzung führen. Wenn Sie die Risiko und die Häufigkeit der Fragmentierung reduzieren möchten, legen Sie die Größe von Inhaltsdatenbanken basierend auf Ihren Unternehmensanforderungen und der Datenbankarchitektur manuell so groß wie möglich fest. Wenn in Ihrem Unternehmen beispielsweise Inhaltsdatenbanken auf 100 GB begrenzt werden müssen, legen Sie nach dem Erstellen der Inhaltsdatenbanken deren Größe in SQL Server Management Studio auf 100 GB fest.
Tabellen können zwar defragmentiert werden, aber die Defragmentierung von Indizes bietet mehr Vorteile im Hinblick auf die Datenbankleistung und ist außerdem wesentlich schneller. In diesem Artikel wird ausschließlich das Defragmentieren von Indizes erläutert.
Bevor Sie einen Wartungsplan für die Datenbankfragmentierung implementieren, bestimmen Sie zunächst, welche Tabellen und Indizes am meisten fragmentiert sind, und erstellen Sie dann einen Wartungsplan für die Neuerstellung oder Neuorganisation dieser Indizes.
Messen der Fragmentierung mit "sys.dm_db_index_physical_stats"
Verwenden Sie die dynamische Verwaltungssicht sys.dm_db_index_physical_stats, um die Fragmentierung für Indizes in einer angegebenen Tabelle oder Ansicht zu bestimmen.
Zum Messen der Fragmentierung sollten Sie die Spalte avg_fragmentation_in_percent überwachen. Der Wert für avg_fragmentation_in_percent sollte für eine maximale Leistung möglichst bei Null liegen. Werte von 0 % bis 10 % können jedoch auch akzeptabel sein.
Weitere Informationen zur Verwendung von sys.dm_db_index_physical_stats finden Sie unter sys.dm_db_index_physical_stats (Transact-SQL) (https://technet.microsoft.com/de-de/library/ms188917.aspx).
Verringern der Fragmentierung für eine Datenbank
Informationen zum Verringern der Fragmentierung für eine Datenbank finden Sie im Abschnitt Messen und Verringern der Fragmentierung im Whitepaper Datenbankwartung für Microsoft SharePoint 2010-Produkte. Das Whitepaper kann unter Datenbankwartung für SharePoint Server 2010 heruntergeladen werden.
Verringern der Fragmentierung für eine spezifische Tabelle und ihre Indizes
Falls Sie den Index defragmentieren möchten, der einer bestimmten Tabelle zugeordnet ist, können Sie statt einer ganzen Datenbank nur den Index neu organisieren oder neu erstellen. Weitere Informationen finden Sie unter Gruppierte Indexstrukturen (https://technet.microsoft.com/de-de/library/ms177443.aspx).
Das Neuorganisieren eines Indexes bedeutet, dass die Blattebene des Indexes neu organisiert wird. Bei der Neuorganisation des Indexes werden gruppierte und nicht gruppierte Indizes in Tabellen und Ansichten defragmentiert und komprimiert. Dadurch kann die Leistung der Indexüberprüfung erheblich verbessert werden. Die Neuorganisation wird immer online ausgeführt, sodass die zugrunde liegende Tabelle für Benutzer verfügbar ist.
Das Neuerstellen eines Indexes bedeutet, dass der Index mit denselben Spalten, demselben Indextyp, Eindeutigkeitsattribut und derselben Sortierreihenfolge neu erstellt wird. Durch das Neuerstellen wird die Leistung von Überprüfungen und Suchvorgängen für Indizes verbessert. Sie können den Index mit einer Tabelle entweder online oder offline neu erstellen.
Der Fragmentierungsgrad eines Indexes bestimmt die verwendete Defragmentierungsmethode und ob er online bleiben kann oder offline geschaltet werden sollte.
| Fragmentierungsebene | Defragmentierungsmethode |
|---|---|
Bis zu 10 % |
Neuorganisieren (online) |
10 – 75 % |
Neuerstellen (online) |
75 % oder mehr |
Neuerstellen (offline) |
Beachten Sie, dass die Verwendung der Befehle DROP INDEX und CREATE INDEX in Microsoft SharePoint Server 2010-Datenbanken nicht unterstützt wird.
Verwenden von "ALTER INDEX"
Mit ALTER INDEX kann ein Datenbankadministrator Wartungsvorgänge für einen vorhandenen Tabellen- oder Ansichtsindex ausführen. Der Befehl kann zum Deaktivieren, Neuerstellen und Neuorganisieren von Indizes oder optional zum Festlegen von Optionen im Index verwendet werden.
In den meisten Fällen können Sie Indizes neu erstellen, während sich die Datenbank im Onlinemodus befindet, da das erneute Erstellen der Indizes im Offlinemodus keine entscheidenden Vorteile bietet. Beachten Sie jedoch, dass die Tabelle beim Neuerstellen eines Indexes mit einer gemeinsamen Tabellensperre versehen wird, wodurch die Ausführung aller Vorgänge mit Ausnahme von SELECT-Vorgängen verhindert wird. In SharePoint Server 2010-Datenbanken werden gruppierte Indizes verwendet. Wenn ein gruppierter Index neu erstellt wird, wird die Tabelle mit einer exklusiven Tabellensperre versehen, wodurch jegliche Zugriffe auf die Tabelle durch Endbenutzer verhindert wird.
Sie können das folgende Beispielskript zum Neuerstellen aller Indizes in einer Tabelle anpassen.
USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, ONLINE = ON,
STATISTICS_NORECOMPUTE = ON)
GO
Besondere Überlegungen für die Berichtsdatenbank
Es wird davon ausgegangen, dass Kunden benutzerdefinierte Berichte basierend auf in der Berichtsdatenbank verfügbaren benutzerdefinierten Feldern und Daten implementieren. Deshalb sollten die folgenden bewährten Methoden für die T-SQL-Erstellung und Indexerstellung eingehalten werden, um eine skalierbare Lösung für die Leistungsberichterstellung sicherzustellen. Diese (dynamisch generierten) Tabellen werden von Project Server 2010 nicht außerhalb des Primärschlüssels indiziert.
Wenn Sie sich an den Microsoft-Kundendienst und -Support wenden, werden Sie möglicherweise von einem Supporttechniker aufgefordert, zusätzlich erstellte Indizes zu entfernen oder zusätzliche Spalten, die vorhandenen Indizes hinzugefügt wurden, zu entfernen. Dies liegt daran, dass zusätzliche Indizes Datenzugriffspfade ändern und in bestimmten Situationen zu unerwarteten Problemen bei der Leistung und bei Sperren/Deadlocks führen können.
Festlegen des Füllfaktors für einen Server
Der Füllfaktor kann zur weiteren Optimierung der Datenspeicherung und Leistung von Indizes verwendet werden. Wenn Indizes erstellt oder neu erstellt werden, bestimmt der Füllfaktorwert (1 – 100) den Prozentsatz des Speicherplatzes auf jeder Seite auf Blattebene, der mit Daten gefüllt werden kann. Der verbleibende Speicherplatz ist für künftiges Wachstum reserviert. Für zahlreiche Situationen ist der standardmäßige serverseitige Füllfaktor 0 optimal. Für SharePoint Server 2010 ist jedoch eine serverweite Einstellung von 70 optimal, um Wachstum zu unterstützen und Fragmentierung zu minimieren.
Es ist zwar möglich, den Füllfaktor für einzelne Tabellen oder Indizes festzulegen, dies wird jedoch nicht empfohlen.
Wenn Sie den Füllfaktorwert für mindestens einen Index anzeigen möchten, können Sie die Katalogsicht sys.indexes abfragen. Weitere Informationen zu dieser Sicht finden Sie unter sys.indexes (Transact-SQL) (https://technet.microsoft.com/de-de/library/ms173760.aspx).
Zum Konfigurieren des serverweiten Füllfaktorwerts können Sie die gespeicherte Systemprozedur sp_configure verwenden. Weitere Informationen finden Sie unter sp_configure (Transact-SQL) (https://technet.microsoft.com/de-de/library/ms188787.aspx).