Datenbankwartung für SharePoint Server 2010

 

Letztes Änderungsdatum des Themas: 2016-11-30

Zusammenfassung: Erfahren Sie, wie Sie die Datenbanken warten, in den Daten gehostet und Konfigurationseinstellungen für Microsoft SharePoint 2010-Produkte gespeichert werden. Lesen Sie Richtlinien, und sehen Sie sich Beispiele zu empfohlenen Strategien und Aufgaben für die Datenbankwartung an.

Gilt für: Microsoft SharePoint Server 2010, Microsoft SharePoint Foundation 2010

Autoren: Bill Baer und Bryan Porter

Technischer Lektor: Paul S. Randal (SQLskills.com (in englischer Sprache))

Inhalt

• Einführung

• Verwenden des Datenbankkonsolenbefehls (Database Console Command, DBCC) CHECKDB zum Überprüfen auf Konsistenzfehler

• Informationen zu DBCC CHECKDB

• DBCC CHECKDB und Leistung

• Messen und Verringern der Indexfragmentierung

• Indexneuerstellungen im Onlinemodus im Vergleich zum Offlinemodus

• Messen der Fragmentierung in einer SQL Server 2008- oder 2005-Datenbank (sys.dm_db_index_physical_stats)

• Verringern der Fragmentierung für eine Datenbank

• Verringern der Fragmentierung für eine spezifische Tabelle und ihre Indizes

• Optimieren der Indexleistung durch Festlegen eines Füllfaktors

• Verkleinern von Datendateien

• Erstellen von SQL Server 2008-Wartungsplänen

• Schlussbemerkung

Einführung

Eine Routinedatenbankwartung ist für den reibungslosen Betrieb von Microsoft SharePoint 2010-Datenbanken wichtig.

Die empfohlenen Wartungsaufgaben für SharePoint 2010-Datenbanken beinhalten Folgendes:

• Überprüfen der Datenbankintegrität

• Defragmentieren von Indizes durch Neuorganisierung oder Neuerstellung

• Festlegen des Füllfaktors für einen Server

Auch wenn in früheren Versionen von SharePoint-Produkten und -Technologien ein manuelles Eingreifen zum Ausführen der Indexdefragmentierung und Statistikwartung erforderlich war, wird dieser Vorgang in SharePoint 2010 durch verschiedene SharePoint-Integritätsanalyseregeln automatisiert. Diese Regeln bewerten die Integrität von Datenbankindizes und -statistiken täglich und beheben diese Elemente für die folgenden Datenbanken automatisch:

• Konfigurationsdatenbanken

• Inhaltsdatenbanken

• Profildatenbanken der Benutzerprofil-Dienstanwendung

• Thematische Datenbanken der Benutzerprofil-Dienstanwendung

• Berichtsdatenbanken der Web Analytics-Dienstanwendung

• Stagingdatenbanken der Web Analytics-Dienstanwendung

• Word Automation Services-Datenbanken

Datenbankwartungsaufgaben können mithilfe von Transact-SQL-Befehlen oder des Datenbankwartungs-Assistenten ausgeführt werden. In diesem Artikel werden die Transact-SQL-Befehle beschrieben, die Sie verwenden können, und es wird die Erstellung von Datenbankwartungsplänen mithilfe des Datenbankwartungs-Assistenten von Microsoft SQL Server erläutert. (Die detaillierten Beispiele sind für Microsoft SQL Server 2008 R2 und Microsoft SQL Server 2005 vorgesehen.)

Verwenden des Datenbankkonsolenbefehls (Database Console Command, DBCC) CHECKDB zum Überprüfen auf Konsistenzfehler

Beginnen Sie Ihre Routinewartung mit Konsistenzprüfungen, um sicherzustellen, dass Ihre Daten und Indizes nicht beschädigt sind. Mithilfe der Datenbankkonsolenbefehls-Anweisung CHECKDB können Sie eine interne Konsistenzprüfung der Daten- und Indexseiten vornehmen.

Die meisten Datenbankkonsistenzprobleme entstehen durch E/A-Subsystemfehler. Es können sich jedoch auch andere Faktoren und Ereignisse auf die Datenbankkonsistenz auswirken. Dazu gehört beispielsweise ein nicht ordnungsgemäßes Herunterfahren eines Datenbankservers oder ein Laufwerksfehler. Beachtliche Leistungs- und Verfügbarkeitsprobleme können manchmal Symptome für zugrunde liegende Datenbankkonsistenzprobleme sein. Führen Sie mindestens einmal pro Woche und beim Auftreten von Ereignissen wie Datenbankserver- oder E/A-Subsystemfehlern Datenbankkonsistenzprüfungen für Ihre SharePoint 2010-Datenbanken aus.

Informationen zu DBCC CHECKDB

DBCC CHECKDB überprüft die logische und physische Integrität aller Objekte in der angegebenen Datenbank durch Ausführen der folgenden Vorgänge:

• Führt das Äquivalent von DBCC CHECKALLOC aus, um die Zuordnungsstrukturen in der Datenbank zu überprüfen.

• Führt das Äquivalent von DBCC CHECKTABLE für jede Tabelle und Sicht in der Datenbank aus, um ihre logische und physische Integrität zu überprüfen.

• Führt das Äquivalent von DBCC CHECKCATALOG für die Datenbank aus, um die Konsistenz der Metadaten in der Datenbank zu überprüfen.

Es wird empfohlen, dass Sie DBCC CHECKDB anstelle der einzelnen Vorgänge (Befehle DBCC CHECKALLOC, DBCC CHECKTABLE und DBCC CHECKCATALOG) ausführen, da DBCC CHECKDB die meisten möglichen Fehler identifiziert und seine Ausführung in einer Produktionsumgebung daher sicherer ist.

DBCC CHECKDB verwendet viele Speicher-, E/A- und CPU-Ressourcen. Anstatt DBCC CHECKDB auf Ihrem Produktionssystem auszuführen, können Sie es in einer wiederhergestellten Sicherung Ihrer SharePoint-Datenbanken auf einem anderen Server ausführen und dabei die Arbeitslast der Konsistenzprüfung vom Produktionssystem abladen.

