使用试验升级查找潜在问题 (SharePoint Foundation 2010)

 

适用于： SharePoint Foundation 2010

上一次修改主题： 2016-11-30

在开始从 Windows SharePoint Services 3.0 升级到 Microsoft SharePoint Foundation 2010 的过程之前，您将需要测试升级过程，以确保确切了解要成功进行升级所必须进行的操作。通过使用试验升级来测试该过程，您可以了解：

• 您的环境中有哪些自定义项，以便能够规划如何在升级过程中处理这些自定义项。

• 您是否应升级硬件以提高升级的效率和速度。

• 升级的时间，即在您的环境中进行升级将用多长时间。

• 您需要在操作上规划哪些内容 － 例如，要提供的资源。

此外，您可以使用试验升级来熟悉升级工具以及过程本身，以便了解进行实际过程时的预期结果。通过测试，您可以了解：

• 您的环境有哪些特殊情况，哪种升级方法对您而言效率最高？

• 升级用户界面什么样？如何知道您已完成一个阶段并将转入另一阶段？

• 日志文件在何处？如何查看日志文件？日志文件提供什么信息？

• 您可以使用哪些技术来减少停机时间？

本文提供了用于测试升级的基本步骤，并给出了有关根据在测试过程中了解的信息来审阅结果和调整升级计划的建议。

本文内容：

• 设置测试环境

• 确定和安装自定义项

• 将真实数据复制到测试环境并尝试升级

• 审阅结果

• 调整计划并再次测试

此外，当测试升级过程时，以下资源也会很有用：

• SharePoint Products 2010 升级工作表

  可使用此工作表在测试升级过程时记录有关环境的信息。可从 https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x804（该链接可能指向英文页面） 下载此工作表。

• Microsoft SharePoint 2010 产品 - 测试升级过程模型

  此海报以直观方式显示了有关测试升级过程的信息。可从 https://go.microsoft.com/fwlink/?linkid=166303&clcid=0x804（该链接可能指向英文页面） 下载此海报。

设置测试环境

您可使用虚拟或物理硬件来测试升级过程。每个环境都是唯一的，因此升级所用时间以及升级特定自定义项的困难程度没有一般原则可循。衡量升级情况的最佳方法是进行一系列试验性升级。

创建测试环境时：

• 使测试服务器场与实际服务器场尽可能保持一致，例如，具有相同的硬件、软件和可用空间。

• 在测试服务器场中使用与在实际服务器场中相同的 URL。（如果不这样做，您将因诊断与实际升级中不会出现的 URL 相关的问题而浪费时间。

• 确保将所有设置和自定义项传送到测试环境。确定和安装自定义项一节中提供了有关收集此信息的说明。

使用虚拟测试环境

当使用虚拟化测试环境进行测试时，无需使用大量硬件。只需使用两台运行 Hyper-V 的服务器即可复制您的环境。其中一台服务器具有前端 Web 服务器和应用程序服务器的映像，另一台服务器具有数据库服务器的映像。

使用物理测试环境

在使用物理环境进行测试时，您需要以尽可能接近的方式复制整个服务器场环境。如果过度减少前端 Web 服务器、应用程序服务器或数据库服务器的数目，将无法准确估计升级过程所用的时间，并且可能无法了解相同角色服务器之间进行交互（如 SQL Server 事务）的复杂性。如果原始服务器场中有多台服务器属于同一个角色，请在测试服务器场中为该角色至少使用两台服务器来测试此类问题。

用于数据库附加升级的其他测试环境

如果使用数据库附加升级方法，则可能需要另建一个测试环境：运行 Windows SharePoint Services 3.0 的一个单服务器场，您可以使用该服务器场在尝试升级数据之前运行升级前检查程序。

通过在现有生产服务器场上运行升级前检查程序，您可以避免此步骤。

确定和安装自定义项

为了使测试过程准确无误，您必须查找当前环境中的所有自定义项，并将它们复制到测试环境。有关您需要确定的自定项的类型的详细信息，请参阅确定如何处理自定义设置 (SharePoint Foundation 2010)。

• 使用升级前检查程序来确定您的环境中的网站定义、网站模板和功能。

  升级前检查程序将扫描每个网站集，并生成有关每个网站状态的报告。它还保存每个列表的列表定义信息。在启动升级过程之前，您可以查看这些报告以找到问题并将其解决。与 Windows SharePoint Services 3.0 的升级前扫描工具不同，升级前检查程序是一种只读工具，不会更改您的网站。有关此工具及其运行步骤的详细信息，请参阅针对未来版本的升级前扫描和报告 (Windows SharePoint Services) 和运行升级前检查程序 (SharePoint Foundation 2010)。

