RE: redo logs in noarchivelog mode

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 28 Mar 2012 12:20:12 -0400
Message-ID: <01cb01cd0cfe$a772d680$f6588380$_at_rsiz.com>

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hans Forbrich
Sent: Wednesday, March 28, 2012 11:31 AM To: oracle-l_at_freelists.org
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
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l

Received on Wed Mar 28 2012 - 11:20:12 CDT