快照隔离与读提交- OLTP和报表数据库

Question

我刚刚读完了一篇关于隔离级别这里的优秀文章。我们公司不久将开始对现有产品进行重写和扩展。我的愿望是拥有一个OLTP数据库和一个单独的、更加非规范化的报告数据库。假设我们有些自律，并且大多数临时和报告类型的查询实际上都会转到reporting数据库，那么我们的OLTP数据库具有默认的读提交隔离级别(对于OLTP不需要更严格的隔离级别)和我们的报告数据库是快照隔离(可能是RCSI)，这听起来是否合适？

我的想法是，如果我们的OLTP数据库实际上是一个真正的OLTP数据库，而不是作为一个报告DB提供双重功能，那么我们就不需要快照隔离，以及它所需要的相关开销。但是，在reporting数据库上进行快照隔离是可取的，这样读取器就不会被源源不断的数据流所阻塞，并且读取最后保存的行版本也是可以接受的。

Answer 1

只是为了补充另一个答案。

Server支持两种不同类型的读提交、遗留锁定读取提交快照和读取提交快照。如果您曾经构建并支持过一个高容量的OLTP应用程序来锁定、读取、提交，那么您就知道为什么引入了RCSI (此外，还可以轻松地将Oracle应用程序移植到SQL Server)。

锁定读提交是很难获得并发性的，而且很容易陷入死锁，因为读取器会阻塞作者，而作者会阻塞读者。死锁是应用程序中的一种bug，但在测试中很难找到它们。因此，你有机会做出一个选择，减少在测试中难以找到的bug的数量。那可值很多钱。RCSI还增加了应用程序的并发性，使您能够更容易地扩展到使用多个核心。

因此，RCSI增加了应用程序的可伸缩性和可靠性，为此需要为更新和删除(如果有触发器的话还要插入)进行额外的簿记，并为每行增加14个字节。

RCSI更容易编程，主要是当您想要读取一行并立即更新它时，有时需要选择使用UPDLOCK表提示进行锁定读取，并且需要确保没有其他会话同时执行相同的操作。

Answer 2

我不认为快照或读取提交的快照必然会增加可能导致性能下降的开销--减少的等待时间可能会增加吞吐量。

RCS和快照的危险更多地与应用程序的编码方式有关--如果您的程序员在快照模式下执行查询时假定了READ提交的阻塞语义，那么您可能会遇到麻烦。例如

UPDATE foo SET bar = 1 + (SELECT MAX(bar) from foo);

可能会在高吞吐量情况下造成问题，因为多个读取器将同时获得相同的MAX(bar)值。

但是，您可能仍然需要某种形式的非OLAP操作报告和查询，而快照模式对那里的性能有很大的好处。

我的观点是，您可以设计和开发您的OLTP系统的RCS模式，并应考虑它。毕竟，Oracle中的大多数OLTP系统就是这样编写的。