我应该在 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 之前重建表索引吗？

我是否遗漏了迁移后应该执行的任何明显操作？

所有帮助都会被热烈投票。

谢谢

Answer 1

“我是否遗漏了迁移后应该执行的明显操作？”

• 确保您运行的是 SS 2005 的最新 SP。
• 令我惊讶的是，您竟然没有提到在 SS 2005 中测试了您的所有 SP 和 UDF，以证明它们以相同的方式成功并且在整个过程中都可以预见地失败。这可能需要一些时间，但为您提供了极大地提升系统稳健性的绝佳机会。

Answer 2

没有太多权威在线资料提供有关迁移的详细信息（除了旨在确保新/升级主机中的数据库结构完整性的程序之外）。出于这个原因，并且因为此迁移似乎是为您安排/计划的事件，我会借此机会重建所有索引，包括聚簇索引。

对某些人来说，这可能看起来“矫枉过正”，但有什么更好的机会来重新平衡和重新打包索引/表，提供与预期 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 ;-)

就像你建议的那样，但我会重建所有/大多数表上的所有索引，甚至（也许特别是......）在非常大的表上。可以肯定的是，应该评估这种操作所涉及的时间和相对风险，但对于大多数情况，即使数据库有 100+ 百万行，总的时间开销也在几个小时左右，时间投入得很好，因为它可能会推迟未来的索引重建。至于风险因素，你好像有后盾……

不用说...当基础表具有聚集索引时，如果还需要重建它，请先删除所有其他索引，以免浪费大量时间更新 em> 非聚集索引（没有认真重建），然后当然要重新创建这些非聚集索引。

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

Answer 3

在数据库离开 SQL 2000 之前添加到您的列表 CheckDB - 您希望尽可能确保不会带来 2000 的损坏，如果有人开始释放系统表中的内容而不是使用正确的命令会给您一个母马曾经迁移过。

如果您重建索引，那么 exec sp_updatestats 'resample' 会给您的索引提供更差的统计信息，因为重建时它们已经更新了。添加的其他统计信息可能需要更新，但请单独更新，不要为它们杀死索引统计信息。