Es wird empfohlen, dass Sie zuerst DBCC CHECKDB ausführen und dann – falls Fehler gefunden werden – die betroffene Datenbank mithilfe Ihrer aktuellen Sicherungen wiederherstellen.

Die folgende Beispielausgabe stammt von DBCC CHECKDB.

DBCC results for 'Contoso_Content_1'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".
DBCC results for 'sys.sysrowsets'.
There are 309 rows in 4 pages for object "sys.sysrowsets".

...more

CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Weitere Informationen zur Verwendung von DBCC CHECKDB für SQL Server 2008 finden Sie unter DBCC CHECKDB (Transact-SQL).

DBCC CHECKDB und Leistung

Es wird empfohlen, Konsistenzprüfungen während nicht produktiver Stunden auszuführen, da DBCC CHECKDB sehr ressourcenintensiv ist (E/A, CPU, Arbeitsspeicher und tempdb-Speicherplatz). Es besteht ein allgemeines Missverständnis darüber, dass DBCC CHECKDB zu Blockierungssperren führt, aber das stimmte bereits vor SQL Server 2000 nicht. Weitere Informationen finden Sie unter Ein SQL Server-DBA-Mythos pro Tag: (2/30) DBCC CHECKDB verursacht Blockierungen (in englischer Sprache) (möglicherweise in englischer Sprache).

Möglicherweise stellen Sie fest, dass beim Ausführen von DBCC CHECKDB zu viele Ressourcen für Ihr Produktionssystem verwendet werden. Führen Sie die Konsistenzprüfungen in diesem Fall nur für jede Tabelle einzeln aus. Die beste Möglichkeit zum Verringern des Mehraufwands bei einer Integritätsprüfung auf dem Produktionssystem besteht in der Verwendung einer der folgenden Optionen:

• Verwenden Sie die Option WITH PHYSICAL_ONLY, um die CPU- und Arbeitsspeicherauslastung zu verringern.

• Stellen Sie eine Datenbanksicherung auf einem separaten Server mit SQL Server wieder her, und führen Sie für die hergestellte Kopie der Datenbank Konsistenzprüfungen aus.

Weitere Informationen zu diesen Optionen finden Sie im Blogeintrag von Paul S. Randal, CHECKDB aus allen Winkeln: Konsistenzprüfungsoptionen für eine VLDB (in englischer Sprache) (möglicherweise in englischer Sprache).

Messen und Verringern der Indexfragmentierung

Die Indexfragmentierung tritt auf, wenn sich die logische Reihenfolge der Seiten in einer Tabelle oder einem Index (durch den Indexschlüssel definiert) von der physischen Reihenfolge der Seiten in den Datendateien unterscheidet. Es kann auch bedeuten, dass die Datendichte auf Datendateiseiten gering ist, was zu einer Datenträgerspeicherplatz-, Arbeitsspeicher- und E/A-Verschwendung führt. Die Indexfragmentierung kann das Ergebnis von Einfüge-, Aktualisierungs- oder Löschvorgängen in einer Tabelle sein. In den folgenden Abbildungen ist der neu erstellte nicht fragmentierte Index einem Index gegenübergestellt, der nach vielen Einfüge-, Aktualisierungs- und Löschvorgängen fragmentiert wurde. Der rote Pfeil gibt die physische Reihenfolge des Indexes an, der schwarze Pfeil gibt die logische Reihenfolge der Indexseiten an.

Abb. 1. Nicht fragmentierter Index (Bildquelle: Paul S. Randal)

 

Abb. 2. Fragmentierter Index (Bildquelle: Paul S. Randal)

 

Da Einfüge-, Aktualisierungs- und Löschvorgänge nicht gleichmäßig zwischen den Zeilen der Tabelle und Indizes verteilt sind, kann die Fülle (oder Datendichte) der einzelnen Zeiten im Laufe der Zeit variieren. Bei Abfragen, die einen Teil oder alle Indizes einer Tabelle scannen, kann die Fragmentierung zusätzliche Seitenlesevorgänge verursachen, was das parallele Scannen von Daten verhindert und sich bedeutend auf die Suchleistung auswirken kann.

Die Indexfragmentierung kann zu einer Verringerung der Leistung und einer ineffizienten Nutzung des Speicherplatzes führen, und Indizes werden möglicherweise für Datenbanken mit nur moderater Verwaltung schnell fragmentiert.

Bestimmen Sie vor dem Implementieren eines Wartungsplans zur Indexfragmentierung, welche Tabellen und Indizes am stärksten fragmentiert sind. Erstellen Sie dann einen Wartungsplan, um diese Indizes neu zu erstellen oder neu zu organisieren.

In SharePoint 2010 stellt AllDocs beispielsweise eine Tabelle, die oft fragmentiert wird. Sie enthält Dokumentbibliotheken, ihre zugehörigen Dokumente, Listen und Listenelemente sowie ihre entsprechenden Metadaten.

Die Fragmentierungsebene eines Indexes ist der Prozentsatz der Indexseiten, die sich nicht in derselben logischen und physischen Reihenfolge befinden.

Indexneuerstellungen im Onlinemodus im Vergleich zum Offlinemodus

Die Indexneuerstellung im Onlinemodus ist nur in den Editionen SQL Server Enterprise, Developer und Evaluation verfügbar. Bei den in diesem Artikel beschriebenen Methoden sind diese Einschränkungen berücksichtigt. Die Verfahren in diesem Artikel gelten für eine Indexneuerstellung im Offlinemodus, wenn die Edition von SQL Server, die eine bestimmte Datenbank hostet, keine Indexneuerstellung im Onlinemodus unterstützt oder wenn der Index, der neu erstellt wird, nicht für eine Indexneuerstellung im Onlinemodus berechtigt ist. Ein Index ist möglicherweise aufgrund des Vorhandenseins von LOB-Spalten (Large Object) wie Spalten mit dem Datentyp NVARCHAR(MAX), IMAGE usw. nicht für eine Neuerstellung im Onlinemodus berechtigt.

Weitere Informationen zu Indexneuerstellungen im Onlinemodus finden Sie unter Funktionsweise von Onlineindexvorgängen. Bei einer Indexneuerstellung im Offlinemodus werden während der Neuerstellung Sperrungen auf Tabellenebene vorgenommen, wodurch möglicherweise das Schreiben in die Tabelle oder sogar der Zugriff auf die Tabelle verhindert wird. Viele der Indizes in SharePoint-Datenbanken werden aufgrund von LOB-Spalten immer mithilfe der Indexneuerstellung im Offlinemodus neu erstellt.