• 对 Windows SharePoint Services 3.0 环境中的所有内容数据库使用 Stsadm –o enumallwebs 操作，以确定子网站中的特定自定义项。此操作将列出环境中每个网站集和子网站的 ID，以及网站所依赖的模板。此操作是在 Windows SharePoint Services 3.0 Service Pack 2 (SP2) 中首次引入的。有关详细信息，请参阅 Enumallwebs：Stsadm 操作 (Windows SharePoint Services)。

• 使用 WinDiff 之类的工具（大多数 Microsoft 操作系统都提供此工具）将生产环境服务器与测试场服务器进行比较。您可以使用此工具来了解服务器上存在哪些文件以及这些文件之间的差异。

• 检查 web.config 文件是否有任何改动，并查看 SafeControls 元素以查找任何自定义控件。

• 使用 SharePoint 诊断工具 (SPDiag) 可查找已部署的解决方案。有关详细信息，请参阅 SharePoint 诊断工具 (SPDiag)。

• 创建找到的所有自定义项的列表。如有可能，请确定自定义项的来源。例如，是否有在内部自定义的第三方外接程序或模板？确定来源之后，可以检查这些自定义项是否有更新或升级版本。有一个工作表可用于填写有关环境的信息，这些信息基于在升级前检查程序的结果中找到的数据和在对自定义项的研究中找到的数据。可从 https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x804（该链接可能指向英文页面） 下载此工作表，并根据需要对其进行自定义。

提示

对于不是您创建的自定义项的相关问题，您应与谁联系？

• 如果在处理从 Microsoft 网站下载的模板（例如 Windows SharePoint Services 3.0 应用程序模板）时遇到问题，请与 Microsoft 联系。

• 如果在处理第三方解决方案供应商为以前的版本提供的模板或组件时遇到问题，请与这些供应商联系。他们可能会提供升级版本。

在识别所有自定义项之后，请将它们复制到测试服务器场中适当的服务器上。在将数据库附加到 SharePoint Foundation 2010 之前，可以使用 Windows PowerShell cmdlet test-spcontentdatabase 来确定环境中是否缺少任何自定义项。在将数据库还原到数据库服务器之后但在运行升级之前，请为每个数据库运行此命令。请注意，此 cmdlet 以静默方式运行，除非存在错误，否则它将不会返回任何输出。

将真实数据复制到测试环境并尝试升级

除非使用实际数据，否则将无法实现测试目标。可以使用以下方法来创建数据的副本：

• 对于就地升级，请创建服务器场备份，然后将其还原到测试环境。有关详细信息，请参阅备份和还原完整服务器场（Windows SharePoint Services 3.0 技术）。

• 对于数据库附加升级，您需要使用 Microsoft SQL Server 备份和还原工具来创建内容数据库以及希望升级的任何其他数据库的副本。有关详细信息，请参阅备份和还原内容数据库 (Windows SharePoint Services 3.0)。

除了针对所有数据的副本进行测试外，没有其他更好的方式来了解在升级过程中可能发生的情况；但是，在进行初始测试时，实际上并不总是会选择此方法。您可以将测试分为多个阶段，每次测试一个数据库（如果数据库很大），这样可以确保测试数据集的特有内容，或者可以组合使用来自环境中代表性网站的数据子集。如果您想先使用一个数据子集进行测试，则请确保该子集具有下列特征：

• 数据子集包含您的环境所支持的典型网站。

• 该数据子集的大小和复杂性与环境的实际大小和复杂性非常相似。

重要

测试数据子集并不会生成关于处理环境的全部数据量将花费多长时间的有效基准。

复制数据之后，先执行一遍升级过程以观察发生的情况。这只是首轮测试。

尝试就地升级

如果要尝试就地升级方法，请使用以下步骤来试验升级过程：

1. 创建服务器场的备份。

2. 将备份还原到测试服务器场。

   有关详细信息，请参阅备份和还原完整服务器场（Windows SharePoint Services 3.0 技术）。

3. 运行升级前检查程序。记下该工具所发现的任何问题。在生产服务器场上运行实际升级之前，您将需要在原始环境中解决这些问题。有关详细信息，请参阅运行升级前检查程序 (SharePoint Foundation 2010)。

4. 按照执行就地升级 (SharePoint Foundation 2010)中的步骤尝试就地升级。

5. 审阅结果。

尝试数据库附加升级

1. 创建内容数据库的 SQL Server 备份。

2. 使用 SQL Server 将备份还原到单服务器测试场中，并将内容数据库附加到该环境。

   有关详细信息，请参阅备份和还原内容数据库 (Windows SharePoint Services 3.0)。

