在Oracle数据库中，提供了一种被称为“事务”的控制机制。通过事物，能够完成对数据有效安全的修改操作，使数据库中的数据达到一个数据一致的状态。举个简单的例子，现在有一个借书系统中设涉及到两张表，一张是图书库存表，一张是用户借书情况表。在用户借书的时候，数据库需要进行两个操作，一是从图书库存表中扣掉库存;另一个操作时在用户借书表中加入这个借书操作。数据库在操作时，往往是先扣减库存，然后再在用户借书情况表中加入借书纪录。假设用户在借书的时候，第一步操作成功，即已经从图书库存表中扣除了某书的库存;但是，在第二步时由于发现用户借的书已经超量或者发现用户的卡中还有罚款不能够借书时，借书就会不成功。若没有事务做控制的话，很明显图书库存就会不准。而在事务的管理下，当第二步不成功的话，第一步操作就会发生回滚。也就是说，事务可以把数据库的好几个操作步骤当作一个整体，当其中有某个操作没有成功的话，则所有操作都会发生回滚。Oracle数据库就是通过这种机制来保障数据的一致性问题。
但是，事务若编写的不好的话，则不但起不到应有的作用，还会大大降低数据库的性能。如在数据库事务执行时间比较长，就很有可能导致锁冲突，从而降低数据库的并发访问性能。所以，数据库管理员在编写事务时，还是需要遵守几个指导方针。
指导方针一：在事务中尽量使得访问的纪录最小。
在事务中，若执行Update等记录操作语句，数据库为了保障数据的一致性，会对其所访问的记录加锁，防止在同一时间内其他用户对其修改。此时，若其他用户需要访问加锁的记录，则必须等待。此时就会发生锁冲突。
所以，在事务中要尽量使得访问的记录量最小。如此就可以减少锁定的行数，从而减少事务之间的冲突。这要求数据库管理员在事务中尽量精确的定位语纪录。如在数据库中读取记录时，最好能够使用Where语句进行定位。并且在编写Where语句的时候，要尽量的详细，最好能够实现一对一，则是最好的。
如在库存盘点的时候，事务处理语句需要从数据库中读取一定数量的记录，并且为这些记录进行加锁。此时，若记录读取的过多的话，就会对其他用户访问表中的记录造成麻烦。为此，数据库管理员应该建议应用前台应用程序在开发的过程中，加入一些限制条件。如按照产品的分类来更新库存。如此的话，就可以减少一个事务一次性读取的记录数量，从而把锁的影响降低到最低。
指导方针二：保持事务尽可能的简洁。
在事务中尽量使得访问的纪录最小，这是从数量的角度来考虑锁冲突。而保持事务尽可能的简洁，则是从时间的角度来考虑避免锁冲突的事情。保持事务尽可能的简洁，主要是要求数据库管理员在编写事务的时候，不要把事务写的太过于庞大与复杂。否则，事务在执行的时候就会占用比较多的时间。而这直接导致的后果就是数据库会把某些记录、甚至一张数据表锁住比较长的时间。这就会恶化锁对数据库的负面影响。
故当用户在知道了必须要进行修改的记录之后，就要马上启动事务;并且在最短时间内执行完相关的修改语句，然后立即递交或者回滚。而且，只有在确实需要时，才打开事务语句。具体的来说，数据库管理员在事务的简洁性方面，可以尝试如下方法。
一是在同一个事务中不要加入过多的修改或者删除语句。如当用户需要更新用户信息表中的相关数据。例如在员工的编号前加入YG前缀并且同时根据员工入职年份计算员工工龄。这两个更新语句若从技术上来说，放在同一个事务中并没有什么不妥。但是，当员工数量比较多时，若把他们合并在一起，则这个事务执行得时间会比较久。为此，最好在更新数据库表的时候，若预计执行时间会比较长，则最好能够把更新语句进行分割，如一列列更新等等。
二是在更新时，若一次性更新的语句比较多，最好能够选择合适的时候更新。更新某个数据库中记录，其执行所需要的时间往往跟数据库的记录成正比。其记录越多，更新所需要的时间越多。为此，笔者建议，当需要更新的记录比较多的时候，最好能够选择合理的时机。如有些应用程序在设计时，可以把这个更新放在后台处理。如此的话，应用程序就可以选择数据库比较空的时候，来更新表中的记录。这无疑可以在很大程度上降低事务对数据库的负面影响。