第三步：删除原来旧的redo logfile
| SVRMGRL>alter database drop logfile group 1; SVRMGRL>alter database drop logfile group 2; SVRMGRL>alter database drop logfile group 3; |
2、检查点发生时DBWR进程没有完成数据写入引发等待：
当日志文件完成一个循环周期后再一次来到原来某个日志文件准备进行重新使用时，发现该日文件对应的数据还没有写入相应的数据文件中，此时LGWR必须等待DBWR完成写入，从而引发等待。
如果怀疑存在这个问题可以通过如下查询来进行监控：
| select event,total_waits,time_waited,average_wait from v$system_event where event like 'log file switch (check%'; |
通过total_waits，time_waited，average_wait这些数值的大小来判断分析问题，如果还不能确定，那么可以查看一下Oracle的alert.log文件看一下相关时间内是否存在“checkpoint not complete”。如果存在那么证明日志文件的操作性能被DBWR进程所拖累。此时可以通过如下措施解决：
● 检查存放数据文件的磁盘是否存在I/O瓶颈（如：是否存在读写竞争、是否存在物理损坏、是否存在RADI类型不符等）；
● 合理规划调整日志文件组日志文件的数量和大小；
● 合理设置FAST_START_MTTR_TARGET参数，以便设置一个合适的数值来控制检查点的发生；
● 可以考虑增加DBWR进程的数量，Oracle最多可以有10个DBWR进程；
● 如果条件允许，可以开启异步I/O；
3、由于日志归档引发的等待：
当归档发生时，归档日志进程不能快速的进行日志归档，从而导致了LGWR的等待。如果怀由此问题可以通过如下语句来监控：
| select event,total_waits,time_waited,average_wait from v$system_event where event like 'log file switch (arch%'; |
同样通过total_waits，time_waited，average_wait这些数值来进行问题分析，如果出现由于归档日志写入缓慢引发的性能问题，可以采用如下办法：
● 确定存放归档日志的磁盘空间没有被写满，如果出现这种情况，那么要对归档日志进行有限度的删除，或者将这些归档日志移走如存放到磁带库上，或者分配更大的存储空间；
● 增加日志文件组，从而为归档多留出一些时间；
● 增加多个归档进程，Oracle最多允许10个归档进程存在，在归档发生时如果LGWR进程发现归档进程ARCH出现不足时，会自动产生新的归档进程，因此如果系统负载有明显增加预先分配足够的归档进程可以提高性能，可以使用alter system命令通过更改LOG_ARCHIVE_MAX_PROCESSES参数来改变归档进程数目；
（2）日志缓冲区数据槽的分配情况引发的等待：
可以通过如下的语句来监控日志缓冲区数据槽的分配情况的百分比：
| select r.value "retries",e.value "entries",r.value/e.value*100 "percentage" from v$sysstat t,v$sysstat e where r.name='redo buffer allocation retries' and e.name='redo entries'; |
这个百分比值不能高于1%，如果这个数值频繁增长，那么一定出现了Log_Buffer内存空间不足，从而使得新产生的redo log entries不能写入Log_Buffer中从而造成等待，这个等待是由于LGWR性能不佳写日志文件过慢造成的，通常来说LGWR写入速度都是非常快速的可以保证新产生的redo log entries内存空间使用的需要，即使在高负载情况下也不会出现太大问题，因而上面的问题通常发生机率较小，但是如果一旦发生，那么很有可能是由于日志文件磁盘I/O规划出现问题，或者日志文件磁盘出现物理损坏，因此在出现这种情况引发的性能问题时，主要应该进行日志文件磁盘I/O规划以及日志文件磁盘是否出现物理损伤方面的排查，同时也可能综合应用如Oracle的alert.log等相关文件进行综合分析。
