DB：
ORA9i 前提：
两个DB操作的客户端工具A和B
（这儿说的DB操作客户端工具是泛指任何工具） 现象：
经常出现A客户端操作DB就像被Lock住，
等很长时间（1，2分钟）才出结果，对所有
表都一样（也只是简单的Select数据，而且
表里面也就几十条数据）。
但是，我发现一个诀窍，只要A被Lock的时候，
用B客户端工具操作一下DB（Select一些数据）
A客户端马上就被解锁！？？？
（注意：B工具我可一直没用）
ORA9i 前提：
两个DB操作的客户端工具A和B
（这儿说的DB操作客户端工具是泛指任何工具） 现象：
经常出现A客户端操作DB就像被Lock住，
等很长时间（1，2分钟）才出结果，对所有
表都一样（也只是简单的Select数据，而且
表里面也就几十条数据）。
但是，我发现一个诀窍，只要A被Lock的时候，
用B客户端工具操作一下DB（Select一些数据）
A客户端马上就被解锁！？？？
（注意：B工具我可一直没用）
再说LOCK的话，没有放它，别说两分钟了，就是两小时你也不一定能继续的
可能是数据库本身出了毛病吧，真的没听说过
不是我一个人，而是所有人都有相同问题
这有可能被锁定,解锁需要commit
請上PATCH至9.2.0.2.1
以上既可
用B客户端工具操作一下DB（Select一些数据）
A客户端马上就被解锁！？？？
（注意：B工具我可一直没用） 是解锁还是只能够select 数据出来？如果只能够select 数据出来，那么说明它选出来的不是服务端的数据，而是客户端的cache中的数据！
是 Oracle8i Enterprise Edition Release 8.1.7.0.1
或表的 MAX_TRANS 太低了！
这有可能被锁定,解锁需要commit
我个人认为这样的可能性比较大
或表的 MAX_TRANS 太低了！这个有可能。
不过我现在没环境，没法测试了
2、请查共享池分配是否合理？
3、跟踪一下你那工具是否还做了其他处理？
4、相应查询的表是否做了其他触发机制？
5、检查一下你那工具运行时占用系统资源的（服务器、客房端都查查）情况！
6、若再不行，把你那神秘的工具说出来让大家用用，我们一起解决！
7、若还不行，我们一起把那该死的工具干掉！
先到v$locked_object 视图中看看是不是真的上锁造成的！！！！