解决session阻塞的问题

简介

    对于数据库运维人员来说创建session或者查询时产生问题是常规情况，下面介绍一种很有效且不借助第三方工具的方式来解决类似问题。

最近开始接触运维工作，所以自己总结一些方案便于不懂数据库的同事解决一些不太紧要的数据库问题。类似方法很多理论也很多，我就不做深究，就是简单写一个方案，便于菜鸟使用的。

阻塞理解

在Sql Server 中当一个数据库会话中的事务正锁定一个或多个其他会话事务想要读取或修改的资源时，会产生阻塞(Blocking)。通常短时间的阻塞没有问题，且是较忙的应用程序所需要的。然而，设计糟糕的应用程序会导致长时间的阻塞，这就不必要地锁定了资源，而且阻塞了其他会话读取和更新它们。

 

例子

   为了更好说明，下面用一个例子来介绍。创建一个表并插入数据，然后创建不同的session，同事阻塞session。具体的代码截图如下：

1.创建表Employee

2.插入测试数据

 

 

现在我们有了测试表，表中有12条数据，打开另一个查询对话框在SSMS中（意味着重新创建了一个session）

3.在新的查询窗口中首先要开启事务，然后写一个插入语句

 

在这个地方，我们能看到开启了一个事务。但是没有end tran 来终止事务，因此事务状态为“open”，现在运行脚本来看一下当前看起的运行处于“open”状态的session。

 

    现在能够看到如上图展示一样，运行的查询正在open状态的session。我们执行了这个命令但是没有完结它，DBA会联系这个session的创建者来完成事务，或者回滚事务。

现在让我们创建另一个session，更新一条记录并且不提交，即让查询session的状态为“open”。因此在新的查询窗口中 写一个语句来执行如下：

 

 

这里会看到系统正在运行后没有完成语句的状态（因为上一个事务没有关闭导致表锁，这个不能插入），现在可以在另外的窗口查询一下阻塞的情况，如下检查阻塞的session。

 

 

如上所示，阻塞的session ID是58，由于我们更新查询导致阻塞了54的执行，54就是我们插入数据未提交的批处理。

现在我们能搞清楚阻塞的原因，也就可以从容解决阻塞了。

解决

方案1

在了解业务的情况下，可以直接使用kill session ID的语句来终止某个阻塞的session。

方案2

在执行的事务的起始加入“set lock_timeout 1000” 语句，这表示如果阻塞超过1000毫秒，这个请求将被终止。

方案3

回滚或者提交事务。这个就不细说了。

下面是所有语句的代码：

 

/****Creating dummy table Employee ****/ 
CREATE TABLE Employee ( Empid int NOT NULL, Name nchar(10) NULL, City nchar(10) NULL ) ON [PRIMARY] GO 
/**** Insert dummy data in Employee table *****/ 
Insert into Employee Values(1245,'George','Jax'), (1045,'Peter','Anadale'), (1157,'John','Dallas'), (1175,'Pete','Topeka'), (875,'Petron','Vienna'), 
(2311,'Kohli','Mumbai'), (1547,'Peter','Kansas'), (3514,'Abian','KHI'), (4251,'Ghani','Alexandria'), (957,'Ahmed','Vienna'), (1084,'Bhanu','Manderin'), 
(2954,'Ganeshan','Mcclean')
 /***** Insert query in new session ****/ 
BEGIN TRAN Insert into Employee Values(1245,'George','Jax') 
/**** Query to check currently running sessions ****/ 
SELECT DISTINCT name AS database_name, session_id, host_name, login_time, login_name, reads, writes FROM sys.dm_exec_sessions 
LEFT OUTER JOIN sys.dm_tran_locks ON sys.dm_exec_sessions.session_id = sys.dm_tran_locks.request_session_id 
INNER JOIN sys.databases ON sys.dm_tran_locks.resource_database_id = sys.databases.database_id 
WHERE resource_type <> 'DATABASE' --AND name ='specific db name' 

ORDER BY name

 /**** update query in new session ****/ 
update Employee set name = 'SHERAZ' where empid = 1245 
/**** Query to check blocking queries with session id ****/ 
SELECT session_id, blocking_session_id, text FROM sys.dm_exec_requests CROSS APPLY sys.dm_exec_sql_text(sql_handle); 
/*** Command if you want to kill blocking session ****/ kill (54)

 

 

总结

     自己也使用过多种不同的语句来查询定位阻塞甚至死锁，然后解决，这里也是介绍一种临时解决方式。万变不离其宗，归根结底还是因为代码甚至数据库设计上存在很多问题才导致的阻塞，比如缺失索引、事务中的查询性能和逻辑顺序存在问题、T-SQL语句性能引起的等等不一而足。对于一些常年解决类似问题的DBA人员来说没啥价值，但是对于不太理解数据库的人来说还是能暂时解决一些紧急问题，当然最后还是要把理论基础打好才能尽可能的杜绝类似情况。