View source for Redo log

{{Multiple issues|
{{refimprove|date=January 2014}}
{{notability|date=January 2014}}
}}
In the [[Oracle database|Oracle]] [[RDBMS]] environment, '''redo logs''' comprise files in a proprietary format which log a history of all changes made to the [[database]]. Each redo log file consists of redo records. A redo record, also called a redo entry, holds a group of [[change vector]]s, each of which describes or represents a change made to a  single block in the database.
For example, if a user <code>UPDATE</code>s a salary-value in a table containing employee-related data, the [[DBMS]] generates a redo record containing change-vectors that describe changes to the data segment block for the table. And if the user then <code>COMMIT</code>s the update, Oracle generates another redo record and assigns the change a "system change number" (SCN).
Whenever something changes in a datafile, Oracle records the change in the redo log. The name ''redo log'' indicates its purpose: If the database crashes, the RDBMS can redo (re-process) all changes on datafiles which will take the database data back to the state it was when the last redo record was written. DBAs use the views <code>V$LOG</code>, <code>V$LOGFILE</code>, <code>V$LOG_HISTORY</code> and <code>V$THREAD</code> to find information about the redo log of the database. Each redo log file belongs to exactly one group (of which at least two must exist). Exactly one of these groups is the CURRENT group (can be queried using the column status of v$log). Oracle uses that current group to write the redo log entries. When the group is full, a '''log switch''' occurs, making another group the current one. Each log switch causes checkpoint, however, the converse is not true: a checkpoint does not cause a redo log switch. One can also manually cause a redo-log switch using the <code>ALTER SYSTEM SWITCH LOGFILE</code> command.
== Classification ==
Redo log files occur in two types:<ref>
{{cite book
|last1= Kyte
|first1= Thomas
|last2= Kuhn
|first2= Darl
|title= Expert Oracle Database Architecture
|url= https://books.google.com/books?id=3_RUBQAAQBAJ
|series= Expert's voice in Oracle
|edition= 3
|publisher= Apress
|publication-date= 2014
|page= 9
|isbn= 9781430262992
|accessdate= 2015-02-19
|quote= I've referred to two types of redo log file: online and archived.
|date= 2014-11-10
}}
</ref>
* online redo logs ("'''ORL'''"<ref>
{{cite book
|last1= Bach
|first1= Martin
|author-link1=
|title= Expert Consolidation in Oracle Database 12c
|url= https://books.google.com/books?id=CO9ZAgAAQBAJ
|series= SpringerLink : Bücher
|publisher= Apress
|publication-date= 2013
|page= 318
|isbn= 9781430244288
|accessdate= 2015-07-12
|quote= Standby redo logs (SRL) on the disaster recovery site act as the counterpart to the primary database's online redo logs (ORL) and allow the remote site to receive redo more efficiently.
|date= 2013-11-23
}}
</ref> or "'''redo logs'''"<ref>
{{cite web
| url            = http://docs.oracle.com/cd/B19306_01/server.102/b14231/onlineredo.htm
| title          = Oracle Database Administrator's Guide, 10g Release 2 (10.2)
| last1          = Fogel
| first1         = Steve
| date           = May 2006
| website        = docs.oracle.com
| publisher      = Oracle
| access-date    = 2015-02-19
| quote          = The current redo log is always online, unlike archived copies of a redo log. Therefore, the online redo log is usually referred to as simply the redo log.
}}
</ref>  for short)
* archived redo logs ("'''archive logs'''")<ref>
{{cite book
|last1= Ries
|first1= Steve
|title= Oca Oracle Database 11g Database Administration I: A Real-World Certification Guide
|url= https://books.google.com/books?id=vV2DcGvT-RcC
|publisher= Packt Publishing Ltd
|publication-date= 2013
|isbn= 9781849687317
|accessdate= 2015-02-19
|quote= [...] when a log switch occurs, the contents of the current redo log are written out to an archived redo log by the ARCn process. These logs are also referred to as offline redo logs or simply archive logs.
|date= 2013-02-22
}}
</ref>
== Usage ==
Before a user receives a "{{mono|Commit complete}}" message, the system must first successfully write the new or changed data to a redo log file.
The RDBMS first writes all changes included in the transaction into the log buffer in the [[System Global Area]] (SGA). Using [[primary memory | memory]] in this way for the initial capture aims to reduce disk IO. Of course, when a transaction commits, the redo log buffer must be flushed to disk, because otherwise the recovery for that commit could not be guaranteed. The LGWR (Log Writer) process does that flushing.
Having a redo log makes it possible to replay SQL statements. Before an Oracle database changes data in a datafile it writes changes to the redo log. If something happens to one of the datafiles, a recovery procedure can restore a backed-up datafile and then replay the redo written since backup-time; this brings the datafile to the state it had before it became unavailable. Standby databases in an [[Oracle Data Guard]] environment use the same technique: one database (the primary database) records all changes and sends them to the standby database(s). Each standby database applies (replays) the arrived redo, resulting in  synchronization with the primary database.<ref>
{{cite book
|last1= Liu
|first1= Henry H.
|author-link1=
|title= Oracle Database Performance and Scalability: A Quantitative Approach
|url= https://books.google.com/books?id=2QspR4VZYboC
|series= Quantitative Software Engineering Series
|volume= 12
|publisher= John Wiley & Sons
|publication-date= 2011
|pages= 238–239
|isbn= 9781118056998
|accessdate= 2015-02-19
|quote= Primary and physical standby databases are synchronized through a service called ''Redo Apply'', which recovers the redo data from the primary database and applies the redo to the standby database. [...] Synchronization between the primary and [logical] standby databases is achieved through a service named SQL Apply, which transforms the redo data from the primary database into SQL statements and then executes the SQL statements on the standby database.
|date= 2011-11-22
}}
</ref>
If a database crashes, the [[data recovery|recovery]] process has to apply all transactions, both uncommitted as well as committed, to the data-files on disk, using the information in the redo log files. Oracle must re-do all redo-log transactions that have both a <code>BEGIN</code> and a <code>COMMIT</code> entry (roll forward), and it must undo all transactions that have a <code>BEGIN</code> entry but no <code>COMMIT</code> entry (roll back).<ref>
{{cite book
|last1= Greenwald
|first1= Rick
|last2= Stackowiak
|first2= Robert
|last3= Stern
|first3= Jonathan
|title= Oracle Essentials: Oracle Database 12c
|url= https://books.google.com/books?id=oSKwAAAAQBAJ
|edition= 5
|publisher= O'Reilly Media, Inc.
|publication-date= 2013
|isbn= 9781449343170
|accessdate= 2015-02-19
|quote= Instance recovery has two phases: roll forward and roll back.
|date= 2013-09-06
}}
</ref> (Re-doing a transaction in this context simply means applying the information in the redo log files to the database; the system does not re-run the transaction itself.) The system thus re-creates committed transactions by applying the “after image” records in the redo log files to the database, and undoes incomplete transactions by using the "before image" records in the undo [[tablespace]].
[[Change data capture]] can read the redo logs.
In Oracle Data Guard configurations, '''standby redo logs''' resemble their equivalent online redo logs, but serve to store redo data transmitted from a different database.<ref>
{{cite web
| url            = http://docs.oracle.com/cd/B19306_01/server.102/b14239/standby.htm#i72373
| title          = Oracle Data Guard: Concepts and Administration: 10g Release 2 (10.2)
| last1          = Schupmann
| first1         = Vivian
| author-link1   =
| year           = 2008
| publisher      = Oracle
| access-date    = 2015-02-19
| quote          = A standby redo log is similar to an online redo log, except that a standby redo log is used to store redo data received from another database.
}}
</ref>
== Implications ==
Given the verbosity of the logging, [[Oracle Corporation]] provides methods for archiving redo logs (archive-logs), and this in turn can feed into data-backup scenarios and [[Oracle Data Guard|standby databases]].
The existence of a detailed series of individually logged transactions and actions provides the basis of several data-management enhancements such as [[Oracle Flashback]], [[Oracle LogMiner|log-mining]] and [[point-in-time recovery]]. The concept of a database incarnation<ref>
{{cite book
|last1= Bach
|first1= Martin
|title= Expert Consolidation in Oracle Database 12c
|url= https://books.google.com/books?id=CO9ZAgAAQBAJ
|series= SpringerLink : Bücher
|publisher= Apress
|publication-date= 2013
|page= 378
|isbn= 9781430244288
|accessdate= 2015-02-04
|quote= An incarnation as per the Oracle documentation is a separate version of the database.
|date= 2013-11-23
}}
</ref>
can influence the use of redo in database recovery.
For [[database tuning]] purposes, efficiently coping with redo logs requires plentiful and fast-access disk.
==See also==
*[[Transaction log]]
== References ==
{{Reflist}}
== External links ==
* [http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/onlineredo.htm Managing the Redo Log] (Oracle documentation)
[[Category:Oracle software]]
[[Category:Transaction processing]]