Selbst bei der Indexneuerstellung im Onlinemodus gibt es noch zwei Stellen im Vorgang, an denen kurzzeitig Sperren vorgenommen werden, und diese könnten zu Blockierungen führen. Daher empfiehlt es sich, Indexneuerstellungsaktivitäten immer für Zeiträume mit geringer Aktivität zu planen.

Messen der Fragmentierung in einer SQL Server 2008- oder 2005-Datenbank (sys.dm_db_index_physical_stats)

Verwenden Sie in SQL Server 2008 oder SQL Server 2005 die dynamische sys.dm_db_index_physical_stats-Verwaltungssicht, um die Fragmentierung für die Indizes in einer bestimmten Tabelle oder Sicht zu ermitteln.

Zum Messen der Fragmentierung empfiehlt es sich, die Spalte avg_fragmentation_in_percent zu überwachen. Der Wert für avg_fragmentation_in_percent sollte für maximale Leistung möglichst nah am Wert Null liegen. Werte von 0–10 % sind jedoch akzeptabel. Weitere Informationen finden Sie unter sys.dm_db_index_physical_stats.

Die folgende Tabelle enthält Beispielergebnisse aus sys.dm_db_index_physical_stats mit dem Wert 9,375 für avg_fragmentation_in_percent in einer Zeile.

database_id	index_type_desc	alloc_unit_type_ desc	avg_fragmentation_ in_percent
10	CLUSTERED INDEX	IN_ROW_DATA	0
10	NONCLUSTERED INDEX	IN_ROW_DATA	0
10	NONCLUSTERED INDEX	IN_ROW_DATA	0
10	CLUSTERED INDEX	IN_ROW_DATA	0
10	NONCLUSTERED INDEX	IN_ROW_DATA	0
10	CLUSTERED INDEX	IN_ROW_DATA	9.375

So verwenden Sie die dynamische sys.dm_db_index_physical_stats-Verwaltungssicht

1. Klicken Sie auf der Taskleiste auf Start, zeigen Sie auf Alle Programme und auf Microsoft SQL Server 2008, und klicken Sie dann auf SQL Server Management Studio.

   Wenn Sie sys.dm_db_index_physical_stats für ein Datenbankobjekt verwenden möchten, müssen Sie die Datenbank-ID und die Objekt-ID kennen.

2. Wählen Sie die Inhaltsdatenbank im Objekt-Explorer aus, und klicken Sie dann auf Neue Abfrage. Führen Sie das folgende Skript aus.

   SELECT DB_ID() AS [Database ID];

   Hinweis

   Wenn Sie DB_ID ohne Angabe eines Datenbanknamens verwenden, muss der Kompatibilitätsgrad der aktuellen Datenbank 100 (eine SQL Server 2008-Datenbank) oder 90 (eine SQL Server 2005-Datenbank) betragen. Wenn Sie ein Upgrade von einer früheren Version von SQL Server ausgeführt haben, müssen Sie in der DB_ID-Anweisung einen Datenbanknamen angeben. Weitere Informationen zu Kompatibilitätsgraden finden Sie unter sp_dbcmptlevel (Transact-SQL).

3. Führen Sie sys.dm_db_index_physical_stats für die ausgewählte Datenbank oder das ausgewählte Objekt aus. Sie können die Datenbank und auch eine Tabelle oder einen Index angeben.

   Verwenden Sie beim Ausführen von sys.dm_db_index_physical_stats die folgende Syntax.

   sys.dm_db_index_physical_stats ( 
       { database_id | NULL | 0 | DEFAULT }
       , { object_id | NULL | 0 | DEFAULT }
       , { index_id | NULL | 0 | -1 | DEFAULT }
       , { partition_number | NULL | 0 | DEFAULT }
       , { mode | NULL | DEFAULT }
   )
   

   Seien Sie vorsichtig, wenn Sie die dynamische sys.dm_db_index_physical_stats-Verwaltungssicht verwenden, da sie sehr ressourcenintensiv sein kann. Unter Inside sys.dm_db_index_physical_stats (in englischer Sprache) (möglicherweise in englischer Sprache) finden Sie eine umfassende Anleitung, in der ihre zahlreichen Verwendungsmöglichkeiten erläutert werden.

Verringern der Fragmentierung für eine Datenbank

Verwenden Sie die folgende Anleitung, um die Ebene der Indexfragmentierung zu verringern.

Ausführen von Integritätsanalyseregeln zur Datenbankwartung

SharePoint 2010 enthält das Integritätsanalyseregel-Framework. Das Framework weist viele Regeln auf, die die Integrität und die Vorgänge in einer SharePoint-Umgebung überwachen und in einige Fällen Aktionen ausführen, um bestimmte Arten von Problemen zu beheben.

SharePoint 2010 enthält verschiedene Regeln, die für die Inhaltsdatenbankwartung relevant sind. Es gibt Regeln, die die Indexfragmentierung für einige SharePoint-Datenbanken automatisch verringern, und Regeln, die nach veralteten Statistiken suchen und diese bei Bedarf aktualisieren. Diese Integritätsanalyseregeln ersetzen den aktualisierten Datenbankstatistik-Zeitgeberauftrag, der in Service Pack 2 für SharePoint-Produkte und -Technologien eingeführt wurde. Diese Regeln sind standardmäßig so konfiguriert, dass sie nach einem Zeitplan ausgeführt werden, der je nach Regelziel täglich, wöchentlich oder bei Bedarf ausgeführt wird.

Alle Integritätsanalyseregeln, die für die tägliche Ausführung konfiguriert und die einem bestimmten SharePoint-Dienst zugeordnet sind, werden vom selben Zeitgeberauftrag ausgeführt. Beim Anpassen des Zeitplans für diesen Zeitgeberauftrag erfolgt die Anpassung, wenn Integritätsanalyseregeln, die für die tägliche Ausführung konfiguriert und diesem Dienst zugeordnet sind, während des Tages ausgeführt werden. Alle in diesem Artikel beschriebenen Regeln sind dem SharePoint Timerdienst zugeordnet.

