Schätzen der Dauer des Upgradevorgangs und des benötigten Speicherplatzes (SharePoint Server 2010)

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Ein wichtiger Aspekt bei der Planung des Upgrades von Microsoft Office SharePoint Server 2007 auf Microsoft SharePoint Server 2010 besteht in der Bestimmung der Dauer des Upgradevorgangs und des erforderlichen Speicherplatzes. Jede Umgebung ist eindeutig und enthält verschiedene Hardwarefunktionen und unterschiedliche Websitemerkmale. Die Menge an Speicherplatz und der Zeitaufwand zum Ausführen eines Upgrades variieren zwischen Umgebungen erheblich. Die beste Möglichkeit zum Einschätzen des erforderlichen Speicherplatzes und der Dauer des Upgradevorgangs ist die Ausführung eines Testupgrades und die anschließende Überprüfung des benötigten Speicherplatzes und des benötigten Zeitaufwands. Weitere Informationen zum Ausführen eines Testupgrades finden Sie unter Verwenden eines Testupgrades zur Ermittlung möglicher Probleme (SharePoint Server 2010).

Inhalt dieses Artikels:

  • Schätzen des für das Upgrade benötigten Speicherplatzes

  • Schätzen der Upgradedauer

Schätzen des für das Upgrade benötigten Speicherplatzes

Beim direkten Upgrade und beim Upgrade durch Datenbankanfügungen nimmt möglicherweise die Größe der Datenbanken während des Upgrades zu. Während des Upgradevorgangs werden außerdem zahlreiche Transaktionen ausgeführt, weshalb die Protokolldateien zum Speichern der Änderungen mehr Speicherplatz benötigen. Sie müssen den zusätzlichen Speicherplatz sowohl für die Datenbanken als auch für die Protokolldateien berücksichtigen.

Stellen Sie beim Planen des Upgrades sicher, dass bei Ihrer aktuellen Umgebung die bewährten Methoden zum Speichern für Office SharePoint Server 2007 berücksichtigt werden, damit während des Upgrades ein optimales Leistungsverhalten gegeben ist. Weitere Informationen finden Sie unter Empfehlungen für den physischen Speicher (Office SharePoint Server). Außerdem sollten Sie die bewährten Methoden für SharePoint Server 2010 nachlesen und etwaige erforderliche Anpassungen an der aktualisierten Umgebung vornehmen.

Aufgrund der Änderungen an den Tabellenstrukturen in der neuen Version nimmt die Größe der Datenbanken temporär zu, während die Daten neu angeordnet werden. Dieser Speicherplatz kann nach dem Upgrade wieder freigegeben werden. Sie sollten aber sicherstellen, dass ausreichend Speicherplatz vorhanden ist, sodass die Datenbanken während eines direkten Upgrades oder eines Upgrades durch Datenbankanfügungen im Vergleich zur aktuellen Größe um bis zu 50 % vergrößert werden können (nach dem Upgrade kann die Datenbank wieder reduziert und ein Großteil dieses Speicherplatzes wieder freigegeben werden). Darüber hinaus sollten Sie darauf achten, dass auf den Datenbankservern ausreichend Speicherplatz für die Vergrößerung der Datenbanken bei typischer Verwendung vorhanden ist. Mit Enterprise Manager in Microsoft SQL Server können Sie die aktuelle Größe der Datenbanken feststellen. Zusätzlich zum Datenbankspeicherplatz benötigen Sie auch Speicherplatz für die folgenden Elemente:

  • Die temporären Datenbanken. Stellen Sie sicher, dass ausreichend Datenbankspeicherplatz für rasch anwachsende temporäre Datenbanken vorhanden ist. Bei unzureichendem Speicherplatz kommt es möglicherweise zu einem Timeout beim Upgradevorgang und das Upgrade schlägt fehl.

  • Die Upgradeprotokolldateien.

  • Die Transaktionsprotokolldateien für die Datenbanken. Diese Protokolldateien müssen schnell anwachsen können, um die vielen Änderungen in den Datenbanken aufzuzeichnen.

    Hinweis

    In sehr großen Umgebungen ist es möglich, dass die standardmäßige Wachstumsrate für die Transaktionsprotokolldateien (10 %) nicht ausreicht, um mit dem Upgradevorgang Schritt zu halten. Dies kann zu einem Timeout führen. Auch in diesem Fall stellt ein Testupgrade die beste Methode dar, um festzustellen, ob die Transaktionsprotokolldateien mit dem Upgradevorgang Schritt halten können. Wenn Ihre Umgebung sehr groß ist oder der Vorgang während eines Testupgrades wegen eines Timeouts beendet wurde, sollten Sie eventuell die SQL Server-Transaktionsprotokolldateien vorab vergrößern, damit genügend Speicherplatz für die zu verarbeitenden Transaktionen vorhanden ist. Weitere Informationen zur Vergrößerung der SQL Server-Transaktionsprotokolldateien finden Sie unter Erweitern einer Datenbank (SQL Server 2005) (https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x407) oder Erweitern einer Datenbank (SQL Server 2008) (https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x407).

