Oracle'sRedoLog

Oracle'sRedoLog
		Each Oracle<wbr></wbr>database<wbr></wbr>has a redo log. This redo log records all changes made in<wbr></wbr>datafiles. Purpose The redo log makes it possible to replay<wbr></wbr>SQL statements. Before Oracle changes data in a<wbr></wbr>datafile<wbr></wbr>it writes these changes to the redo log. If something happens to one of the datafiles, a backed up datafile can be restored and the redo, that was written since, replied, which brings the datafile to the state it had before it became unavailable. The same technique is also used in a<wbr></wbr>data guard environment(standby databases): One database (the<wbr></wbr>primary database) records all changes and<wbr></wbr>sends<wbr></wbr>them to the standby databases. These standby databases in turn apply (reply) the arrived redo which keeps the synchronized with the primary database. Archive Log vs Noarchive Log As Oracle rotates through its redo log groups, it will eventually overwrite a group which it has already written to. Data that is being overwriten would of course be useless for a recovery scenario. In order to prevent that, a database can (and for production databases<wbr></wbr>should) be run in archive log mode. Simply stated, in archive log mode, Oracle makes sure that online redo log files are not overwritten unless they have been savely archived somewhere. A database can only be recoverd from<wbr></wbr>media failure<wbr></wbr>if it runs under archive log. See also<wbr></wbr>Archive vs Noarchive Log Mode LGWR<wbr></wbr>writes the redo log buffers to disk. The background process in charge for archiving redo logs isARCn<wbr></wbr>(if automatic archiving is enabled.) In order to find out in which mode the instance runs, one can use<wbr></wbr>archive log list<wbr></wbr>from within sql plus. Log Buffer All changes that are covered by redo is first written into the<wbr></wbr>log buffer. The idea to first store it in the memory is to reduce disk IO. Of course, when a<wbr></wbr>transaction<wbr></wbr>commits, the redo log buffer must be flushed to disk, because otherwise the recovery for that commit could not be guaranteed. It is<wbr></wbr>LGWR (Log Writer)that does that flushing. Determining amount of generated redo log select <wbr></wbr> n.name, t.value from <wbr></wbr> v$mystat<wbr><wbr></wbr></wbr> t join <wbr></wbr> v$statname n on <wbr></wbr> t.statistic# = n.statistic# where <wbr></wbr> n.name = 'redo size'; See also the package<wbr></wbr>redo_diff RBA (Redo Byte Address) The RBA consists of three parts and is ten bytes long: · Log sequence number · Block number within this sequence · Offset within this block The location of each redo log entry is identified throuhg an RBA. The RBAs are important for dirty<wbr></wbr>db blocks<wbr></wbr>in the buffer cache. Log sequence number Whenever Oracle (or more precisely, the<wbr></wbr>log writer<wbr></wbr>process) writes to another<wbr></wbr>online redo log file group<wbr></wbr>(also referred to aslog switch), the<wbr></wbr>log sequence<wbr></wbr>number increments by one. If the database is opened with<wbr></wbr>reset logs, the log sequence number is reset to 1. Determining optimal redo log size The optimal size of redo log files can be queried with select optimal_logfile_size from v$instance_recovery; Misc See also<wbr></wbr>managed standby databases. ASM<wbr></wbr>simplifies the optimal layout of redo log files. Minimizing generation of redo For a few operations, it is possible to minimize the generation of redo if the<wbr></wbr>nologging option<wbr></wbr>is set. Redo transport services Redo transport services<wbr></wbr>transport redo data from one server to another. Notes Redo is totally different from<wbr></wbr>undo<wbr></wbr>(rollback). Thanks Thanks to<wbr></wbr>Seghir Souidi<wbr></wbr>and<wbr></wbr>Hubert Savio<wbr></wbr>who helped improve this page.

<wbr></wbr>