Sql server 哪个事务级别最适合从应用程序事件日志表读取记录？

我正在实现一个后台进程，用于将事件日志记录从SQL数据库移动到mongoDB

已知事件日志/审核跟踪条目仅在事件结束时更改一次。过程如下：

1） 将创建一个事件日志条目，以确定业务流程是否已启动

2） 为业务流程启动一个新事务

3） 将创建审核跟踪条目

4） 尝试以成功状态更新事件日志条目

5） 事务完成

6） 如果事务失败-将事件日志条目更新为失败

因此，从理论上讲，后台进程可以安全地读取所有已标记为失败/成功的日志条目，并且很可能在特定超时后也可以安全地读取由于未知原因而停留在“进程已启动”状态的条目

为了避免在后台进程成批读取事件日志记录时锁定事件日志表，我想使用一个宽松的隔离级别，但我不确定在一个经常发生大量并行插入和更新的表上使用哪个级别是安全的（尽管只更新我的后台进程将忽略的记录；所以我不关心脏读）

在我的情况下，忽略当前插入的记录似乎是可以接受的（无论如何，我将在下一次后台作业运行中获取这些记录），但在当前未更新的旧记录中获取重复/丢失的记录是不可接受的。

---

另外，您可能会问-为什么不直接登录到mongoDB？有两个原因：1）数据库中有许多触发器和存储的过程记录到SQL表中，客户不想重新实现所有这些；2） 客户希望确保事件日志/审计跟踪与业务流程事务的原子性，他担心直接记录到mongoDB可能会出现以下情况：由于某些原因（很可能是非常关键的原因），事件日志条目在SQL事务成功且数据更改时丢失。使用SQL事务在单个原子工作单元中写入mongoDB是不可能的。

为什么不为日志读取器使用

SNAPSHOT

隔离？@DanGuzman感谢您的想法，我想我必须重新编写这个问题（将对其进行编辑）。在这种情况下，read committed是安全的。由于完成的日志是不可变的，在我看来，快照或读取提交的快照并没有提供额外的好处。我只是好奇，既然您提到了使用SQL server进行日志的所有理由，为什么要在插入SQL之后将数据移到mongoDB？任何在SQL Server中做不到的事情，都必须利用mongo？@PeterHe，因为事件日志表增长太快，它已经有10Gb的数据，而业务数据只占1Gb左右。这使得数据库拷贝的空间效率非常低。