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

我有一个非常大的（100 +演出）SQL Server 2005数据库，它接收大量的插入和更新，并且选择频率较低。这些选择需要很多索引来保持它们的正常运行，但似乎索引的数量影响了插入和更新的效率。使用重复的SQL Server数据库进行查询

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

来源

2010-01-12 Charles

您正在寻找使用复制来设置主/子数据库拓扑。使用SQL服务器，您需要在两个数据库之间设置复制（最好在单独的硬件上）。主数据库您应该用于插入和更新。孩子将服务你所有的选择查询。您还需要优化他们将执行的工作类型的数据库配置设置。如果您在子数据库上有大量选择查询，则可能还需要设置视图，以使查询的表现比表上的复杂联接更好。

上复制一些参考材料：

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

它只是谷歌，你会发现很多关于如何安装和配置：

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

来源

2010-01-12 17:18:55 nopuck4you

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

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

来源

2010-01-12 17:18:50 CraigF

谢谢。根据我的镜像经验，“镜像”数据库不可用于查询。它始终处于“恢复”状态。 – Charles 2010-01-12 17:28:06

确实如此，因此镜像不起作用。其他两个选项可以工作。 – CraigF 2010-01-12 18:35:25

一般来说，所有集基于操作（包括更新索引）比非基于集合的操作更快

1,000插入将最有可能比插入的1,000记录慢。

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

来源

2010-01-12 17:21:47 Quassnoi

事务复制可以做到这一点，因为与发布者相比，订户可以拥有多个aditional索引。但是您必须记住一个简单的事实：所有插入/更新/删除将在报告副本（订阅者）处复制，并且aditional索引将会减慢复制速度。实际上可能会将复制速度放慢到无法跟上的速度，导致分布数据库的膨胀。但是，只有当您持续保持较高的更新率时才会这样。如果问题只发生在持续高峰时段，那么分布数据库将作为一个队列来吸收峰值并在非高峰时段将其平稳化。

如果没有绝对的，100％的证明证据证明这是额外的索引会减慢插入/更新/删除，而没有测试插入/更新/删除实际上是否显着没有额外的索引更好。具体来说，确保罪魁祸首不是其他常见的嫌疑人：锁争夺。

来源

2010-01-12 19:51:29

不要忘记在创建两个数据库时调整填充因子。数据库中频率更新频率应该较低，在“数据仓库”/只读数据库中应该为100。

来源

2010-01-12 20:08:09 Jay

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

回答

相关问题