Integritätsanalyseregeln, die für die Ausführung in einem anderen Zeitintervall (beispielsweise wöchentlich) konfiguriert oder einem anderen Dienst zugeordnet sind, weisen unterschiedliche Zeitgeberaufträge auf. Wenn Sie eine Integritätsanalyseregel für die wöchentliche Ausführung konfigurieren, wird diese Regel durch den Zeitgeberauftrag ausgeführt, der für die wöchentliche Ausführung des bestimmten Diensts konfiguriert ist, dem diese Integritätsanalyseregel zugeordnet ist. Mit anderen Worten wird die Regel in dem Zeitplan ausgeführt, der für diesen Zeitgeberauftrag definiert wurde.

Sie können Integritätsanalyseregeln manuell ausführen, indem Sie in der Zentraladministration auf der Seite für die Integritätsanalyseregeln auf dem Menüband auf Jetzt ausführen klicken. Durch das Ausführen dieser Regeln wird die Integrität der Indizes und Statistiken bewertet. Bei Bedarf wird der Index auch neu erstellt und neu berechnet.

Von SharePoint verwendete Datenbanken weisen fragmentierte Indizes auf: Beim Ausführen dieser Regel werden die folgenden Aufgaben ausgeführt:

• Die Regel meldet Indizes als fragmentiert. Da das Bewerten der Indexintegrität ein teurer Vorgang ist, meldet die Integritätsanalyseregel Indizes nach ihrer Ausführung immer als fragmentiert, um die Korrekturmaßnahme auszulösen.

• Die Regelaktion sucht für jede SharePoint-Datenbank nach der gespeicherten Prozedur proc_DefragmentIndices und führt sie aus, wenn sie gefunden wird. Dadurch wird eine Auflistung aller Indizes in der Datenbank erstellt. In jedem Index wird die vorhandene Fragmentierungsstufe bewertet. Jeder Index, der zu mehr als 30 Prozent fragmentiert ist, wird für die Neuerstellung berücksichtigt.

• Wenn die Edition von SQL Server die Indexneuerstellung im Onlinemodus unterstützt, wird für jeden Index eine Indexneuerstellung im Onlinemodus vorgenommen. Wenn ein Fehler auftritt (z. B. der zugrunde liegende Index unterstützt Neuerstellungen im Onlinemodus aufgrund von LOB-Spalten nicht), wird eine Indexneuerstellung im Offlinemodus ausgeführt.

Wie bereits erwähnt wartet diese Regel nicht alle Datenbanken in einer SharePoint-Umgebung. Bestimmte Datenbanken verwenden andere Regeln, um ähnliche Wartungsaktivitäten auszuführen.

Suche – Mindestens eine Eigenschaftendatenbank weist einen fragmentierten Index auf: Diese Regel wartet die Indizes in den Eigenschaftendatenbanken der SharePoint 2010-Unternehmenssuche. Diese Regel ist standardmäßig für die wöchentliche Ausführung auf einem beliebigen Server in der Farm konfiguriert. Alle Verarbeitungsvorgänge für diese Regel, einschließlich Korrekturmaßnahmen, treten während der Check-Phase der Regel auf. Wenn Sie also Indexneuerstellungen für die Eigenschaftendatenbank der Unternehmenssuche verwalten möchten, reicht es nicht aus, diese Regel einfach so zu konfigurieren, dass Indizes nicht automatisch erstellt werden. Sie müssen die Regel vollständig deaktivieren, wenn von SharePoint 2010 nicht automatisch Indexwartungsvorgänge ausgeführt werden sollen.

Beim Ausführen von Search - One or more property databases have fragmented indices werden die folgenden Aufgaben ausgeführt:

• Die Regel überprüft, ob sich die Umgebung in einem Zustand befindet, in dem eine Indexneuerstellung sicher ausgeführt werden kann.

• Die Regel führt für jede Eigenschaftendatenbank, die für Suchanwendungen in der lokalen Farm konfiguriert ist, die gespeicherte Prozedur proc_MSS_DefragSearchIndexes aus. Dadurch wird eine Auflistung aller Indizes erstellt, die eine durchschnittliche Fragmentierung von mehr als 10 % aufweisen.

• Jeder Index in der Liste, der sich auf die Leistung der Eigenschaftendatenbank auswirkt, wird neu erstellt. Wenn die Edition von SQL Server die Indexneuerstellung im Onlinemodus unterstützt, wird eine Indexerstellung im Onlinemodus vorgenommen. Wenn eine Indexneuerstellung ausgeführt wird und ein Fehler auftritt, wird der Index im Offlinemodus neu erstellt.

Suche – Mindestens eine Durchforstungsdatenbank weist ggf. fragmentierte Indizes auf: Diese Regel wartet die Indizes in den Eigenschaftendatenbanken der SharePoint 2010-Unternehmenssuche. Diese Regel ist standardmäßig für die wöchentliche Ausführung auf einem beliebigen Server in der Farm konfiguriert. Alle Verarbeitungsvorgänge für diese Regel, einschließlich Korrekturmaßnahmen, treten während der Check-Phase der Regel auf. Wenn Sie also Indexneuerstellungen für die Eigenschaftendatenbank der Unternehmenssuche verwalten möchten, reicht es nicht aus, diese Regel einfach so zu konfigurieren, dass Indizes nicht automatisch erstellt werden. Sie müssen die Regel vollständig deaktivieren, wenn von SharePoint 2010 nicht automatisch Indexwartungsvorgänge ausgeführt werden sollen.

Beim Ausführen von Search - One or more property databases have fragmented indices werden die folgenden Aufgaben ausgeführt:

• Die Regel überprüft, ob sich die Umgebung in einem Zustand befindet, in dem eine Indexneuerstellung sicher ausgeführt werden kann.

• Die Regel führt für jede Eigenschaftendatenbank, die für Suchanwendungen in der lokalen Farm konfiguriert ist, die gespeicherte Prozedur proc_MSS_DefragSearchIndexes aus. Dadurch wird eine Auflistung aller Indizes erstellt, die eine durchschnittliche Fragmentierung von mehr als 10 % aufweisen.

