使用重复的SQL Server数据库进行查询

Question

我有一个非常大（100+演出）的SQL Server 2005数据库，它接收大量的插入和更新，选择频率较低。选择需要很多索引才能使它们运行良好，但似乎索引的数量正在影响插入和更新的效率。

问题：是否有一种方法可以保留数据库的两个副本，其中一个用于插入和更新，而第二个用于选择？第二个副本不需要实时更新，但不应超过一个小时。是否可以在每个数据库副本上保留不同的索引时执行此类复制？也许你有其他解决方案？

Answer 1

您希望使用复制设置主/子数据库拓扑。使用SQL Server，您需要在两个数据库之间设置复制（最好是在单独的硬件上）。您应该使用主数据库进行插入和更新。 Child将为您的所有选择查询提供服务。您还希望针对它们将要执行的工作类型优化两个数据库配置设置。如果您对子数据库有大量选择查询，您可能还需要设置视图，使查询的性能优于表上的复杂连接。

有关复制的一些参考资料：

http://technet.microsoft.com/en-us/library/ms151198.aspx

只需google它，您就会找到有关如何设置和配置的大量信息：

http://search.aim.com/search/search?&query=sql+server+2005+replication&invocationType=tb50fftrab

Answer 2

事务复制可以执行此操作，因为订阅者可以与发布者相比具有多个附加索引。但是你必须记住一个简单的事实：所有插入/更新/删除都将在报告副本（订阅者）上复制，而aditional索引将...减慢复制速度。实际上，可以将复制速度降低到无法跟上的速率，从而导致分发DB的膨胀。但这只有在您拥有恒定的高更新率时才会出现。如果问题只发生durink尖峰，则分布DB将充当吸收峰值的队列，并在非高峰时段将其关闭。

如果没有绝对的，100％证据证明正在减慢插入/更新/删除的额外索引，并且没有测试插入/更新/删除实际上表现更好的话，我不会接受这种努力没有额外的索引。具体来说，确保罪魁祸首不是另一个常见的嫌疑人：锁定争用。

Answer 3

您可以安排bcp脚本将数据复制到其他数据库。

您还可以尝试使用事务日志传送来更新只读数据库。

Answer 4

通常，所有基于集合的操作（包括更新索引）都比非基于集合的操作快

1,000插入很可能比1,000记录的一次插入慢。

您可以将更新批处理到第二个数据库。这将首先使索引更新更快，其次，使峰值平滑。

Answer 5

创建两个数据库时，不要忘记调整填充因子。它应该在频繁更新的数据库上低（呃），在“数据仓库”/只读数据库上为100。