Striping and Mirroring of Online Redo Logs in Oracle Database

July 5, 2012 - PRLog -- Online redo-logs are important components during instance recovery and in definite circumstances, during media recovery. The online redo-logs include the redo records to roll the database forward. The redo records contain undo or rollback detail for transactions in the database. This rollback information will be utilized to roll back uncommitted transactions at the end of the recovery occurrence. In past version of Oracle, each of the online redo-logs files is utilized to symbolize a single point of failure. The loss of an online redo-log results in an outage.

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.

http://www.dbametrix.com/remote-dba.html

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