SQL> select group#,member from v$logfile;
GROUP# MEMBER
--- ----------------------------------------------------------------
3 /u01/oradata/WILSON/onlinelog/o1_mf_3_6bcsqtfj_.log
3 /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_3_6bcsqtwv_.log
2 /u01/oradata/WILSON/onlinelog/o1_mf_2_6bcsqs3t_.log
2 /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_2_6bcsqstm_.log
1 /u01/oradata/WILSON/onlinelog/o1_mf_1_6bcsqpty_.log
1 /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_1_6bcsqqt0_.log
6 rows selected
SQL> alter database add logfile ('/u01/oradata/WILSON/onlinelog/redo4a.log', '/u01/flash_recovery_area/WILSON/onlinelog/redo4b.log') size 10m;
Database altered
SQL> select group#, sequence#, bytes, members, status from v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
---------- ---------- ---------- ---------- ----------------
1 217 52428800 2 INACTIVE
2 218 52428800 2 CURRENT
3 216 52428800 2 INACTIVE
4 0 10485760 2 UNUSED
SQL> select group#,member from v$logfile;
GROUP# MEMBER
- ----------------------------------------------------------------
3 /u01/oradata/WILSON/onlinelog/o1_mf_3_6bcsqtfj_.log
3 /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_3_6bcsqtwv_.log
2 /u01/oradata/WILSON/onlinelog/o1_mf_2_6bcsqs3t_.log
2 /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_2_6bcsqstm_.log
1 /u01/oradata/WILSON/onlinelog/o1_mf_1_6bcsqpty_.log
1 /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_1_6bcsqqt0_.log
4 /u01/oradata/WILSON/onlinelog/redo4a.log
4 /u01/flash_recovery_area/WILSON/onlinelog/redo4b.log
8 rows selected
3、关于redo log sizing
最后聊聊redo log的大小问题。在负载较高和投产的系统中，我们经常会遇到log过小引起的一系列问题。通过AWR报告和alert log，我们都可以发现这种现象的端倪。
如果系统在关键作业时生成的redo size峰值量很高，并且持续很长时间。我们在Alert log上可以看到频繁的online log切换，同时连带出现“check point not complete”或者“could not allocate log sequence”提示。说明日志切换过于频繁。
从AWR报告上，我们主要关注两个与redo log相关的事件：log file parallel write和log file sync。如果两个事件出现在top events中，作为dba和调试人员就需要注意了。
在Oracle的官方资料中，对redo log的大小设置也是以切换频率而定的，要求调整到15-20分钟进行一次切换。调整的手段主要是增加日志组数量和调大日志成员文件大小。这样，都可以给dbwr和arc进程更多的时间在后台进行数据写入和归档。
在实际中，笔者还要建议关注日志组成员的数目，我们对日志采用多路径冗余手段，是为了防止出现单磁盘文件以外损坏。但是，过多的日志成员数目也会带来性能瓶颈。笔者曾见过一个日志组成员数量是10个文件，散布在10个设备上。这样，就意味lgwr要写入十次才能将一个log entry写入，性能可想而知。
在oracle 10g中，官方提供了视图v$instance_recovery，也可以提供一定程度的log大小建议。