阻塞分析

--阻塞
/***********************************************************************************************************************
阻塞:其中一个事务阻塞,其它事务等待对方释放它们的锁,同时会导致死锁问题。     

整理人:中国风(Roy)     

日期:2008.07.20
************************************************************************************************************************/     

--生成测试表Ta
if not object_id(‘Ta‘) is null
    drop table Ta
go
create table Ta(ID int Primary key,Col1 int,Col2 nvarchar(10))
insert Ta
select 1,101,‘A‘ union all
select 2,102,‘B‘ union all
select 3,103,‘C‘
go
生成数据:
/*
表Ta
ID          Col1        Col2
----------- ----------- ----------
1           101         A
2           102         B
3           103         C     

(3 行受影响)
*/     

将处理阻塞减到最少:
1、事务要尽量短
2、不要在事务中请求用户输入
3、在读数据考虑便用行版本管理
4、在事务中尽量访问最少量的数据
5、尽可能地使用低的事务隔离级别     

go
阻塞1(事务):
--测试单表     

-----------------------------连接窗口1(update/insert/delete)----------------------
begin tran
--update
    update ta set col2=‘BB‘ where ID=2
--或insert
begin tran
    insert Ta values(4,104,‘D‘)
--或delete
begin tran
    delete ta where ID=1     

--rollback tran     

------------------------------------------连接窗口2--------------------------------
begin tran
    select * from ta     

--rollback tran     

--------------分析-----------------------
select
    request_session_id as spid,
    resource_type,
    db_name(resource_database_id) as dbName,
    resource_description,
    resource_associated_entity_id,
    request_mode as mode,
    request_status as Status
from
    sys.dm_tran_locks
/*
spid        resource_type dbName resource_description resource_associated_entity_id mode  Status
----------- ------------- ------ -------------------- ----------------------------- ----- ------
55          DATABASE      Test   0                    S                             GRANT NULL
54          DATABASE      Test   0                    S                             GRANT NULL
53          DATABASE      Test   0                    S                             GRANT NULL
55          PAGE          Test   1:201                72057594040483840             IS    GRANT
54          PAGE          Test   1:201                72057594040483840             IX    GRANT
55          OBJECT        Test   1774629365           IS                            GRANT NULL
54          OBJECT        Test   1774629365           IX                            GRANT NULL
54          KEY           Test   (020068e8b274)       72057594040483840             X     GRANT --(spID:54请求了排它锁)
55          KEY           Test   (020068e8b274)       72057594040483840             S     WAIT  --(spID:55共享锁+等待状态)
(9 行受影响)
*/     

--查连接住信息(spid:54、55)
select connect_time,last_read,last_write,most_recent_sql_handle
from sys.dm_exec_connections where session_id in(54,55)     

--查看会话信息
select login_time,host_name,program_name,login_name,last_request_start_time,last_request_end_time
from sys.dm_exec_sessions where session_id in(54,55)     

--查看阻塞正在执行的请求
select
    session_id,blocking_session_id,wait_type,wait_time,wait_resource
from
    sys.dm_exec_requests
where
    blocking_session_id>0--正在阻塞请求的会话的 ID。如果此列是 NULL,则不会阻塞请求     

--查看正在执行的SQL语句     

select
    a.session_id,sql.text,a.most_recent_sql_handle
from
    sys.dm_exec_connections a
cross apply
    sys.dm_exec_sql_text(a.most_recent_sql_handle) as SQL   --也可用函数fn_get_sql通过most_recent_sql_handle得到执行语句
where
    a.Session_id in(54,55)
/*
session_id  text
----------- -----------------------------------------------
54          begin tran   update ta set col2=‘BB‘ where ID=2
55          begin tran   select * from ta
*/     

处理方法:
--连接窗口2
begin tran
    select * from ta with (nolock)--用nolock:业务数据不断变化中,如销售查看当月时可用。     

阻塞2(索引):     

-----------------------连接窗口1
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE    --针对会话设置了 TRANSACTION ISOLATION LEVEL
begin tran
    update ta set col2=‘BB‘ where COl1=102     

--rollback tran     

------------------------连接窗口2
insert into ta(ID,Col1,Col2) values(5,105,‘E‘)     

处理方法:     

create index IX_Ta_Col1 on Ta(Col1)--用COl1列上创索引,当更新时条件:COl1=102会用到索引IX_Ta_Col1上得到一个排它键的范围锁     

阻塞3(会话设置):     

-------------------------------连接窗口1     

begin tran
--update
    update ta set col2=‘BB‘ where ID=2
    select col2 from ta where ID=2     

--rollback tran     

--------------------------------连接窗口2     

SET TRANSACTION ISOLATION LEVEL READ COMMITTED --设置会话已提交读:指定语句不能读取已由其他事务修改但尚未提交的数据
begin tran
    select * from ta      

处理方法:
--------------------------------连接窗口2(善用会话设置:业务数据不断变化中,如销售查看当月时可用)     

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED --设置会话未提交读:指定语句可以读取已由其他事务修改但尚未提交的行
begin tran
    select * from ta   

转自:http://blog.csdn.net/roy_88/article/details/2682044

