锁已经配到100万了为什么数据库经常报1204错误?

qzwsf · 发表于 2010-8-9 14:50

什么版本?BUG可能性大哦

1038345 · 发表于 2010-8-10 15:56

数据库版本是15.0.3

select * from master.dbo.syslocks,我在系统不忙时查到只有几条记录，在系统忙时这个表的数据太多了,数据库响应不过来了.

1038345 · 发表于 2010-8-10 16:09

查询计划用到索引了

1038345 · 发表于 2010-8-13 10:01

原帖由 jarjar 于 2010-8-7 18:15 发表

当update语句也是table scan的时候，请检查锁的情况。

sp_lock输出太多，可以用select * from master.dbo.syslocks。

如果12.5.3以上，select top 100 * from master.dbo.syslocks
否则
set rowcount 100
select * from master.dbo.syslocks

这位朋友,请问update语句用table scan的时候锁是怎么使用的,扫描经过的地方都会上锁吗？

5个周 · 发表于 2010-8-13 14:08

只有需要被update的记录才会被加锁，你这问题只能通过总结出现的规律从业务上来分析。

5个周 · 发表于 2010-8-13 14:20

原帖由 1038345 于 2010-8-10 15:56 发表
数据库版本是15.0.3

select * from master.dbo.syslocks,我在系统不忙时查到只有几条记录，在系统忙时这个表的数据太多了,数据库响应不过来了.

有个笨办法：做个脚本，每5分钟连到数据库里面把sp_lock或者syslocks输出，如果输出文件的尺寸开始增大，则打开输出文件找到持锁最多的进程spid，然后赶快连进去，dbcc traceon(3604) dbcc sqltext(spid)，观察个一天两天也就知道是什么业务产生大量的锁了。

自动一点呢，就写个循环执行的程序：开始select spid,max(count(spid)) from syslocks(大概就就这意思)，然后dbcc traceon(3604) dbcc sqltext(spid)输出到一张表或者其他地方去，晚了order by一下这张表就完了呗。

还有一个可能性，就是你的业务用了很多临时表，因为ASE 15的系统表开始用行锁了，所以临时表消耗了很多锁资源，这种情况的话可能就要稍麻烦一点，要在创建临时表的时候指定用allpage而不是用缺省的allrows。

lifesunson · 发表于 2011-8-26 10:13

怪不得看不懂了
原来是sybase

wangminitpub · 发表于 2013-5-28 17:21

不一定是一个作业造成，还有一种可能是在循环体里每一次循环都增加一个更新操作，但由于没有commit，占的锁不释放，大的循环会造成锁满了