使用数据库快照与快照隔离级别事务

时间:2019-11-10 13:14:21

标签: sql-server snapshot-isolation

我维护一个MVC应用程序,该应用程序包含一些长期运行的批处理过程,用于发送新闻稿,生成报告等。

我以前曾遇到过很多死锁问题,这些长时间运行的查询中的一个可能在行上持有锁,然后需要由另一个进程进行更新。

我最初想到的解决方案是执行一个计划任务,该任务可以创建数据库快照,就像这样...

CREATE DATABASE MyDatabase_snapshot_[yyyyMMddHHmmss]... AS SNAPSHOT OF MyDatabase

然后,我的应用程序将具有一些逻辑,这些逻辑将查找最新的可用快照,并将其用于长时间运行的进程的只读连接,或需要只读连接的其他任何地方。

当前设置功能完善且可靠。但是,依赖于计划的任务并不能使我感到高兴。我可以想象,在将来的某个阶段,如果有人在照顾这个项目,这可能是容易引起混乱的问题的来源。例如,如果数据库已移至另一台服务器,并且快照创建计划任务未正确设置。

从那时起,我意识到我可以通过使用快照事务隔离来达到相似的结果,并且避免了管理数据库快照的创建和清理的所有额外复杂性。

但是我现在想知道使用事务与继续使用静态快照相比是否存在性能缺陷。

请考虑以下情形。

系统会定期向大约2万订户发送个性化的作业列表。对于这些订户中的每个订户,它都会进行数据库查找以创建匹配的作业列表。

正在做的事情,正在遍历完整的收件人列表,并逐一列出...

  1. 打开与快照数据库的连接
  2. 运行查询以找到匹配的作业
  3. 关闭快照数据库连接

如果相反,它将执行以下操作...

  1. 打开与普通数据库的数据库连接 (非快照)
  2. 创建快照隔离的事务
  3. 运行查询以找到匹配的作业
  4. 关闭交易
  5. 关闭数据库连接

这实际上转化为数据库服务器需要更多工作吗?

具体来说,我想知道第二步涉及什么。

从应用程序中消除复杂性是一件好事,但不能以牺牲性能为代价。尤其是由于此特定过程已经占用大量服务器资源,并且需要花费很长时间才能运行。

0 个答案:

没有答案
相关问题