Schätzen der Upgradedauer

Nachdem Sie den benötigten Speicherplatz geschätzt und einige Tests durchgeführt haben, können Sie nun berechnen, wie lange der eigentliche Upgradevorgang dauern wird. Die Upgradedauer kann je nach Umgebung stark variieren. Die Leistung für ein Upgrade hängt stark von der verwendeten Hardware, von der Komplexität der Websites und den speziellen Merkmalen Ihrer Implementierung ab. Wenn Sie beispielsweise über viele große Dokumentbibliotheken verfügen, wird das Upgrade wahrscheinlich länger dauern als bei einer einfacheren Website.

Die Faktoren, die die Leistung beeinflussen, werden in der folgenden Tabelle beschrieben.

Faktoren im Zusammenhang mit dem Inhalt Faktoren im Zusammenhang mit der Hardware

Anzahl von:

  • Websitesammlungen

  • Unterwebsites

  • Listen

  • Dokumentversionen (Anzahl und Größe)

  • Dokumente

  • Links

Plus die Gesamtgröße der Datenbank selbst.

  • SQL Server-Datenträger-E/A pro Sekunde

  • SQL Server-Datenbank und Datenträgerlayout

  • Optimierungen der temporären SQL Server-Datenbank

  • CPU- und Arbeitsspeichermerkmale für SQL Server

  • CPU- und Arbeitsspeichermerkmale für den Webserver

  • Netzwerkbandbreite und Wartezeit

Die Struktur der Daten kann sich auf die Dauer des Upgradevorgangs auswirken. Beispielsweise dauert das Upgraden von 10.000 Listen mit jeweils 10 Elemente länger als das Upgraden von 10 Listen mit jeweils 10.000 Elementen. Die zum Upgraden der Listeninfrastruktur erforderlichen Aktionen müssen unabhängig von der Anzahl von Elementen für jede Liste ausgeführt werden. Deshalb bedeuten mehr Listen auch mehr Aktionen. Dasselbe gilt für die meisten Elemente in der Spalte "Faktoren im Zusammenhang mit dem Inhalt" der oben aufgeführten Tabelle.

Die Struktur der Hardware kann ebenfalls große Auswirkungen auf die Leistung haben. Im Allgemeinen ist die Leistung des Datenbankservers wichtiger als die Leistung des Webservers, aber Hardware mit zu geringer Leistung oder Verbindungsproblemen auf einer der Ebenen können erhebliche Auswirkungen auf die Upgradeleistung haben.

Die gewählte Upgrademethode hat ebenfalls großen Einfluss auf die Dauer des Upgradevorgangs. Das Upgrade durch Datenbankanfügungen ist die schnellste Methode (beachten Sie jedoch, dass die Schritte vor und nach dem eigentlichen Upgradevorgang viel mehr Zeit in Anspruch nehmen als beim direkten Upgrade). Das direkte Upgrade dauert ein bisschen länger, da Sie neben den Websites auch die Umgebung upgraden, aber mit dieser Methode müssen Sie nicht so viele Schritte vor und nach dem Upgradevorgang ausführen.

Die beste Möglichkeit zum Schätzen der Gesamtdauer besteht im Ausführen eines Testupgrades für einen kleinen Teil der Daten und der anschließenden Überprüfung der Upgradeprotokolldateien. Die Protokolldateien enthalten die Dauer des Upgrades – suchen Sie am Ende der Upgradeprotokolldatei nach Gesamte abgelaufene Zeit. Mithilfe dieser Zeitangabe können Sie den Zeitaufwand für den kompletten Inhalt abschätzen. Anhand der Protokolldateien können Sie auch den Fortschritt während des Upgradevorgangs überprüfen. Die Datei upgrade.log ist im Verzeichnis %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS gespeichert.

