21-log buffer及日志管理深入分析及性能调整.pptVIP

而较小尺寸的联机日志文件会引起log file switch completion和log file switch (checkpoint incomplete) 这两个等待事件。log file switch completion表示进程正在等待日志切换完成。而当应用程序产生很多重做，然后由LGWR进程非常快得写日志文件并进行日志切换时，这时DBWR进程还没有把脏数据块写入磁盘以通知checkpoint结束时，这个时候产生log file switch (checkpoint incomplete)等待事件。可以通过增加联机日志文件的尺寸来减少log file switch completion和log file switch (checkpoint incomplete)。 使用如下SQL来显示有关日志缓冲区的latch free的misrate是否很大。 select name,gets,misses,to_char((misses/(gets+misses)) * 100,990.99) misrate from v$latch where name in ( redo allocation , redo copy, redo writing) / 如果是redo copy的丢失率很严重，则可以考虑增加隐藏参数：_log_simultaneous_copies的值。 该参数定义了redo copy latch的数量，该参数缺省为CPU数量的两倍。从8i起，该参数成为隐藏参数，因为不适合为系统增加过多的redo copy latch，特别是在OLTP环境中。增加该参数可以减少前台对redo copy latch的等待，但是要注意，过多的redo copy latch可能会使得LGWR等待更长的时间。 因为前面我们已经知道，LGWR在确定了要写哪些日志块以后，会等待前台进程完成对这些日志块的操作以后，才开始正式写入。 所以，如果很多的前台进程都可以获得redo copy latch以后，就可能引起LGWR要等很长时间才能开始正式写入。 如果是redo allocation的丢失率很严重，需要考虑是否有可能减少重做记录的生成。具体可以看下面有关如何减少重做记录的部分。 8i以前，存在一个参数：log_small_entry_max_size，该参数说明了当重做记录的尺寸小于该参数指定值时，使用redo allocation latch来保护重做记录拷贝到日志缓冲区的过程，否则，如果重做记录大于该参数值时，使用redo copy latch来保护这个过程。 但是从8i以后，取消了该参数，只要拷贝重做记录到日志缓冲区，就获得redo copy latch。如果是redo writing的丢失率很严重，则说明LGWR写的时间过长，导致其他进程无法获得该latch。这时可以通过减小_log_io_size来增加LGWR写的频率。具体_log_io_size的用法可以参考下面log buffer的设置部分。 log buffer的设置 对于日志缓冲区来说，设置过小，容易引起log buffer space等待事件。但也不是说设置的越大就越好的，设置过大，由于LGWR进程会不断启动刷新日志缓冲区从而释放内存，所以可能会根本用不上多余的内存，从而浪费内存。设置合适的日志缓冲区大小，目的是为了能够让LGWR进程合理的触发。理想情况下是，一方面，在LGWR进程向联机日志文件中写重做记录时，日志缓冲区中还是有剩余的可用空间以供其他进程所使用；另一方面，当LGWR进程完成时，日志缓冲区中的剩余可用空间不要很多，因为这时LGWR所写入日志文件的日志块就可以释放出来了，成为新的剩余可用空间。然后，LGWR可以再次启动刷新脏的日志块。如此良性循环，就能在满足性能的前提下，充分利用日志缓冲区。没必要盲目的把日志缓冲区设置的很大，完全可以把节省下来的内存交给比如数据块缓冲区（buffer cache）等这样更需要内存的组件。 我们已经知道，当重做记录达到日志缓冲区的1/3或1M时，就会触发LGWR进程。也就是说，oracle缺省认为LGWR进程在写日志缓冲区大小的1/3或1M的重做记录的过程中，剩下的日志缓冲区可以供新的重做记录的需要。 当LGWR写完以后，那么这1/3或1M的日志缓冲区就又可以成为可用的日志块以容纳新的重做记录了。由此，我们可以很容易推导出，当我们设置日志缓冲区达到3M（3×1M）以上时，这时多余出来的日志缓冲区实际上并不能用得上，换句话说，多余出来的内存就被我们浪费了。不过，本质上，这个启动LGWR的限度值是由一个隐藏参数：_log_io_size决定的，如下所示。该参数表示日志缓冲区中存在多少个脏日志