1_log_buffer上的优化思路

LGWR 进程将log buffer 中的日志条目写往在线日志的条件有如下3个：
1.事务提交时
2.log buffer 中日志条目超过1M时
3.每隔3秒是

虽然触发lgwr 进程写日志的条件很多，但在日志生成量很大的系统中（比如每秒生成10M以上），建议设置比较大的 logbuffer （如 50m）,从而防止log buffer 空间不足。

oracle 写日志特性：
1.由于lgwr 进程每一次写日志条目，均需要获得众多的latch,如redo writing latch,redo allocation latch,redo copy latch.所以 LGWR 写进程写的越频繁，相关latch 的争用概率就越大，DML操作的性能则越慢。
2.提交越频繁，日志空间的浪费可能越大。基于以上两点，建议不要过于频繁的提交。
3.日志块越大，日志空间的浪费可能越大。当然日志块大小由操作系统决定时，我们不能人为修改其大小。
4.lgwr进程不再同一个日志块写2次的策略使得lgwr写的日志代码相对比较简单，提高了效率。另外，lgwr 写日志块时无需去读上一块日志块的信息，节省I/O

LOG FILE SYNC 等待事件：
如果服务进程执行事务提交时，在等待lgwr 进程成功的将log buffer 中的日志写到日志文件之前，服务器进程等待log file sync 事件。由于LGWR进程不可避免的需要执行写日志文件操作。所以 log file sync 等待事件是oracle 中最普通的等待事件之一。由于lgwr 进程执行写操作的时间非常短，所以一般来讲 LOG FILE SYNC 等待事件不会成为数据库性能的瓶颈。引起 LOG FILE SYNC 等待时间主要有以下几个原因：

1.LGWR 进程写的不够快。
当在线日志所在存储性能缓慢时，LGWR 进程写日志的时间加长，因此可能会增加log file sync 的等待时间。

2.提交或者回滚的次数过于频繁
过于频繁的提交是出现log file sync 等待的关键因素。一般情况下，每提交一次就会发生一次 log file sync等待。

3.重做日志缓冲区过大
重做日志缓冲区过大，log file sync 等待会有增加的趋势。因为重做日志缓冲区过大时，lgwr 进程会减少写日志的次数，但每次写日志的数据会增加，所以log file sync 的等待时间会延长。不过重做日志缓冲区的大小设置并没有标准，而且在不同的oracle版本中，重做日志缓冲区的默认大小也一直在变化。因此，一般情况下，在较多事务的系统中，建议设置较大的重做日志缓冲区，这有利于提高性能。过小的重做日志缓冲区可能会引起log buffer space 等待事件。

4.控制文件争用
LGWR 进程写日志的同时会在控制文件中记录写进度。当控制文件争用而出现enq:CF -contention 等待事件时，前台进程可能会出现log file sync 等待。

5.系统CPU 资源紧张
当系统CPU 资源紧张时，LGWR 进程可能会因为无法获得CPU时间片而导致LOG FILE SYNC 等待事件。

减少日志量的方法：

lgwr 进程性能的下降直接关系到整个系统的性能，所以减少重做日志可以从某种程度上减轻系统的压力，以下为常见的减少日志量的方法：

1.使用nologging 选项，nologging 有3个级别，分别是 SQL级别，表级别，表空间级别
2.通过SQL*LOADER 装载大量数据时，使用 DIRECT LOAD 选项
3.需要保存临时数据时，尽量使用临时表。使用临时表本身不会创建对于数据的重做日志
4.若LOB数据量较大，使用nologging 属性。

对已经有索引的表执行direct load 时，在不影响select 语句性能的前提下，可以按照以下步骤进行安装：
1.将索引修改为unusable 状态
2.装载数据
3.以nologging 方法重建索引

注意：在数据库级别开启了force logging 之后， 所有的nologging 操作依然会logging 。千万不能再生产系统中设置隐含参数 _disable_logging 设置成true 之后可能导致数据库无法启动。

欢迎关注我的公众号
这是一个专注写Oracle，mysql,python,shell,cloud 的小公号。欢迎交流沟通