|
• 问题的出现及现象描述
今年9月，我给我公司的一个报社用户升级基于sybase数据库的应用系统。为此制定了两套升级方案：一是整库的dump/load，二是表的bcp。考虑到升级的时间限制、库结构的变化以及数据库字符集要由iso_1迁移为cp850，最后决定采用方案二，即：表的bcp拷贝。经过供需双方技术人员的共同努力，整个系统顺利升级并一次切换成功。
就在其后的系统运行跟踪期间，系统出现了异常，具体现象表现为，输入登陆帐号后，应用程序界面迟迟不出现，而查看Windows进程却发该应用的进程显示，把Sybase 数据库服务重起后，则应用系统恢复正常。
• 查明问题原因
这个问题在我们众多的用户中从来没碰到过。经过现场观察和深入分析，首先查看服务器的系统日志和Sybase数据库的errorlog日志文件，经过细致的观察，均发现有大量的错误信息存在：
00:00000:00203:2007/09/03 10:12:04.59 kernel Cannot send, host process disconnected: 2708 spid: 203
00:00000:00203:2007/09/03 10:12:04.59 server Error: 1608, Severity: 18, State: 4
00:00000:00203:2007/09/03 10:12:04.59 server A client process exited abnormally, or a network error was encountered. Unless other errors occurred, continue processing normally
根据以往经验，1608错误原因一般是网络不稳定或客户端不正常退出引起的，经过对网络环境进行勘察核实，首先排除了网络不稳定因素和病毒；由于现场问题时，问题不再现，而数据库、应用软件都很正常，致使排错进程陷入僵局。
不经意间，想起以前作过锁表的实验，会不会是锁的阻塞引起的呢？于是对应用系统登陆模块用到的表进行手动了锁定试验：(应用系统登陆都要用到该表)
use ImplyDB
Go
Begin tran
Update ImplyTable set UpdateFlag=’1’ where LoginName=’user1’
Go
此时进入应用系统时，异常出现了，由此断定故障就是由锁的阻塞引起的。
• 故障现象解释
Adaptive Server 的缺省隔离级别是1，即防止脏读。级别1的查询只读取已提交的数据更改。在隔离级别1，如果事务需要读取被另一会话中未完成的事务修改过的行，该事务将等待，直到第一个事务完成（提交或回退）。
此次系统异常的原因，可能是工作站由于性能的原因，不能及时完成对登陆表的处理，而占用了锁，进而造成随后登陆的帐户的锁的等待，因此造成表的阻塞，从而引发文中所描述的异常现象。
• 故障处理
原因找到了，问题迎刃而解。首先安装我公司研发的锁监控程序，其次，将表锁改为行锁。
|
