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.
Quick Links:
Do you have
an Oracle Question?
Best regards,
Oracle Database, SQL,
Application, Programming Tips
All the site contents are Copyright © www.erpgreat.com
and the content authors. All rights reserved.
All product names are trademarks of their respective
companies.
The site www.erpgreat.com is not affiliated with or endorsed
by any company listed at this site.
Every effort is made to ensure the content integrity.
Information used on this site is at your own risk.
The content on this site may not be reproduced
or redistributed without the express written permission of
www.erpgreat.com or the content authors.