整理自《OCA/OCP认证考试指南
》
001
001
日志重做缓冲区是小型的、用于短期存储将写入到磁盘上的重做日志的变更向量的临时区域。“变更向量”是应用于某些对象的修改，执行DML语句会生成应用于数据的变更向量。有了重做日志，数据库就可以确保数据永不丢失：每当数据块发生更改时，都会将应用于块的变更向量写到重做日志，如果需要还原数据文件，则通过重做日志，可以将变更向量提取并应用于数据文件备份。
002
会话服务器进程不将重做记录直接写入重做日志文件，否则，每当执行DML语句时，会话将不得不等待磁盘I/O操作完成。相反，会话将重做记录写入到内存中的redo log buffer。这样做的速度将远比写入磁盘快。此后，日志缓冲区（可能包含交替的多个会话的变更向量）写出到联机重做日志文件。因此，redo log buffer对磁盘的一次写入是来自多个事务的一批变更向量。即使如此，redo log buffer中的变更向量也是接近实时地写入磁盘，当会话发出commit语句时，会实时执行redo log buffer写操作。写操作由日志写入器后台进程（LGWR）完成。
003
与其它内存结构相比，redo log buffer较小，因为它是一个
非常短暂的存储区域。将变更向量插入其中，并几乎实时地使其流向磁盘。redo log buffer最多不必超过数MB。的确，如果将其设置为大于默认值，就会对性能产生极坏的影响。默认值由Oracle服务器确定，而且取决于服务器节点中的CPU数量。
004 redo log buffer的大小设置
不可设置小于默认值的日志缓冲区。如果尝试这么做，则日志缓冲区一定会被设置为默认大小。可以创建一个大于默认值的缓冲区，但通常不提倡这样做。问题在于，当发出commit语句时，一部分提交处理涉及将redo log buffer内容写入磁盘上的联机重做日志文件。写操作实时执行，在其进行过程中，发出commit语句的会话将挂起。提交处理是Oracle体系结构的关键部分。要确保提交的事务永不丢失，那么，在缓存中的数据块发生更改（意味着事务已完成）而且将变更向量写入磁盘上的重做日志（如有必要，可以恢复事务）前，不能将完成提交的消息返回给会话。大日志缓冲区意味着：在发出commit语句时，需要写入的内容更多，在发出完成提交消息以及会话恢复工作之前，需要耗费更长的时间。
注意：就某些应用程序而言，有必要将日志缓冲区大小设置为高于默认值，但通常使用默认日志缓冲区开始调整。
005 redo log buffer相关瓶颈
日志缓冲区在启动实例时分配，如果不重新启动实例，就不能在随后调整其大小。它是一个循环缓冲区。在服务器进程向其中写入变更向量时，当前的写地址会来回移动。日志写入器进程以批处理方式写出向量，此时，其占用的空间将变得可用，并可由更多的变更向量覆盖。在活动高峰时刻，变更向量的生成速度可能高于日志写入器进程的写出速度。如果发生这种情况，在日志写入器清理缓冲区时，所有的DML活动都将停止数毫秒。
在Oracle体系结构中，将日志缓冲区转储到磁盘是基本瓶颈之一。DML的速度不能超过LGWR将变更向量转储到联机重做日志文件的速度。
提示：如果重做生成是限制数据库性能的因素，唯一的选项是使用RAC。在RAC数据库中，每个实例都有自己的日志缓冲区和自己的LGWR。这是将重做数据并行写入磁盘的唯一方法。
006 考点
日志缓冲区的大小固定不变，在启动实例时被设置为固定值。无法对其进行自动管理。
007 整理
redo log buffer的作用是啥？buffer是啥？buffer是缓冲区。缓冲区用来做什么的？缓冲区用来提速的。所以，redo log buffer的存在的目的肯定也是用来提速的。根据buffer的前缀redo log来推断，这个提速应该是用在redo log相关的东西上。那么具体怎么提速？
首先，既然有提速，那么肯定存在慢的地方。慢的地方在哪里？从字面意思来看，redo log buffer和联机重做日志有关，而联机重做日志是由log buffer写入到磁盘中的，也就是说，如果日志不经过redo log buffer，速度比经过redo log buffer慢。
具体的说，redo里面记录的是“变更向量”，也就是应用于某些对象的修改的整个记录。通过重做日志还原数据文件，就是将日志里的变更向量提取出来，应用于数据文件。每次执行DML语句，就会产生变更向量，也就是所谓的重做记录，如果不经过redo log buffer，那每次必须等到服务器进程把重做记录写到磁盘才能进行真正的块修改。
所以这就是redo log buffer的意义所在，将变更向量先暂时寄存在redo log buffer中，然后通过redo log buffer再写到磁盘中，而不是直接写到磁盘中。也就是说，将重做记录写到redo log buffer替代了将重做记录直接写入磁盘的日志文件。
至于为什么这样会提速。是因为CPU和硬盘两者处理数据的速率差距太大，硬盘根本跟不上CPU的处理速率。缓冲区的处理数据的速度比cpu慢，比磁盘快，在计算机里，数据在两个部件之间I/O速度由慢的那个部件来确定。比如由cpu向磁盘写重做记录，那必须按照磁盘能够接受的速度，而不是cpu的速度来传输。所以cpu把数据传输给内存，这个速度比直接把数据给磁盘快多了，但是内存到磁盘的速度，依然还是只能按照磁盘的来；但是因为重做记录数据量小，重做记录写入磁盘是实时或者几乎实时写入的。
将重做记录直接写入硬盘的结果就是始终按照硬盘的速度来处理数据，这样一来，重做记录不写好，用户那边就没法得到事务提交成功的反馈，而且重做记录生成的速率会比重做记录写到磁盘的速率快得多，然后导致一系列的后续恶果，整个数据库就没法高效运行了。
和redo log buffer相关的另一个问题是redo log buffer大小的设置。在这之前先简要 描述一个“快速提交”机制。当遇到需要大量修改块的事务时，当客户端发出commit命令时，几乎会瞬间响应，提示你事务已提交完成。这里事务已提交完成并不见得是所有修改的块——脏块真的全部都刷到磁盘，而是指关于这个事务的所有重做记录都已经刷到磁盘的online redo log里面了。
那么问题来了，如果redo log buffer的大小设置的比较大，会出现什么情况？
在发出commit语句的时候，在redo log buffer中相关的重做记录就要刷到磁盘的redo去，在刷立志，哦不，是日志这个过程中，发出commit语句的会话会被挂起。要确保提交的事务永不丢失，那么在缓存中的数据块发生更改而且将变更向量写入磁盘上的redo前，不能将提交完成的消息返回给会话。执行的时间客户端是感受不到也不需要知道的。客户只要知道他所做的更改生效就行。
所以问题就是：大的redo log buffer意味着：在发出commit语句时，需要写入的内容更多，在发出提交完成的消息以及会话恢复正常工作之前，需要比合适大小的log buffer耗费更长的时间。
补充一点，如果DML语句生成重做的速度比LGWR将变更向量写到磁盘的redo中的速度更快的话，DML活动就会停止一段时间，因为log buffer里面已经没有空闲空间了，必须等LGWR来清理一些可用空间来。
所以，将redo log buffer里的变更向量转储到磁盘的redo中是数据库性能的一个基本瓶颈。解决这个瓶颈的办法有上好存储，或者使用RAC，扩大redo log buffer不是好主意，会造成之前说的提交延迟的毛病。
redo log buffer在数据库中对应的参数是log_buffer,修改redo log buffer的大小单位只能默认为字节，k，m，g都是不行的，例如：
ALTER SYSTEM SET log_buffer = 65536 scope=spfile;
相关的等待事件：
logbuffer allocate：
等待分配log buffer的时间
redo copy：
写入redo file的时间
出现这些等待事件不代表有问题，但是allocate等待事件过多，就代表着log buffer确实不够用了，redo copy时间过长则代表lgwr的数目不足，
或者磁盘写入效率过低；
快速提交实现的原理也就是写入log而不是真正的修改数据块，
数据块被改变的时候是我们执行sql的时候，那个时间是真真正正的修改数据块的时间 ，
其实真正数据的修改速度是没有被提升的，
只不过commit的时间缩短了
。
