仓酷云

标题: 事件堵塞案例详解 [打印本页]

作者: 柔情似水    时间: 2015-1-16 14:09
标题: 事件堵塞案例详解
支持多线程,充分利用CPU资源--堵塞
/**********************************************************************************************************
堵塞:个中一个事件堵塞,别的事件守候对方开释它们的锁,同时会招致逝世锁成绩。
收拾人:中国风(Roy)
日期:2008.07.20
***********************************************************************************************************
--天生测试表Ta
ifnotobject_id(Ta)isnull
droptableTa
go
createtableTa(IDintPrimarykey,Col1int,Col2nvarchar(10))
insertTa
select1,101,Aunionall
select2,102,Bunionall
select3,103,C
go
天生数据:
/*
表Ta
IDCol1Col2
--------------------------------
1101A
2102B
3103C

(3行受影响)
*/

将处置堵塞减到起码:
1、事件要只管短
2、不要在事件中哀求用户输出
3、在读数据思索便用行版本办理
4、在事件中只管会见起码量的数据
5、尽量地利用低的事件断绝级别

go
堵塞1(事件):
--测试单表

-----------------------------毗连窗口1(update/insert/delete)----------------------
begintran
--update
updatetasetcol2=BBwhereID=2
--或insert
begintran
insertTavalues(4,104,D)
--或delete
begintran
deletetawhereID=1

--rollbacktran

------------------------------------------毗连窗口2--------------------------------
begintran
select*fromta

--rollbacktran

--------------剖析-----------------------
select
request_session_idasspid,
resource_type,
db_name(resource_database_id)asdbName,
resource_description,
resource_associated_entity_id,
request_modeasmode,
request_statusasStatus
from
sys.dm_tran_locks
/*
spidresource_typedbNameresource_descriptionresource_associated_entity_idmodeStatus
------------------------------------------------------------------------------------------
55DATABASETest0SGRANTNULL
54DATABASETest0SGRANTNULL
53DATABASETest0SGRANTNULL
55PAGETest1:20172057594040483840ISGRANT
54PAGETest1:20172057594040483840IXGRANT
55OBJECTTest1774629365ISGRANTNULL
54OBJECTTest1774629365IXGRANTNULL
54KEYTest(020068e8b274)72057594040483840XGRANT--(spID:54哀求了排它锁)
55KEYTest(020068e8b274)72057594040483840SWAIT--(spID:55共享锁+守候形态)
(9行受影响)
*/

--查毗连住信息(spid:54、55)
selectconnect_time,last_read,last_write,most_recent_sql_handle
fromsys.dm_exec_connectionswheresession_idin(54,55)

--检察会话信息
selectlogin_time,host_name,program_name,login_name,last_request_start_time,last_request_end_time
fromsys.dm_exec_sessionswheresession_idin(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_connectionsa
crossapply
sys.dm_exec_sql_text(a.most_recent_sql_handle)asSQL--也可用函数fn_get_sql经由过程most_recent_sql_handle失掉实行语句
where
a.Session_idin(54,55)
/*
session_idtext
----------------------------------------------------------
54begintranupdatetasetcol2=BBwhereID=2
55begintranselect*fromta
*/

处置办法:
--毗连窗口2
begintran
select*fromtawith(nolock)--用nolock:营业数据不休变更中,如发卖检察当月时可用。


堵塞2(索引):

-----------------------毗连窗口1
SETTRANSACTIONISOLATIONLEVELSERIALIZABLE--针对会话设置了TRANSACTIONISOLATIONLEVEL
begintran
updatetasetcol2=BBwhereCOl1=102

--rollbacktran


------------------------毗连窗口2
insertintota(ID,Col1,Col2)values(5,105,E)


处置办法:

createindexIX_Ta_Col1onTa(Col1)--用COl1列上创索引,当更新时前提:COl1=102会用到索引IX_Ta_Col1上失掉一个排它键的局限锁


堵塞3(会话设置):

-------------------------------毗连窗口1

begintran
--update
updatetasetcol2=BBwhereID=2
selectcol2fromtawhereID=2

--rollbacktran

--------------------------------毗连窗口2

SETTRANSACTIONISOLATIONLEVELREADCOMMITTED--设置会话已提交读:指定语句不克不及读取已由其他事件修正但还没有提交的数据
begintran
select*fromta

处置办法:
--------------------------------毗连窗口2(善用会话设置:营业数据不休变更中,如发卖检察当月时可用)

SETTRANSACTIONISOLATIONLEVELREADUNCOMMITTED--设置会话未提交读:指定语句能够读取已由其他事件修正但还没有提交的行
begintran
select*fromtaMyISAMMysql的默认数据库,最为常用。拥有较高的插入,查询速度,但不支持事务
作者: 冷月葬花魂    时间: 2015-1-18 12:18
理解了存储结构,再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识
作者: 精灵巫婆    时间: 2015-1-26 18:47
比如,MicrosoftSQLServer2008的某一个版本可以满足现在的这个业务的需要,而且价格还比Oracle11g要便宜,那么这一产品就是适合的。
作者: 若相依    时间: 2015-2-4 21:00
如果我们从集合论(关系代数)的角度来看,一张数据库的表就是一组数据元的关系,而每个SQL语句会改变一种或数种关系,从而产生出新的数据元的关系(即产生新的表)。
作者: 再见西城    时间: 2015-3-1 12:22
如果,某一版本可以提供强大的并发响应,但是没有Oracle的相应版本稳定,或者价格较贵,那么,它就是不适合的。
作者: 简单生活    时间: 2015-3-10 17:51
我们学到了什么?思考问题的时候从表的角度来思考问
作者: 柔情似水    时间: 2015-3-17 09:47
学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!
作者: 老尸    时间: 2015-3-24 06:46
数据库物理框架没有变动undo和redo都放在数据库得transaction中,个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库,可能能在一定程度上避免I/O效率问题。




欢迎光临 仓酷云 (http://ckuyun.com/) Powered by Discuz! X3.2