在SQL Server 2008中将新索引部署到非常大的表的最佳方法

Question

我有一个生产数据库,其中一个表已经变得非常大(大量的累积数据).

为了提高查询性能,我使用了sql server优化器,它建议了一个新的索引.

所以我制作了一个生产数据库的副本进行测试,它确实提高了性能,但我的问题是创建索引需要大约24小时,而在创建索引时,应用程序无法使用.

对于这个特定的应用程序,停机几个小时不是问题,但24小时停机将是,我正在寻找一种方法来创建这个索引,而不必这样做.

我现在只有一些想法.

一个想法是将备份复制到另一台服务器.应用新索引和任何其他更改.将备份复制回生产服务器.从备份开始,将应用程序关闭并合并任何新数据.

当然,这有一系列问题,比如必须将数据合并在一起,所以我不喜欢这个想法.

这是SQL Server 2008 Standard Ed.

我通常通过脚本部署数据库更改.

更新:另一个想法是在几天内将存档数据移出主表.然后在表变小时创建索引.然后慢慢迁移数据.

Answer 1

如果您使用的是 Enterprise，则可以使用构建索引ONLINE的选项CREATE INDEX，而无需在表上保持长期锁定。其使用有一些注意事项；有关详细信息，请参阅链接的文章，您可能会发现性能影响太大。但这是学术性的，正如您所说的您正在使用标准（抱歉一开始就忽略了这一点）。

它是虚拟机这一事实立即让人想到暂时“提升”虚拟机，甚至暂时重新定位到已满的非虚拟机。对于在非常大的表上重建索引，我认为 RAM 和 I/O 速度将是最大的因素；VM是直接使用驱动器还是虚拟化驱动器？您可以暂时将数据转移到物理驱动器吗？之类的东西。

FWIW，你的离线操作的想法正是我在 MySQL 数据库上所做的（从来没有必要在 SQL Server 数据库上这样做）：关闭主数据库，抓取快照，清除二进制日志/启用二进制日志记录，然后将其重新启动。在单独的机器上创建索引。准备好后，关闭数据库，备份更新的数据库（以防万一），放回快照，应用二进制日志，然后备份数据库。它真的很容易; 我希望您也可以使用 SQL Server 做到这一点。当然，它确实假设您可以在可接受的时间窗口内对（新优化的）表应用 24 小时的二进制日志！

Answer 2

考虑到VM机器上缺乏可用的处理能力，再加上毫无疑问相当差的IO吞吐量，我实际上会考虑计算备份、恢复到一半像样的服务器、索引然后备份/恢复到VM的时间机器。

为了避免初始备份花费很长时间，您可以有一天备份并在一天中移动它，然后当维护时段开始时，备份事务日志并将其移动 - 在此基础上它将更小移动。（这假设批量/完整日志模式）