sybase数据库死锁问题,跪求达人

qfsb_p 2004-07-08 04:47:12
假设在客户端执行一个应用通过odbc访问sybase数据库进行操作时,网络突然断了,这样在sybase服务端很容易会死锁的(类似
begin tran
lock table Table_XXX in exclusive mode
go
产生的死锁)。
在我的sybase的服务端,这个锁将一直存在,并阻塞我对Table_XXX进行的查询。
我目前是这样解决的:
在select语句后加上 AT ISOLATION READ UNCOMMITTED

我想问:
服务方是否有参数配置,可以自动释放这种锁?
...全文
318 点赞 收藏 29
写回复
29 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
qfsb_p 2004-09-01
谢谢大家,结贴
回复
enhydraboy 2004-08-25
我认为,根本问题是你写的语句的问题,为什么一下子要把整个表上EXCLUSIVE锁。除非很特别的情况下,不要随便使用表级锁。
而且,你出现的这个问题,是由于网络底层问题,导致服务器端的PROCESS没有正常释放,在这种情况下,只有让DBA帮助你kill掉这个process.
回复
九头鸟 2004-08-25
还是你的程序的问题,你可在PB下可执行的窗口中执行EXEC SP_lock;exec sp_who;看看的被锁的问题
回复
SnakeWOo 2004-08-24
另外,程序设计中应该尽量避免大的事务
回复
SnakeWOo 2004-08-24
你可以试试把表改成DOL表
回复
mike678cn 2004-08-20
up
回复
aceplus 2004-08-19
把对数据库的操作封装到应用层,如果没有,封装为存储过程在数据库里执行--压力是大那么一点点
回复
ailun1982 2004-08-17
应该修改程序,把你的程序写上来
回复
mike678cn 2004-08-16
同样关注
回复
qfsb_p 2004-08-16
楼上的解决办法不行
回复
half 2004-07-26
我觉得有两个办法处理:
1、修改你的客户端程序,在每个处理过程中采用同一事务处理,即将auto commit =false。
2、编写一个后台循环检查数据库锁表的服务程序。
回复
hobbylu 2004-07-23
锁的策略
APL
在isolation level 1,共享锁在整个操作期间都锁住访问页(不是事务,而是操作)
在isolation level 2 or 3 或使用holdlock查询, 锁直到整个事务结束
DOL(忽略)
以后再讲
回复
hobbylu 2004-07-23
sybase对于锁的设计,有它自己的道理
做select的时候它要保证你选择的数据的准确性,所以在表上面加共享锁,根据你的表的锁机制,还分不同级别的锁。一般我们知道共享锁就行了。
共享锁就是其他的用户还可以对该表加共享锁,但是要对数据做修改的就不行了。
回复
qfsb_p 2004-07-23
sky125,如果手动kill的话,势必要有专门的人员关注这个应用以及对应的数据库资源,这样的话,用户会觉得开销太大的。
yuantonghua,number of locks指的是在sybase中的锁的个数,并非我指的。

hobbylu,你说的是什么意思,我觉得似懂非懂,请再指教!谢谢
回复
sky125 2004-07-22
为什么不能手动kiill 这个lock_id呢
回复
yuantonghua 2004-07-18
你可以调整一下SYBASE的参数试试,如"number of locks"
回复
sqhua 2004-07-17
这又是Sybase设计不好的地方,锁就锁吗,Select应该可以照用的
而且不应该把整个表锁起来
回复
sqhua 2004-07-17
oracle not this problem
回复
SybaseASE 2004-07-14
事务不提交,当然锁不能释放,好象SERVER不能自动处理,需要你自己处理
回复
aceplus 2004-07-13
在select语句后加上 AT ISOLATION READ UNCOMMITTED
这样会产生很多问题的吧?
回复
发帖
Sybase
创建于2007-09-28

2576

社区成员

Sybase相关技术讨论区
申请成为版主
帖子事件
创建了帖子
2004-07-08 04:47
社区公告
暂无公告