Oracle 10g 突发 1000 人 update 一个表中的一行, 导至严重延时如何解决呢?

Question

  Oracle 10g 突发 1000 人 update 一个表中的一行, 导至严重延时如何解决呢?
  (请说说解决方向)

Answer 1

首先还是从应用入手吧。为什么会出现1000个session同时update同一行？

Answer 2

 情况是: 1000个用户用同一个名和密码, 同时登录, 修改时间. 例如:   表:  
       username |  password  | datetime
  ---------------------------------------------
                |            |
  ---------------------------------------------

Answer 3

1000个用户同时登陆？这种几率非常的小。除非你在用户登陆修改时间后没有立即commitoracle数据库commit是非常快的，只需要相关的日志写入就commit完成了。修改一条记录的日志是如此的少，如果立即commit，那么时间最多也就是豪秒级。如果你1000个用户能够在毫秒级上实现同时登陆，那不得不佩服你了:)

Answer 4

另外，按照你的表结构，每个用户是一行的，就算真的是1000个用户同时登陆，修改各自的登陆时间，那么也是每个人修改自己的那一行而已。oracle修改数据的时候是在行级加锁的，也就是我改我的，你改你的，没有问题

Answer 5

LZ是说1000个用户用同一个username和password，表里就这一行数据。只是不可能同一时刻有1000个用户来登陆吧？这么巧？

Answer 6

估计是比较大的系统，客户提出的一项压力测试要求。不过我猜想是不是LZ的系统在登录时除了修改时间还有其它很多操作，但这些操作都是用一个事务来控制的？我觉得即使是1000个用户同时并发更新一行记录，更新完立即commit的话，也不会造成不可忍受的的“严重延时”，这种操作，10秒完成都是比较夸张了。

Answer 7

另外，还有一个思路，就是写到缓冲的做法，登录时首选检测该行记录是否被锁定，如果锁定则将登录时间插入到另外一张表A中去，再采用某种策略（定时或定量）检测表A中是否有记录，如果有，则取出表中最大的便当时间与该行的时间进行比较，以确定是否需要更新这一行的时间，更新完结，A中的记录即可删除。这种方法都是下下策了。

Answer 8

  hevin 和 NinGoo 分析挺有道理, 不过现在做的这个测试确实有这样的延时出现,   能否再说说有别的具体解决方法和问题解决方向呢?

Answer 9

LZ说的应该是 1000人同时使用一个公共账号，来登录系统吧。如果记录日志是update操作，并且没有立即commit的话，可能造成这种情况。
建议： 记录日志方式更改为insert ，只是追加记录，或者取消。毕竟公共账号记录一条日志没有什么意义。更改之后应该不会出现这种问题了。