Die Schätzung, die Sie basierend auf dem Testupgrade vornehmen, gilt nur für den eigentlichen Datenupgradevorgang; die Schritte, die Sie vor und nach diesem Vorgang ausführen müssen und mehr Zeit in Anspruch nehmen können als das eigentliche Upgrade der Daten, sind darin nicht enthalten. Bei der Schätzung der Upgradedauer müssen Sie neben dem Zeitaufwand zur Verarbeitung der Daten daher auch schätzen, wie lange die Aktivitäten vor und nach dem eigentlichen Datenupgradevorgang dauern werden.

Berücksichtigen Sie beim Planen der Schritte vor dem Upgrade die folgenden Faktoren:

  • Erstellen benutzerdefinierter Elemente   Das Upgraden von Webparts oder das erneute Erstellen benutzerdefinierter Vorlagen für die Nutzung neuer Features nimmt einige Zeit in Anspruch. Daher sollten Sie mit der Erstellung benutzerdefinierter Elemente schon frühzeitig, während der Testphase des Projekts, beginnen.

  • Sichern der Datenbanken   Für eine direkte Sicherung müssen Sie eine vollständige Sicherung – keine differenzielle Sicherung – der gesamten Umgebung vornehmen, damit Sie für den unwahrscheinlichen Fall, dass beim Upgrade Fehler auftreten und Sie Ihre Serverfarm neu erstellen müssen, gewappnet sind. Bei großen Umgebungen kann dieser Schritt sehr viel Zeit beanspruchen. Insbesondere können, wenn Sie in eine Netzwerkadresse sichern, Netzwerkwartezeitprobleme diesen Vorgang verlangsamen.

Berücksichtigen Sie beim Planen der Schritte nach dem Upgrade die folgenden Faktoren:

  • Überprüfen und Ändern von Websites   Geben Sie den Benutzern nach dem Upgrade genügend Zeit, um ihre Websites zu überprüfen. Dies kann mehrere Tage in Anspruch nehmen. Weitere Informationen finden Sie unter Überprüfen des Upgrades und aktualisierter Websites (SharePoint Server 2010).

  • Erstellen der Dienstanwendungen und Konfigurieren der Dienste   Dieser Schritt gilt nur für Upgrades durch Datenbankanfügungen (bei einem direkten Upgrade werden die Dienstanwendungen im Rahmen des Upgradevorgangs erstellt). Das Erstellen von Dienstanwendungen und das Konfigurieren von Diensten dauert nicht lange. Wenn die Datenbanken jedoch vorab von einem Datenbankadministrator erstellt werden sollen, benötigen Sie eventuell einen oder zwei Tage Vorlaufzeit.

  • Konvertieren der Profileigenschaften zu Taxonomiedaten und Aktualisieren des Fotospeichers für Benutzerprofildienste   Sie müssen Benutzerprofileigenschaften konvertieren, die Auswahllisten einschließen, sodass die mit dem verwalteten Metadatendienst bereitgestellten Taxonomiefeatures verwendet werden. Abhängig von der Anzahl der Benutzerprofile in der Umgebung kann der Upgradevorgang durch diese Schritte um eine oder mehrere Stunden verlängert werden.

  • Ausführen eines Personencrawls Bei großen Organisationen kann dieser Schritt mehr als 24 Stunden dauern.

  • Ausführen eines Suchcrawls im gesamten Inhalt Bei großen Websites kann dieser Schritt mehr als 24 Stunden dauern.

