Multiplexing Redo Logs Onto Raid

I have a situation where I would like to multiplex the redo logs but the other drive on which to multiplex is a raid. I have heard that putting redo logs on raids is bad. Is it better in this situation just not multiplexing? Or should I just go ahead and put the redo logs on the raid?


raid 1 --- reading and writing fast
raid 5 --- reading fast but writing slow

If your log groups are not on raid you must multiplex them.If they r on raid 1 no need to multiplex as it is already mirrored by raid 1


How about on Raid 5?


On raid 5 too mirroring is done but compressed (with parity bits), better you have a multiplexed log


RAID 0 - Striping. Fast access to disks
RAID 1 - Mirror, you have only half of the total space, ecause the other half is the mirror.

This are the two RAID levels (0+1) recomended to use with Oracle. RAID 5 is slower. Remember that redologs and archivelogs, are two components that typically include a great contention in I/O operations. So that, it is recomended to put that type of files in fast and separated storage device.


Whats the difference or relationship between Oracle undo tablespace and redo logs?


UNDO tablespace stores the before image of the data blocks, so the rest of the users can see consistent data before the user modifying the data commits its changes.

The redo logs on the other side store the already commited data and are used for instance recovery. When an instance recovery is required, Oracle first rolls the data forward (reading the commited transactions from the redo logs) , then rolls backward and rolls the uncommited transactions, so the database is in consistent state.


It's in the concepts book. A simple answer could be:

Rollback segments are used to rollback or "undo" transactions. They're also used to provide read consistency. I believe they contain both the before and after images of all changes made during a transaction. They also can be overwritten after the transaction completes (commit or rollback).

Redo logs are used for recovery. They're essentially a sequential, chronological, history of all changes made to the database. For example if you need to restore an old version a datafile, redo logs(both archived and online) are used to bring the restored datafile back in sync with the database.


It might help to think of rollback as "Undo". Rollback remembers all the changes made to a database during a transaction. If the transaction fails or if you decide it wasn't what you wanted to do, you (or Oracle itself) can "Undo" the changes and revert to the original data in the database.

Redo, as it's name suggests, allows Oracle to roll forward and re-apply changes that may have been lost, for instance in the event of a database crash. When the instance starts up, Oracle checks the "age" of the data files against the control file and, if it finds a datafile is out of date, applies the redo (if available!) to bring it in line with the control file. If necessary it can then roll back any transactions which were incomplete at the time of the crash.

I'm sure you'll get lots more technical explanations, but that's the gist of it. Have a look at the Server Administrators Guide more information.


The redo logs are used to redo or do over things that have been entered into the database, and the rollback segments are used to undo things that have been 'entered' into the database.

Lets say you have a transaction that affects 1 million rows, all of the changes will be stored as both redo and undo. Now lets say that you type commit, now everything in the log buffer will be written to your online redo log files and your rollback segments will no longer hold the extents that held this transaction.Now you have a disk failure.you will apply the redo to redo (do over) that transaction.

Next example:
Same transaction, but right before you type commit there is a power surge and your session just dies or you type rollback. Now all the changes that you made (before commiting) will be rolled back and undone.