Oracle优化之I/O解析（五）

5 控制文件相关的IO事件
这一类等待事件发生在对控制的IO事件时。对控制文件的IO访问一般都是由Redo Log文件切换、checkpoint等（如更新SCN）引起的。


5.1、control file parallel write
这一等待事件通常发生在一个服务进程在更新所有控制文件时，通常是以下情况：
1）会话启动了一个控制文件事务（在提交事务之前更新所有控制文件为最新）；
2）会话提交了一个事务到控制文件
3）一个控制文件的条目被修改了，该修改要更新到所有控制文件上去




考虑用以下手段来进行优化：


1）在保证控制文件的备份数量足够安全（不会出现控制文件全部丢失）的情况下使控制文件数量最少；
2）如果操作系统支持AIO，设置数据库支持AIO；
3）将控制文件转移到IO负载比较低的磁盘上去。


5.2、control file sequential read
通常发生在对一个单独的控制文件的IO读操作时，通常可能是以下情况：
1）备份一个控制文件
2）RAC中在实例之前共享一个控制文件信息时；
3）读取控制文件的头数据块或者其他数据块时。


用以下语句可以找到是访问哪个控制导致的该等待事件：
select p1 as filename from v$session_wait
where event='control file sequetial read' and state='WAITING';


我们可以采取以下手段来降低这一等待：
1）如果操作系统支持AIO，设置数据库支持AIO
2）将控制文件转移到IO负载比较低的磁盘上去。




5.3 control file single write
select p1 as filename from v$session_wait
where enent='control file single write' and state='WAITING';
优化手段同上；




5.4、RedoLog相关的IO事件


5.4、、log file parallel write
这一等待事件发生在LGWR进程等待完成将Redo记录写入Redo Log文件时，在LGWR进程将Log Buffer中的数据写入Log File时会发生该事件。
当使用了异步IO时，这种写操作是并行的，否则只会一个接着一个Redo文件的写入。LGWR进程必须等待所有的Redo log文件都被写入。因而redo log文件所有在磁盘的IO效率就直接影响了该等待事件的总的等待时间。


降低log file parallel write等待的方法有：
1）不要使表空间长期处于热备状态。当表空间处于热备状态时，表空间不再被更新，redo log会急剧增加。
2）将Redo log文件放在高速存储设备上，千万别放在RAID5上，可以考虑放在裸设备上；
3）redo log文件 的磁盘应尽量避免有其他IO操作的存在；
4）对某些操作，如大批量数据导入，可以设置nologging、unrecoverable选项，或者在sql语句中使用提示/*+APPEND*/,以减少redo log的产生
5）在确保redo log数据足够安全（不会发生Log文件丢失）的情况下，尽量减少redo log 组的成员数；
6）在配置需要使用redo log功能时，如Streams复制、logminer、逻辑模式的DG，尽量设置为最低级别的补充日志（supplemental logging）
7）适当增加log_buffer的大小






我们可以按照以下方法来调整log_buffer的大小，比较redo log buffer分配的重试（在请求log buffer时，无足够buffer，需要重新提交请求）率，如果该比例大于0.1%， 就需要考虑增加log_buffer的大小


select retries.value/entries.value "redo log buffer retry ratio"
from v$sysstat retries,v$sysstat entries
where retries.name='redo buffer allocation retries'
and entries.name='redo entries';
另外，如果系统统计数据中redo log space requests大于0，说明有进程在等待分配redo log文件空间，而不是等待buffer空间。这时我们也需要考虑增加log_buffer的大小。




select name,value from v$sysstat where name='redo log space requests';
但是，log_buffer的大小不要超过128*CPU或者512K（取两个数字中最大的一个）数。


5.2、log file sync
当oracle前台进程提交或者回滚事务需要等待提交或回滚完成时会产生该等待事件。部分等待的原因可能是等待LGWR进程将会话事务的redo记录从log buffer中拷贝到磁盘上去。这时，就会出现前台进程等待log file sync，而后台lgwr进程带等待log file parallel write的情况。


