.NET SQLDatareader 隔离读取答案

【问题标题】：.NET SQLDatareader isolated read.NET SQLDatareader 隔离读取
【发布时间】：2014-04-26 10:04:29
【问题描述】：

我有一个 SQL Server 数据库，它存储带有信用的帐户（大约 200.000 条记录），以及一个存储交易的单独表（大约 20.000.000 条）。

每当将交易添加到数据库时，信用都会更新。

我需要做的是更新客户端程序（使用 Web 服务）以在本地存储积分，并且每当将新事务添加到服务器时，它们也会发送到客户端（使用增量时间戳）。我的主要问题是为客户创建第一个数据集。我需要提供所有帐户的列表和交易表上的最后一个时间戳。

这意味着我必须创建此列表和快照中的最后一个时间戳，因为在创建此列表期间的任何更新都意味着积分总数和最后一个交易时间戳不匹配。

我研究了ALLOW_SNAPSHOT_ISOLATION 设置并在SqlCommand 事务上使用快照隔离，但据我所知，这将导致显着的性能损失。这是真的吗，这个问题可以通过其他方式解决吗？

【问题讨论】：

标签： sql .net sql-server transactions isolation

【解决方案1】：

但据我所知，这会导致显着的性能损失。

我什至不想知道你在哪里读到的。 I'll refer you to the official document. 成本来自用于行版本的额外 tempdb 空间和遍历旧行版本。如果您的写入率较低，则这些问题不会引起您的注意。

快照隔离是解决阻塞和一致性问题的福音。它非常适合您的场景。

Stack Overflow 上的许多 SQL Server 问题让我评论“你调查过快照隔离了吗？”。最未充分利用的功能。

Oracle 和 Postgres 始终开启。

【讨论】：

在链接的文章中给出了许多性能后果，并且必须有一个原因 sql server 默认关闭...我会尝试自己测量性能损失，而不是相信什么互联网”的说法。我希望有另一个技巧来做我想做的事，但正如你所说，我的场景是快照隔离的设计目的之一。
由于兼容性，默认关闭。 Azure 的 SQL 是强制的。如果您担心，您绝对应该测试它。也就是说，我从未经历或听说过性能问题。这似乎是一个没有人抱怨的功能。您了解他们警告的具体性能问题吗？你应该。他们警告说“成本来自用于行版本的额外 tempdb 空间和遍历旧行版本。”。我对此说：“如果您的写入率较低，这些问题与您无关。”。对我来说听起来很合乎逻辑。
几乎每个 SQL Server 功能都有性能警告，伙计！你在使用索引吗？这些命中率是快照的 10 倍。
来自文章“数据阅读者面临遍历版本链接列表的额外成本。快照越旧，在快照隔离事务中访问它的过程越慢。”由于我有许多需要报告的繁重查询，因此这可能是一个问题。是否可以像某些示例那样在需要时打开 ALLOW_SNAPSHOT_ISOLATION 并在不需要时关闭？
没错。但是，如果没有行版本，则不会产生任何性能成本。请理解，行版本是在写入时创建的，并在可能使用它们的最后一个事务结束后迅速丢弃。它们是临时数据。你甚至有多少写？暂时打开它是可以的，但它需要一个数据库 X 锁，这意味着杀死所有会话。

【解决方案2】：

不要急于跳上 SI 马车。和其他所有东西一样，它有它的好处，也有它的缺点。

就缺点而言，例如，应用程序可能会依赖阻塞行为或/并且愿意等待数据的最后一个版本。您应该在 SI 下彻底测试应用程序，以确保其行为正确。此外，未提交的事务可能会弄乱版本存储并导致 tempdb 急剧增长，因此必须进行监控。

此外，如果您通常没有阻塞问题，那么 SI 对您来说可能是多余的。

相反，如果您需要一次性或接近它，请为您的数据库创建一个 database snapshot，从该快照创建初始列表，然后简单地删除它。

【讨论】：

我们目前有超过 700 个需要每日快照的客户端系统，数据库大小为 25Gb，所以我发现使用该选项存在一些问题。感谢您的建议，将研究它
+1 因为这里有很多优点。不过，我不会高估它们在大多数部署中的重要性。或者，也许我是从未被 SI 咬过的人中罕见的例外？从开发人员的角度来看，这是一个福音。
@usr 我确实喜欢 RCSI 和 SI，我自己实现了很多次，但总是先进行测试，计划，调整 tempdb 的大小，监控任何异常......是的，我们有一些时刻:)