SQL Server AlwaysOn中的脏读
我有一对SQL Server 2014数据库设置为同步AlwaysOn可用性组。
两台服务器均设置为Synchronous commit可用性模式，会话超时为50秒。次级被设置为Read-intent only可读的次级。
如果我写入主数据，然后立即（通过ApplicationIntent=ReadOnly）从辅助数据中读取，则我将始终读取脏数据（即写入之前的状态）。如果我在写入和读取之间等待大约一秒钟，我将获得正确的数据。
这是预期的行为吗？如果是这样，我可以做些什么来确保从辅助读取是最新的？
我想将辅助服务器用作主服务器（以及故障转移）的只读版本，以减少主服务器上的负载。
问题答案：
除非您使用无锁提示，否则您不可能得到脏读。
在AlwaysOn中启用只读辅助副本时。内部SQL使用行版本控制来存储行的先前版本。
此外，您使用的是同步提交模式，这可确保日志记录首先在辅助数据库上提交，然后在主要数据库上提交。
您看到的是数据延迟。
本白皮书处理了这种情况。下面是相关部分，有助于您进一步了解它。
在辅助副本上运行的报告工作负载将导致一些数据延迟，通常要几秒钟到几分钟，这取决于主要工作负载和网络延迟。
即使将辅助副本配置为同步模式，也存在数据延迟。确实，同步副本通过在将ACK发送到主数据库之前对已提交事务的事务日志记录进行加固来帮助确保在理想条件下（即RPO
= 0）没有数据丢失，但这并不能保证REDO线程辅助副本上的磁盘确实已将关联的日志记录应用于数据库页面。因此存在一些数据延迟。您可能想知道在异步模式下配置辅助副本时，这种数据延迟是否更有可能发生。这是一个较难回答的问题。如果主副本和辅助副本之间的网络无法跟上事务日志流量（即，如果没有足够的带宽），则异步副本可能会进一步落后，从而导致更高的数据延迟。
对于同步副本，不足的网络带宽不会导致辅助节点上的数据延迟增加，但会减慢主节点工作负载的事务响应时间和吞吐量。
-
我试图理解React.js，经常会遇到一个术语“脏的”，比如脏的检查/检查、脏的数据、脏的模型 我问了这个问题，但弄不清“脏”这个词到底是什么意思
-
脏矩形 有时候用CAShapeLayer或者其他矢量图形图层替代Core Graphics并不是那么切实可行。比如我们的绘图应用：我们用线条完美地完成了矢量绘制。但是设想一下如果我们能进一步提高应用的性能，让它就像一个黑板一样工作，然后用『粉笔』来绘制线条。模拟粉笔最简单的方法就是用一个『线刷』图片然后将它粘贴到用户手指碰触的地方，但是这个方法用CAShapeLayer没办法实现。
-
问题内容： 在“旧的JDBC美好时光”中，我编写了许多SQL代码，这些代码仅针对实际上已更改的“属性/成员”进行了针对性的更新： 例如，考虑具有以下成员的对象： 如果仅在某些业务方法中进行了更改，我将只为该成员发出一个SQL 。 但是，似乎（这是我对Hibernate的“印象”）在使用标准Hibernate映射（映射完整类）时，即使仅单个成员的更新也会导致Hibernate生成的SQL语句中对象的
-
我是PHP新手 默认情况下，rails框架中提供了以下脏方法，这里的是模型对象，表示表中的行。 我对感兴趣
-
问题内容： 在“旧的JDBC美好时光”中，我编写了许多SQL代码，这些代码仅针对实际更改的“属性/成员”进行了针对性的更新： 例如，考虑具有以下成员的对象： 如果仅在某些业务方法中进行了更改，我将只为该成员发出一个SQL 。 但是，似乎（这是我对Hibernate的“印象”）在使用标准Hibernate映射（映射完整类）时，即使仅单个成员的更新也将导致由Hibernate生成的SQL语句中对象的完
-
我们有一个在负载均衡器下运行的web应用程序。两个用户尝试执行相同的操作，例如，两个用户同时发出相同的订单，这会创建重复的订单。 在一个事务提交之前，另一个请求正在检查是否有任何顺序。它正在创建重复的条目。两个请求都试图同时处理。 用户A 我们尝试了以下选项， 将整个管理器锁定，锁定类型为 但是这些选择都没有帮助。 请建议如何进行。 谢啦