数据库管理员应该要了解的是，重做日志文件的机制跟数据文件的管理机制类似。当因为数据更新、新建记录或者数据库结构变更产生重做记录时，其也不是马上写入重做日志文件中。而是先将重做记录写入到重做日志高速缓存中。等到符合一定的条件，再将重做记录写入到硬盘上的冲作日志文件中。这主要是为了性能的考虑。因为往内存中写入数据要比往硬盘中写入数据快几千倍。

　　重做日志文件对于Oracle数据库的重要性显而易见，如上图所示，

　　当利用Update等数据操作语更新数据或者调整数据库物理机构时，数据库会先将相关的更改信息保存在数据高速缓存中。同时也会产生重做记录，这些重做记录也是保存在重做日志高速缓存中。这在某种程度上可以提高数据库的性能。但是，如果这个重做日志缓存设置的不恰当的话，也会出问题。如当一个Update语句需要更新大量的数据时，则写一部份记录到重做日志高速缓存中，其空间就会满了，需要将重做记录写入到重做日志文件中。此时更新作业不得不暂时等待，因为此时无法将重做记录写入到重做日志高速缓存中。只有将现有重做日志高速缓存中的信息都写入到重做日志文件中后，系统才会清空重做日志缓存中的信息，系统才能够将更新的信息保存到重做日志高速缓存中。所以当这个等待的次数多了，那就会极大的影响数据库的性能。 不要让临时表空间影响数据库性能

　　所以说，重做日志高速缓存是把双刃剑。若重做日志高速缓存大小合适的话，确实可以提高Update等语句的操作效率。但是如果设置的不合适的话，则会起到适得其反的效果。反而会因为等待次数过多而影响到这些语句的执行效果。故在一些数据更新量比较大的系统中，特别需要进行成批更改的数据库中，调整重做日志高速缓存的大小也是改善数据库性能的一个重要举措。

　　一、避免一个误区：重做日志高速缓存越大越好。

　　在配置重做日志高速缓存大小的时候，首先需要避免一个误区，即并不是说重做日志高速缓存越大越好。如果将重做日志高速缓存设置的很大，也会产生不利的影响。

　　如重做日志高速缓存是内存中的一块区域，它是数据库启动的时候就已经分配好了的，是一块独享的内存区域。也就是说，如果给其分配了一定大小的区域之后，无论现在重做记录需要多少的高速缓存，其都会独占的享用这块区域。即使只用来1％，这多余的内容也不会给其他程序使用。而且，根据LGWR进程的规则，默认情况下一般当达到重做日志高速缓存大小的50％时，将会将重做日志高速缓存中的重作记录写入到重做日志文件中。所以如果将重做日志高速缓存设置的比较大的话，对于内存来说也是一种浪费。 提高Oracle数据库缓存命中率

　　其次会降低重做日志文件的作用。虽然在有些书上说重做记录会随时写入到重做日志文件中。其实这是不科学的。一产生重做记录后不会马上写入到重做日志文件中，而是写保存在重做日志高速缓存中。然后根据重做记录的数量来决定写入到重做日志文件中的时刻。也就是说，在将数据高速缓存中的数据写入到数据文件中这个时间间隔内，重做记录会分几次写入到重做日志文件中。所以，重做日志文件中的信息也会有一个时间的延迟，不一定根数据库真实的内容保持同步。所以到数据库发生故障时，即使有重做日志文件的存在，也不一定能够恢复到故障的点（当然离故障的点很近，可能只差几秒）。当重做日志高速缓存空间越大的话，那么将重做记录写入到重做日志文件中的时间间隔会越长。此时数据库如果发生故障，则其丢失的数据相对来说会更多。所以说，虽然增加重做日志高速缓存的大小可以避免因为等待而导致的性能下降问题，但是也会对数据的安全性对来一定的损害。故最后数据库管理员在设置这个重做日志高速数据缓存空间的时候，对于这个大小，还是要有一个分寸。切记，这个空间并不是越大越好。

　　二、什么时候该修改重做日志高速缓存空间的大小？

　　是否需要修改这个重做日志高速缓存空间的大小，主要需要看数据库的运行状况。在上面的分析中，笔者提到过一个等待的概念。即在数据更新或则数据结构调整的过程中，用户进程等待重做日志缓存的现象。一般情况下，如果这个等待的次数越多，显然说明用户在这等待的时间上占用了比较多的时间。为此需要根据这个等待到次数来确定是否需要重新调整重做日志高速缓存空间。在数据库中可以通过数据字典视图V$SYSSTAT来查询用户用户进程等待重做日志缓存的次数。在这个视图中，有一个叫做“重做缓存重分配”的纪录，英文名字为“redo buffer allocation retries”。这条记录的vlaue字段的值就表示用户进程等待重做日志缓存的次数。如果这个值为0的话，就表示用户进程在数据更新或者数据结构调整的时候，不需要等到重做日志高速缓存。所以性能是最佳的。但是这只是一种比较理想的状态。在数据库运行了一段时间后，这条记录的值往往不会为0，有时候会达到两位数、三位数等等。那么是否这个值越大，就越说明有需要调整重做日志高速缓存大小的必要呢？

　　这么说有一定道理，但是也太过于决定。在实际工作中，我们往往还需要借鉴另外一个值。在这张视图中，还有一条记录叫做“redo entries”。如果按名次排序的话，他们这两条记录是一前一后紧靠在一起的。通常情况下，如果把“redo buffer allocation retries”记录的Value值除以“redo entries”记录的Value值，如果大于0.01（即1％），则说明这个数据缓存大小可能并不是很合适，需要通过调整重做日志缓存大小来提高数据库的性能。如果这个比率小于1％的话，即使用户进程等待的次数再多，一般也不需要调整其大小。因为此时用户的等待次数对于数据库的性能影响是微乎其微的，甚至可以忽略不计。从这里可以看出，并不是说用户进程的等待次数越多，就说明其大小越需要调整。一般我们都需要将用户进程等待次数与“redo entries”记录的Value值进行比较，最后以1％这个值为关卡，来判断是否需要调整重做日志高速缓存的大小。

　　三、如何调整重做日志高速缓存的大小？

　　在Oracle数据库中，重做日志高速缓存的大小是由初始化参数log_buffer来控制的。在对其进行更改之前，有必要先查询一下这个参数的值。在数据库命令行中，可以通过show log_butter来查询重做日志缓存的大小。然后数据库管理员可以在这个值的基础上增加重做日志高速缓存的大小。这个参数是一个动态的参数，可以在数据库运行期间修改这个参数。如果某个事务需要长时间运行、并且会产生大量重做记录的时候，通过参数增加这个参数的值，往往可以减少对重做日志文件的硬盘操作次数，从而提高数据库的性能。

　　由于这是一个动态的参数，为此在更改的时候需要注意一点，即在下次数据库启动的时候是否需要将这个修改保留。如果需要的话，则在这个参数内存中的值的时候，同时需要更改初始化参数文件中的值。如果采用文本参数文件启动的话，需要手工更改参数文件。如果采用服务器参数文件启动的话，则可以在命令中指定其同时修改内存与服务器参数文件中的值。

　　最后笔者再次提醒一句，重做日志高速缓存并不是越大越好。通常情况下，需要将上面提高的两个记录进行对比，以1％作为其调整的关口。如果超过1％，则就可以通过调整重做日志高速缓存来达到改善数据库性能的目的。反之，如果值小于1％，那么即使增加了重做日志高速缓存的大小，也很难起到应有的效果。相反会造成一定的安全隐患，而且会浪费内存空间。所以，这个调整重做日志高速缓存时还需要谨慎行事。