关系数据库中的事务日志

   为了保持数据库的一致性，需要有一种机制使数据库在发生错误之后能够回到一致性的状态。现在我们来假设有一个这样的事务，A帐户中有1000元，B帐户中有2000元，现在用户需要从A帐户中转帐50元到B帐户中。数据库正常的运行的事务如下：1，读数据块，A(1000元）到内存中，2，读数据块，B(2000)至内存中，3，将A减去50，写数据块，A(950元），4，将B加50元,写数据块，B(2050元)。整个事务
结束，这是正常情况下。如果在第3步的时候，由于数据库出错而事务终止(如系统崩溃，停电，用户rollback),数据库重新启动的时候A帐户为950元，B帐户为2000元，这显然不正常，我们把这种状态称之为不一致性状态。
   我们需要有一种机制来保护一个事务的原子性，这种机制称之为事务日志。这种思想大体是这样的：在对磁盘数据项进行修改以前，必须把对数据块进行修改的描述信息输出
到稳定存储器上。在ORACLE的解释中，事务日志是指包含对数据块的修改信息。事务日志的写操作全部完成后才开始写真正的数据块。
    现在有事务日志机制以后，我们再来看这种情况，如果在第3步中出现异常，由于事务的日志已经写到磁盘上了，重启以后通过对事务日志进redo,那么就可以对整个事务进行重新
执行，使数据库达到一个致性的状态。如果在进行写事务日志时，系统就出现了异常，这时候就更没关系了，由于事务日志还没有开始写完，所以并不对真正的数据块进行修改，在用户看来这个事务就不曾发生过，这时候数据库还是一致的。
    那对什么时候的事务开始进行REDO呢？这时候后需要引入另外一个种checkpoint技术。关于checkpoint技术以后再讨论。