• Jeder Index in der Liste, der sich auf die Leistung der Eigenschaftendatenbank auswirkt, wird neu erstellt. Wenn die Edition von SQL Server die Indexneuerstellung im Onlinemodus unterstützt, wird eine Indexerstellung im Onlinemodus vorgenommen. Wenn eine Indexneuerstellung ausgeführt wird und ein Fehler auftritt, wird der Index im Offlinemodus neu erstellt.

Suche – Mindestens eine Durchforstungsdatenbank weist ggf. Indizes auf: Diese Regel wartet die Indizes in den Durchforstungsdatenbanken der SharePoint 2010-Unternehmenssuche. Diese Regel ist standardmäßig für die Ausführung bei Bedarf konfiguriert. Sie kann auf einem beliebigen Server in der Farm ausgeführt werden.

Die Regel meldet Indizes in der Durchforstungsdatenbank als fragmentiert, da das Überprüfen der Fragmentierung in einer Datenbank teuer ist. Das einfache Deaktivieren der Aktivität "Reparieren" für diese Regel führt zu einem Bericht, gemäß dem alle Durchforstungsdatenbanken nicht integer sind, selbst wenn die Indizes der Durchforstungsdaten kürzlich neu erstellt wurden.

Wenn Sie Indizes in Durchforstungsdatenbanken manuell warten möchten, deaktivieren Sie die Search - One or more crawl databases may have fragmented indices-Regel vollständig.

Beim Ausführen von Search - One or more crawl databases may have fragmented indices werden die folgenden Aufgaben ausgeführt:

• Die Regel überprüft, ob sich die Umgebung in einem Zustand befindet, in dem eine Indexneuerstellung sicher ausgeführt werden kann.

• Die Regel führt für jede Durchforstungsdatenbank, die für Suchanwendungen in der lokalen Farm konfiguriert ist, die gespeicherte Prozedur proc_MSS_DefragGathererIndexes aus.

• Jeder Index in der Durchforstungsdatenbank in der Liste wird neu erstellt. Wenn die Edition von SQL Server die Indexneuerstellung im Onlinemodus unterstützt, wird eine Indexerstellung im Onlinemodus vorgenommen. Wenn eine Indexneuerstellung ausgeführt wird und ein Fehler auftritt, wird der Index im Offlinemodus neu erstellt.

Aufgrund der Natur von Durchforstungsdatenbanken müssen Sie diese Datenbank in der Regel nicht häufig fragmentieren. Führen Sie diese Regel aus, nachdem Sie den Inhalt vollständig durchforstet haben. Überwachen Sie anschließend die Fragmentierung der Indizes in der Durchforstungsdatenbank, und führen Sie diese Regel aus, wenn die Indexfragmentierung zunimmt. Die Indexfragmentierung kann aufgrund der plötzlichen Hinzufügung oder Entfernung einer großen Menge an durchforstetem Inhalt auftreten – beispielsweise während des Inhaltsausschlusses, der aus einem Umgebungscleanup resultiert, oder nach dem Integrieren einer neuen Inhaltsquelle wie einer Dateifreigabe oder einer umfangreichen SharePoint-Webanwendung.

Für die folgenden Datenbanken ist kein automatisierter Wartungsmechanismus vorhanden. Diese Datenbanken weisen in der Regel keine hohe Fragmentierung auf. Überwachen Sie diese Datenbanken zur Fragmentierung, und erstellen Sie die Indizes in diesen Datenbanken neu, wenn die Fragmentierung 30 % überschreitet.

• Suchverwaltungsdatenbank

• Datenbank für einmaliges Anmelden

• Statusdienstdatenbank

• Profilsynchronisierungsdatenbank

• Verwendungsdatenbank

• Datenbank für verwaltete Metadaten

• Business Connectivity Services-Datenbank

• Datenbank des PerformancePoint-Diensts

Weitere Informationen zu den für SharePoint 2010-Datenbanken unterstützten Änderungen finden Sie unter Unterstützung für Änderungen an den von Office-Serverprodukten und Windows SharePoint Services verwendeten Datenbanken in der Microsoft Knowledge Base.

Wenn sich die Leistung einer stark fragmentierten Datenbank oder Tabelle durch häufiges Defragmentieren nicht deutlich verbessert, müssen Sie die Leistung des E/A-Subsystems überprüfen.

Verringern der Fragmentierung für eine spezifische Tabelle und ihre Indizes

Falls Sie einen 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.

• 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 Sichten defragmentiert und komprimiert. Dadurch kann die Leistung der Indexüberprüfung erheblich verbessert werden. Bei der Neuorganisation eines Indexes wird der dem Index zugeordnete vorhandene Speicherplatz verwendet. Die Neuorganisation wird immer online ausgeführt, sodass die zugrunde liegende Tabelle für Benutzer verfügbar ist.

• Das Neuerstellen eines Indexes bedeutet, dass eine neue Kopie des Indexes erstellt wird. Daher ist für einen Neuerstellungsvorgang genügend zusätzlicher Speicherplatz erforderlich, damit die neue Kopie des Indexes erstellt werden kann, bevor der alte fragmentierte Index gelöscht wird. Durch das Neuerstellen wird die Leistung von Indexscans und -suchen verbessert. Sie können den Index für eine Tabelle im Online- oder Offlinemodus erstellen.

Die Fragmentierungsebene eines Indexes bestimmt die Methode, die Sie zum Fragmentieren verwenden, und sie bestimmt auch, ob der Index im Onlinemodus verbleiben kann oder in den Offlinemodus geschaltet werden muss. In der folgenden Tabelle sind die für verschiedene Fragmentierungsebenen empfohlenen Defragmentierungsmethoden beschrieben.

Fragmentierungsebene	Defragmentierungsmethode
Bis zu 10 %	Neuorganisieren (online)
10–75 %	Neuerstellen (online)
75 %	Neuerstellen (offline)

Sie können Indizes mithilfe der ALTER INDEX-Anweisung von SQL Server 2008 oder SQL Server 2005 oder dem Wartungsplanungs-Assistenten von SQL Server 2008 oder SQL Server 2005 neu organisieren oder neu erstellen. In diesem Artikel werden nur die SQL Server 2008- oder SQL Server 2005-Optionen ausführlich dargestellt.

Verwenden von ALTER INDEX

