随笔分类 -  SQL Server--Transaction And Lock

1 2 下一页

SQL Server--存在则更新问题
摘要：在博客园看到一篇讨论特别多的文章“探讨SQL Server并发处理存在就更新七种解决方案”，这种业务需求很常见：如果记录存在就更新，不存在就插入。 最常见的做法： 一个很明显的问题，在高并发下可能存在操作同一条记录的多个线程都进入到INSERT环节，导致插入失败。 上面问题原因在于进入INSERT或 阅读全文

posted @ 2017-06-01 15:48 笑东风 阅读(8500) 评论(20) 推荐(8) 编辑

SQL SERVER--单回话下的死锁
摘要：很多时候，死锁由两个或多个会话请求其他Session持有的锁而同时又持有其他Session，但也有一些特殊的死锁仅由单个Session锁触发，今天看到一篇相关的文章，搬运过来与各位共享！ 引发死锁的代码： 执行环境SQL SERVER 2012 (11.0.5058) 执行上面的代码后，通过Prof 阅读全文

posted @ 2016-07-05 19:57 笑东风 阅读(614) 评论(1) 推荐(0) 编辑

曲苑杂坛--DML操作中如何处理那些未提交的数据
摘要：对数据库稍有了解的人，数据库使用排他锁X锁来避免两个事务同时修改同一条数据，同时使用较低级别如行上加锁来提高并发度。以下了两种场景很容易理解：1>事务1执行 UPDATE TB1 SET C2=1 WHERE C1=1(此处假设C1为主键，使用行锁)，事务1未提交，而后事务2执行UPDATE TB1... 阅读全文

posted @ 2015-01-24 22:49 笑东风 阅读(668) 评论(6) 推荐(0) 编辑

Transaction And Lock--READ COMMITTED隔离级别下的"脏读"
摘要：在READ UNCOMMITTED事务隔离级别下或使用WITH(NOLOCK)来查询数据时，会出现脏读情况，因此对于一些比较"关键"的业务，会要求不能使用WITH(NOLOCK)或允许在READ UNCOMMITTED事务隔离级别下，于是我们使用默认的READ COMMITTED隔离级别来访问数据，... 阅读全文

posted @ 2014-06-09 19:16 笑东风 阅读(6379) 评论(21) 推荐(2) 编辑

Transaction And Lock--唯一索引下INSERT导致的死锁
摘要：背景：曾经的一位同事问我:"数据库只有并发INSERT 操作，会造成死锁么？"，我没有太多思考地回答"不会"，但真的不会吗？测试：--=================================--创建测试表CREATE TABLE TB3( ID INT PRIMARY KEY)GO--===================================--新开回话1BEGIN TRAN INSERT INTO TB3SELECT 2WAITFOR DELAY '0:0:10'INSERT INTO TB3SELECT 1--= 阅读全文

posted @ 2014-03-05 14:57 笑东风 阅读(3605) 评论(1) 推荐(0) 编辑

