none
awayson不同节点会不会相互影响? RRS feed

  • 问题

  • 主库:修改数据,辅库查询被修改的数据。这时会产生锁吗?

    如果2个事务都在主库在执行,比如修改数据和查询数据,查询在没有nolock的情况,会产生锁

    insert也会如此,我同时想请问下为什么会出现这种情况

    select * from tab where modifydate>'2019-11-12'   --聚集索引

    insert into tab values (..)     --被锁

    2019年12月30日 9:37

答案

  • Hi database_noob,

    >>主库:修改数据,辅库查询被修改的数据。这时会产生锁吗?

    不会。 主数据库上修改数据,此时事务未提交,未被打包成日志块传送给辅助数据库,辅助数据数据库就没有固化日志和Redo这些事务的线程。不会相互干扰。

    对于SQL  server中事务和锁的一些知识,我建议你可以阅读以下博客,来了解更多相关知识。

    SQL Server中的事务与锁

    Best regards,
    Cathy 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com


    2019年12月31日 7:32

全部回复

  • 不会,没有提交的事务,在辅助上不会重做,这个时候你是看不到的
    2019年12月30日 10:40
  • Hi database_noob,

    >>主库:修改数据,辅库查询被修改的数据。这时会产生锁吗?

    不会。 主数据库上修改数据,此时事务未提交,未被打包成日志块传送给辅助数据库,辅助数据数据库就没有固化日志和Redo这些事务的线程。不会相互干扰。

    对于SQL  server中事务和锁的一些知识,我建议你可以阅读以下博客,来了解更多相关知识。

    SQL Server中的事务与锁

    Best regards,
    Cathy 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com


    2019年12月31日 7:32
  • 不会,没有提交的事务,在辅助上不会重做,这个时候你是看不到的

         多谢回答,我还想问下:在不能修改nolock的情况下,怎么能有效的解决写库的select 和insert(update)导致的互锁,我从扩展事件上经常会发现select语句查询Abort,而另一个事务的insert或update执行时间非常长,这种情况发生后感觉每次insert都要等select过了30秒abort后才能插入

    这个是sqlserver原本的机制问题还是聚集索引等的问题

    2019年12月31日 7:42
  • Hi database_noob,

    >>主库:修改数据,辅库查询被修改的数据。这时会产生锁吗?

    不会。 主数据库上修改数据,此时事务未提交,未被打包成日志块传送给辅助数据库,辅助数据数据库就没有固化日志和Redo这些事务的线程。不会相互干扰。

    对于SQL  server中事务和锁的一些知识,我建议你可以阅读以下博客,来了解更多相关知识。

    SQL Server中的事务与锁

    Best regards,
    Cathy 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com


    多谢回答,我还想问下:在不能修改nolock的情况下,怎么能有效的解决写库的select 和insert(update)导致的互锁,我从扩展事件上经常会发现select语句查询Abort,而另一个事务的insert或update执行时间非常长,这种情况发生后感觉每次insert都要等select过了30秒abort后才能插入

    这个是sqlserver原本的机制问题还是聚集索引等的问题


    2019年12月31日 7:42
  • Hi database_noob,

    你可以通过添加行级锁。请阅读这个博客获取更多详细信息。

    Best regards,
    Cathy 

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com

    2019年12月31日 9:41
  • Hi database_noob,

    你可以通过添加行级锁。请阅读这个博客获取更多详细信息。

    Best regards,
    Cathy 

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com

          你的案例是2个update产生的X锁,我的情况是一个select和一个update,应该是S锁
    2019年12月31日 9:47
  • Hi database_noob,

    这个是SQL server 本身机制。Update是U锁。 或者你可以尝试降低数据库隔离级别。在READ UNCOMMITTED级别运行的事务,不会发出共享锁来防止其他事务修改当前事务读取的数据。READ UNCOMMITTED事务也不会被排他锁阻塞。共享锁会禁止当前事务读取其他事务已修改但尚未提交的行。设置此选项之后,此事务可以读取其他事务未提交的修改。在事务结束之前,其他事务也可以更改数据中的值。该选项的作用与在事务内所有SELECT语句中的所有表上设置NOLOCK相同。这是隔离级别中限制最少的级别。 

    Best regards,
    Cathy 

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com

    2020年1月1日 9:43
  • 从扩展事件上经常会发现select语句查询Abort,而另一个事务的insert或update执行时间非常长,这种情况发生后感觉每次insert都要等select过了30秒abort后才能插入

    -------------- 从你这个描述上看,主要的问题是 INSERT.UPDATE 时间过长吧?

    你应该确认一下这个是什么原因导致的,是高并发,还是单操作涉及的量太大

    2020年1月2日 1:02
  • 从扩展事件上经常会发现select语句查询Abort,而另一个事务的insert或update执行时间非常长,这种情况发生后感觉每次insert都要等select过了30秒abort后才能插入

    -------------- 从你这个描述上看,主要的问题是 INSERT.UPDATE 时间过长吧?

    你应该确认一下这个是什么原因导致的,是高并发,还是单操作涉及的量太大

         不是。就是由于S锁导致,INSERT,UPDATE都是非常简单的语句。例如:

         INSERT INTO TAB VALUES (...);

         UPDATE TAB SET ... WHERE GUID='XXX';

         一开始也不知道是什么情况,后来通过扩展信息才发现端倪,select 和update\insert,在运气不好的情况下互锁,然后SELECT过了30秒abort,insert然后就插入成功。现在的策略只能把select移至读库加nolock,但是有些操作需要实时性比较高一定要读写库,因为不能查到脏数据。

    2020年1月2日 1:28
  • Hi database_noob,

    这个是SQL server 本身机制。Update是U锁。 或者你可以尝试降低数据库隔离级别。在READ UNCOMMITTED级别运行的事务,不会发出共享锁来防止其他事务修改当前事务读取的数据。READ UNCOMMITTED事务也不会被排他锁阻塞。共享锁会禁止当前事务读取其他事务已修改但尚未提交的行。设置此选项之后,此事务可以读取其他事务未提交的修改。在事务结束之前,其他事务也可以更改数据中的值。该选项的作用与在事务内所有SELECT语句中的所有表上设置NOLOCK相同。这是隔离级别中限制最少的级别。 

    Best regards,
    Cathy 

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com

         多谢,但是现实中如果要查订单之类的数据,数据一定要实时性高,不能查脏数据。导致不能加nolock的情况,这种情况下就啥办法了。
    2020年1月2日 1:30