最近在维护Web Service接口时,由于数据数据量达到千万级别,接口调用不时出现错误让人不胜烦恼,经过性能测试查出瓶颈在数据库数据处理上,可着实忙了一番。相信众多程序猿和DBA都会头痛性能的问题,尤其是应用程序池的超时和假死造成的后台数据处理中断,带来的数据维护带来不小的麻烦。

 

在此背景下追查后台处理数据时请求中断成为目前棘手的问题,被吊打之余正努力想办法解决根本问题,小弟在解决防止数据处理时请求中断上,想到了Transaction的可行性,于是有了这篇随笔出来,废话比较多,下面开始吧

 

首先做点准备工作,建库建表



create database tranTest
go

use TranTest
go

create table TranTest(
ID int identity (1,1),
CreateTime datetime,
Value int
)
go



 

带transaction的 Proc ,不才sql小学级别,将就着看,大意是1秒钟插一条记录到TranTest表中,持续30秒



create proc [dbo].[testTrans]
as 
begin
declare @timeSpan datetime
declare @timeStart datetime
declare @val int = 1
    begin try 
        begin transaction 
            set @timeSpan = GETDATE();set @timeStart=getdate();
            while(DATEDIFF(second,@timeStart,getdate())<=30)
            begin
                while(DATEDIFF(SECOND,@timeSpan,getdate())=1)
                begin
                    set @timeSpan = GETDATE()
                    insert into TranTest values (getdate(),@val);
                    --update trantest set value=@val,createtime=getdate() where id=(select max(id) from trantest)
                    --set @val = @val +1
                end
            end
        commit transaction 
    end try 
    begin catch 
    select ERROR_NUMBER() as errornumber 
    rollback transaction 
    end catch
end



 

有了材料咱开始吧,首先要验证是transaction默认Level设置,在中断时的锁是行锁还是表锁

场景设置: 先运行3秒,强制中断,查询表中的数据,查看锁情况

exec  testTrans  走起,执行3秒强制结束查询分析器的执行

 

sql server中锁表 锁表的sql_sql server中锁表

查看数据及锁的情况,带脏读查看表数据如下,3秒钟插入了3条,由于强制中止了执行,造成5条锁数据,其中重点关注id为54的锁(database级锁本文不做扩展),此时不带脏读是查不出数据的(去掉with(nolock)),由于只有3条数据都被加锁,无法确定是否为

sql server中锁表 锁表的sql_数据库_02

上表使用的sql如下,新开查询分析页使用exec ('kill 54')解除锁,再来查询表数据,会发现表中没有数据,此时sql server回滚了数据操作



select * from TranTest with(nolock)

SELECT request_session_id sessionid,
resource_type type,
resource_database_id dbid,
OBJECT_NAME(resource_associated_entity_id, resource_database_id) objectname,
request_mode rmode,
request_status rstatus
FROM sys.dm_tran_locks
WHERE resource_type IN ('DATABASE', 'OBJECT')

解除锁
exec ('kill 54')



 

修改下Proc中的30,将30改为3运行到结束,先正常插入3条数据为后面测试做准备。再将proc更新成如下代码,单独修改单条数据



alter proc [dbo].[testTrans]
as 
begin
declare @timeSpan datetime
declare @timeStart datetime
declare @val int = 1
    begin try 
        begin transaction 
            set @timeSpan = GETDATE();set @timeStart=getdate();
            while(DATEDIFF(second,@timeStart,getdate())<=30)
            begin
                while(DATEDIFF(SECOND,@timeSpan,getdate())=1)
                begin
                    set @timeSpan = GETDATE()
                    --insert into TranTest values (getdate(),@val);
                    update trantest set value=@val,createtime=getdate() where id=(select max(id) from trantest)
                    set @val = @val +1
                end
            end
        commit transaction 
    end try 
    begin catch 
    select ERROR_NUMBER() as errornumber 
    rollback transaction 
    end catch
end



 

运行更新后的proc,3秒时强制终止执行,看下表值的前后变化,依然新开查询分析页,查询表中的值

sql server中锁表 锁表的sql_数据_03

 

我们使用脏读方式看到了ID为3的数据被更新了,再来看看锁的情况,此时的锁默认为行锁,验证方法很简单,使用select * from TranTest查询时查询被hang住了,使用select * from TranTest where id=1 时,数据就出来了,如果将 where 的条件改成 id=3查询依然无法返回,此时说明ID=3的这条数据被锁

sql server中锁表 锁表的sql_查询分析器_04

 

下面继续看看回滚方面的验证,上图已经查到行锁ID为54,使用exec('kill 54')解除行锁, 再来查看表数据,ID=3的数据恢复到初始状态,回滚被执行了

sql server中锁表 锁表的sql_sql server中锁表_05

 

有小伙伴可能会问,IIS的应用程序池连接中断和查询分析器强制终止是相同行为吗,要验证很简单,建一个空网站,调用上面的proc,设置执行超时时间为3秒,行为与查询分析器中一样,大家可以去验证一下,关于锁的Level问题和Database级的锁后面继续探索

 

sql server中锁表 锁表的sql_表数据_06