SharePoint 32位到64位迁移实战指南

1. 项目概述：从32位到64位的SharePoint迁移之路

十年前，当我第一次接触SharePoint Server 2007的32位环境时，服务器内存还普遍停留在4GB以下。如今随着业务数据量呈指数级增长，32位系统的4GB内存限制已成为性能瓶颈。最近刚完成一个跨国企业的SharePoint 2007迁移项目，将他们的文档管理中心从32位环境整体迁移到64位平台，系统响应时间直接从平均8秒降至2秒以内。这种架构升级不仅能突破内存限制，更能为后续的功能扩展奠定基础。

2. 迁移前的关键准备工作

2.1 环境兼容性核查清单

在开始迁移前，我们花了三天时间进行全面的环境扫描。使用Microsoft的Pre-Scan工具（preupgrade.exe）检查出三个关键问题：一个自定义Web部件使用了32位COM组件、搜索服务的索引文件格式不兼容，以及用户配置文件导入作业的定时任务配置需要调整。建议制作如下检查表：

1. 硬件验证：

   • CPU支持x64指令集（通过CPU-Z工具确认）
   • 内存≥8GB（实际生产环境建议16GB起）
   • 磁盘空间≥原数据库大小的2倍

2. 软件依赖项：

   # 检查所有已安装的32位组件 Get-WmiObject Win32_Product | Where-Object {$_.Name -like "*SharePoint*"} | Select-Object Name, Version, InstallDate

3. 自定义解决方案审计：

   • 所有.wsp解决方案包的位数标识
   • 第三方插件版本兼容性（特别关注报表工具和工作流扩展）

重要提示：务必在测试环境先运行stsadm -o preupgradecheck，这个内置命令会生成详细的兼容性报告。

2.2 数据备份策略设计

我们采用了三级备份方案确保万无一失：

1. 完整场备份（含配置数据库）：

   stsadm -o backup -directory \\backup\sharepoint -backupmethod full

2. 内容数据库单独备份（通过SQL Server Management Studio）
3. 文件系统快照（特别是_layouts和ISAPI目录）

在最近一次迁移中，这个备份方案成功帮助我们恢复了因存储阵列故障而损坏的网站集。建议备份时记录以下元数据：

• 备份开始/结束时间戳
• 每个备份文件对应的SHA256校验和
• 备份介质存储位置拓扑图

3. 分阶段迁移实施流程

3.1 构建64位基础环境

新建服务器时我们选择了Windows Server 2008 R2 SP1（内核版本6.1），这个版本对SharePoint 2007的64位支持最稳定。安装过程中有几个关键选择：

1. 数据库服务器配置：

   • SQL Server 2005 SP3或2008 SP1（必须x64版）
   • 排序规则选择SQL_Latin1_General_CP1_CI_AS
   • 启用Lock Pages in Memory权限

2. SharePoint安装参数示例：

   setup.exe /config config.xml

   其中config.xml需包含：

   <Configuration> <Package Id="sts"> <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/> </Package> <Logging Type="verbose" Path="C:\InstallLogs" /> </Configuration>

3. 服务账户规划：

   • 新建专用域账户（如SP_FarmAdmin）
   • 最小权限原则分配SQL和文件系统权限
   • 密码策略设置为永不过期（需域策略配合）

3.2 数据库迁移实战步骤

实际迁移中最耗时的环节是内容数据库转移。我们开发了自动化脚本处理这个流程：

1. 分离原数据库：

   EXEC sp_detach_db 'WSS_Content_Prod', 'true';

2. 文件传输校验：

   $srcFile = "\\oldserver\data\WSS_Content_Prod.mdf" $destFile = "D:\SQLData\WSS_Content_Prod.mdf" Copy-Item $srcFile $destFile -Verbose Test-FileHash -Path $destFile -Algorithm SHA256

3. 附加到新实例：

   CREATE DATABASE [WSS_Content_Prod] ON (FILENAME = 'D:\SQLData\WSS_Content_Prod.mdf'), (FILENAME = 'E:\SQLLogs\WSS_Content_Prod_log.ldf') FOR ATTACH;

遇到超过100GB的大型数据库时，建议使用SQL Server的备份压缩功能，实测可将传输时间缩短40%。曾有一个1.2TB的文档库，通过压缩后实际传输量仅680GB。

4. 迁移后的验证与优化

4.1 功能回归测试要点

我们创建了包含217个测试用例的检查清单，其中几个关键验证项包括：

1. 搜索服务测试：

   • 新建爬网内容源并执行完全爬网
   • 验证搜索结果包含最新文档
   • 检查搜索语法（如"filetype:pdf"）是否正常

2. 工作流验证：

   • 启动审批工作流并跟踪任务分配
   • 检查历史记录完整性
   • 测试条件分支逻辑

3. 自定义功能测试矩阵：

4.2 性能调优实战技巧

迁移完成后通过PerfMon发现两个性能瓶颈：SQL Server的Page Life Expectancy偏低（<300秒）和前端服务器的ASP.NET请求队列积压。我们采取的优化措施：

1. 内存配置调整：

   -- SQL Server内存限制 EXEC sp_configure 'max server memory', 12288; RECONFIGURE;

2. IIS应用程序池优化：

   • 回收条件：固定时间间隔（1740分钟）
   • 私有内存限制：不超过物理内存的60%
   • 关闭重叠回收（对于SharePoint 2007必须）

3. SharePoint特定参数：

   stsadm -o setproperty -propertyname requestthrottle -propertyvalue 24 stsadm -o setproperty -propertyname searchmemorylimit -propertyvalue 1024

经过这些调整，系统在2000并发用户压力测试下保持稳定，内存使用率从98%降至75%左右。

5. 常见问题排错指南

5.1 典型错误解决方案

1. "Could not load file or assembly"错误：

   • 检查GAC中所有程序集的Platform Target是否为AnyCPU
   • 使用Fuslogvw.exe查看绑定日志
   • 特别关注Microsoft.SharePoint.dll的版本

2. 搜索服务无法启动：

   # 重建搜索索引 stsadm -o osearch -action stop stsadm -o osearch -action start -role indexquery

3. 用户配置文件同步失败：

   • 确认MOSS Profile Import服务账户权限
   • 检查Active Directory连接性
   • 清空并重建配置文件数据库

5.2 性能监控关键指标

建议部署以下监控项并设置基线告警：

1. SharePoint计数器：

   • ASP.NET\Requests Queued > 50
   • SharePoint\Database Queries/Sec > 100
   • SharePoint\Cache Hit Ratio < 70%

2. SQL Server计数器：

   • Buffer Manager\Page life expectancy < 300
   • SQL Statistics\Batch Requests/sec 突增50%
   • Locks\Lock Waits/sec > 10

3. 硬件监控阈值：

   • 内存使用率 > 85%持续5分钟
   • 磁盘队列长度 > 2（RAID10环境）
   • CPU温度 > 75℃

在最近一次性能危机中，正是磁盘队列长度告警帮助我们及时发现了一个即将故障的RAID控制器，避免了数据丢失事故。

6. 升级后的扩展建议

完成64位迁移只是第一步，根据我们的项目经验，接下来可以考虑：

1. 存储架构优化：

   • 将Blob存储迁移到外部BLOB存储（EBS）
   • 实现内容数据库分片策略
   • 引入SSD缓存层

2. 高可用增强：

   # 配置数据库镜像 stsadm -o setadminport -port 8080 stsadm -o setproperty -pn>