RE: redo logs in noarchivelog mode
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 28 Mar 2012 12:20:12 -0400
Excellent summary Hans. The only thing I would add is the answer to the OP's
unstated question that I suspect is lurking:
How frequently is the changed information recorded in the redo logs sooner
than it is written to the database files?
Answer: at least almost always.
A key point being that getting stuff into the redo log allows the dbwr
function is be efficiently lazy about how quickly it gets an individual
block change to the dbfiles in favor of getting batches of changes to the
dbfiles at higher throughput and lower contention.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Hans Forbrich
Sent: Wednesday, March 28, 2012 11:31 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: redo logs in noarchivelog mode
Redo logs are mainly used for 'online recovery'. (Ignoring Log Miner and
other uses.)
Common misconception is that the redo is only written at commit. In fact,
it is written pretty much when it is generated (at worst within 3 seconds),
so a lot of state information is continuously available. (Not counting
exceptions.) Often forgotten is that it includes the changes to the
undo/rollback information as well.
If the database crashes for any reason, on restart the system will look for
the last known stable state of each file and apply any redo since that time,
if it s available, and then rolling back any uncommitted transactions at the
time of failure. Thus it brings the database back to a stable state.
The redo logs are used as a kind of circular 'buffer' - assign several
[relatively small] files to be used as log files, write to one log file,
close it off and switch to the 'next' one, rinse and repeat until all of the
preassigned files are used and then go back to the first one.
Multiplex these files for safety (multiplex = software controlled mirroring,
slightly safer than hardware mirroring)
Archiving adds the ability to take that redo from 'online' to 'nearline'
(on a separate disk or machine) or 'offline' (tape, offsite, etc.) but the
recovery process stays pretty much the same - go back to a stable image of
the database from before the crash, apply all the redo - even if that means
getting near/off-line logs) and then rollback uncommitted transactions.
Note that if you have a small database (small is a relative term - non-SAN
disk is cheap, so a couple 10's of GB) and if you have sufficient redo
groups to keep all the online redo logs with overwriting since the last
complete backup, you can simulate complete point in time recovery without
needing archive logs. Shutdown the database, make a complete copy of all
database and a *separate* redo log files. Just make sure you understand the
context of the redo log files - they can ONLY be restored long with the
*previous* day's data files, or you will clobber the recovery.
HTH
/Hans
On 28/03/2012 8:37 AM, Richard, Carmelinda wrote:
> This may be a stupid question, but I was installing a new database for the
first time, and I started wondering, what is the useful purpose of redo logs
if a database is in noarchivelog mode? Only if the database crashes and
transactions were written to the redo logs before they make it into the
database files?
>
> Thanks,
> Carmelinda
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