Weitere Faktoren in Ihrer Umgebung können ebenfalls zu einer längeren Upgradedauer beitragen, z. B.:

  • Sehr große Dokumentbibliotheken   Das Upgrade einer Dokumentbibliothek mit mehr als 250.000 Dokumenten, die sich alle im Stammverzeichnis der Dokumentbibliothek befinden (und nicht in Ordnern), kann sehr lange dauern und möglicherweise nicht erfolgreich sein. Durch die Einhaltung der Richtlinien für Microsoft Office SharePoint Server 2007 zur Aufteilung großer Dokumentbibliotheken in Ordner können Sie die Größe der Bibliothek beschränken. Wenn Sie beispielsweise die 250.000 Dokumente der zuvor genannten Dokumentbibliothek in 125 Ordner unterteilen, sollte das Upgrade einfacher sein.

  • Sehr große Datenbanken   Das Upgrade von Datenbanken, die größer als 100 GB sind, kann lange dauern

    Hinweis

    Wenn Sie über Inhaltsdatenbanken verfügen, die größer als 100 GB sind und gemischte Websitetypen enthalten (z. B. Meine Website-Websites und Teamwebsites zusammen mit veröffentlichten Websites), wird empfohlen, diese vor dem Upgrade in kleinere Datenbanken mit einem einheitlichen Datentyp zu unterteilen. Bei größeren Datenbanken nimmt nicht nur das Upgrade mehr Zeit in Anspruch, sondern sie sind auch schwieriger wiederherzustellen, wenn das Upgrade nicht erfolgreich abgeschlossen wird.
    Zum Verschieben von Websites zwischen Datenbanken können Sie die Vorgänge mergecontentdbs oder backup und restore in Stsadm.exe verwenden. Weitere Informationen finden Sie unter Mergecontentdbs: Stsadm-Vorgang (Office SharePoint Server) und Sicherung und Wiederherstellung: Stsadm-Vorgänge (Office SharePoint Server).

    Wenn Sie über eine sehr große Datenbank verfügen (mit mehr als 100 GB), die Sie nicht unterteilen können, da sich der Großteil des Inhalts in einer einzigen Websitesammlung befindet, sollten Sie vielleicht eine andere Upgrademethode verwenden. Ein Upgrade durch Datenbankanfügungen ist bei sehr großen Datenbanken schwieriger, da das Sichern und Wiederherstellen solcher großen Datenbanken problematisch ist.

    Warnung

    Achten Sie darauf, dass Sie die Kapazitätsplanungsrichtlinien der vorherigen und neuen Version befolgen, bevor Sie ein Upgrade versuchen. Wenn Sie die Richtlinien für optimale Leistung überschritten haben, kann der Upgradevorgang länger dauern oder möglicherweise nicht erfolgreich sein (z. B. könnte der Vorgang immer wieder bei derselben großen Dokumentbibliothek wegen eines Timeouts abgebrochen werden). Wenn Ihre Bereitstellung die empfohlenen Kapazitätsrichtlinien nicht erfüllt, sollten Sie überlegen, ob es vielleicht möglich wäre, die Richtlinien vor dem Upgrade mit wenig Arbeitsaufwand zu erfüllen. Ein Testupgrade kann Ihnen bei dieser Entscheidung behilflich sein.

  • Kommunikationsanforderungen

    Sie müssen die Benutzer und das Team über den Upgradezeitplan informieren und ihnen Zeit zur Erledigung ihrer Aufgaben geben. Weitere Informationen finden Sie unter Erstellen eines Kommunikationsplans (SharePoint Server 2010).

  • Verwalten von System Center-Benachrichtigungen und - Alarmen

    Sie müssen die Systemleistung während des Upgrades überwachen, aber Sie müssen keine speziellen Features überwachen. Deaktivieren Sie nicht notwendige Alarme und Benachrichtigungen von Microsoft System Center Operations Manager oder Microsoft Operations Manager, und aktivieren Sie diese nach dem Upgrade erneut.

  • Aktivieren/Deaktivieren der SQL-Spiegelung und des Protokollversands

    Sie sollten die Spiegelung und den Protokollversand vor dem Upgrade deaktivieren und nach dem Upgrade erneut aktivieren, wenn Sie sicher sind, dass die Umgebung ordnungsgemäß ausgeführt wird. Es wird empfohlen, die Spiegelung und den Protokollversand während des Upgrades nicht auszuführen, da dadurch die Server mit SQL Server zusätzlich ausgelastet und außerdem Ressourcen mit der Spiegelung oder dem Versand temporärer Daten verschwendet würden.

Testen Sie den Upgradevorgang, um festzustellen, wie lange er dauert. Erstellen Sie anschließend einen Zeitplan für die Upgradevorgänge, und testen Sie diese, um den Zeitaufwand zu bestimmen. Sie sollten dabei auch die Zeit für die Ausführung der Schritte vor und nach dem Upgrade berücksichtigen: Wenn das Sichern der Umgebung vor Beginn des Upgrades 5 Stunden dauert, müssen Sie diese Zeit in die Ausfallzeit einschließen. Berücksichtigen Sie auch Pufferzeit für den Fall, dass eine Wiederherstellung erforderlich ist – Sie sollten sowohl die geplante Ausfallzeit (realistischer Fall) als auch die Notausfallzeit (schlimmster Fall) bestimmen.