Mit ALTER INDEX kann ein Datenbankadministrator Wartungsvorgänge für einen Tabellen- oder Sichtindex ausführen. Damit können Sie Indizes deaktivieren, neu erstellen und neu organisieren. Sie können mit der Anweisung auch Optionen für den Index festlegen. In den meisten Fällen können Sie Indizes neu erstellen, während sich die Datenbank im Onlinemodus befindet. Dadurch stehen die Daten den Benutzern länger zur Verfügung als bei einer Indexneuerstellung im Offlinemodus.

Sie können das folgende Beispielskript so anpassen, dass alle Indizes für eine Tabelle neu erstellt werden.

USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO

Optimieren der Indexleistung durch Festlegen eines Füllfaktors

Verwenden Sie zur weiteren Optimierung der Datenspeicherung und Leistung von Indizes den Füllfaktor. Beim Erstellen oder Neuerstellen von Indizes bestimmt der Füllfaktorwert (1–100) den Prozentsatz an Speicherplatz, der auf jeder Blattebenenseite mit Daten gefüllt werden kann. Der verbleibende Speicherplatz ist für künftiges Wachstum reserviert. In vielen Situationen ist der standardmäßige serverweite Füllfaktor 0 (füllt jede Seite zu 100 %) optimal. Für SharePoint 2010 ist jedoch eine serverweite Einstellung von 80 optimal, um Wachstum zu unterstützen und die Fragmentierung zu verringern.

Wenn Sie den Füllfaktor für mindestens einen Index anzeigen möchten, fragen Sie die Katalogsicht sys.indexes ab. Weitere Informationen zur Sicht finden Sie unter sys.indexes (Transact-SQL).

Wenn Sie den serverweiten Füllfaktorwert festlegen möchten, verwenden Sie die gespeicherte Systemprozedur sp_configure. Weitere Informationen finden Sie unter spconfigure (Transact-SQL).

Verkleinern von Datendateien

In SQL Server 2008 und SQL Server 2005 können Sie alle Dateien in einer Datenbank (mit den Dateinamenerweiterungen MDF, LDF und NDF) verkleinern, um nicht verwendete Seiten zu entfernen und Speicherplatz freizugeben. Datendateien in SharePoint 2010-Datenbanken werden nicht automatisch verkleinert, auch wenn durch zahlreiche Aktivitäten nicht verwendete Leerräume in der Datenbank geschaffen werden. Zu den Aktivitäten, mit denen Leerräume geschaffen werden können, zählen das Ausführen des Windows PowerShell-Befehls Move-SPSite und das Löschen von Dokumenten, Dokumentbibliotheken, Listen, Listenelementen und Websites.

Abb. 3. Datenbankbelegung

 

Freier Speicherplatz wird vom Ende der Datei freigegeben. So wird in einer Inhaltsdatenbankdatei mit 60 GB und einer angegebenen Zielgröße von 40 GB so viel Speicherplatz wie möglich von den 20 GB am Ende (konzeptionell das "rechte" Ende) der Datenbankdatei freigegeben. Wenn verwendete Seiten in diesen 20 GB enthalten sind, werden diese Seiten anschließend in die 40 GB am Anfang der verbleibenden Datei verschoben. Datenbankdateien können einzeln oder als Gruppe verschoben werden.

Führen Sie Verkleinerungsvorgänge nur selten aus und nur, nachdem Sie einen Vorgang ausgeführt haben, bei dem viele Daten aus einer Datenbank gespeichert werden, und auch nur dann, wenn Sie davon ausgehen, dass Sie diesen freien Speicherplatz nicht erneut verwenden. Datendatei-Verkleinerungsvorgänge führen zu starker Indexfragmentierung und sind sehr ressourcenintensiv. Beispiele, bei denen Sie Datenbankdateien möglicherweise verkleinern müssen, sind das Neuzuordnen einer großen Anzahl von Websitesammlungen von einer Inhaltsdatenbank zu einer anderen oder das Löschen einer großen Liste. Bei diesen Vorgängen können große Mengen an nicht verwendeten Leerräumen entstehen. Datenbankdateien können nur so stark verkleinert werden, bis kein freier Speicherplatz mehr verbleibt. Daher profitieren Sie bei einer Inhaltsdatenbank, in der Sie selten Inhalt löschen, nicht viel von der Verkleinerung und stellen wahrscheinlich eine Abnahme der Leistung fest, wenn sie wachsen muss und zusätzliche Daten ohne spezielle Zuordnungen aufnehmen muss. Weitere Informationen finden Sie unter Datenbankdatei-Initialisierung.

Verkleinern Sie Datenbanken nicht regelmäßig, da das Verkleinern zur Indexfragmentierung führt. Verkleinern Sie Datenbankdateien stattdessen nur als Reaktion auf große Mengen an nicht verwendetem Speicherplatz, der als Ergebnis von Vorgängen auftritt, die sich bedeutend auf die relative Menge des nicht verwendeten Speicherplatzes in einer Datenbank auswirken. Falls überhaupt möglich, sollten Sie das Verkleinern einer Datenbank vermeiden.

Wenn Sie eine Datenbank jedoch verkleinern müssen, verwenden Sie die folgenden Richtlinien:

• Verkleinern Sie Datenbanken nicht automatisch, oder konfigurieren Sie keinen Wartungsplan, mit dem Ihre Datenbanken programmgesteuert verkleinert werden.

• Verkleinern Sie eine Datenbank nur, wenn Benutzer oder Administratoren 50 % oder mehr des Inhalts entfernen und Sie davon ausgehen, dass Sie den nicht verwendeten Speicher nicht erneut verwenden.

• Verkleinern Sie nur Inhaltsdatenbanken. Benutzer und Administratoren löschen nicht genug Daten aus der Konfigurationsdatenbank, der Inhaltsdatenbank der Zentraladministration und verschiedenen Dienstanwendungsdatenbanken, dass eine bedeutende Menge an freiem Speicherplatz entsteht.

• Das Verkleinern von Datenbanken ist sehr ressourcenintensiv. Daher sollten Sie, wenn Sie eine Datenbank unbedingt verkleinern müssen, den Zeitpunkt für die Ausführung des Verkleinerungsvorgangs sorgfältig planen.

