昨天下午测试人员说运行审核功能时，整个项目就会很慢长达2分钟，当时有两个人测试，本地和服务器共用一个数据库。
因为这个模块不是我做的，我只是旁听了整个问题，开发A ：项目运行时没问题的，只是在不停的锁表，（这个是可以通过sql查到的）。经理：为什么会不停的锁表，查一下。
我还在开发自己的模块，不过也查了一句话，如果事物得不到提交会造成锁表。
下午开发A和经理一起找到了问题所在，我没参与，因为我还有我的工作。问题在开发A 写了一个死循环不停的操作数据库，但事物却得不到提交，按照Oracle的原子性，当操作数据库
表事物未提交时，其他用户是无法读到他在正在操作的数据，这就是为什么开发A 测到这里觉得慢，测试A也测到这里，开发A 关掉了自己的进程，测试A 就可以打开一面读到数据，当
然测试A 操作审核数据时，也一样会这样，因为不管是谁操作了这个死循环，其他人员到要等，等操作这个死循环的人结束他的事物，其他人才能再次访问，这个时间就是测试A夸张的
说有时打开的页面需要两分钟，而有时会快，但操作审核会一样的不行。
问题找到了，不在去怪服务器不行。一个问题如果没有描述清楚，就会引起不必要的浪费时间，让经理去搞了两天的服务器，什么大环境配置。
及时不能准确的说出问题所在，最起码要把发生问题的过程表述正确。
回顾下Oracle事物ACID的基本概念（原子性、一致性、隔离性、持久性）：
1.原子性(Atomicity):事务要么成功(可见)，要么失败(不可见)。不存在事务部分成功的情况。
当我们修改一条数据，我们同时生成一条undo记录描述如何撤销这个修改。这就意味着当我们处在事务处理中时，如果另外一个用户试图查看正在被我们修改的数据，会被告知需要使用undo记录，构造数据被修改之前的状态。这就使得修改只有在提交之后才可见。保证了其他用户要么看到事务的全部或者啥也看不到。
2.一致性(Consistency)：数据库在事务开始前和结束后都应该是一致的。
一致性要求数据库在任何时候都是处于一个一致、合法的状态。我们可能会说undo数据的存在意味着其他用户会被阻止看到事务中间过程的数据，因此，看不到数据库从一个合法的状态到另外一个暂时的不合法状态，他们看到的要么是事务之前的状态要么是事务之后的状态。(数据库内部当然能看到中间过程的状态数据，而且有些时候很有用，但是终端用户看不到不一致的数据)。假入银行有A、B两个用户，账户余额都是100元。现在A用户向B用户转账50元。过程如下：
事务开始
1.A用户账户减去50元
2.B用户账户加上50元
3.记录一条转账日志
事务结束
在事务的第1步之后的这个中间状态，A用户账户余额为50元，B用户账户余额还没有增加，还是100元，这就是一个事务中间的非一致状态。但是我们知道，事务要么成功，要么失败，不存在部分成功，所以，用户看到的数据，永远是一致的。
3.隔离性(Isolation):一个事务不会看到另外一个还未完成的事务产生的结果。每个事务就像在单独、隔离的环境下运行一样。
我们已经知道undo数据使得用户看不到事务的中间数据直到我们提交了修改。实际上，我们走的更远：undo数据使得其他事务在整个事务过程中，不必受到我们事务的影响(这个不是Oracle默认的隔离级别，但是支持)。当然，当2个用户同时去修改同样的数据时，还是会发生问题。完美的隔离是不可能的，因为事实上一个事务必须在有限的时间内完成。
4.持久性(Durability)：成功提交的事务，数据是持久保留，不会因为系统失败而丢失。
持久性是redo日志提供的一大好处。你怎么保证提交的事务数据在系统失败的情况下也不会丢失？很明显的策略就是不停地把redo日志写到磁盘。如果你没有redo日志，当你修改数据的时候，这就可能意味着你要做很多数据块的随机写。想象一下你往表order_lines中插入10条数据，表上面有3个索引。这个可能需要31个随机的分散的磁盘写操作，让1个表数据块和31个索引块数据持久保存下来。但是Oracle有redo机制。你只要保留少量的关于修改的日志，而不是整个你修改的数据块。31条修改日志最后可能只是1个顺序写操作。