我应该在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亿多行中,总体时间开销大约为几小时,投入时间也很充足,因为它可能推迟未来的索引重建.至于风险因素,你似乎有一个备份......

毋庸置疑......当底层表有一个聚簇索引,并且还希望重建它时,请先删除所有其他索引,以免在更新非聚簇索引时浪费大量时间(没有它们)正在认真重建),然后当然重新创建这些非聚集索引.

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