理解REDOLOGLOGBUFFER和LGWR.docVIP

理解REDO LOG 3 LOG BUFFER 和LGWR REDO LOG的产生十分频繁，几乎每秒钟都有几百K到几M的RED LOG产生，甚至某些大型数据库每秒钟产生的REDO LOG量达到了10M以上。不过前台进程每次产生的REDO量却不大，一般在几百字节到几K，而一般来所一个事务产生的REDO 量也不过几K到几十K。基于REDO产生的这个特点，如果每次REDO产生后就必须写入REDO LOG文件，那么就会存在两个问题，一个是REDO LOG文件写入的频率过高，会导致REDO LOG文件的IO存在问题，第二个是如果由前台进程来完成REDO LOG的写入，那么会导致大量并发的前台进程产生REDO LOG文件的争用。为了解决这两个问题，Oracle在REDO LOG机制中引入了LGWR后台进程和LOG BUFFER。 LOG BUFFER是Oracle用来缓存前台进程产生的REDO LOG信息的，有了LOG BUFFER，前台进程就可以将产生的REDO LOG信息写入LOG BUFFER,而不需要直接写入REDO LOG文件，这样就大大提高了REDO LOG产生和保存的时间，从而提高数据库在高并发情况下的性能。 既然前台进程不将REDO LOG信息写入REDO LOG文件了，那么就必须要有一个后台进程来完成这个工作。这个后台进程就是LGWR，LGWR进程的主要工作就是将LOG BUFFER中的数据批量写入到REDO LOG文件中。对于Oracle数据库中，只要对数据库的改变写入到REDO LOG文件中了，那么就可以确保相关的事务不会丢失了。 引入LOG BUFFER后，提高了整个数据库RDMBS写日志的性能，但是如何确保一个已经提交的事务确确实实的被保存在数据库中，不会因为之后数据库发生故障而丢失呢？实际上在前面两节中我们介绍的REDO LOG的一些基本的算法确保了这一点。首先WRITE AHEAD LOG协议确保了只要保存到REDO LOG文件中的数据库变化一定能够被重演，不会丢失，也不会产生二义性。其次是在事务提交的时候，会产生一个COMMIT的CV，这个CV被写入LOG BUFFER后，前台进程会发出一个信号，要求LGWR将和这个事务相关的REDO LOG信息写入到REDO LOG文件中，只有这个事务相关的REDO LOG信息已经确确实实被写入REDO LOG文件的时候，前台进程才会向客户端发出事务提交成功的消息，这样一个事务才算是被提交完成了。在这个协议下，只要客户端收到了提交完成的消息，那么可以确保，该事务已经存盘，不???丢失了。LGWR会绕过操作系统的缓冲，直接写入数据文件中，以确保REDO LOG的信息不会因为操作系统出现故障（比如宕机）而丢失要求确保写入REDO LOG文件的数据。 实际上，虽然Oracle数据库使用了绕过缓冲直接写REDO LOG文件的方法，以避免操作系统故障导致的数据丢失，不过我们还是无法确保这些数据已经确确实实被写到了物理磁盘上。因为我们RDBMS使用的绝大多数存储系统都是带有写缓冲的，写缓冲可以有效的提高存储系统写性能，不过也带来了另外的一个问题，就是说一旦存储出现故障，可能会导致REDO LOG的信息丢失，甚至导致REDO LOG出现严重损坏。存储故障的概率较小，不过这种小概率事件一旦发生还是会导致一些数据库事务的丢失，因此虽然Oracle的内部算法可以确保一旦事务提交成功，事务就确认被保存完毕了，不过还是可能出现提交成功的事务丢失的现象。 实际上，Oracle在设计REDO LOG文件的时候，已经最大限度的考虑了REDO LOG文件的安全性，REDO LOG文件的BLOCK SIZE和数据库的BLOCK SIZE是完全不同的，REDO LOG文件的BLOCK SIZE是和操作系统的IO BLOCK SZIE完全相同的，这种设计确保了一个REDO LOG BLOCK是在一次物理IO中同时写入的，因此REDO LOG BLOCK不会出现块断裂的现象。 了解LOG BUFFER和LGWR的算法，有助于我们分析和解决相关的性能问题，因此我们需要花一点时间来了解LOG BUFFER相关的基本算法。用一句话来概括，LOG BUFFER是一个循环使用的顺序型BUFFER。这句话里包含了两个含义，一个是LOG BUFFER是一个顺序读写的BUFFER，LOG BUFFER数据的写入是顺序的；第二个含义是LOG BUFFER是一个循环BUFFER，当LOG BUFFER写满后，会回到头上来继续写入REDO LOG信息。LOG BUFFER数据的写入是由前台进程完成的，这个写入操作是并发的，每个前台进程在生成了REDO LOG信息后，需要首先在LOG BUFFER中分配空间，然后将REDO LOG信息