实际上，一个log file sync等待事件包涵了多个步骤：
1、如果lgwr空闲则唤醒lgwr进程
2、lgwr收集需要写的redo记录并提交IO请求
3、等待写log的IO完成
4、LGWR IO提交处理
5、LGWR提交已经完成了写日志的前台/用户进程
6、前台/用户进程被唤醒


我们采取以下调优手段来降低log file sync等待：
1）减少redo log的产生、提供redo log的IO效率、减少redo log与其他IO的冲突
2）将一些小事务合并成批量事务，以减少提交和回滚次数


5.3、log file single write &&  log file sequential read


log file single writ只会发生在打开或关闭一个redo log文件后，向文件头写入相关信息时，因为文件头的信息中包含了文件号，因此文件头信息不会并行写入多个文件，而是单独一个个写入，因而其等待时间不会被统计到log file parallel write之中。


5.4、log file switch completion && switch logfile command && log file switch （clearding log file）


alter system switch logfile;
日志切换由以下步骤组成：
1）从控制文件获取下一日志文件的文件号；
2）获取redo copy和redo allocation的latch
3）清空redo，将buffer中的redo记录写入log文件中去
4）关闭当前redo log文件
5）更新控制文件，包括：
a）设置下一日志文件为当前日志文件
b）设置之前的日志文件为INACTIVE
c）如果在Archive模式下，将之前文件加到归档文件列中
d）打开新的日志文件 组中的所有文件
e）将scn写入文件头
f）打开允许产生redo log的开关




一般来说，在系统运行高峰期以20~30分钟切换一次为佳），通过以下语句可以查询日志的切换记录及其切换间隔时间：
select to_char(b.first_time,'YYYY-MM-DD HH24:MI:SS') as swtich_time,
(b.first_time - a.first_time) *24 as "switch_interval(hr)"
from v$log_history a,v$log_history b
where a.sequence# +1  = b.sequence#
and rownum <=10
order by 1;




5.5、log file switch(checkpoint incomplete)
当在做日志切换时，同时会做Checkpoint，如果此时有其他Checkpoint正在进行时，需要等待正在进行的Checkpoint完成，此时就会产生log file switch（Checkpoint incomplete）等待事件。


通过以下方法来进行调优：
1）增加redo log文件的大小，使日志切换频率降低
2）增大参数log_checkpoint_interval大小，该参数设置系统两次Checkpoint之间redo log数据块（该数据块的大小由操作系统的数据块大小决定）的数量。
但是oracle会限制这些数据块总的大小要小于最小log文件的90%，如最小log文件为100M，操作系统的数据块大小为512K，则log_checkpoint_interval要小于（100*90%/0.5)=180


5.6、log switch/archive && log file switch(archiving needed)
log switch/archive等待事件在会话等待所有archive 线程对当前log文件archive操作完成。当LGWR进行切换日志时，如果要切入的日志还没有被archive,需要等待其被完成archive,这时会产生log file switch(archive needed)等待事件，这时在ALERT log中我们还能发现以下信息：


thred 1 connot allocate new log,sequence 9556
all online logs needed archiving


这两个事件只有数据库在Archive模式下才会出现。说明Archive操作太慢。
对这两个事件的调优主要是针对Archive设置的调优。
要跳高Archie的效率，可以采取以下方法：
1）调整redo log文件的个数和大小
2）调整Checkpoint的间隔和效率
3）配置多arch进程
通过参数log_archive_max_processes可以配置最大arch进程数量。我们可以做一个脚本来执行“alert system archive log all;'命令，然后设置一个作业以固定间隔时间来执行该脚本。
这个命令可以强制归档所有未归档的日志文件，这可以帮助均衡arch进程的归档 处理负担。




4）增加Archive进程
增加Archive进程的buffer大小可以提高Archive效率，其大小是由参数log_archive_buffer_size控制的。该参数的初始设置为4k，最大可以增加到128k，但是，要注意，增加该参数虽然可以提供Archive效率，但是可能会使系统的整体性能下降；


另外，我们还可以通过增加Archive进程的buffer数量唉提高Archive效率。buffer数量由参数log_archive_buffer控制，最大为8


5）减少系统的IO冲突、提供系统IO效率

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29677883/viewspace-1170214/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29677883/viewspace-1170214/