3. 运行升级前检查程序。记下该工具所发现的任何问题以及做出的任何更改。在生产服务器场上运行实际升级之前，您将需要在原始环境中解决这些问题并进行相应更改。有关详细信息，请参阅运行升级前检查程序 (SharePoint Foundation 2010)。

4. 按照准备新的 SharePoint Foundation 环境中的步骤进行操作，以针对数据库附加升级配置测试环境。

5. 按照附加数据库并升级到 SharePoint Foundation 2010 中的步骤进行操作，以尝试数据库附加升级过程。

审阅结果

测试升级完成之后，可以审阅结果并重新检查计划。查看日志文件、查看升级的网站，并签出自定义项。对于您的环境，升级的工作情况怎么样？您发现了什么情况？您需要如何重新考虑升级计划？

审阅日志文件

审阅以下日志文件：

• 升级前检查程序日志文件。

  升级前检查程序 (stsadm -o preupgradecheck) 的日志文件位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS 中。日志文件按以下格式命名：PreUpgradeCheck_YYYYMMDD-HHMMSS-SSS-随机数字.log，其中 YYYYMMDD 是日期，HHMMSS-SSS 是时间（24 小时制的小时数，然后是分钟数、秒数和毫秒数），随机数字用于区分可能发生的同步运行升级前检查程序的多个操作。

• SharePoint 产品配置向导 (Psconfig.exe) 日志文件（在试验就地升级的过程中运行此向导时生成）。

  PSCDiagnostics 日志文件位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS 中。

• 升级日志文件和升级错误日志文件（在运行升级时生成）。

  升级日志文件 (.log) 和升级错误日志文件 (.err) 位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS 中。日志文件按以下格式命名：Upgrade-YYYYMMDD-HHMMSS-SSS.log，其中 YYYYMMDD 是日期，HHMMSS-SSS 是时间（24 小时制的小时数，然后是分钟数、秒数和毫秒数）。

若要审阅日志文件以查找和解决问题，请从文件的开头开始。如果环境中的几个网站集都发生错误或警告，或者错误或警告完全阻止了升级过程，则这些错误或警告可能重复出现。例如，如果您无法连接到配置数据库，则升级过程将尝试（并失败）数次，而这些尝试将列在日志文件中。

搜索或直接浏览查找以下条目：

• Finished upgrading SPFarm Name= <配置数据库的名称>

• In-place upgrade session finishes. Root object = SPFarm= <配置数据库的名称> , recursive = True. 0 errors and 0 warnings encountered.

如果找到这些条目，则表明安装成功。

如果在上一步中未找到这些条目，则可以在 Upgrade.log 文件中搜索或直接浏览查找下列词条，以确定可能造成失败的特定问题：

• 在日志文件中搜索 ERROR 以查找任何失败错误（如组件失败或数据库连接错误）。

• 搜索 WARNING 以查找缺少功能或组件之类的问题。

若要查找升级问题，您可能会发现使用日志分析程序针对日志文件运行查询将非常有用。

必要时重新启动升级

在数据库附加升级过程中，将跳过任何无法升级的网站。在就地升级过程中，如果服务器重新启动或升级失败，则需要重新启动升级过程以升级其余的网站。

若要查看在升级过程中是否遗漏或跳过了任何网站，请在 SharePoint Foundation 2010 服务器场中的每台前端 Web 服务器上运行以下 Stsadm 操作：stsadm -o localupgradestatus。有关此操作的详细信息，请参阅 Localupgradestatus：Stsadm 操作 (Windows SharePoint Services)。

如果升级时跳过任何网站集，则可以使用以下 Windows PowerShell cmdlet 对包含该网站集的数据库重新启动升级过程：upgrade-spcontentdatabase -id <GUID>。有关此 cmdlet 的详细信息，请参阅 Upgrade-SPContentDatabase。

有关详细信息，请参阅继续升级 (SharePoint Foundation 2010)。

审阅升级后的网站

在生产环境中运行升级过程之前，请审阅升级后的网站以找出任何需要解决的问题。有关要查找的特定内容的详细信息，请参阅验证升级和审阅升级后的网站 (SharePoint Foundation 2010)。

调整计划并再次测试

重复测试过程，直至您确信已找到了所有可能面临的问题，并且知道如何处理这些问题。您的目标是明确以下问题：假设现在是星期日下午 4:00，您必须在星期一早上重新实现联机，但升级进行得不顺利，这种情况下您有什么计划？您是否已经没有退路？请测试您的回滚计划，并在您开始实际升级之前确保该计划的有效性。