常用脚本--查看当前锁信息
摘要：USE [master]GO/****** Object: StoredProcedure [dbo].[p_lockinfo] Script Date: 02/07/2014 11:54:29 ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROC [dbo].[usp_lockinfo]@kill_lock_spid BIT=0, --是否杀掉死锁的进程,1 杀掉, 0 仅显示@show_spid_if_nolock BIT=1 --如果没有死锁的进程,是否显示正常进程信息,1 显示,0 不显示ASBEGIN ... 阅读全文

posted @ 2014-02-07 12:02 笑东风 阅读(529) 评论(0) 推荐(0) 编辑

常用脚本--查看死锁和阻塞usp_who_lock
摘要：USE [master]GO/****** Object: StoredProcedure [dbo].[sp_who_lock] Script Date: 02/07/2014 11:51:24 ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOCREATE PROCEDURE [dbo].[usp_who_lock]ASBEGINDECLARE @spid INT,@bl INT,@intTransactionCountOnEntry INT, @intRowcount INT, @intCou... 阅读全文

posted @ 2014-02-07 11:54 笑东风 阅读(834) 评论(0) 推荐(0) 编辑

Transaction And Lock--锁相关基础
摘要：--=======================================================--锁提示--holdlock ：将共享锁保留到事务完成，而不是在相应的表、行或数据页不需要时就立即释放锁。holdlock等同于serializable--pagelock ：在通常使用单个表锁的地方采用页锁--nolock ：不要发出共享锁，并且不要提供排他锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。--有可能发生脏读。仅应用于select语句；NOLOCK在查询数据时不会被U锁阻塞，但是会被SCH-M锁阻塞；NOLOCK在任何事务隔离级别下效果都一样 阅读全文

posted @ 2014-01-17 15:23 笑东风 阅读(861) 评论(0) 推荐(0) 编辑

Transaction And Lock--解决死锁/锁的几种有效方式
摘要：修改资源访问顺序，使多个事务对资源的访问方式一致 优化查询SELECT，使得S锁能尽早释放 均可能将更新和删除语句放到事务末端(使得X锁占用时间最小) 避免事务执行期间暂停或等待外部输入 将较大事务拆分成多个小事务提交 控制事务在合适的隔离级别上运行 建立合适索引提示语句效率 删除无用索引和统计 将数据更新修改为数据插入 将数据拆按状态分到多个表 考虑使用快照解决S锁阻塞X锁 考虑使用程序队列来限制并发数（高并发造成大量的锁等待和上下文切换以及CPU资源消耗） 使用复制等技术将读写分离 在程序段使用缓存来避免对相同数据频繁更新 阅读全文

posted @ 2014-01-16 18:23 笑东风 阅读(605) 评论(0) 推荐(0) 编辑

Transaction And Lock--由Lookup导致的死锁情况
摘要：存在这样情况： 1.表TB1有一列建立索引 2.事务A对表进行更新，先获取对表的X锁以更新基本表中数据，然后对索引申请X锁以更新索引数据。 3.事务B对表进行更新，先获取索引上S锁以使用索引进行Loopup来查询数据，然后申请表的X锁以更新基本表数据 由于事务A和事务B申请到一部分锁资源同时需要对方的锁资源来完成操作，由于锁的不可剥夺性导致死锁产生 解决此类死锁的有效办法： 1.减少每次修改数据的行数,以减少事务的执行时间，从而降低事务发生的可能性 2.在一些情况下使用Include索引来减少lookup操作 阅读全文

posted @ 2014-01-16 18:22 笑东风 阅读(426) 评论(0) 推荐(0) 编辑

Transaction And Lock--由外键导致的死锁
摘要：死锁发生情况：1. 存在表A和表B，表A的主键是表B的外键2.事务A在表A上申请到X锁以修改表A中数据和删除表A中的数据，然后需要检查表B中的数据是否满足外键约束，从而需要Range锁来锁住表B3.事务B在表B上申请到X锁以修改表B中数据，然后向表A申请S锁来查询数据以上情况表造成资源环状阻塞，从而应发死锁。解决办法：1. 从设计角度来看，应避免修改表A中主键的值2. 对表B上的外键列建立索引，从而使事务A发生时将range锁放到索引上，从而降低死锁发生的概率​ 阅读全文

posted @ 2014-01-16 18:20 笑东风 阅读(906) 评论(0) 推荐(0) 编辑

Transaction And Lock--在事务中使用TRY CATCH
摘要：在事务中使用TRY CATCH的一些基础 阅读全文

posted @ 2014-01-16 18:15 笑东风 阅读(1579) 评论(0) 推荐(0) 编辑

Transaction And Lock--存储过程中使用事务的模板
摘要：一个存储过程中使用事务的模板 阅读全文

posted @ 2014-01-16 18:14 笑东风 阅读(316) 评论(0) 推荐(0) 编辑

Transaction And Lock--死锁错误号1205
摘要：在TSQL中，如果需要判断当前错误是否是因为死锁引起，可以使用ERROR_NUMBER()=1205来判断 在C#中，使用SQLException来捕获 SQLException.Number=1205代表由死锁引发 使用跟踪标记来查看死锁 1204 返回参与死锁的锁的资源和类型，以及受影响的当前命令。作用域：仅全局 1222 以不符合任何XSD 架构的XML 格式，返回参与死锁的锁的资源和类型，以及受影响的当前命令 阅读全文

posted @ 2014-01-16 18:12 笑东风 阅读(441) 评论(0) 推荐(0) 编辑

Transaction And Lock--已提交读快照
摘要：在事务执行过程中，并不保证两次读取数据一致，当数据在其他事务中修改并提交，再次查询能立即得到最新的数据。 使用快照来保存修改数据的原始版本，读取数据时如数据已经被修改但为提交，则读取快照中的副本数据 --===================================================== 在开启行版本控制后，SQL SERVER 会将行版本数据存放tempdb里，需要考虑tempdb的负载 --===================================================== 优点：有效减少读和写得阻塞,不会读取过时数据和不会引发数据版本冲突 缺点：维护行版本需要额外的开销 阅读全文

posted @ 2014-01-16 18:10 笑东风 阅读(296) 评论(0) 推荐(0) 编辑

Transaction And Lock--两种方式实现可重复读
摘要：一些需求要求两次查询数据之间不允许数据被修改，即可重复读取可重复读REPEATABLE READ与串行化SERIALIZABLE的区别在于串行化要求满足该查询的数据不被修改且无新满足该查询条件的数据插入（使用范围锁），可重复读只要求数据不被修改（保留S锁至事务结束）。而在read commit事务隔离级别下，被更新的数据会被加S锁，并一直保持事务提交或回滚，因此数据在事务区间内不能被其他事务修改，也保证了两次查询得到数据不发生变化(数据的值而不是行数)因此我们可以使用几种方式来保持数据不发生变化：方式1：在提交读隔离级别下使用HOLDLOCKHOLDLOCK相当于SERIALIZABLE隔离级 阅读全文

posted @ 2014-01-16 18:09 笑东风 阅读(387) 评论(0) 推荐(0) 编辑

Transaction And Lock--存在嵌套事务吗？
摘要：在很多编程语言中，可以实现嵌套，但在TSQL中，可以实现嵌套事务吗？ 答案：不可以 阅读全文

posted @ 2014-01-16 18:08 笑东风 阅读(372) 评论(0) 推荐(0) 编辑

Transaction And Lock--事务中使用return会回滚事务吗？
摘要：事务中使用return会回滚事务吗？ 答案：不会，如果在事务中没有显示提交或回滚事务边return，事务不会被提交或回滚，在C#中，如果没有使用连接池，则事务在连接断开和销毁时被强制回滚，如果使用连接池，则事务在连接被再次使用时调用的exec sp_reset_connection存储过程清理掉。如果该连接没有被再次使用或删除，则事务一直存在，便会一直锁住相关资源不释放，照常日志变大，镜像和复制异常等情况。 阅读全文

posted @ 2014-01-16 18:06 笑东风 阅读(3516) 评论(0) 推荐(0) 编辑

Transcation And Lock--SQL SERVER 事务隔离级别
摘要：SQL SERVER 事务隔离级别：1.未提交读(READ UNCOMMITED) 允许脏读，读取数据时不加共享锁，与使用WITH(NOLOCK)结果相同2.已提交读 不允许脏读，读取数据时加共享锁，但在查询结束后立即释放共享锁，而不用等到事务结束3.可重复读 不允许“不可重复读”，读取数据时加共享锁，将共享锁一直保持到事务结束，从而阻塞其他事务修改被读取的数据4.快照 SQL SERVER 有两种行版本控制,在事务修改数据时，保留一份未修改前的数据副本，其他事务读取数据时访问副本数据，从而有效较少读和写的阻塞 a)已提交读快照隔离(READ_COMMITED_SNAPSHOT) b)SNAP 阅读全文

posted @ 2014-01-16 18:05 笑东风 阅读(229) 评论(0) 推荐(0) 编辑

Transaction And Lock--常用的查询事务和锁的语句
摘要：常用的查询事务和锁的语句 阅读全文

posted @ 2014-01-16 18:04 笑东风 阅读(1126) 评论(0) 推荐(1) 编辑

1 2 下一页

导航

点击右上角即可分享
微信分享提示