To avoid that, it is essential to multiplex the redo log files, such that each online redo log group are copies of each other and are entirely maintained by Oracle. Each member of a redo group should be on divide disks or controllers. Striping them across multiple disks is not very beneficial from a performance viewpoint, since redo writes are sequential. That is not striping the redo-logs is not a guarantee of being able to write sequentially to them, since the read/write head may still have to move back and forth to perform I/O on other files resident on the same disks. However, it certainly increases the possibilities of sequential writes, and thus higher throughput. Also, note that certain systems can parallelize even sequential writes, under specific situations.
In such cases, striping the redo logs may achieve the same throughput. However, striping may alleviate disk hot spots if they are examined due to heavy writes being done to the online redo logs in certain environments. But again, as stated earlier, striping without mirroring would spread each online redo file across multiple disks, thus increasing the points of failure. Multiplexing of the redo-group within Oracle is preferred to hardware and software mirroring in case both cannot be utilized. With multiplexing, Oracle continues to run even if just one member in each redo-group is available and the rest are corrupt. In the case of hardware and software mirroring, however, Oracle would stop running if the primary file becomes corrupt, even with the mirror still valid. Furthermore, Oracle multiplexing protects from administrative accidents such as a system administrator accidently removing file, whereas hardware and software mirroring may not.
Before, during, and after backups, periodically monitoring the online redo-group is advisable to watch for any logs acquiring the STALE or INVALID status. An online redo log can become STALE if writes to that log are pending due to the log being temporary unavailable, such as when a shutdown ABORT is issued just prior to a write. A redo log may become INVALID if there is any file corruption due to hardware errors, and so on. Both situations can be monitored via the status column in the dynamic view V$LOGFILE or from alert-log file.
Dbametrix offers solid performance tuning and disaster recovery deployment in remote database services in affordable rate and prompt response time. For more information kindly check following website. http://www.dbametrix.com