时间: 2025-01-06 06:18:53

阻塞分析的相关文章

MySQL锁阻塞分析

日常维护中,经常会碰到线程被阻塞,导致数据库响应非常慢,下面就看看如何获取是哪个线程导致了阻塞的. blog地址:http://blog.csdn.net/hw_libo/article/details/39080809 1. 环境说明 RHEL 6.4 x86_64 + MySQL 5.6.19 事务隔离级别:RR 2. 测试过程 3. 查看锁阻塞线程信息 这里用几中方法进行分析: 3.1  使用show processlist查看 MySQL [(none)]> show processli

MySQL5.6锁阻塞分析

日常维护中,经常会碰到线程被阻塞,导致数据库响应非常慢,下面就看看如何获取是哪个线程导致了阻塞的. blog地址:http://blog.csdn.net/hw_libo/article/details/39080809 1. 环境说明RHEL 6.4 x86_64 + MySQL 5.6.19事务隔离级别:RR 2. 测试过程 3. 查看锁阻塞线程信息这里用几中方法进行分析:3.1  使用show processlist查看MySQL [(none)]> show processlist;+-

SQL Server 查看进程阻塞及处理

修改或删除数据前先备份,先备份,先备份(重要事情说三遍)! 1.首先,查看线程,分析是否存在阻塞进程,blocked>0都是当前被阻塞的进程  SELECT * FROM sysprocesses where blocked >0 order by blocked ; 2.找到被阻塞的线程后,想要继续查看进程被谁阻塞,分析导致阻塞的源头 SELECT * FROM SYSPROCESSES WHERE spid =spid_no(这是你要分析的进程ID) 3.查看此进程执行的SQL 是哪个,查

从架构师的角度分析Android Handler 源码的正确姿势

Handler的原理是什么?能深入分析下 Handler的实现机制吗?面试官问该问题是想问清楚handler的源码,handler机制如何实现,对消息泵Looper理不理解(更多完整项目下载.未完待续.源码.图文知识后续上传github.) 1. Handler 机制简介 定义 一套 Android 消息传递机制 作用 在多线程的应用场景中,将工作线程中需更新UI的操作信息 传递到 UI主线程,从而实现 工作线程对UI的更新处理,最终实现异步消息的处理 使用Handler的原因:将工作线程需操作

数据库事务【隔离级别】

为了快速同步数据的需要,我分段执行了两次python脚本,即开启了两个进程同步数据,结果服务器不时报出数据库死锁异常,通过排查代码和数据库日志发现,是由长事务并发引起的.代码中有入账和出账两个方法,里面涉及操作较多,都为其加了事务,抛出异常时可自动回滚,采用数据库(mysql)默认的隔离级别(Repeatable read).提到并发,一般就会想到用同步代码块的方法的处理,但是由于项目是分布式的,共用一个主库,单单在代码加锁是不能保证数据的准确的,那就只能在数据库层面去考虑加锁了.由于数据量暂时

事务库事务隔离级别

为了快速同步数据的需要,我分段执行了两次python脚本,即开启了两个进程同步数据,结果服务器不时报出数据库死锁异常,通过排查代码和数据库日志发现,是由长事务并发引起的.代码中有入账和出账两个方法,里面涉及操作较多,都为其加了事务,抛出异常时可自动回滚,采用数据库(mysql)默认的隔离级别(Repeatable read).提到并发,一般就会想到用同步代码块的方法的处理,但是由于项目是分布式的,共用一个主库,单单在代码加锁是不能保证数据的准确的,那就只能在数据库层面去考虑加锁了.由于数据量暂时

Oracle内存详解之二 Library cache 库缓冲-转载

Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息. Library cache需要解决三个问题: 1.快速定位的问题:Library cache中对象众多,Oracle如何管理这些对象,以便服务进程可以迅速找到他们需要的信息.比如某个服务进程需要迅速定位

一个锁等待现象的诊断案例

作者:苏坡 袋鼠云云服务部-DBA团队 数据库工程师 前两日与一个客户交流, 客户提出了一些 对mysql隔离级别以及锁的疑问, 然后问到了出现锁等待现象的排查思路. 这不禁让我回想起 long long ago, 做过的一个诊断案例. 当年我还不是一枚老司机, 折腾了两三天才完全搞定, 现在回想还颇有些借鉴价值, 故,分享之~ 一.问题描述 数据库实例:主库XXXX:3306 问题详情:客户反映,涉及到user_site表相关的程序回调操作很慢,部分操作会超时报错: 下单操作很慢甚至直接报错失

14.2 Go性能优化

14.2 Go性能优化 优化手段 1.减少HTTP请求数,合并CSS.JS.图片 2.使用CDN,就近访问 3.启用nginx gzip压缩,降低传输内容大小 4.优化后端api性能 api服务性能优化目标 1.线上程序是黑盒状态 2.通过性能分析,可知程序占用多少资源 3.找到系统瓶颈 go性能优化方向 1.Cpu维度优化 2.Mem维度优化 3.锁竞争维度的优化 1.1. 性能优化原理 1.知道程序占用了多少资源,如cpu,内存量 2.知道程序的函数占用资源比例 3.如有A,B两个数据就可以