我应该在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

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

对于某些人来说，这可能看起来“过度”，但是有什么更好的机会重新平衡和重新打包索引/表格，提供与预期的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亿多行中，总体时间开销大约为几小时，投入时间也很充足，因为它可能推迟未来的索引重建。至于风险因素，你似乎有一个备份...

什么是不言而喻......当基础表具有聚簇索引，并且如果还希望重建它时，请先删除所有其他索引，以免在更新中浪费大量时间非聚集索引（没有认真重建），然后当然会重新创建这些非聚集索引。

根据所讨论的表和索引的数量，编写一些小的存储过程来自动化索引丢弃（并重新创建，虽然单独检查填充因子也很重要，但这可能是有利可图的，重新计算和其他参数）。

Answer 2

“我错过了迁移后应该执行的任何明显的事情吗？”

• 确保您正在运行SS 2005的最新SP。
• 我很惊讶您没有提及在SS 2005中测试过所有的SP和UDF，以证明它们以相同的方式取得成功并且在整个过程中无法预测。这可能需要一些时间才能完成，但是为您提供了极大的机会来大幅提升系统的稳健性。

Answer 3

在数据库离开SQL 2000之前加入你的列表CheckDB - 你希望尽可能确保2000年没有损坏，如果有人开始在系统表中释放东西而不是使用正确的命令会给你一个母马曾迁移过。

如果重建索引，那么exec sp_updatestats'resample'将为您的索引提供更糟糕的统计信息，因为它们已经被重建更新了。添加的其他统计信息可能需要更新，但要单独执行，不要删除它们的索引统计信息。