估计升级过程将花费的时间和所需的空间量 (SharePoint Foundation 2010)
适用于： SharePoint Foundation 2010
上一次修改主题： 2016-11-30
规划从 Windows SharePoint Services 3.0 到 Microsoft SharePoint Foundation 2010 的升级过程时最重要的是确定生成过程将花费的时间和将需要的存储空间。每个环境都独一无二，包括不同的硬件功能和不同的网站特征。运行升级所需的空间和时间长度根据环境不同会有较大的差异。估计这些因子的最好方法是执行一个试验升级，然后查看该升级所占用的空间和时间。有关如何执行试验升级的详细信息，请参阅使用试验升级查找潜在问题 (SharePoint Foundation 2010)。
本文内容：
估计升级所需的空间
估计升级将花费的时间
估计升级所需的空间
对于就地升级方法和数据库附加升级方法，升级过程中数据库都有可能会扩展。另外，升级过程运行时还会发生大量事务，因此必须确保日志文件有空间可扩展以容纳正在发生的更改。您必须对数据库和日志文件进行增长规划。
计划升级时，请确保您的当前环境遵循 Windows SharePoint Services 3.0 关于存储的最佳做法，以便在升级过程中您可以获得最佳体验和性能。有关详细信息，请参阅物理存储建议 (Office SharePoint Server)。您还应该查看有关 SharePoint Foundation 2010 的最佳做法并对升级后的环境进行任何所需的调整。
由于在新版本中表结构发生了更改，因此在重新组织数据时数据库将临时增长。升级后可以恢复此增长的空间，但您应确保在运行就地升级或数据库附加升级时，存在相当于数据库当前大小 50% 的空间，以防数据库增加这么多空间（请注意，在升级后，您可以再次减少数据库以恢复该空间中的一大部分）。您还应确保数据库服务器上具有空间，可满足数据库因典型用途而随时间不断增长的结果。若要了解数据库当前的大小，请使用 Microsoft SQL Server 中的“企业管理器”。除了数据库空间以外，还必须具有可供以下项使用的空间：
临时数据库。请确保具有足够的数据库空间，以便能够满足快速增长的临时数据库对空间的需求。如果没有足够的空间，则升级过程可能会超时，并且升级将失败。
升级日志文件。
数据库的事务日志文件。这些日志文件必须迅速增大以适应数据库中发生的更改次数。
备注
在超大型环境中，事务日志文件的默认增长率 (10%) 有可能跟不上升级过程；这会导致超时。此外，若要确定事务日志文件能否跟上升级过程，试验升级是最佳方法。如果环境非常大，或者升级过程在试验升级期间超时，请考虑预先扩展 SQL Server 事务日志文件以确保有空间可用于必须处理的事务数。有关如何扩展 SQL Server 事务日志的详细信息，请参阅扩展数据库 (SQL Server 2005) (https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x804) 或扩展数据库 (SQL Server 2008) (https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x804)。
估计升级将花费的时间
得到磁盘空间的估计值并且进行一些测试后，现在可以计算实际升级过程所需时间的粗略估计值。在不同环境中，升级时间会有很大差异。升级的性能主要取决于所使用的硬件、网站的复杂程度以及实现的特定特征。例如，如果有许多大型文档库，则升级这些文档库所花费的时间可能就比升级简单网站长。
下表描述了影响性能的因素。
| 内容因素 | 硬件因素 |
|---|---|
数量：
包括整体数据库本身的大小。 |
|
数据结构的设计方式会影响到数据升级所要花费的时间。例如，每个含有 10 项的 10,000 个列表的升级时间将比每个含有 10,000 项的 10 个列表的升级时间要长。必须为每个列表执行升级列表基础结构所需的操作，而不考虑项的数量；因此，列表越多就等于是操作越多。对于上表中“内容因素”列中的大多数项都是如此。
硬件的结构也会对性能造成很大的影响。通常，数据库服务器的性能要比 Web 服务器的性能更加重要，但是任一层上硬件动力不足或连接有问题会严重影响升级性能。
所选择的升级方法也会使升级过程所需时间有很大差异。执行数据库附加升级是最快速的方法（但是，此方法的升级前和升级后步骤所需时间比就地升级要长）。就地升级花费的时间要多一点，因为您除了升级网站还要升级环境，但使用此方法时就不必执行那么多的升级前和升级后步骤了。
估计总时间的最佳方法是对一小部分或所有数据进行试验升级，然后查看升级日志文件。日志文件中包含升级过程的持续时间（请查看升级日志文件底部的“经过的总时间”）。使用此时间可以计划全套内容的持续时间。在升级过程中还可以使用日志文件检查进度。该 upgrade.log 文件位于 %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS 中。
根据试验升级得出的估计时间只是针对数据的实际升级过程的时间；它并不包括此步骤之前和之后必须执行的所有步骤所需的时间，而这些步骤花费的时间可能比升级数据本身所需时间更长。在估计升级将花费的时间时，除了估计处理数据所需的时间之外，还必须估计升级前和升级后这两个阶段的活动将花费的时间。
对于升级前步骤，请考虑以下因素：
创建自定义元素 创建 Web 部件或重做自定义模板以利用新功能将花费一些时间。创建自定义元素的过程应在项目的评估阶段中尽早开始。
备份数据库 对于就地升级，必须执行整个环境的完整备份（而非差异备份），以确保能够在升级失败而必须重建服务器场时（这种可能性微乎其微）进行恢复。对于大型环境，此步骤可能会花费大量时间。尤其是备份到网络位置时，网络延迟问题会减慢这一过程。
对于升级后步骤，请考虑以下因素：
- 验证网站并进行更改 给用户足够的时间在升级后验证其网站。这可能需要几天时间。有关详细信息，请参阅验证升级和审阅升级后的网站 (SharePoint Foundation 2010)。
环境中的其他因素也会导致升级时间变长，这些因素包括：
超大型文档库 如果文档库中有超过 250,000 个文档，且所有文档都位于文档库的根中（而非文件夹中），则升级这样的库将花费很长时间，并且升级可能会失败。遵照使用文件夹分解大型文档库的 Windows SharePoint Services 3.0 指导标准可以帮助您管理库的大小。例如，如果重新排列同一文档库，使 250,000 个文档划分为 125 个文件夹，则升级这样的文档库应该更容易些。
超大型数据库 升级大于 100 GB 的数据库需要很长时间。
备注
如果您的内容数据库大于 100 GB，则您可能需要在运行升级之前将其分隔为一些较小的数据库。大型数据库不仅需要花费更长时间来升级，还使升级失败后的恢复变得更加困难。
可以使用 Stsadm.exe 中的 mergecontentdbs 或 backup 和 restore 操作在数据库之间移动网站。有关详细信息，请参阅 Mergecontentdbs：Stsadm 操作 (Windows SharePoint Services) 和 Backup 和 restore：Stsadm 操作 (Windows SharePoint Services)。如果您拥有无法拆分（因为大部分内容在一个网站集中）的超大型数据库（大于 100 GB），则可能需要重新考虑升级方法。数据库附加升级方法较难处理超大型数据库，因为备份和还原如此之大的数据库本身就是个问题。
警告
尝试升级之前，请遵循以前版本和新版本中的容量规划指导标准。如果超出了最佳性能指导标准，则升级过程可能花费更长时间，还可能失败（例如，升级过程对同一大型文档库可能重复超时）。如果部署不满足推荐的容量指导标准，则在尝试升级之前请考虑是否需要做些什么来满足这些指导标准。此外，试验升级可以帮助您做出该决定。
通信要求
需要通知您的用户和升级计划团队，并给他们留出一些时间来完成各自的任务。有关详细信息，请参阅创建沟通计划 (SharePoint Foundation 2010)。
管理系统中心警报和告警
升级过程中需要监视系统的性能，但不需要监视特定的功能。暂停来自 Microsoft Systems Center Operations Manager 或 Microsoft Operations Manager 的任何不需要的警报和告警，然后在升级后重新开启这些警报。
打开/关闭 SQL 监视和日志传送功能
升级前应关闭监视和日志传送功能，然后在升级后，已确定环境运行正确时重新打开这些功能。建议不要在升级的过程中运行监视或日志传送功能，因为这样会在运行 SQL Server 的服务器上创建其他负载，另外还会因监视或传送的是临时数据而浪费资源。
测试升级过程以了解该过程可能会花费的时间，然后针对升级操作创建一个计划并测试该计划，以确定您的时间线。应在操作时间线中包括执行升级前和升级后步骤所需的时间：如果开始前需要 5 个小时来备份环境，则需要在中断窗口中包括这段时间。另外还应包括缓冲时间以防您需要执行还原或恢复操作，即应同时确定计划的中断时间线（现实情况）和紧急的中断时间线（最糟情况）。