发布: 2010 年 5 月 12 日
在开始从 Microsoft Office SharePoint Server 2007 升级到 Microsoft SharePoint Server 2010 的过程之前,您将需要测试升级过程,以确保确切了解要成功进行升级所必须执行的操作。通过使用试验升级来测试该过程,您可以了解:
此外,您可以使用试验升级来熟悉升级工具以及过程本身,以便了解进行实际过程时的预期结果。通过测试,您可以了解:
-
您的环境有哪些特殊情况,哪种升级方法对您而言效率最高?
-
升级用户界面什么样?如何知道您已完成一个阶段并将转入另一阶段?
-
日志文件位于何处,如何读取日志文件?日志文件提供什么信息?
-
您可以使用哪些技术来减少停机时间?
本文提供了用于测试升级的基本步骤,并给出了有关根据在测试过程中了解的信息来审阅结果和调整升级计划的建议。
本文内容:
此外,当测试升级过程时,以下资源也会很有用:
设置测试环境
您可使用虚拟或物理硬件来测试升级过程。每个环境都是唯一的,因此升级所用时间以及升级特定自定义项的困难程度没有一般原则可循。衡量升级情况的最佳方法是进行一系列试验性升级。
创建测试环境时:
-
使测试服务器场与实际服务器场尽可能保持一致,例如,具有相同的硬件、软件和可用空间。
-
在测试服务器场和实际服务器场中使用相同的 URL。(否则,您将会浪费时间来诊断实际升级中将不会出现的 URL 相关问题。)
-
确保将所有设置和自定义项传送到测试环境。确定和安装自定义项一节中提供了有关收集此信息的说明。
使用虚拟测试环境
当使用虚拟化测试环境进行测试时,无需使用大量硬件。只需使用两台运行 Hyper-V 的服务器即可复制您的环境。其中一台服务器具有前端 Web 服务器和应用程序服务器的映像,另一台服务器具有数据库服务器的映像。
使用物理测试环境
在使用物理环境进行测试时,您需要以尽可能接近的方式复制整个服务器场环境。如果过度减少前端 Web 服务器、应用程序服务器或数据库服务器的数目,将无法准确估计升级过程所用的时间,并且可能无法了解相同角色服务器之间进行交互(如 SQL Server 事务)的复杂性。如果原始服务器场中有多台服务器属于同一个角色,请在测试服务器场中为该角色至少使用两台服务器来测试此类问题。
用于数据库附加升级的其他测试环境
如果使用数据库附加升级方法,则可能需要另建一个测试环境:运行 Office SharePoint Server 2007 的一个单服务器场,您可以使用该服务器场在尝试升级数据之前运行升级前检查程序。
通过在现有生产服务器场上运行升级前检查程序,您可以避免此步骤。
确定和安装自定义项
为了使测试过程准确无误,您必须查找当前环境中的所有自定义项,并将它们复制到测试环境。有关需要标识的自定义项类型的详细信息,请参阅确定如何处理自定义项 (SharePoint Server 2010)。
提示: |
|---|
|
对于不是您创建的自定义项的相关问题,您应与谁联系?
|
在识别所有自定义项之后,请将它们复制到测试服务器场中适当的服务器上。在将数据库附加到 SharePoint Server 2010 之前,可以使用 Windows PowerShell cmdlet test-spcontentdatabase 来确定环境中是否缺少任何自定义项。在将数据库还原到数据库服务器之后但在运行升级之前,请为每个数据库运行此命令。请注意,此 cmdlet 以静默方式运行,除非存在错误,否则它将不会返回任何输出。
将真实数据复制到测试环境并尝试升级
除非使用实际数据,否则将无法实现测试目标。可以使用以下方法来创建数据的副本:
除了针对所有数据的副本进行测试外,没有其他更好的方式来了解在升级过程中可能发生的情况;但是,在进行初始测试时,实际上并不总是会选择此方法。您可以将测试分为多个阶段,每次测试一个数据库(如果数据库很大),这样可以确保测试数据集的特有内容,或者可以组合使用来自环境中代表性网站的数据子集。如果您想先使用一个数据子集进行测试,则请确保该子集具有下列特征:
重要: |
|---|
|
测试数据子集并不会生成关于处理环境的全部数据量将花费多长时间的有效基准。
|
复制数据之后,先执行一遍升级过程以观察发生的情况。这只是首轮测试。
尝试就地升级
尝试数据库附加升级
审阅结果
测试升级完成之后,可以审阅结果并重新检查计划。查看日志文件、查看升级的网站,并签出自定义项。对于您的环境,升级的工作情况怎么样?您发现了什么情况?您需要如何重新考虑升级计划?
审阅日志文件
审阅以下日志文件:
-
升级前检查程序日志文件。
升级前检查程序 (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 文件中搜索或直接浏览查找下列词条,以确定可能造成失败的特定问题:
若要查找升级问题,您可能会发现使用日志分析程序针对日志文件运行查询将非常有用。
必要时重新启动升级
审阅升级后的网站
调整计划并再次测试
重复测试过程,直至您确信已找到了所有可能面临的问题,并且知道如何处理这些问题。您的目标是明确以下问题:假设现在是星期日下午 4:00,您必须在星期一早上重新实现联机,但升级进行得不顺利,这种情况下您有什么计划?您是否已经没有退路?请测试您的回滚计划,并在您开始实际升级之前确保该计划的有效性。
更改历史记录
|
日期
|
描述
|
|---|
|
2010 年 5 月 12 日
|
初始发布
|