• Nach dem Verkleinern einer Datenbank sind die Indizes in dieser Datenbank fragmentiert. Verwenden Sie ALTER INDEX… REORGANIZE, um die Fragmentierung zu beheben. Wenn Sie die Konfiguration nicht so vorgenommen haben, dass die sofortige Dateiinitialisierung zulässig ist, verkleinern Sie die Datenbank auf eine Zielgröße, die die für das Wachstum in der nächsten Zeit erwartete erforderliche Größe umfasst. Weitere Informationen finden Sie unter Datenbankdatei-Initialisierung.

Sie können Datenbanken und Datenbankdateien manuell verkleinern, um Speicherplatz freizugeben, indem Sie die Anweisungen DBCC SHRINKFILE und DBCC SHRINKDATABASE in SQL Server 2008 oder SQL Server 2005 Management Studio ausführen.

Weitere Informationen dazu, warum das Verkleinern einer Datenbank die Leistung beeinträchtigt und nur ausgeführt werden sollte, wenn es unbedingt erforderlich ist, finden Sie unter Warum Sie Ihre Datendateien nicht verkleinern sollten (in englischer Sprache) (möglicherweise in englischer Sprache).

Verkleinern einer Datenbank mithilfe von Transact-SQL-Befehlen

DBCC SHRINKDATABASE verkleinert die Daten und Protokolldateien für eine bestimmte Datenbank. Verwenden Sie zum Verkleinern einzelner Dateien DBCC SHRINKFILE.

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE verwendet die folgende Syntax.

DBCC SHRINKDATABASE 
( 'database_name' | database_id | 0 
     [ ,target_percent ] 
     [ , { NOTRUNCATE | TRUNCATEONLY } ] 
)
[ WITH NO_INFOMSGS ]

database_name | database_id | 0 gibt den Namen oder die ID der Datenbank an. Zum Auswählen der aktuellen Datenbank verwenden Sie 0.

target_percent ist der freie Speicherplatz (als Prozentsatz), den Sie nach dem Verkleinern der Datenbank beibehalten möchten.

NOTRUNCATE komprimiert die Daten in Datendateien, indem zugewiesene Seiten vom Ende einer Datei zu den nicht zugewiesenen Seiten am Anfang der Datei verschoben werden.

TRUNCATEONLY gibt den gesamten freien Speicher am Ende der Datei für das Betriebssystem frei, verschiebt aber keine Seiten in der Datei.

Weitere Informationen finden Sie unter DBCC SHRINKDATABASE (Transact-SQL).

DBCC SHRINKFILE

DBCC SHRINKFILE verwendet die folgende Syntax.

