SQL Server 2000升级到2005后，是否需要重建表索引？

Question

我的任务是完成SQL Server 2000升级到2005的迁移工作。我将执行逐步迁移。

恢复备份后，我计划执行以下步骤：

ALTER DATABASE <database_name> SET COMPATIBILITY_LEVEL = 90;

DBCC CHECKDB(<database_name>) WITH NO_INFOMSGS

DBCC UPDATEUSAGE(<database_name>) WITH NO_INFOMSGS

exec sp_updatestats ‘resample’

在使用DBCC UPDATEUSAGE和sp_updatestats之前，我需要重建表索引吗？

迁移后是否有任何明显的遗漏需要执行？

所有帮助将会得到热情的赞同。

谢谢

- Joe T

---

如果您重新构建索引，请勿在此之后缩小文件。 - Andrew

@Andrew 感谢你的研究，我已经知道收缩数据库可能会导致索引碎片化，并且数据库很可能会增长，因此应该避免收缩。 - Joe T

微软还建议您将破损页面检测更改为CHECKSUM。在重新构建索引之前，您应该这样做，以确保页面添加了校验和。 - Nick Kavadias

修改数据库 <dbname> 设置页面校验 = 校验和 - Nick Kavadias

Answer 1

关于迁移的具体细节（除了旨在确保新/升级主机上数据库结构完整性的程序）并没有太多权威的在线资料。因此，考虑到这次迁移对您来说是计划好的事件，我建议您趁机重建所有索引，包括聚集索引。

对一些人来说，这可能看起来“过度”，但重新平衡和重新打包索引/表、提供与预期CRUD使用相符的新填充因子以及总体上断言数据库在其新主机中的健康状况，何不利用这个机会呢？

实际上，我会...

ALTER DATABASE <database_name> SET COMPATIBILITY_LEVEL = 90;

DBCC CHECKDB(<database_name>)
   -- WITH NO_INFOMSGS  (I'd take the messages, I'm curious by nature ;-)

像您建议的那样，但是我会重建所有/大多数表上的所有索引，甚至（也许特别是...）在非常大的表上。为了确保，应该评估此类操作所涉及的时间和相对风险，但对于大多数情况，即使是拥有1亿+行的数据库，总的时间开销也只需几个小时，这是值得投资的时间，因为它可以推迟未来的索引重建。至于风险因素，您似乎已备份...

不言而喻... 当底层表具有聚集索引并且如果希望重建它，则在删除所有其他索引之前，请务必注意，否则会浪费大量时间更新非聚集索引（而没有真正重建它们），然后当然重新创建这些非聚集索引。

根据涉及的表和索引数量，编写一些小型存储过程以自动化索引删除（和重新创建，尽管可能还重要单独审查填充因子、重新计算和其他参数）可能是有利可图的。

- mjv

---

@mjv 感谢您的回答，它让我相信对于这个原始数据库重建所有索引是一个好主意。在任何 SQL Server 主题上找到权威信息都非常困难。 - Joe T

Answer 2

“在迁移后，我是否错过了任何明显需要执行的步骤？”

• 确保您正在运行 SS 2005 的最新 SP。
• 我很惊讶您没有提到已经在 SS 2005 中测试了所有存储过程和用户定义函数，以证明它们能够成功地执行相同的方式并且在整个过程中都能够可预测地失败。这可能需要一些时间来完成，但可以大大提高系统的稳健性。

- dcpking

---

尽管OP的关注点似乎是数据完整性和索引维护，但这些都是非常重要的考虑因素。我们不应该认为在升级后，UDFs、SPs、自定义函数和系统的其他过程元素会毫无问题地运行。话虽如此，在大多数普通情况下，并不需要逐个确认每个元素；例如，检查遵循特定模式的一个或两个SPs，就可以确定整个类别的SPs是否合格。 - mjv

@dcpking 谢谢你的答案，我同意在开始迁移工作之前应该应用最新的补丁。所有 SPs 将被检查，值得庆幸的是，在要迁移的数据库中不存在任何 UDF 或自定义函数。 - Joe T

Answer 3

在数据库离开 SQL 2000 之前，添加到您的 CheckDB 列表中 - 您希望尽可能确定没有来自 2000 的损坏被带过来，如果有人开始在系统表中释放东西而不是使用适当的命令，那么一旦迁移就会给您带来麻烦。

如果您重建索引，那么执行 sp_updatestats 'resample' 将为您的索引提供更差的统计信息，因为它们已经通过重建进行了更新。可能需要更新添加的其他统计信息，但请逐个进行，不要杀死它们的索引统计信息。

- Andrew

---

@Andrew 谢谢你的回答。在备份数据库之前，我会考虑运行 CHECKDB。很难知道在减少用户停机时间和降低风险之间保持平衡。 - Joe T