当前,当后台进程运行其插入和更新操作时,Web应用程序似乎被阻塞,无法访问数据库。
我想知道一个好的解决方案是什么。我应该创建另一个表格,在其中进行插入操作,然后将表格复制到另一个只读表格中吗?还有其他的方法吗?
非常感谢您提供任何帮助和建议!
特别是对于SQL Server,您可能希望更改数据库以启用READ_COMMITTED_SHAPSHOT。
这基本上可以防止在数据上有待处理的插入/更新时,您的选择查询被锁定。
一些需要关注的问题:
1) 你的插入/更新或选择查询是否属于事务的一部分?如果是,确保为您的特定情况设置了最有利的事务隔离级别。
2) 这个巨大的表上是否有太多的索引?索引可以加速选择,但会减慢插入和更新。确保只使用必要的索引。
3) 与#2有关。您是否缺少将加速选择的索引?您的选择语句是否正在进行全表扫描?查看查询执行计划以了解实际情况。(查询分析器可以协助您)。
4) 考虑将巨大的数据复制到一个或多个只读数据库服务器中,这些服务器可以处理选择流量,而读/写主表(即现有表)主要处理插入/更新流量。
5) 您的插入/更新操作是否触发了触发器,可能会导致性能或锁定问题?
6) 您的应用程序是否遇到死锁事务?请查看此MSDN文章并查看它是否有所帮助。此外,请确保您了解哲学家就餐问题,以避免死锁事务。
如果您使用的是企业版,则最理想的解决方案是使用滑动窗口分区。基本上,您需要在相同的文件组上创建一个相同的表,将数据加载到该表中,然后“切换”该表的分区到生产表中。实际操作只是元数据翻转,所以它几乎瞬间完成。请查看这里获取更多信息:http://technet.microsoft.com/en-us/library/ms191160.aspx
如果您只需要从Web应用程序中的表中读取数据,则可能希望尝试使用READ_UNCOMMITTED隔离级别进行查询。它不会锁定任何内容并读取未提交的数据。我不建议在银行应用程序等方面这样做,但大多数典型的业务Web应用程序可能不会有问题。确保在查询后将隔离级别设置回您通常使用的级别(READ COMMITTED?)。
如果对于您来说使用READ_UNCOMMITTED不可行,则可以熟悉基于行版本控制的隔离级别。例如,快照隔离使用乐观的方法来修改数据,从而减少了对行的悲观锁定的需求。