DBCC SHRINKFILE 
(
     { 'file_name' | file_id } 
    { [ , EMPTYFILE ] 
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH NO_INFOMSGS ]

file_name | file_id gibt den Namen oder die ID der Datei an.

EMPTYFILE migriert alle Daten aus der angegebenen Datei zu den anderen Dateien in derselben Dateigruppe.

target_size ist die Zielgröße für die Datei in Megabytes (als ganze Zahl ausgedrückt).

NOTRUNCATE komprimiert die Daten in Datendateien, indem zugewiesene Seiten vom Ende einer Datei zu den nicht zugewiesenen Seiten am Anfang der Datei verschoben werden.

TRUNCATEONLY gibt den gesamten freien Speicher am Ende der Datei für das Betriebssystem frei, verschiebt aber keine Seiten innerhalb der Datei.

Weitere Informationen finden Sie unter DBCC SHRINKFILE (Transact-SQL).

Verkleinern einer Datenbank mit SQL Server 2008 Management Studio

Verwenden Sie die folgende Vorgehensweise.

So verkleinern Sie eine Datenbank mit SQL Server 2008 Management Studio

1. Wählen Sie auf der Taskleiste Start, Alle Programme, Microsoft SQL Server 2008, SQL Server Management Studio aus.

2. Stellen Sie im Objekt-Explorer eine Verbindung mit einer Instanz des SQL Server 2008-Datenbankmoduls her, und erweitern Sie dann diese Instanz.

3. Erweitern Sie Datenbanken, klicken Sie mit der rechten Maustaste auf die zu verkleinernde Datenbank, und wählen Sie Tasks, Verkleinern, Dateien.

4. Wählen Sie den Dateityp und den Dateinamen aus.

5. Wählen Sie Dateien vor dem Freigeben von nicht belegtem Speicherplatz neu organisieren aus. Sie müssen auch den Wert für Datei verkleinern festlegen. Wählen Sie diese Option aus, um den gesamten nicht verwendeten Speicherplatz in der Datei für das Betriebssystem freizugeben und Zeilen zu den nicht zugewiesenen Seiten zu verschieben.

6. Klicken Sie auf OK.

Erstellen von SQL Server 2008-Wartungsplänen

Sie können programmgesteuert viele der in diesem Artikel beschriebenen Datenbankwartungsvorgänge anwenden, indem Sie SQL Server-Wartungspläne implementieren. Mit Wartungsplänen können wichtige Aufgaben automatisiert und geplant werden, um Ihre Daten zu schützen. Durch Verwendung von Wartungsplänen in SQL Server 2008 oder SQL Server 2005 kann ein Administrator Vorgänge wie das Ausführen von Datenbankkonsistenzprüfungen, Neuorganisieren von Indizes oder Neuerstellen von Indizes planen. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Wartungsplanungs-Assistent für SQL Server 2008.

• Datenbankwartungsplan-Assistent für SQL Server 2005.

So konfigurieren Sie einen SQL Server 2008-Datenbankwartungsplan

1. Wählen Sie auf der Taskleiste Start, Alle Programme, Microsoft SQL Server 2008, SQL Server Management Studio aus.

2. Stellen Sie im Objekt-Explorer eine Verbindung mit einer Instanz des SQL Server 2008-Datenbankmoduls her, und erweitern Sie dann diese Instanz.

3. Wählen Sie Verwaltung aus, klicken Sie mit der rechten Maustaste auf Wartungspläne, und wählen Sie dann Wartungsplanungs-Assistent aus.

4. Klicken Sie auf Weiter, bis Sie zur Seite Planeigenschaften auswählen gelangen.

   Abb. 4. Seite "Planeigenschaften auswählen"

   

5. Geben Sie in den Feldern Name und Beschreibung einen Namen und eine Beschreibung an.

6. Entscheiden Sie, ob Sie einen oder mehrere Wartungspläne konfigurieren möchten.

   • Wenn Sie einen einzelnen Wartungsplan konfigurieren möchten, wählen Sie Einzelner Zeitplan für den gesamten Plan oder kein Zeitplan aus.

   • Wenn Sie mehrere Wartungspläne mit bestimmten Aufgaben konfigurieren möchten, wählen Sie Getrennte Zeitpläne für jede Aufgabe aus.

   Wenn Ihre Umgebung zehn oder mehr Inhaltsdatenbanken oder mehr als 200 GB Inhalt enthält, wird die Konfiguration separater Wartungspläne empfohlen, damit die entsprechende Spezifität beibehalten wird und das Wartungsfenster so groß wie möglich ist.

   Wenn Sie mehrere Wartungspläne für eine Datenbank konfigurieren, geben Sie einen Namen oder eine Beschreibung an, mit dem bzw. der Sie die Pläne und ihre Zwecke, einschließlich der Zeitpläne, voneinander unterscheiden können.

7. Klicken Sie auf Ändern, um einen Zeitplan für einen oder mehrere Pläne festzulegen.

   Das Dialogfeld Eigenschaften des Auftragszeitplans wird angezeigt.

   Abb. 5. Dialogfeld "Eigenschaften des Auftragszeitplans"

   

8. Schließen Sie den Zeitplan ab, klicken Sie auf OK und dann auf Weiter.

9. Wählen Sie auf der Seite Wartungstasks auswählen die Wartungstasks aus, die in den Plan einbezogen werden sollen, und klicken Sie dann auf Weiter.

   Abb. 6. Seite "Wartungstasks auswählen"

   

   Beachten Sie die folgenden Hinweise:

   • Ein Wartungsplan sollte eine Neuorganisierung oder eine Neuerstellung des Indexes beinhalten, nicht beides.

   • Ein Wartungsplan sollte niemals das Verkleinern einer Datenbank beinhalten.

   • Wenn Sie die Dauer der einzelnen Aufgaben ermitteln möchten, sollten Sie alle Aufgaben einzeln testen, bevor Sie sie in einem Plan zusammenfassen. Sie müssen möglicherweise mehrere Wartungspläne mit separaten Zeitplänen definieren, damit Aufgaben zu einer Zeit fertiggestellt werden, in der die Benutzer nicht beeinträchtigt werden.

   • Der Task Wartungscleanup entfernt Dateien, die nach einer geplanten Wartung übriggeblieben sind.

10. Ändern Sie auf der Seite Wartungstaskreihenfolge auswählen die Reihenfolge der Wartungsplantasks, wenn dies erforderlich ist. Wählen Sie einen Task aus, und klicken Sie dann auf Nach oben oder Nach unten. Nachdem Sie die Tasks sortiert haben, klicken Sie auf Weiter.

    Hinweis

    Wenn Ihre Datenbanken sehr groß sind, möchten Sie möglicherweise einen separaten Wartungsplan erstellen, bei dem die Datenbankintegrität seltener überprüft wird als bei der Indexwartung.

    Abb. 7. Seite "Wartungstaskreihenfolge auswählen"

    

11. Als Nächstes führt Sie der Assistent durch das Festlegen der Details für jeden Task. Wählen Sie auf der Seite Task 'Datenbankintegrität überprüfen' definieren die Datenbanken aus, deren Integrität überprüft werden soll, und klicken Sie dann auf Weiter.

    Hinweis

    Sie können die Integrität aller SharePoint 2010-Datenbanken auf sichere Weise überprüfen.

    Abb. 8. Seite "Task 'Datenbankintegrität überprüfen' definieren

    

12. Geben Sie auf der Seite Task 'Index neu organisieren' definieren in der Liste Datenbanken die Datenbanken an, deren Indizes Sie neu organisieren möchten, aktivieren Sie das Kontrollkästchen Große Objekte komprimieren, und klicken Sie dann auf Weiter.

    Abb. 9. Seite "Task 'Index neu organisieren' definieren"

    

13. Wenn Indizes neu erstellt und nicht neu organisiert werden sollen, geben Sie auf der Seite Task 'Index neu erstellen' definieren in der Liste Datenbanken die Datenbanken an.

14. Wählen Sie Prozentsatz für freien Speicherplatz pro Seite ändern in aus, geben Sie 80 ein, und klicken Sie dann auf Weiter.

    Mit Prozentsatz für freien Speicherplatz pro Seite ändern in wird der Füllfaktor für die Datenbank festgelegt.

    Abb. 10. Seite "Task 'Index neu erstellen' definieren"

    

15. Geben Sie auf der Seite Task 'Wartungscleanup' definieren die erforderlichen Werte an, und klicken Sie dann auf Weiter.

    Tipp

    Es empfiehlt sich, dass Sie Wartungsplantextberichte löschen.

    Abb. 11. Seite "Task 'Wartungscleanup' definieren"

    

16. Wählen Sie auf der Seite Berichtsoptionen auswählen die Option Bericht in eine Textdatei schreiben aus, wählen Sie einen Ort für die Dateien aus, und klicken Sie dann auf Weiter, bis Sie den Assistenten fertig gestellt haben.

    Abb. 12. Seite "Berichtsoptionen auswählen"

    

Schlussbemerkung

Durch eine konsistente Wartung der Datenbanken, die SharePoint 2010 hosten, kann die Integrität und Leistung des Systems bedeutend verbessert werden.

Stellen Sie sicher, dass für alle Datenbanken zuverlässige Sicherungen vorhanden sind, bevor Sie Wartungsvorgänge und -pläne implementieren.

Bevor Sie einen Wartungsplan oder bestimmte konsistent ausgeführte Wartungsvorgänge implementieren, müssen Sie testen, welche Auswirkungen die Vorgänge auf das System haben und wie viel Zeit die Ausführung in Anspruch nimmt.

Legen Sie möglichst fest, dass Wartungsvorgänge oder -pläne außerhalb der Betriebszeiten ausgeführt werden, um Leistungsbeeinträchtigungen für Benutzer so gering wie möglich zu halten.

See Also

Other Resources

Dieses Thema ist auch als Download verfügbar