周二下午处理了一单sql server2012只读节点阻塞严重的问题。首先接到应用人员说明的问题，然后我们进入该服务器进行查询分析：
    
SELECT blocking_session_id, wait_duration_ms, session_id 
FROM sys.dm_os_waiting_tasks 
WHERE blocking_session_id IS NOT NULL;

blocking_session_id     wait_duration_ms      session_id 
40                      23675                  238
40                      10544                  115
.............................................

粗看一下，好像是40大概产生了好几十个阻塞。致使连接到上面的用户基本上不能使用

也可以通过sys.sysprocesses来查询，其中blocked是阻塞产生源。

40应该是一个后台进程，所需求的资源为LCK_M_SCH_M，当某任务正在等待获取架构修改锁时出现。在任务等待获取使用中止阻塞程序的架构修改锁时发生。 （与 ALTER TABLE 和 ALTER INDEX 的低优先级等待选项相关。）

select blocking_session_id,wait_duration_ms, session_id FROM sys.dm_os_waiting_tasks where session_id = 40;

blocking_session_id     wait_duration_ms      session_id

139                     375601                40

可以看到是139在阻塞这个会话，并且很长时间了，继续查询139执行的会话是：

SELECT t.text 
FROM sys.dm_exec_connections c 
CROSS APPLY sys.dm_exec_sql_text (c.most_recent_sql_handle) t 
WHERE c.session_id = 139

text

exec mytest_custom_proc '','','','','','','','','','','','传统业代','1','','54','500','0','','613672'

可以看到执行了一个存储过程，正是这个语句一直在阻塞。
把该存储过程给到，开发人员分析，他们说这是某个客户端正在执行业务数据导出所致

其中，导出的是状态为1的客户状态，经过统计分析，这个为1的状态的数量级大概在150万左右，加上网络传输，所以一直卡在这里，并且后来检查，不只是一个人在导出这个量级的数据！

所以基本上可以确定的是，从awayson的主节点发起了一个修改，在备节点进行处理，而备节点提供给客户查询，这个查询时间太长，导致主节点发起的修改无法完成，形成第一层阻塞。而备节点的还原操作因为被hang，而其它基于该表查询申请共享锁hang住。

最后处理办法：

    由于有好几个客户在做，无赖之下，我们把只读节点停止，重新启动。开发人员修改程序，对这种大批量的导出进行处理